Network Buses

Contents
1 List of network buses 1
1.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 RS-232 2
2.1 Scope of the standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Limitations of the standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Role in modern personal computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.5 Standard details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5.1 Voltage levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5.2 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.3 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.4 Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6.1 RTS/CTS handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6.2 3-wire and 5-wire RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Seldom used features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7.1 Signal rate selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7.2 Loopback testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7.3 Timing signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7.4 Secondary channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.8 Related standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.9 Development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Serial port 9
3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 DTE and DCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Pinouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Hardware abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
i
ii CONTENTS
3.2 Common applications for serial ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Data bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3 Parity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.4 Stop bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.5 Conventional notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.6 Flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Virtual serial ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 RS-485 15
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Standard scope and denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Master-slave arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Three-wire connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Full duplex operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7.1 Pin labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.8 Waveform example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.9 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.11 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 RS-422 19
5.1 Standard scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Probus 21
6.1 Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.2 Security layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.3 Bit-transmission layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3 Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CONTENTS iii
6.4 Standardisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.5 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7 Fieldbus 24
7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.1 Bitbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.2 Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3 IEC 61158 specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.5 Cost advantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.8 Process Fieldbus vs. Device Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.9 Ethernet and Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.10 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.11 Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.12 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.13 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.14 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.15 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.16 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8 CAN bus 29
8.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.1 Automotive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.2 Industrial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.3 Data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.4 ID allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.5 Bit timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.6 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.7 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.7.1 Data frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.7.2 Remote frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.7.3 Error frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.7.4 Overload frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.8 Interframe spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.9 Bit stung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iv CONTENTS
8.10 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.11 Higher layer implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.12 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.13 Development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.14 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.15 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.16 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.17 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9 Ethernet 37
9.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2 Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.3 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.3.1 Shared media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.3.2 Repeaters and hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.3.3 Bridging and switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.3.4 Advanced networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.4 Varieties of Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.5 Layer 2 Datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.6 Autonegotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.10 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.11 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10 Ethernet physical layer 45
10.1 Physical layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.1 Xerox experimental Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.2 Early implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.3 Fast Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.4 1 Gbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.5 10 Gbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.6 25 and 50 Gbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.7 40 and 100 Gbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.2 Terabit and beyond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.3 First mile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.4 Twisted-pair cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.5 Minimum cable lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.6 Related standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CONTENTS v
11 Ethernet frame 48
11.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.1 Preamble and start frame delimiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.2 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.3 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1.4 Frame check sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1.5 End of frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1.6 Interpacket gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.2 Ethernet frame types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.2.1 Ethernet II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.2.2 Novell raw IEEE 802.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.2.3 IEEE 802.2 LLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.2.4 IEEE 802.2 SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.3 Maximum throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.4 Runt frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.7 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12 Autonegotiation 53
12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.2 Electrical signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.3 The base link code word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.4 Message and unformatted next page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.5 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.6 Interoperability problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.7 Duplex mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.8 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.9 Patents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.10See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.11References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.12External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13 Internet protocol suite 57
13.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1.1 Early research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1.2 Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.1.3 Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.2 Key architectural principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.3 Abstraction layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
13.3.1 Link layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
13.3.2 Internet layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
vi CONTENTS
13.3.3 Transport layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.3.4 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.4 Layer names and number of layers in the literature . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.5 Comparison of TCP/IP and OSI layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.6 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.9 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.10External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
14 IPv4 65
14.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1.1 Address representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1.2 Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1.3 Special-use addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.1.4 Link-local addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.1.5 Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.1.6 Addresses ending in 0 or 255 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.1.7 Address resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.2 Address space exhaustion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.3 Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.3.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
14.3.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.4 Fragmentation and reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.4.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14.4.2 Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14.5 Assistive protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.7 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.10Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
15 IP address 72
15.1 IP versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1.1 IPv4 addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1.2 IPv4 address exhaustion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.1.3 IPv6 addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.2 IP subnetworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
15.3 IP address assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
15.3.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
15.3.2 Uses of dynamic address assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CONTENTS vii
15.3.3 Address autoconguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.3.4 Uses of static addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.4 IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.5 Public addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.6 Modications to IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.6.1 IP blocking and rewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.6.2 IP address translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.7 Diagnostic tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.10External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
16 Transmission Control Protocol 78
16.1 Historical origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
16.2 Network function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
16.3 TCP segment structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
16.4 Protocol operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
16.4.1 Connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
16.4.2 Connection termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
16.4.3 Resource usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
16.4.4 Data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
16.4.5 Maximum segment size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
16.4.6 Selective acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
16.4.7 Window scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
16.4.8 TCP timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.4.9 Out-of-band data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.4.10 Forcing data delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.5 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.5.1 Denial of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.5.2 Connection hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
16.5.3 TCP veto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
16.6 TCP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
16.7 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
16.8 TCP over wireless networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
16.9 Hardware implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
16.10Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
16.11Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
16.12Checksum computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
16.12.1 TCP checksum for IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
16.12.2 TCP checksum for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
16.12.3 Checksum ooad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
16.13See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
viii CONTENTS
16.14References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
16.15Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
16.16External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
16.16.1 RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
16.16.2 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
17 User Datagram Protocol 92
17.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
17.2 Service ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
17.3 Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
17.4 Checksum computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
17.4.1 IPv4 Pseudo Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
17.4.2 IPv6 Pseudo Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
17.5 Reliability and congestion control solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
17.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
17.7 Comparison of UDP and TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
17.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
17.9 Notes and references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
17.9.1 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
17.9.2 RFC references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
17.10External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
18 Internet Control Message Protocol 96
18.1 Technical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
18.2 ICMP segment structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
18.2.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
18.2.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
18.3 Control messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
18.3.1 Source quench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
18.3.2 Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
18.3.3 Time exceeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
18.3.4 Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
18.3.5 Timestamp reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
18.3.6 Address mask request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
18.3.7 Address mask reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
18.3.8 Destination unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
18.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
18.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
18.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
19 Internet Group Management Protocol 100
19.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
CONTENTS ix
19.2 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
19.3 Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
19.3.1 IGMPv2 messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19.3.2 IGMPv3 membership query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19.4 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
19.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
20 Industrial Ethernet 102
20.1 Application environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
20.2 Advantages and diculties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
20.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
20.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
20.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
21 PROFINET 104
21.1 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
21.2 Component model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
21.3 Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
21.4 IO addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
21.5 Real time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
21.6 Isochronous communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
21.7 Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
21.8 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
21.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
21.10Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
21.11External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
21.12Text and image sources, contributors, and licenses . . . . . . . . . . . . . . . . . . . . . . . . . . 107
21.12.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
21.12.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
21.12.3 Content license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Chapter 1
List of network buses
List of electrical characteristics of single collision domain
segment slow speed network buses:
The number of nodes can be limited by either number
of available addresses or bus capacitance. None of the
above use any analog domain modulation techniques like
MLT-3 encoding, PAM-5 etc.
PSI5 designed with automation applications in mind is a
bit unusual in that it uses Manchester code.
1.1 See also
Characteristic impedance
Category 5 cable
Telegraphers equations
Single ended
Network segment
CEBus
KNX (standard) (EIB)
1.2 References
[1] Microcontroller Interfaces, Part 3. 090114 ucpros.com
[2] Ujjals DMX512 Pages....DMX512 Physical properties.
090610 dmx512-online.com
[3] LanBox-LC FAQ, DMX FAQ and Specications.
090610 lanbox.com
1.3 External links
bipom.com - Micro interfacing.pdf
1
Chapter 2
RS-232
This article is about the RS-232 standard. For RS-232
variants, see serial port.
V.24 redirects here. For other uses, see V24 (disam-
biguation).
In telecommunications, RS-232 is a standard for serial
A DB25 connector as described in the RS-232 standard
communication transmission of data. It formally de-
nes the signals connecting between a DTE (data terminal
equipment) such as a computer terminal, and a DCE (data
circuit-terminating equipment, originally dened as data
communication equipment
[1]
), such as a modem. The
RS-232 standard is commonly used in computer serial
ports. The standard denes the electrical characteristics
and timing of signals, the meaning of signals, and the
physical size and pinout of connectors. The current ver-
sion of the standard is TIA-232-F Interface Between Data
Terminal Equipment and Data Circuit-Terminating Equip-
ment Employing Serial Binary Data Interchange, issued in
1997.
An RS-232 serial port was once a standard feature of
a personal computer, used for connections to modems,
printers, mice, data storage, uninterruptible power sup-
plies, and other peripheral devices. However, RS-232 is
hampered by lowtransmission speed, large voltage swing,
and large standard connectors. In modern personal com-
puters, USB has displaced RS-232 from most of its pe-
ripheral interface roles. Many computers do not come
equipped with RS-232 ports and must use either an ex-
ternal USB-to-RS-232 converter or an internal expansion
card with one or more serial ports to connect to RS-232
peripherals. RS-232 devices are widely used, especially
in industrial machines, networking equipment and scien-
tic instruments.
2.1 Scope of the standard
The Electronic Industries Association (EIA) standard RS-
232-C
[1]
as of 1969 denes:
Electrical signal characteristics such as voltage lev-
els, signaling rate, timing and slew-rate of signals,
voltage withstand level, short-circuit behavior, and
maximum load capacitance.
Interface mechanical characteristics, pluggable con-
nectors and pin identication.
Functions of each circuit in the interface connector.
Standard subsets of interface circuits for selected
telecom applications.
The standard does not dene such elements as the
character encoding or the framing of characters, or error
detection protocols. The character format and transmis-
sion bit rate are set by the serial port hardware which may
also contain circuits to convert the internal logic levels to
RS-232 compatible signal levels. The standard does not
dene bit rates for transmission, except that it says it is
intended for bit rates lower than 20,000 bits per second.
2.2 History
RS-232 was rst introduced in 1962 by the Radio Sector
of the EIA.
[2][3]
The original DTEs were electromechan-
ical teletypewriters, and the original DCEs were (usually)
modems. When electronic terminals (smart and dumb)
began to be used, they were often designed to be inter-
changeable with teletypewriters, and so supported RS-
232. The C revision of the standard was issued in 1969
in part to accommodate the electrical characteristics of
these devices.
Since the requirements of devices such as computers,
printers, test instruments, POS terminals and so on were
not foreseen by the standard, designers implementing an
RS-232 compatible interface on their equipment often
interpreted the standard idiosyncratically. The resulting
common problems were non-standard pin assignment of
2
2.4. ROLE IN MODERN PERSONAL COMPUTERS 3
circuits on connectors, and incorrect or missing control
signals. The lack of adherence to the standards produced
a thriving industry of breakout boxes, patch boxes, test
equipment, books, and other aids for the connection of
disparate equipment. Acommon deviation fromthe stan-
dard was to drive the signals at a reduced voltage. Some
manufacturers therefore built transmitters that supplied
+5 V and 5 V and labeled them as RS-232 compati-
ble.
Later personal computers (and other devices) started to
make use of the standard so that they could connect to ex-
isting equipment. For many years, an RS-232-compatible
port was a standard feature for serial communications,
such as modem connections, on many computers. It re-
mained in widespread use into the late 1990s. In personal
computer peripherals, it has largely been supplanted by
other interface standards, such as USB. RS-232 is still
used to connect older designs of peripherals, industrial
equipment (such as PLCs), console ports and special pur-
pose equipment.
The standard has been renamed several times during its
history as the sponsoring organization changed its name,
and has been variously known as EIA RS-232, EIA 232,
and most recently as TIA 232. The standard continued to
be revised and updated by the Electronic Industries Al-
liance and since 1988 by the Telecommunications Indus-
try Association (TIA).
[4]
Revision Cwas issued in a docu-
ment dated August 1969. Revision D was issued in 1986.
The current revision is TIA-232-F Interface Between Data
Terminal Equipment and Data Circuit-Terminating Equip-
ment Employing Serial Binary Data Interchange, issued
in 1997. Changes since Revision C have been in timing
and details intended to improve harmonization with the
CCITT standard V.24, but equipment built to the current
standard will interoperate with older versions.
Related ITU-T standards include V.24 (circuit identica-
tion) and V.28 (signal voltage and timing characteristics).
In revision D of EIA-232, the D-subminiature connector
was formally included as part of the standard (it was only
referenced in the appendix of RS 232 C). The voltage
range was extended to +/- 25 volts, and the circuit capac-
itance limit was expressly stated as 2500 pF. Revision E
of EIA 232 introduced a new, smaller, standard D-shell
26-pin Alt A connector, and made other changes to im-
prove compatibility with CCITT standards V.24, V.28
and ISO 2110.
[5]
2.3 Limitations of the standard
Because RS-232 is used beyond the original purpose of
interconnecting a terminal with a modem, successor stan-
dards have been developed to address the limitations. Is-
sues with the RS-232 standard include:
[6]
The large voltage swings and requirement for posi-
tive and negative supplies increases power consump-
tion of the interface and complicates power supply
design. The voltage swing requirement also limits
the upper speed of a compatible interface.
Single-ended signaling referred to a common signal
ground limits the noise immunity and transmission
distance.
Multi-drop connection among more than two de-
vices is not dened. While multi-drop work-
arounds have been devised, they have limitations
in speed and compatibility.
Asymmetrical denitions of the two ends of the
link make the assignment of the role of a newly de-
veloped device problematic; the designer must de-
cide on either a DTE-like or DCE-like interface and
which connector pin assignments to use.
The handshaking and control lines of the interface
are intended for the setup and takedown of a dial-
up communication circuit; in particular, the use of
handshake lines for ow control is not reliably im-
plemented in many devices.
No method is specied for sending power to a de-
vice. While a small amount of current can be ex-
tracted from the DTR and RTS lines, this is only
suitable for low power devices such as mice.
The 25-way connector recommended in the stan-
dard is large compared to current practice.
The standard does not address the possibility of con-
necting a DTE directly to a DTE, or a DCE to a
DCE.
2.4 Role in modern personal com-
puters
Main article: Serial port
In the book PC 97 Hardware Design Guide,
[7]
Microsoft
deprecated support for the RS-232 compatible serial port
of the original IBMPCdesign. Today, RS-232 has mostly
been replaced in personal computers by USB for local
communications. Compared with RS-232, USB is faster,
uses lower voltages, and has connectors that are simpler
to connect and use. However, USB is limited by standard
to no more than 5 meters of cable, thus favoring RS-232
when longer distances are needed. Both standards have
software support in popular operating systems.
USBis designed to make it easy for device drivers to com-
municate with hardware. USB is more complex than the
RS-232 standard because it includes a protocol for trans-
ferring data to devices. This requires more software to
support the protocol used. There is no direct analog to
4 CHAPTER 2. RS-232
PCI Express x1 card with one RS-232 port
the terminal programs used to let users communicate di-
rectly with serial ports.
Serial ports of personal computers are also sometimes
used to directly control various hardware devices, such
as relays or lamps. Personal computers may use a serial
port to interface to devices such as uninterruptible power
supplies. In some cases, serial data is not exchanged, but
the control lines are used to signal conditions such as loss
of power or low battery alarms. An application program
can detect or change the state of RS 232 control lines
in the registers of the serial hardware using only a few
input/output instructions; by contrast, a USB interface re-
quires software to decode the serial data.
Devices that convert between USB and RS-232 do not
work with all software or on all personal computers.
In elds such as laboratory automation or surveying, RS
232 devices may continue to be used. PLCs, VFDs, servo
drives, and CNC equipment are programmable via RS-
232. Some manufacturers have responded to this de-
mand: Toshiba re-introduced the DE-9M connector on
the Tecra laptop.
Serial ports with RS-232 are also commonly used to
communicate to headless systems such as servers, where
no monitor or keyboard is installed, during boot when
operating system is not running yet and therefore no net-
work connection is possible. An RS-232 serial port can
communicate to some embedded systems such as routers
as an alternative to network mode of monitoring.
2.5 Standard details
In RS-232, user data is sent as a time-series of bits.
Both synchronous and asynchronous transmissions are
supported by the standard. In addition to the data circuits,
the standard denes a number of control circuits used to
manage the connection between the DTE and DCE. Each
data or control circuit only operates in one direction, that
is, signaling from a DTE to the attached DCE or the re-
verse. Since transmit data and receive data are separate
circuits, the interface can operate in a full duplex manner,
supporting concurrent data ow in both directions. The
standard does not dene character framing within the data
stream, or character encoding.
2.5.1 Voltage levels
Start b0 b1 b2 b3 b4 b5 b6 b7 Stop
+3V
-3V
+15V
-15V
Start 1 1 0 1 0 0 1 0 Stop
Idle Idle
LSB MSB
Space
Mark
Time
Diagrammatic oscilloscope trace of voltage levels for an ASCII
K character (0x4B) with 1 start bit, 8 data bits, 1 stop bit. This
is typical for start-stop communications, but the standard does
not dictate a character format or bit order.
RS-232 data line on the terminals of the receiver side (RxD)
probed by an oscilloscope (for an ASCII K character (0x4B)
with 1 start bit, 8 data bits, 1 stop bit and no parity bits).
The RS-232 standard denes the voltage levels that cor-
respond to logical one and logical zero levels for the data
transmission and the control signal lines. Valid signals are
either in the range of +3 to +15 volts or the range 3 to
15 volts with respect to the ground/common pin; con-
sequently, the range between 3 to +3 volts is not a valid
RS-232 level. For data transmission lines (TxD, RxD
and their secondary channel equivalents) logic one is de-
ned as a negative voltage, the signal condition is called
2.5. STANDARD DETAILS 5
mark. Logic zero is positive and the signal condition
is termed space. Control signals have the opposite po-
larity: the asserted or active state is positive voltage and
the deasserted or inactive state is negative voltage. Exam-
ples of control lines include request to send (RTS), clear
to send (CTS), data terminal ready (DTR), and data set
ready (DSR).
The standard species a maximum open-circuit voltage
of 25 volts: signal levels of 5 V, 10 V, 12 V, and
15 V are all commonly seen depending on the voltages
available to the line driver circuit. Some RS-232 driver
chips have inbuilt circuitry to produce the required volt-
ages from a 3 or 5 volt supply. RS-232 drivers and re-
ceivers must be able to withstand indenite short circuit
to ground or to any voltage level up to 25 volts. The slew
rate, or how fast the signal changes between levels, is also
controlled.
Because the voltage levels are higher than logic levels
typically used by integrated circuits, special intervening
driver circuits are required to translate logic levels. These
also protect the devices internal circuitry from short cir-
cuits or transients that may appear on the RS-232 inter-
face, and provide sucient current to comply with the
slew rate requirements for data transmission.
Because both ends of the RS-232 circuit depend on the
ground pin being zero volts, problems will occur when
connecting machinery and computers where the voltage
between the ground pin on one end, and the ground pin
on the other is not zero. This may also cause a hazardous
ground loop. Use of a common ground limits RS-232 to
applications with relatively short cables. If the two de-
vices are far enough apart or on separate power systems,
the local ground connections at either end of the cable
will have diering voltages; this dierence will reduce
the noise margin of the signals. Balanced, dierential,
serial connections such as USB, RS-422 and RS-485 can
tolerate larger ground voltage dierences because of the
dierential signaling.
[8]
Unused interface signals terminated to ground will have
an undened logic state. Where it is necessary to per-
manently set a control signal to a dened state, it must
be connected to a voltage source that asserts the logic 1
or logic 0 level, for example with a pullup resistor. Some
devices provide test voltages on their interface connectors
for this purpose.
2.5.2 Connectors
RS-232 devices may be classied as Data Terminal
Equipment (DTE) or Data Communication Equipment
(DCE); this denes at each device which wires will be
sending and receiving each signal. The standard recom-
mended but did not make mandatory the D-subminiature
25-pin connector. According to the standard, male con-
nectors have DTE pin functions, and female connectors
have DCE pin functions. Other devices may have any
combination of connector gender and pin denitions.
Many terminals were manufactured with female connec-
tors but were sold with a cable with male connectors at
each end; the terminal with its cable satised the recom-
mendations in the standard. The standard species 20
dierent signal connections. Since most devices use only
a few signals, smaller connectors can often be used.
Personal computer manufacturers replaced the DB-25M
connector by the smaller DE-9Mconnector. Dierent pin
numbers were used for the signals (for this see serial port).
This connector, with varying pinouts, became common
for personal computers and related devices.
Presence of a 25-pin D-sub connector does not necessar-
ily indicate an RS-232-C compliant interface. For exam-
ple, on the original IBM PC, a male D-sub was an RS-
232-C DTE port (with a non-standard current loop inter-
face on reserved pins), but the female D-sub connector on
the same PC model was used for the parallel Centronics
printer port. Some personal computers put non-standard
voltages or signals on some pins of their serial ports.
2.5.3 Signals
The following table lists commonly used RS-232 signals
and pin assignments.
[9]
See serial port (pinouts) for non-
standard variations including the popular DE-9 connec-
tor.
The signals are named from the standpoint of the DTE.
The ground signal is a common return for the other con-
nections. The DB-25 connector includes a second pro-
tective ground on pin 1.
Data can be sent over a secondary channel (when imple-
mented by the DTE and DCE devices), which is equiv-
alent to the primary channel. Pin assignments are de-
scribed in following table:
Ring Indicator' (RI), is a signal sent from the modem to
the terminal device. It indicates to the terminal device
that the phone line is ringing. In many computer serial
ports, a hardware interrupt is generated when the RI sig-
nal changes state. Having support for this hardware in-
terrupt means that a program or operating system can be
informed of a change in state of the RI pin, without re-
quiring the software to constantly poll the state of the
pin. RI is a one-way signal from the modem to the ter-
minal (or more generally, the DCE to the DTE) that does
not correspond to another signal that carries similar in-
formation the opposite way.
On an external modemthe status of the Ring Indicator pin
is often coupled to the AA (auto answer) light, which
ashes if the RI signal has detected a ring. The asserted
RI signal follows the ringing pattern closely, which can
permit software to detect distinctive ring patterns.
The Ring Indicator signal is used by some older
uninterruptible power supplies (UPSs) to signal a power
6 CHAPTER 2. RS-232
failure state to the computer.
Certain personal computers can be congured for wake-
on-ring, allowing a computer that is suspended to answer
a phone call.
2.5.4 Cables
Main article: Serial cable
The standard does not dene a maximum cable length
but instead denes the maximum capacitance that a com-
pliant drive circuit must tolerate. A widely used rule of
thumb indicates that cables more than 50 feet (15 m) long
will have too much capacitance, unless special cables are
used. By using low-capacitance cables, full speed com-
munication can be maintained over larger distances up to
about 1,000 feet (300 m).
[10]
For longer distances, other
signal standards are better suited to maintain high speed.
Since the standard denitions are not always correctly ap-
plied, it is often necessary to consult documentation, test
connections with a breakout box, or use trial and error
to nd a cable that works when interconnecting two de-
vices. Connecting a fully standard-compliant DCEdevice
and DTE device would use a cable that connects identical
pin numbers in each connector (a so-called straight ca-
ble). "Gender changers" are available to solve gender
mismatches between cables and connectors. Connect-
ing devices with dierent types of connectors requires
a cable that connects the corresponding pins according to
the table above. Cables with 9 pins on one end and 25
on the other are common. Manufacturers of equipment
with 8P8C connectors usually provide a cable with either
a DB-25 or DE-9 connector (or sometimes interchange-
able connectors so they can work with multiple devices).
Poor-quality cables can cause false signals by crosstalk
between data and control lines (such as Ring Indicator).
If a given cable will not allowa data connection, especially
if a gender changer is in use, a null modem cable may
be necessary. Gender changers and null modem cables
are not mentioned in the standard, so there is no ocially
sanctioned design for them.
2.6 Conventions
For functional communication through a serial port in-
terface, conventions of bit rate, character framing, com-
munications protocol, character encoding, data compres-
sion, and error detection, not dened in RS 232, must
be agreed to by both sending and receiving equipment.
For example, consider the serial ports of the original
IBM PC. This implementation used an 8250 UART us-
ing asynchronous start-stop character formatting with 7
or 8 data bits per frame, usually ASCII character cod-
ing, and data rates programmable between 75 bits per
second and 115,200 bits per second. Data rates above
20,000 bits per second are out of the scope of the stan-
dard, although higher data rates are sometimes used by
commercially manufactured equipment. Since most RS-
232 devices do not have automatic baud rate detection,
users must manually set the baud rate (and all other pa-
rameters) at both ends of the RS-232 connection.
In the particular case of the 8250 UART used by the IBM
PC and others, baud rates were programmable by writing
integer values to a divider register and by selecting one
of several clock prescalers for the divider. This allowed
a PC to be connected to devices using rates other than
those standardized for modems. Not all baud rates can
be programmed, due to the clock frequency of the 8250
UART in the PC, and the granularity of the baud rate
setting. This includes the baud rate of MIDI, 31,250 bits
per second, which is not achievable by a standard IBM
PC serial port.
[11]
MIDI-to-RS-232 interfaces designed
for the IBM PC include baud rate translation hardware to
adjust the baud rate of the MIDI data to something that
the IBM PC can support, for example 19,200 or 38,400
bits per second.
2.6.1 RTS/CTS handshaking
Further information: Flow control (data)
In older versions of the specication, RS-232s use of the
RTS and CTS lines is asymmetric: The DTE asserts RTS
to indicate a desire to transmit to the DCE, and the DCE
asserts CTS in response to grant permission. This allows
for half-duplex modems that disable their transmitters
when not required, and must transmit a synchronization
preamble to the receiver when they are re-enabled. This
scheme is also employed on present-day RS-232 to RS-
485 converters, where the RS-232s RTS signal is used
to ask the converter to take control of the RS-485 busa
concept that does not otherwise exist in RS-232. There is
no way for the DTE to indicate that it is unable to accept
data from the DCE.
A non-standard symmetric alternative, commonly called
RTS/CTS handshaking, was developed by various
equipment manufacturers. In this scheme, CTS is no
longer a response to RTS; instead, CTS indicates permis-
sion from the DCE for the DTE to send data to the DCE,
and RTS indicates permission fromthe DTE for the DCE
to send data to the DTE. RTS and CTS are controlled by
the DTE and DCE respectively, each independent of the
other. This was eventually codied in version RS-232-
E (actually TIA-232-E by that time) by dening a new
signal, RTR (Ready to Receive), which is CCITT V.24
circuit 133. TIA-232-E and the corresponding interna-
tional standards were updated to show that circuit 133,
when implemented, shares the same pin as RTS (Request
to Send), and that when 133 is in use, RTS is assumed by
the DCE to be ON at all times.
[12]
2.8. RELATED STANDARDS 7
Thus, with this alternative usage, one can think of RTS
asserted (positive voltage, logic 0) meaning that the DTE
is indicating it is ready to receive from the DCE, rather
than requesting permission from the DCE to send char-
acters to the DCE.
Note that equipment using this protocol must be prepared
to buer some extra data, since a transmission may have
begun just before the control line state change.
RTS/CTS handshaking is an example of hardware ow
control. However, hardware owcontrol in the descrip-
tion of the options available on an RS-232-equipped de-
vice does not always mean RTS/CTS handshaking.
2.6.2 3-wire and 5-wire RS-232
A minimal 3-wire RS-232 connection consisting only
of transmit data, receive data, and ground, is commonly
used when the full facilities of RS-232 are not required.
Even a two-wire connection (data and ground) can be
used if the data ow is one way (for example, a digital
postal scale that periodically sends a weight reading, or a
GPS receiver that periodically sends position, if no con-
guration via RS-232 is necessary). When only hardware
ow control is required in addition to two-way data, the
RTS and CTS lines are added in a 5-wire version.
2.7 Seldom used features
The EIA-232 standard species connections for several
features that are not used in most implementations. Their
use requires 25-pin connectors and cables.
2.7.1 Signal rate selection
The DTE or DCE can specify use of a high or low
signaling rate. The rates as well as which device will select
the rate must be congured in both the DTE and DCE.
The prearranged device selects the high rate by setting pin
23 to ON.
2.7.2 Loopback testing
Many DCE devices have a loopback capability used for
testing. When enabled, signals are echoed back to the
sender rather than being sent on to the receiver. If sup-
ported, the DTE can signal the local DCE (the one it is
connected to) to enter loopback mode by setting pin 18 to
ON, or the remote DCE (the one the local DCE is con-
nected to) to enter loopback mode by setting pin 21 to
ON. The latter tests the communications link as well as
both DCEs. When the DCE is in test mode it signals the
DTE by setting pin 25 to ON.
A commonly used version of loopback testing does not
involve any special capability of either end. A hardware
loopback is simply a wire connecting complementary pins
together in the same connector (see loopback).
Loopback testing is often performed with a specialized
DTE called a bit error rate tester (or BERT).
2.7.3 Timing signals
Some synchronous devices provide a clock signal to syn-
chronize data transmission, especially at higher data rates.
Two timing signals are provided by the DCE on pins 15
and 17. Pin 15 is the transmitter clock, or send timing
(ST); the DTE puts the next bit on the data line (pin 2)
when this clock transitions fromOFF to ON(so it is stable
during the ON to OFF transition when the DCE registers
the bit). Pin 17 is the receiver clock, or receive timing
(RT); the DTE reads the next bit from the data line (pin
3) when this clock transitions from ON to OFF.
Alternatively, the DTE can provide a clock signal, called
transmitter timing (TT), on pin 24 for transmitted data.
Data is changed when the clock transitions from OFF to
ON and read during the ON to OFF transition. TT can
be used to overcome the issue where ST must traverse a
cable of unknown length and delay, clock a bit out of the
DTE after another unknown delay, and return it to the
DCE over the same unknown cable delay. Since the re-
lation between the transmitted bit and TT can be xed in
the DTE design, and since both signals traverse the same
cable length, using TT eliminates the issue. TT may be
generated by looping ST back with an appropriate phase
change to align it with the transmitted data. ST loop back
to TT lets the DTE use the DCE as the frequency refer-
ence, and correct the clock to data timing.
Synchronous clocking is required for such protocols as
SDLC, HDLC, and X.25.
2.7.4 Secondary channel
There is a secondary data channel, identical in capabil-
ity to the rst. Five signals (plus the common ground
of the primary channel) comprise the secondary chan-
nel: Secondary Transmitted Data (STD), Secondary Re-
ceived Data (SRD), Secondary Request To Send (SRTS),
Secondary Clear To Send (SCTS), and Secondary Carrier
Detect (SDCD).
2.8 Related standards
Other serial signaling standards may not interoperate with
standard-compliant RS-232 ports. For example, using
the TTL levels of near +5 and 0 V puts the mark level in
the undened area of the standard. Such levels are some-
times used with NMEA 0183-compliant GPS receivers
8 CHAPTER 2. RS-232
and depth nders.
A 20 mA current loop uses the absence of 20 mA cur-
rent for high, and the presence of current in the loop for
low; this signaling method is often used for long-distance
and optically isolated links. Connection of a current-loop
device to a compliant RS-232 port requires a level trans-
lator. Current-loop devices can supply voltages in ex-
cess of the withstand voltage limits of a compliant device.
The original IBM PC serial port card implemented a 20
mA current-loop interface, which was never emulated by
other suppliers of plug-compatible equipment.
Other serial interfaces similar to RS-232:
RS-422 (a high-speed system similar to RS-232 but
with dierential signaling)
RS-423 (a high-speed system similar to RS-422 but
with unbalanced signaling)
RS-449 (a functional and mechanical interface that
used RS-422 and RS-423 signals - it never caught on
like RS-232 and was withdrawn by the EIA)
RS-485 (a descendant of RS-422 that can be used
as a bus in multidrop congurations)
MIL-STD-188 (a system like RS-232 but with bet-
ter impedance and rise time control)
EIA-530 (a high-speed system using RS-422 or RS-
423 electrical properties in an EIA-232 pinout con-
guration, thus combining the best of both; super-
sedes RS-449)
EIA/TIA-561 8 Position Non-Synchronous Inter-
face Between Data Terminal Equipment and Data
Circuit Terminating Equipment Employing Serial
Binary Data Interchange
EIA/TIA-562 Electrical Characteristics for an Un-
balanced Digital Interface (low-voltage version of
EIA/TIA-232)
TIA-574 (standardizes the 9-pin D-subminiature
connector pinout for use with EIA-232 electrical
signalling, as originated on the IBM PC/AT)
2.9 Development tools
When developing or troubleshooting systems using RS-
232, close examination of hardware signals can be im-
portant to nd problems. A serial line analyzer is a de-
vice similar to a logic analyzer but specialized for RS-
232s voltage levels, connectors, and, where used, clock
signals. The serial line analyzer can collect, store, and
display the data and control signals, allowing developers
to view them in detail. Some simply display the signals as
waveforms; more elaborate versions include the ability to
decode characters in ASCII or other common codes and
to interpret common protocols used over RS-232 such
as SDLC, HDLC, DDCMP, and X.25. Serial line ana-
lyzers are available as standalone units, as software and
interface cables for general-purpose logic analyzers and
oscilloscopes, and as programs that run on common per-
sonal computers and devices.
2.10 References
[1] EIA standard RS-232-C: Interface between Data Terminal
Equipment and Data Communication Equipment Employ-
ing Serial Binary Data Interchange. Washington: Elec-
tronic Industries Association. Engineering Dept. 1969.
OCLC 38637094.
[2] RS232 Tutorial on Data Interface and cables. ARC
Electronics. 2010. Retrieved 28 July 2011.
[3] Metering Glossary Landis + Gyr Tutorial (see EIA)
[4] TIA Facts at a Glance. About TIA. Telecommunications
Industry Association. Retrieved 28 July 2011.
[5] S. Mackay, E. Wright, D. Reynders, J. Park, Practical
Industrial Data Networks:Design, Installation and Trou-
bleshooting, Newnes, 2004 ISBN07506 5807X, pages 41-
42
[6] Horowitz, Paul; Wineld Hill (1989). The Art of Electron-
ics (2nd ed.). Cambridge, England: Cambridge University
Press. pp. 723726. ISBN 0-521-37095-7.
[7] PC 97 Hardware Design Guide. Redmond, Wash: Mi-
crosoft Press. 1997. ISBN 1-57231-381-1.
[8] Wilson, Michael R. (January 2000). TIA/EIA-422-B
Overview. Application Note 1031. National Semicon-
ductor. Retrieved 28 July 2011.
[9] gren, Joakim (18 September 2008). Serial (PC 9)".
Hardware Book. Retrieved 28 July 2011.
[10] Lawrence, Tony (1992). Serial Wiring. A. P. Lawrence.
Retrieved 28 July 2011.
[11] InfoWorld 30 Mar 1992 page 80
[12] [email protected] (Casey Leedom) (1990-02-20).
"[news:<[email protected]> Re: EIA-232
full duplex RTS/CTS ow control standard proposal]".
comp.dcom.modems. Web link. Retrieved 2008-04-30.
Chapter 3
Serial port
A male DE-9 connector used for a serial port on an IBM PC
compatible computer along with the serial port symbol. (Pinout)
In computing, a serial port is a serial communication
physical interface through which information transfers in
or out one bit at a time (in contrast to a parallel port).
[1]
Throughout most of the history of personal computers,
data was transferred through serial ports to devices such
as modems, terminals and various peripherals.
Pair of female Mini DIN-8 connectors used for RS-422 serial
ports on a Macintosh LC computer
While such interfaces as Ethernet, FireWire, and USB all
send data as a serial stream, the term serial port usually
identies hardware more or less compliant to the RS-232
standard, intended to interface with a modem or with a
similar communication device.
Modern computers without serial ports may require
serial-to-USB converters to allow compatibility with RS
232 serial devices. Serial ports are still used in applica-
tions such as industrial automation systems, scientic in-
struments, point of sale systems and some industrial and
consumer products. Server computers may use a serial
port as a control console for diagnostics. Network equip-
ment (such as routers and switches) often use serial con-
sole for conguration. Serial ports are still used in these
areas as they are simple, cheap and their console func-
tions are highly standardized and widespread. A serial
port requires very little supporting software from the host
system.
3.1 Hardware
PCI Express card with one serial port
Some computers, such as the IBMPC, used an integrated
circuit called a UART, that converted characters to (and
9
10 CHAPTER 3. SERIAL PORT
from) asynchronous serial form, and automatically looked
after the timing and framing of data. Very low-cost sys-
tems, such as some early home computers, would instead
use the CPU to send the data through an output pin, us-
ing the bit-banging technique. Before large-scale inte-
gration (LSI) UART integrated circuits were common, a
minicomputer or microcomputer would have a serial port
made of multiple small-scale integrated circuits to imple-
ment shift registers, logic gates, counters, and all the other
logic for a serial port.
Early home computers often had proprietary serial ports
with pinouts and voltage levels incompatible with RS-
232. Inter-operation with RS-232 devices may be impos-
sible as the serial port cannot withstand the voltage levels
produced and may have other dierences that "lock in"
the user to products of a particular manufacturer.
Low-cost processors now allow higher-speed, but more
complex, serial communication standards such as USB
and FireWire to replace RS-232. These make it possible
to connect devices that would not have operated feasi-
bly over slower serial connections, such as mass storage,
sound, and video devices.
Many personal computer motherboards still have at least
one serial port, even if accessible only through a pin
header. Small-form-factor systems and laptops may omit
RS-232 connector ports to conserve space, but the elec-
tronics are still there. RS-232 has been standard for so
long that the circuits needed to control a serial port be-
came very cheap and often exist on a single chip, some-
times also with circuitry for a parallel port.
3.1.1 DTE and DCE
The individual signals on a serial port are unidirectional
and when connecting two devices the outputs of one de-
vice must be connected to the inputs of the other. Devices
are divided into two categories "data terminal equipment"
(DTE) and "data circuit-terminating equipment" (DCE).
A line that is an output on a DTE device is an input on
a DCE device and vice-versa so a DCE device can be
connected to a DTE device with a straight wired cable.
Conventionally, computers and terminals are DTE while
modems and peripherals are DCE.
If it is necessary to connect two DTE devices (or two
DCE devices but that is more unusual) a cross-over null
modem, in the form of either an adapter or a cable, must
be used.
3.1.2 Connectors
While the RS-232 standard originally specied a 25-pin
D-type connector, many designers of personal computers
chose to implement only a subset of the full standard: they
traded o compatibility with the standard against the use
of less costly and more compact connectors (in particu-
lar the DE-9 version used by the original IBM PC-AT).
The desire to supply serial interface cards with two ports
required that IBM reduce the size of the connector to t
onto a single card back panel. A DE-9 connector also
ts onto a card with a second DB-25 connector that was
similarly changed from the original Centronics-style con-
nector. Starting around the time of the introduction of the
IBM PC-AT, serial ports were commonly built with a 9-
pin connector to save cost and space. However, presence
of a 9-pin D-subminiature connector is not sucient to
indicate the connection is in fact a serial port, since this
connector was also used for video, joysticks, and other
purposes.
Some miniaturized electronics, particularly graphing cal-
culators and hand-held amateur and two-way radio equip-
ment, have serial ports using a phone connector, usually
the smaller 2.5 or 3.5 mm connectors and use the most
basic 3-wire interface.
Many models of Macintosh favored the related RS-422
standard, mostly using German Mini-DIN connectors,
except in the earliest models. The Macintosh included a
standard set of two ports for connection to a printer and a
modem, but some PowerBook laptops had only one com-
bined port to save space.
The standard species 20 dierent signal connections.
Since most devices use only a few signals, smaller con-
nectors can often be used. For example, the 9-pin DE-9
connector was used by most IBM-compatible PCs since
the IBM PC AT, and has been standardized as TIA-
574. More recently, modular connectors have been used.
Most common are 8P8C connectors. Standard EIA/TIA
561 species a pin assignment, but the Yost Serial De-
vice Wiring Standard
[2]
invented by Dave Yost (and
popularized by the Unix System Administration Hand-
book) is common on Unix computers and newer devices
from Cisco Systems. Many devices don't use either of
these standards. 10P10C connectors can be found on
some devices as well. Digital Equipment Corporation
dened their own DECconnect connection system which
was based on the Modied Modular Jack (MMJ) con-
nector. This is a 6-pin modular jack where the key is
oset from the center position. As with the Yost stan-
dard, DECconnect uses a symmetrical pin layout which
enables the direct connection between two DTEs. An-
other common connector is the DH10 header connector
common on motherboards and add-in cards which is usu-
ally converted via a cable to the more standard 9-pin DE-
9 connector (and frequently mounted on a free slot plate
or other part of the housing).
3.1.3 Pinouts
The following table lists commonly used RS-232 signals
and pin assignments.
[3]
The signals are named from the standpoint of the DTE,
for example, an IBM-PC compatible serial port. The
3.2. COMMON APPLICATIONS FOR SERIAL PORTS 11
ground signal is a common return for the other connec-
tions; it appears on two pins in the Yost standard but is
the same signal. The DB-25 connector includes a second
protective ground on pin 1. Connecting this to pin 7
(signal reference ground) is a common practice but not
essential.
Note that EIA/TIA 561 combines DSR and RI,
[8][9]
and
the Yost standard combines DSR and DCD.
A converter from USB to an RS-232 compatible serial port; more
than a physical transition, it requires a driver in the host system
software and a built-in processor to emulate the functions of the
IBM XT compatible serial port hardware.
3.1.4 Hardware abstraction
Operating systems usually use a symbolic name to refer
to the serial ports of a computer. Unix-like operating sys-
tems usually label the serial port devices /dev/tty* (TTY
is a common trademark-free abbreviation for teletype)
where * represents a string identifying the terminal de-
vice; the syntax of that string depends on the oper-
ating system and the device. On Linux, 8250/16550
UART hardware serial ports are named /dev/ttyS*, USB
adapters appear as /dev/ttyUSB* and various types of vir-
tual serial ports do not necessarily have names starting
with tty.
The Microsoft MS-DOS and Windows environments re-
fer to serial ports as COM ports: COM1, COM2,..etc.
Ports numbered greater than COM9 should be referred
to using the \\.\COM10 syntax.
[10]
3.2 Common applications for serial
ports
The RS-232 standard is used by many specialized and
custom-built devices. This list includes some of the more
common devices that are connected to the serial port on
a PC. Some of these such as modems and serial mice are
falling into disuse while others are readily available.
Serial ports are very common on most types of
microcontroller, where they can be used to communicate
with a PC or other serial devices.
Dial-up modems
Conguration and management of networking
equipment such as routers, switches, rewalls, load
balancers
GPS receivers (typically NMEA0183 at 4,800 bit/s)
Bar code scanners and other point of sale devices
LED and LCD text displays
Satellite phones, low-speed satellite modems and
other satellite based transceiver devices
Flat-screen (LCD and Plasma) monitors to control
screen functions by external computer, other AV
components or remotes
Test and measuring equipment such as digital
multimeters and weighing systems
Updating Firmware on various consumer devices.
Some CNC controllers
Uninterruptible power supply
Stenography or Stenotype machines.
Software debuggers that run on a second computer.
Industrial eld buses
Printers
Computer terminal, teletype
Older digital cameras
Networking (Macintosh AppleTalk using RS-422 at
230.4 kbit/s)
Serial mouse
Older GSM mobile phones
Some Telescopes
IDE hard drive
[11][12]
repair
[13][14]
Since the control signals for a serial port can be easily
turned on and o by a switch, some applications used
the control lines of a serial port to monitor external de-
vices, without exchanging serial data. A common com-
mercial application of this principle was for some mod-
els of uninterruptible power supply which used the con-
trol lines to signal loss of power, battery low alarm
and other status information. At least some Morse code
12 CHAPTER 3. SERIAL PORT
training software used a code key connected to the se-
rial port, to simulate actual code use. The status bits of
the serial port could be sampled very rapidly and at pre-
dictable times, making it possible for the software to de-
cipher Morse code.
3.3 Settings
Many settings are required for serial connections used for
asynchronous start-stop communication, to select speed,
number of data bits per character, parity, and number of
stop bits per character. In modern serial ports using a
UART integrated circuit, all settings are usually software-
controlled; hardware from the 1980s and earlier may re-
quire setting switches or jumpers on a circuit board. One
of the simplications made in such serial bus standards
as Ethernet, FireWire, and USB is that many of those pa-
rameters have xed values so that users can not and need
not change the conguration; the speed is either xed or
automatically negotiated. Often if the settings are entered
incorrectly the connection will not be dropped; however,
any data sent will be received on the other end as non-
sense.
3.3.1 Speed
Serial ports use two-level (binary) signaling, so the data
rate in bits per second is equal to the symbol rate in bauds.
A standard series of rates is based on multiples of the
rates for electromechanical teleprinters; some serial ports
allow many arbitrary rates to be selected. The port speed
and device speed must match. The capability to set a bit
rate does not imply that a working connection will re-
sult. Not all bit rates are possible with all serial ports.
Some special-purpose protocols such as MIDI for musi-
cal instrument control, use serial data rates other than the
teleprinter series. Some serial port systems can automat-
ically detect the bit rate.
The speed includes bits for framing (stop bits, parity, etc.)
and so the eective data rate is lower than the bit trans-
mission rate. For example with 8-N-1 character framing
only 80% of the bits are available for data (for every eight
bits of data, two more framing bits are sent).
Bit rates commonly supported include 75, 110, 300,
1200, 2400, 4800, 9600, 19200, 38400, 57600 and
115200 bit/s.
[15]
Crystal oscillators with a frequency of
1.843200 MHz are sold specically for this purpose.
This is 16 times the fastest bit rate and the serial port
circuit can easily divide this down to lower frequencies as
required.
3.3.2 Data bits
The number of data bits in each character can be 5 (for
Baudot code), 6 (rarely used), 7 (for true ASCII), 8 (for
most kinds of data, as this size matches the size of a byte),
or 9 (rarely used). 8 data bits are almost universally used
in newer applications. 5 or 7 bits generally only make
sense with older equipment such as teleprinters.
Most serial communications designs send the data bits
within each byte LSB (Least signicant bit) rst. This
standard is also referred to as little endian. Also possi-
ble, but rarely used, is big endian or MSB (Most Sig-
nicant Bit) rst serial communications; this was used,
for example, by the IBM 2741 printing terminal. (See
Bit numbering for more about bit ordering.) The order
of bits is not usually congurable within the serial port
interface. To communicate with systems that require a
dierent bit ordering than the local default, local software
can re-order the bits within each byte just before sending
and just after receiving.
3.3.3 Parity
Main article: Parity bit
Parity is a method of detecting errors in transmission.
When parity is used with a serial port, an extra data bit is
sent with each data character, arranged so that the num-
ber of 1 bits in each character, including the parity bit, is
always odd or always even. If a byte is received with the
wrong number of 1s, then it must have been corrupted.
However, an even number of errors can pass the parity
check.
Electromechanical teleprinters were arranged to print a
special character when received data contained a parity
error, to allow detection of messages damaged by line
noise. A single parity bit does not allow implementation
of error correction on each character, and communication
protocols working over serial data links will have higher-
level mechanisms to ensure data validity and request re-
transmission of data that has been incorrectly received.
The parity bit in each character can be set to none (N),
odd (O), even (E), mark (M), or space (S). None means
that no parity bit is sent at all. Mark parity means that the
parity bit is always set to the mark signal condition (log-
ical 1) and likewise space parity always sends the parity
bit in the space signal condition. Aside from uncommon
applications that use the 9th (parity) bit for some form
of addressing or special signalling, mark or space par-
ity is uncommon, as it adds no error detection informa-
tion. Odd parity is more useful than even, since it ensures
that at least one state transition occurs in each character,
which makes it more reliable. The most common parity
setting, however, is none, with error detection handled
by a communication protocol.
3.4. VIRTUAL SERIAL PORTS 13
3.3.4 Stop bits
Stop bits sent at the end of every character allow the re-
ceiving signal hardware to detect the end of a character
and to resynchronise with the character stream. Elec-
tronic devices usually use one stop bit. If slow electrome-
chanical teleprinters are used, one-and-one half or two
stop bits are required.
3.3.5 Conventional notation
The D/P/S (Data/Parity/Stop) conventional notation
species the framing of a serial connection. The most
common usage on microcomputers is 8/N/1 (8N1). This
species 8 data bits, no parity, 1 stop bit. In this nota-
tion, the parity bit is not included in the data bits. 7/E/1
(7E1) means that an even parity bit is added to the seven
data bits for a total of eight bits between the start and stop
bits. If a receiver of a 7/E/1 stream is expecting an 8/N/1
stream, half the possible bytes will be interpreted as hav-
ing the high bit set.
3.3.6 Flow control
Main article: Flow control (data)
A serial port may use signals in the interface to pause and
resume the transmission of data. For example, a slow
printer might need to handshake with the serial port to
indicate that data should be paused while the mechanism
advances a line.
Common hardware handshake signals (hardware ow
control) use the RS-232 RTS/CTS or DTR/DSR signal
circuits. Generally, the RTS and CTS are turned o and
on from alternate ends to control data ow, for instance
when a buer is almost full. DTR and DSR are usually
on all the time and, per the RS-232 standard and its suc-
cessors, are used to signal from each end that the other
equipment is actually present and powered-up. However,
manufacturers have over the years built many devices that
implemented non-standard variations on the standard, for
example, printers that use DTR as ow control.
Another method of ow control (software ow control)
uses special characters such as XON/XOFF to control
the ow of data. The XON/XOFF characters are sent
by the receiver to the sender to control when the sender
will send data, that is, these characters go in the opposite
direction to the data being sent. The circuit starts in the
sending allowed state. When the receivers buers ap-
proach capacity, the receiver sends the XOFF character
to tell the sender to stop sending data. Later, after the
receiver has emptied its buers, it sends an XON charac-
ter to tell the sender to resume transmission. These are
non-printing characters and are interpreted as handshake
signals by printers, terminals, and computer systems.
XON/XOFF ow control is an example of in-band sig-
naling, in which control information is sent over the same
channel used for the data. XON/XOFF handshaking
presents diculties as XON and XOFF characters might
appear in the data being sent and receivers may inter-
pret them as ow control. Such characters sent as part of
the data stream must be encoded in an escape sequence
to prevent this, and the receiving and sending software
must generate and interpret these escape sequences. On
the other hand, since no extra signal circuits are required,
XON/XOFF ow control can be done on a 3 wire inter-
face.
3.4 Virtual serial ports
Main article: COM port redirector
A virtual serial port is an emulation of the standard
serial port. This port is created by software which en-
able extra serial ports in an operating system without ad-
ditional hardware installation (such as expansion cards,
etc.). It is possible to create a large number of virtual
serial ports in a PC. The only limitation is the amount
of resources, such as operating memory and computing
power, needed to emulate many serial ports at the same
time.
Virtual serial ports emulate all hardware serial port
functionality, including Baud rate, Data bits, Par-
ity bits, Stop bits, etc. Additionally they allow
controlling the data ow, emulating all signal lines
(DTR/DSR/CTS/RTS/DCD/RI) and customizing
pinout. Virtual serial ports are common with Bluetooth
and are the standard way of receiving data from
Bluetooth-equipped GPS modules.
Virtual serial port emulation can be useful in case there is
a lack of available physical serial ports or they do not meet
the current requirements. For instance, virtual serial ports
can share data between several applications from one
GPS device connected to a serial port. Another option
is to communicate with any other serial devices via inter-
net or LAN as if they are locally connected to computer
(Serial over LAN/Serial-over-Ethernet technology). Two
computers or applications can communicate through an
emulated serial port link. Virtual serial port emulators
are available for many operating systems including Ma-
cOS, Linux, and various mobile and desktop versions of
Microsoft Windows.
3.5 See also
COM (hardware interface)
Teleprinter
14 CHAPTER 3. SERIAL PORT
3.6 References
[1] Webopedia (2003-09-03). What is serial port? - AWord
Denition From the Webopedia Computer Dictionary.
Webopedia.com. Retrieved 2009-08-07.
[2] Yost Serial Device Wiring Standard
[3] Joakim gren. Serial (PC 9)".
[4] Cyclom-Y Installation Manual, page 38, retrieved on 29
November 2008
[5] RJ-45 8-Pin to Modem (ALTPIN option)".
Digiftp.digi.com. Retrieved 2014-02-08.
[6] National Instruments Serial Quick Reference Guide,
February 2007
[7] RJ-45 10-Pin Plug to DB-25 Modem Cable.
Digiftp.digi.com. Retrieved 2014-02-08.
[8] Hardware Book RS-232D
[9] RS-232D EIA/TIA-561 RJ45 Pinout
[10] HOWTO: Specify Serial Ports Larger than COM9. Mi-
crosoft support. Retrieved 26 October 2013.
[11] Pauls 8051 Code Library, IDE Hard Drive Interface.
Pjrc.com. 2005-02-24. Retrieved 2014-02-08.
[12] IDE Hard Disk experiments. Hem.passagen.se. 2004-
02-15. Retrieved 2014-02-08.
[13] The Solution for Seagate 7200.11 HDDs - Hard Drive
and Removable Media issues - MSFN Forum. Msfn.org.
Retrieved 2014-02-08.
[14] Fixing a Seagate 7200.11 Hard Drive.
Sites.google.com. Retrieved 2014-02-08.
[15] DCB Structure. MSDN. Microsoft. Retrieved 15 March
2011.
3.7 External links
Serial Port Programming in Linux
RS-232 and other serial port pinouts list
Back of an old desktop computer showing 25-pin
male serial port.
Chapter 4
RS-485
TIA-485-A, also known as ANSI/TIA/EIA-485,
TIA/EIA-485, EIA-485 or RS-485, is a standard den-
ing the electrical characteristics of drivers and receivers
for use in balanced digital multipoint systems. The stan-
dard is published by the Telecommunications Industry
Association/Electronic Industries Alliance (TIA/EIA).
Digital communications networks implementing the
EIA-485 standard can be used eectively over long dis-
tances and in electrically noisy environments. Multiple
receivers may be connected to such a network in a linear,
multi-drop conguration. These characteristics make
such networks useful in industrial environments and
similar applications.
The EIA once labeled all its standards with the prex
RS (Recommended Standard), but the EIA-TIA of-
cially replaced RS with EIA/TIA to help identify
the origin of its standards.
[1]
The EIA has ocially dis-
banded and the standard is now maintained by the TIA.
The RS-485 standard is superseded by TIA-485, but of-
ten engineers and applications guides continue to use the
RS designation.
4.1 Overview
RS-485 enables the conguration of inexpensive local
networks and multidrop communications links. It oers
data transmission speeds of 35 Mbit/s up to 10 m and
100 kbit/s at 1200 m. Since it uses a dierential balanced
line over twisted pair (like RS-422), it can span relatively
large distances (up to 4,000 feet (1,200 m)). A rule of
thumb is that the speed in bit/s multiplied by the length
in meters should not exceed 10
8
. Thus a 50 meter cable
should not signal faster than 2 Mbit/s.
[2]
In contrast to RS-422, which has a single driver circuit
which cannot be switched o, RS-485 drivers need to be
put in transmit mode explicitly by asserting a signal to
the driver. This allows RS-485 to implement linear bus
topologies using only two wires. The equipment located
along a set of RS-485 wires are interchangeably called
nodes, stations or devices.
[3]
The recommended arrangement of the wires is as a con-
nected series of point-to-point (multidropped) nodes, i.e.
a line or bus, not a star, ring, or multiply connected net-
work. Ideally, the two ends of the cable will have a termi-
nation resistor connected across the two wires. Without
termination resistors, reections of fast driver edges can
cause multiple data edges that can cause data corruption.
Termination resistors also reduce electrical noise sensi-
tivity due to the lower impedance, and bias resistors (see
below) are required. The value of each termination resis-
tor should be equal to the cable characteristic impedance
(typically, 120 ohms for twisted pairs).
Star and ring topologies are not recommended because of
signal reections or excessively low or high termination
impedance. If a star conguration is unavoidable, spe-
cial RS-485 star/hub repeaters are available which bidi-
rectionally listen for data on each span and then retransmit
the data onto all other spans.
120
680
680

+
Typical bias network together with termination. Biasing and ter-
mination values are not specied in the RS-485 standard.
Somewhere along the set of wires, pull up or pull down
resistors are established to fail-safe bias each data wire
when the lines are not being driven by any device. This
way, the lines will be biased to known voltages and nodes
will not interpret the noise from undriven lines as actual
15
16 CHAPTER 4. RS-485
data; without biasing resistors, the data lines oat in such
a way that electrical noise sensitivity is greatest when all
device stations are silent or unpowered.
[4]
4.2 Standard scope and denition
RS-485 only species electrical characteristics of the
generator and the receiver. It does not specify or rec-
ommend any communications protocol, only the physical
layer. Other standards dene the protocols for communi-
cation over an RS-485 link. The foreword to the stan-
dard recommends The Telecommunications Systems
Bulletin TSB-89 which contains application guidelines,
including data signaling rate vs. cable length, stub length,
and congurations.
Section 4 denes the electrical characteristics of the gen-
erator (transmitter or driver), receiver, transceiver, and
system. These characteristics include: denition of a
unit load, voltage ranges, open circuit voltages, thresh-
olds, and transient tolerance. It also denes three genera-
tor interface points (signal lines); A, B and C. The
data is transmitted on A and B. C is a ground ref-
erence. This section also denes the logic states 1 (o)
and 0 (on), by the polarity between A and B terminals.
If A is negative with respect to B, the state is binary 1.
The reversed polarity (A +, B-) is binary 0. The standard
does not assign any logic function to the two states.
4.3 Master-slave arrangement
Often in a master-slave arrangement when one device
dubbed the master initiates all communication activ-
ity, the master device itself provides the bias and not the
slave devices. In this conguration, the master device is
typically centrally located along the set of RS-485 wires,
so it would be two slave devices located at the physical
end of the wires that would provide the termination. The
master device itself would provide termination if it were
located at a physical end of the wires, but that is often
a bad design
[5]
as the master would be better located at
a halfway point between the slave devices, to maximize
signal strength and therefore line distance and speed. Ap-
plying the bias at multiple node locations could possibly
cause a violation of the RS-485 specication and cause
communications to malfunction.
4.4 Three-wire connection
Connection of a third wire between the source and re-
ceiver may be done to limit the common mode voltage
that can be impressed on the receiver inputs.
RS-485 3 wire connection
4.5 Full duplex operation
RS-485, like RS-422, can be made full-duplex by using
four wires. Since RS-485 is a multi-point specication,
however, this is not necessary in many cases. RS-485 and
RS-422 can interoperate with certain restrictions.
Converters between RS-485 and other formats are avail-
able to allow a personal computer to communicate with
remote devices. By using Repeaters and Multi-
Repeaters very large RS-485 networks can be formed.
TSB-89A, The Application Guidelines for TIA/EIA-
485-A has one diagram called Star Conguration. Not
recommended. Using an RS-485 Multi-Repeater can
allow for Star Congurations with Home Runs (or
multi-drop) connections similar to Ethernet Hub/Star im-
plementations (with greater distances). Hub/Star systems
(with Multi-Repeaters) allowfor very maintainable sys-
tems, without violating any of the RS-485 specications.
Repeaters can also be used to extend the distance or num-
ber of nodes on a network.
4.6 Applications
RS-485 signals are used in a wide range of computer
and automation systems. In a computer system, SCSI2
and SCSI-3 may use this specication to implement the
physical layer for data transmission between a controller
and a disk drive. RS-485 is used for low-speed data com-
munications in commercial aircraft cabins vehicle bus. It
requires minimal wiring, and can share the wiring among
several seats, reducing weight.
RS-485 is used as the physical layer underlying many
standard and proprietary automation protocols used to
implement Industrial Control Systems, including the most
common versions of Modbus and Probus. These are
4.8. WAVEFORM EXAMPLE 17
used in programmable logic controllers and on factory
oors. Since it is dierential, it resists electromagnetic
interference from motors and welding equipment.
In theatre and performance venues RS-485 networks
are used to control lighting and other systems using the
DMX512 protocol.
RS-485 is also used in building automation as the sim-
ple bus wiring and long cable length is ideal for joining
remote devices. It may be used to control video surveil-
lance systems or to interconnect security control panels
and devices such as access control card readers.
Its also used in model railway: controlling the layout in
a network/PC environment, connectors in this case are
8P8C / RJ45.
Although many applications use RS-485 signal levels, the
speed, format, and protocol of the data transmission is
not specied by RS-485. Interoperability of even simi-
lar devices from dierent manufacturers is not assured
by compliance with the signal levels alone.
4.7 Connectors
RS-485 does not specify any connector or pinout.
Circuits may be terminated on screw terminals, D-
subminiature connectors, or other types of connectors.
4.7.1 Pin labeling
The RS-485 dierential line consists of two pins:
A aka '-' aka TxD-/RxD- aka inverting pin
Baka '+' aka TxD+/RxD+aka non-inverting pin
SC aka G aka reference pin.
The SC line is the optional voltage reference connection.
This is the reference potential used by the transceiver to
measure the A and B voltages.
The B line is positive (compared to A) when the line is
idle (i.e., data is 1).
In addition to the A and B connections, the EIA stan-
dard also species a third interconnection point called C,
which is the common signal reference ground.
These names are all in use on various equipment, but the
actual standard released by EIA only uses the names A
and B. However, despite the unambiguous standard, there
is much confusion about which is which:
The RS-485 signaling specication states that signal A is
the inverting or '-' pin and signal B is the non-inverting
or '+' pin.
[6]
This is in conict with the A/B naming used by a num-
ber of dierential transceiver manufacturers, including,
among others:
Texas Instruments, as seen in their application hand-
book on EIA-422/485 communications (A=non-
inverting, B=inverting)
Intersil, as seen in their data sheet for the ISL4489
transceiver
[7]
Maxim, as seen in their data sheet for the MAX483
transceiver
[8]
Linear Technology, as seen in their datasheet for the
LTC2850, LTC2851, LTC2852
[9]
Analog Devices, as seen in their datasheet for the
ADM3483, ADM3485, ADM3488, ADM3490,
ADM3491
[10]
FTDI, as seen in their datasheet for the USB-RS485-
WE-1800-BT
[11]
These manufacturers are incorrect, but their practice is
in widespread use. Therefore, care must be taken when
using A/B naming.
To avoid these confusions, some equipment manufactur-
ers have created a third D+ and D- naming convention.
The standard does not discuss cable shielding, but makes
some recommendations on preferred methods of inter-
connecting the signal reference common and equipment
case grounds.
4.8 Waveform example
The diagrambelowshows potentials of the '+' and '' pins
of an RS-485 line during transmission of one byte (0xD3,
least signicant bit rst) of data using an asynchronous
start-stop method.
Mark
Mark
Idle
Mark Space
M
a
r
k
S
p
a
c
e
S
p
a
c
e
S
t
a
r
t
S
t
o
p
Mark
Idle 1 1 1 1 1 0 0 0
U
U
+
_
4.9 See also
Electronic Industries Alliance
Fieldbus
18 CHAPTER 4. RS-485
List of network buses
Modbus
Probus
RS-232
RS-422
RS-423
UART
4.10 References
[1] Trim-the-fat-o-RS-485-designs. EE Times. 2000.
[2] Soltero, Manny; Zhang, Jing; Cockril, Chris; Zhang,
Kevin; Kinnaird, Clark; Kugelstadt, Thomas (May 2010)
[2002]. RS-422 and RS-485 Standards Overview and Sys-
tem Congurations, Application Report (pdf). Texas In-
struments (Technical report). SLLA070D.
[3] Electronic Industries Association (1983). Electrical Char-
acteristics of Generators and Receivers for Use in Bal-
anced Multipoint Systems. EIA Standard RS-485. OCLC
10728525.
[4] DS3695,DS3695A,DS3695AT,DS3695T,DS96172,
DS96174,DS96F172MQML,DS96F174MQML: Applica-
tion Note 847 FAILSAFE Biasing of Dierential Buses
(Literature Number: SNLA031), Texas Instruments, 1998
[5] Thomas, George (MarchApril 2008). Examining the
BACnet MS/TP Physical Layer. the Extension (Contem-
porary Control Systems, Inc.) 9 (2).
[6] Polarities for Dierential Pair Signals (RS-422 and RS-
485)". B&B Electronics. 2011.
[7] Data Sheet FN6074.3: 15kV ESD Protected, 1/8 Unit
Load, 5V, Low Power, High Speed and Slew Rate Limited,
Full Duplex, RS-485/RS-422 Transceivers, Intersil Corpo-
ration, 28 April 2006
[8] Data Sheet 19-0122
MAX481/MAX483/MAX485/MAX487
MAX491/MAX1487: Low-Power, Slew-Rate-Limited
RS-485/RS-422 Transceivers, Maxim Integrated,
September 2009
[9] LTC2850/LTC2851/LTC2852 3.3V 20Mbps
RS485/RS422 Transceivers, Linear Technology Corpora-
tion, 2007
[10] ADM3483/ADM3485/ADM3488/ADM3490/ADM3491
(Rev. E), Analog Devices, Inc., 22 November 2011
[11] USB to RS485 Serial Converter Cable Datasheet, Future
Technology Devices International Ltd, 27 May 2010
4.11 External links
TUTORIAL 763: Guidelines for Proper Wiring of
an RS-485 (TIA/EIA-485-A) Network, Maxim Inte-
grated, 19 November 2001
RS232 to RS485 cable pinout. Pinouts.ru. 7 Oc-
tober 2012.
RS485 serial information. Lammert Bies. August
2012. Retrieved 12 November 2012. Practical
information about implementing RS485
Scordino, Claudio (22 November 2011). Linux
RS485 support. Retrieved 12 November 2012.
Implementation of RS485 standard in the Linux OS
Marais, Hein (2008), APPLICATION NOTE AN-
960: RS-485/RS-422 Circuit Implementation Guide,
Analog Devices
Chapter 5
RS-422
RS-422, also known as TIA/EIA-422, is a technical stan-
dard originated by the Electronic Industries Alliance that
species electrical characteristics of a digital signaling
circuit. Dierential signaling can transmit data at rates
as high as 10 Mbit/s, or may be sent on cables as long as
1500 meters. Some systems directly interconnect using
RS-422 signals, or RS-422 converters may be used to ex-
tend the range of RS-232 connections. The standard only
denes signal levels; other properties of a serial interface,
such as electrical connectors and pin wiring, are set by
other standards.
5.1 Standard scope
RS-422 is the common short form title of American
National Standards Institute (ANSI) standard
ANSI/TIA/EIA-422-B Electrical Characteristics of
Balanced Voltage Dierential Interface Circuits and its
international equivalent ITU-T Recommendation T-REC-
V.11,
[1]
also known as X.27. These technical standards
specify the electrical characteristics of the balanced
voltage digital interface circuit.
[2]
RS-422 provides
for data transmission, using balanced, or dierential,
signaling, with unidirectional/non-reversible, terminated
or non-terminated transmission lines, point to point, or
multi-drop. In contrast to EIA-485 (which is multi-point
instead of multi-drop), RS-422/V.11 does not allow
multiple drivers but only multiple receivers.
Revision B, published in May 1994 was rearmed by the
Telecommunications Industry Association in 2005.
5.2 Characteristics
Several key advantages oered by this standard include
the dierential receiver, a dierential driver and data rates
as high as 10 Megabits per second at 12 metres (40 ft).
The specication itself does not set an upper limit on data
rate, but rather shows how signal rate degrades with cable
length. The gure plotting this stops at 10 Mbit/s.
RS-422 only species the electrical signaling characteris-
tics of a single balanced signal. Protocols and pin assign-
ments are dened in other specications. The mechanical
connections for this interface are specied by EIA-530
(DB-25 connector) or EIA-449 (DC-37 connector), how-
ever devices exist which have 4 screw-posts to implement
the transmit and receive pair only. The maximum cable
length is 1500 m. Maximum data rates are 10 Mbit/s at
12 m or 100 kbit/s at 1200 m. RS-422 cannot implement
a truly multi-point communications network such as with
EIA-485, however one driver can be connected to up to
ten receivers.
RS-422 can interoperate with interfaces designed to MIL-
STD-188-114B, but they are not identical. RS-422 uses a
nominal 0 to 5 volt signal while MIL-STD-188-114Buses
a signal symmetric about 0 V. However the tolerance for
common mode voltage in both specications allows them
to interoperate. Care must be taken with the termination
network.
EIA-423 is a similar specication for unbalanced signal-
ing (RS-423).
5.3 Applications
A common use of RS-422 is for RS-232 extenders.
An RS-232-compatible variant of RS-422 using a mini-
DIN8 connector was widely used on Macintosh hard-
ware until it (and ADB) were replaced by Universal Serial
Bus on the iMac in 1998.
Broadcast automation systems and post-production linear
editing facilities use RS-422A to remotely control the
players/recorders located in the central apparatus room.
In most cases the Sony 9-pin connection is used, which
makes use of a standard DE-9 connector. This is a de-
facto industry standard connector for RS-422 used by
many manufacturers.
When used in relation to communications wiring, RS-422
wiring refers to cable made of 2 sets of twisted pair, often
with each pair being shielded, and a ground wire. While a
double pair cable may be practical for many RS-422 ap-
plications, the RS-422 specication only denes one sig-
nal path and does not assign any function to it. Any com-
plete cable assembly with connectors should be labeled
with the specication that dened the signal function and
19
20 CHAPTER 5. RS-422
mechanical layout of the connector, such as RS-449.
5.4 See also
Electronic Industries Alliance
Probus
Fieldbus
List of network buses
5.5 References
This article is based on material taken from the Free On-
line Dictionary of Computing prior to 1 November 2008
and incorporated under the relicensing terms of the
GFDL, version 1.3 or later.
[1] http://www.itu.int/rec/T-REC-V.11/en V.11 ITU Rec-
ommendation T-REC-V.11
[2] TIA/EIA STANDARD, Electrical Characteristics of Bal-
anced Voltage Digital Interface Circuits, TIA/EIA-422-B,
May 1994
5.6 External links
The Telecommunications Industry Association
National Semiconductor Application Note AN-
1031 TIA/EIA-422-B Overview, January 2000,
National Semiconductor Inc., retrieved from
National Semiconductor Application Note AN-759
Comparing EIA-485 and EIA-422-A Line Drivers
and Receivers in Multipoint Applications, February
1991, National Semiconductor Inc., retrieved from
National Semiconductor Application Note AN-
214 Transmission Line Drivers and Receivers or
TIA/EIA Standards RS-422 and RS-423 August
1993, National Semiconductor Inc., retrieved from
Maxim IC Application Note 723 Selecting and Us-
ing RS-232, RS-422, and RS-485 Serial Data Stan-
dards Dec 2000,
Maxim Integrated Products, Inc., retrieved from
Texas Instruments Application Report 422 and 485
Standards Overview and System Congurations
June 2002, Texas Instruments, retrieved from
Texas Instruments Application Report SLLA067B
Comparing Bus Solutions October 2009, Texas
Instruments, retrieved from
Chapter 6
Probus
Probus electrical connector
PROFIBUS (Process Field Bus) is a standard for eldbus
communication in automation technology and was rst
promoted in 1989 by BMBF (German department of
education and research) and then used by Siemens. It
should not be confused with the PROFINET standard
for Industrial Ethernet. PROFIBUS is neither an openly
published nor a royalty-free protocol, as opposed to
MODBUS.
6.1 Origin
The history of PROFIBUS goes back to a publicly pro-
moted plan for an association which started in Germany
in 1986 and for which 21 companies and institutes de-
vised a master project plan called "eldbus". The goal
was to implement and spread the use of a bit-serial eld
bus based on the basic requirements of the eld device
interfaces. For this purpose, member companies agreed
to support a common technical concept for production
(i.e. discrete or factory automation) and process automa-
tion. First, the complex communication protocol Probus
FMS (Field bus Message Specication), which was tai-
lored for demanding communication tasks, was speci-
ed. Subsequently in 1993, the specication for the sim-
pler and thus considerably faster protocol PROFIBUS
DP (Decentralised Peripherals) was completed. Probus
FMS is used for (non deterministic) communication of
data between Probus Masters. Probus DP is a pro-
tocol made for (deterministic) communication between
Probus masters and their remote I/O slaves.
There are two variations of PROFIBUS in use today;
the most commonly used PROFIBUS DP, and the lesser
used, application specic, PROFIBUS PA:
PROFIBUS DP (Decentralised Peripherals) is
used to operate sensors and actuators via a cen-
tralised controller in production (factory) automa-
tion applications. The many standard diagnostic op-
tions, in particular, are focused on here.
PROFIBUS PA (Process Automation) is used to
monitor measuring equipment via a process con-
trol system in process automation applications. This
variant is designed for use in explosion/hazardous
areas (Ex-zone 0 and 1). The Physical Layer (i.e.
the cable) conforms to IEC 61158-2, which allows
power to be delivered over the bus to eld instru-
ments, while limiting current ows so that explosive
conditions are not created, even if a malfunction oc-
curs. The number of devices attached to a PA seg-
ment is limited by this feature. PA has a data trans-
mission rate of 31.25 kbit/s. However, PA uses the
same protocol as DP, and can be linked to a DP net-
work using a coupler device. The much faster DP
acts as a backbone network for transmitting process
signals to the controller. This means that DP and
PA can work tightly together, especially in hybrid
applications where process and factory automation
networks operate side by side.
In excess of 30 million PROFIBUS nodes were installed
by the end of 2009. 5 million of these are in the process
industries.
6.2 Technology
PROFIBUS Protocol (OSI reference model)
21
22 CHAPTER 6. PROFIBUS
6.2.1 Application layer
To utilise these functions, various service levels of the DP
protocol were dened:
DP-V0 for cyclic exchange of data and diagnosis
DP-V1 for acyclic data exchange and alarmhandling
DP-V2 for isochronous mode and data exchange
broadcast (slave-to-slave communication)
6.2.2 Security layer
The security layer FDL(Field bus Data Link) works with
a hybrid access method that combines token passing with
a master-slave method. In a PROFIBUS DP network, the
controllers or process control systems are the masters and
the sensors and actuators are the slaves.
Various telegram types are used. They can be dierenti-
ated by their start delimiter (SD):
No data: SD1 = 0x10
Variable length data:
SD2 = 0x68
Fixed length data:
SD3 = 0xA2
Token:
SD4 = 0xDC
Brief acknowledgement:
SC = 0xE5
SD: Start Delimiter
LE: Length of protocol data unit, (incl.
DA,SA,FC,DSAP,SSAP)
LEr: Repetition of protocol data unit, (Hamming dis-
tance = 4)
FC: Function Code
DA: Destination Address
SA: Source Address
DSAP: Destination Service Access Point
SSAP: Source Service Access Point
Note: SAP55 is optional and may be disabled if the slave
doesn't provide non-volatile storage memory for the sta-
tion address.
PDU: Protocol Data Unit (protocol data)
FCS: Frame Checking Sequence
ED: End Delimiter (= 0x16 !)
The FCS is calculated by simply adding up the bytes
within the specied length. An overow is ignored here.
Each byte is saved with an even parity and transferred
asynchronously with a start and stop bit. There may not
be a pause between a stop bit and the following start bit
when the bytes of a telegram are transmitted. The master
signals the start of a new telegram with a SYN pause of
at least 33 bits (logical 1 = bus idle).
6.2.3 Bit-transmission layer
Three dierent methods are specied for the bit-
transmission layer:
With electrical transmission pursuant to EIA-485,
twisted pair cables with impedances of 150 ohms are
used in a bus topology. Bit rates from9.6 kbit/s to 12
Mbit/s can be used. The cable length between two
repeaters is limited from 100 to 1200 m, depending
on the bit rate used. This transmission method is
primarily used with PROFIBUS DP.
With optical transmission via ber optics, star-, bus-
and ring-topologies are used. The distance between
the repeaters can be up to 15 km. The ring topology
can also be executed redundantly.
With MBP (Manchester Bus Powered) transmission
technology, data and eld bus power are fed through
the same cable. The power can be reduced in such a
way that use in explosion-hazardous environments is
possible. The bus topology can be up to 1900 mlong
and permits branching to eld devices (max. 60 m
branches). The bit rate here is a xed 31.25 kbit/s.
This technology was specially established for use in
process automation for PROFIBUS PA.
For data transfer via sliding contacts for mobile devices or
optical or radio data transmission in open spaces, prod-
ucts from various manufacturers can be obtained, how-
ever they do not conform to any standard.
PROFIBUS DP uses two core screened cable with a vi-
olet sheath, and runs at speeds between 9.6kbit/s and
12Mbit/s. A particular speed can be chosen for a net-
work to give enough time for communication with all
the devices present in the network. If systems change
slowly then lower communication speed is suitable, and
if the systems change quickly then eective communica-
tion will happen through faster speed. The RS485 bal-
anced transmission used in PROFIBUS DP only allows
126 devices to be connected at once; however, more de-
vices can be connected or the network expanded with the
use of hubs or repeaters.
PROFIBUS PA is slower than PROFIBUS DP and runs
at xed speed of 31.2kbit/s via blue sheathed two core
screened cable. The communication may be initiated to
minimise the risk of explosion or for the systems that in-
trinsically need safe equipment. The message formats in
PROFIBUS PA are identical to PROFIBUS DP.
6.7. REFERENCES 23
Note: PROFIBUS DP and PROFIBUS PA should not be
confused with PROFINET.
6.3 Proles
Proles are pre-dened congurations of the functions
and features available fromPROFIBUS for use in specic
devices or applications. They are specied by PI work-
ing groups and published by PI. Proles are important for
openness, interoperability and interchangeability, so that
the end user can be sure that similar equipments from
dierent vendors perform in a standardised way. User
choice also encourages competition that drives vendors
towards enhanced performance and lower costs.
There are PROFIBUS proles for Encoders, Labora-
tory instruments, Intelligent pumps, Robots and Numer-
ically Controlled machines, for example. Proles also
exist for applications such as using HART and wire-
less with PROFIBUS, and process automation devices
via PROFIBUS PA. Other proles have been specied
for Motion Control (PROFIdrive) and Functional Safety
(PROFIsafe).
6.4 Standardisation
PROFIBUS was dened in 1991/1993 in DIN 19245,
was then included in EN 50170 in 1996 and, since 1999,
established in IEC 61158/IEC 61784.
6.5 Organisation
The PROFIBUS Nutzerorganisation e.V. (PROFIBUS
User Organisation, or PNO) was created in 1989. This
group was composed mainly of manufacturers and users
from Europe. In 1992, the rst regional PROFIBUS or-
ganisation was founded (PROFIBUS Schweiz in Switzer-
land). In the following years, additional Regional
PROFIBUS & PROFINET Associations (RPAs) were
added.
In 1995, all the RPAs joined together under the interna-
tional umbrella association PROFIBUS & PROFINET
International (PI). Today, PROFIBUS is represented by
25 RPAs around the world (including PNO) with over
1400 members, including most if not all major automa-
tion vendors and service suppliers, along with many end
users.
6.6 See also
Fieldbus
List of automation protocols
6.7 References
probus.com, PROFIBUS system description
J. Weigmann, G. Kilian: Decentralization with
PROFIBUS DP/DPV1, ISBN 978-3-89578-218-3
M. Felser: PROFIBUS Manual, A collection of infor-
mation explaining PROFIBUS networks assembled by
Prof. Max Felser, ISBN 978-3-8442-1435-2
6.8 External links
PROFIBUS & PROFINET International
PROFIBUS Manual by Prof. Max Felser - on-line
version
Chapter 7
Fieldbus
Fieldbus is the name of a family of industrial computer
network protocols used for real-time distributed control,
standardized as IEC 61158.
A complex automated industrial system such as man-
ufacturing assembly line usually needs a distributed
control systeman organized hierarchy of controller
systemsto function. In this hierarchy, there is usu-
ally a Human Machine Interface (HMI) at the top, where
an operator can monitor or operate the system. This is
typically linked to a middle layer of programmable logic
controllers (PLC) via a non-time-critical communications
system(e.g. Ethernet). At the bottomof the control chain
is the eldbus that links the PLCs to the components that
actually do the work, such as sensors, actuators, electric
motors, console lights, switches, valves and contactors.
7.1 Description
Fieldbus is an industrial network systemfor real-time dis-
tributed control. It is a way to connect instruments in a
manufacturing plant. Fieldbus works on a network struc-
ture which typically allows daisy-chain, star, ring, branch,
and tree network topologies. Previously, computers were
connected using RS-232 (serial connections) by which
only two devices could communicate. This would be the
equivalent of the currently used 4-20 mA communication
scheme which requires that each device has its own com-
munication point at the controller level, while the eldbus
is the equivalent of the current LAN-type connections,
which require only one communication point at the con-
troller level and allow multiple (hundreds) of analog and
digital points to be connected at the same time. This re-
duces both the length of the cable required and the num-
ber of cables required. Furthermore, since devices that
communicate through eldbus require a microprocessor,
multiple points are typically provided by the same device.
Some eldbus devices now support control schemes such
as PID control on the device side instead of forcing the
controller to do the processing.
7.2 History
7.2.1 Bitbus
The oldest commonly used eld bus technology is Bitbus.
Bitbus was created by Intel Corporation to enhance use of
Multibus systems in industrial systems by separating slow
i/o functions from faster memory access. In 1983, Intel
created the 8044 Bitbus microcontroller by adding eld
bus rmware to its existing 8051 microcontroller. Bit-
bus uses EIA-485 at the physical layer, with two twisted
pairs - one for data and the other for clocking and signals.
Use of SDLC at the data link layer permits 250 nodes
on one segment with a total distance of 13.2 km. Bitbus
has one master node and multiple slaves, with slaves only
responding to requests from the master. Bitbus does not
dene routing at the network layer. The 8044 permits
only a relatively small data packet (13 bytes), but embeds
an ecient set of RAC (remote access and control) tasks
and the ability to develop custom RAC tasks. In 1990,
the IEEE adopted Bitbus as the Microcontroller System
Serial Control Bus (IEEE-1118).
[1][2]
Today BITBUS is maintained by the BEUG - BITBUS
European Users Group.
[3]
7.2.2 Standardization
Although eldbus technology has been around since
1988, with the completion of the ISA S50.02 standard,
the development of the international standard took many
years. In 1999, the IEC SC65C/WG6 standards com-
mittee met to resolve dierence in the draft IEC eldbus
standard. The result of this meeting was the initial form
of the IEC 61158 standard with eight dierent protocol
sets called Types as follows:
Type 1 Foundation Fieldbus H1
Type 2 ControlNet
Type 3 PROFIBUS
Type 4 P-Net
Type 5 FOUNDATION eldbus HSE (High Speed
Ethernet)
24
7.4. STANDARDS 25
Type 6 SwiftNet (a protocol developed for Boeing,
since withdrawn)
Type 7 WorldFIP
Type 8 Interbus
This form of standard was rst developed for the
European Common Market, concentrates less on com-
monality, and achieves its primary purposeelimination
of restraint of trade between nations. Issues of common-
ality are now left to the international consortia that sup-
port each of the eldbus standard types. Almost as soon
as it was approved, the IEC standards development work
ceased and the committee was dissolved. A new IEC
committee SC65C/MT-9 was formed to resolve the con-
icts in form and substance within the more than 4000
pages of IEC 61158. The work on the above protocol
types is substantially complete. New protocols, such as
for safety eldbuses or real-time ethernet- eldbuses are
being accepted into the denition of the international
eldbus standard during a typical 5-year maintenance cy-
cle.
Both Foundation Fieldbus and Probus technologies are
now commonly implemented within the process control
eld, both for new developments and major rets. In
2006, China saw the largest FF (Foundation Fieldbus)
systems installations at NanHai and SECCO, each with
around 15000 eldbus devices connected.
7.3 IEC 61158 specication
There were many competing technologies for eldbus and
the original hope for one single unied communications
mechanism has not been realized. This should not be
unexpected since eldbus technology needs to be imple-
mented dierently in dierent applications; automotive
eldbus is functionally dierent from process plant con-
trol. The nal edition of IEC standard IEC 61158 allows
8 technologies.This are the some hierarchic layer of the
automation protocols.
IEC 61158 consists of the following parts, under the gen-
eral title Digital data communications for measurement
and control Fieldbus for use in industrial control sys-
tems:
Part 1: Overview and guidance for the IEC 61158
series
Part 2: Physical Layer specication and service def-
inition
Part 3: Data Link Service denition
Part 4: Data Link Protocol specication
Part 5: Application Layer Service denition
Part 6: Application Layer Protocol specication
7.4 Standards
There are a wide variety of competing eldbus standards.
Some of the most widely used ones include:
AS-Interface
CAN
EtherCAT
FOUNDATION eldbus
Interbus
LonWorks
Modbus
Probus
BITBUS
CompoNet
SafetyBUS p
RAPIEnet
See List of automation protocols for more examples.
7.5 Cost advantage
The amount of cabling required is much lower in Field-
bus than in 4-20 mA installations. This is because many
devices share the same set of cables in a multi-dropped
fashion rather than requiring a dedicated set of cables
per device as in the case of 4-20 mA devices. More-
over, several parameters can be communicated per device
in a Fieldbus network whereas only one parameter can
be transmitted on a 4-20 mA connection. Fieldbus also
provides a good foundation for the creation of a predic-
tive and proactive maintenance strategy. The diagnostics
available from eldbus devices can be used to address is-
sues with devices before they become critical problems.
[4]
7.6 Networking
With the exception of ARCNET, which was conceived as
early as 1975 for oce connectivity and later found uses
in industry, the majority of eldbus standards were de-
veloped in the 1980s and became fully established in the
marketplace during the mid-1990s. In the United States,
Allen-Bradley developed standards that eventually grew
into DeviceNet and ControlNet; in Europe, Siemens and
other manufacturers developed a protocol which evolved
into PROFIBUS.
26 CHAPTER 7. FIELDBUS
During the 1980s, to solve communication problems be-
tween dierent control systems in cars, the German com-
pany Robert Bosch GmbH rst developed the Controller
Area Network (CAN). The concept of CAN was that ev-
ery device can be connected by a single set of wires, and
every device that is connected can freely exchange data
with any other device. CAN soon migrated into the fac-
tory automation marketplace (with many others).
Despite each technology sharing the generic name of
eldbus the various eldbus are not readily interchange-
able. The dierences between them are so profound that
they cannot be easily connected to each other.
[5]
To un-
derstand the dierences among eldbus standards, it is
necessary to understand how eldbus networks are de-
signed. With reference to the OSI model, eldbus stan-
dards are determined by the physical media of the ca-
bling, and layers one, two and seven of the reference
model.
For each technology the physical medium and the physi-
cal layer standards fully describe, in detail, the implemen-
tation of bit timing, synchronization, encoding/decoding,
band rate, bus length and the physical connection of the
transceiver to the communication wires. The data link
layer standard is responsible for fully specifying howmes-
sages are assembled ready for transmission by the physi-
cal layer, error handling, message-ltering and bus arbi-
tration and how these standards are to be implemented in
hardware. The application layer standard, in general de-
nes how the data communication layers are interfaced to
the application that wishes to communicate. It describes
message specications, network management implemen-
tations and response to the request fromthe application of
services. Layers three to six are not described in eldbus
standards.
[6]
Technical committees, with representatives of many dif-
ferent companies, have been responsible for turning the
original specications into international ISO standards.
Bury, among others, reports that work is underway to
implement a common eldbus protocol.
[7]
This will en-
tail a common set of application-layer services that can
be provided regardless of the lower-layer implementa-
tion details. Although very much in its infancy, it is ex-
pected that this protocol may become reality by 2010.
Whether designed for low-level sensor communications
or high-level machine connectivity (or both), a eldbus is
an important enabling technology for an open architec-
ture controller.
[8]
7.7 Features
Dierent eldbuses oer dierent sets of features and
performance. It is dicult to make a general comparison
of eldbus performance because of fundamental dier-
ences in data transfer methodology. In the comparison
table below it is simply noted if the eldbus in question
typically supports data update cycles of 1 millisecond or
faster.
7.8 Process Fieldbus vs. Device
Networks
It should be noted that requirements of eldbus networks
for process automation applications (owmeters, pressure
transmitters, and other measurement devices and control
valves in industries such as hydrocarbon processing and
power generation) are dierent from the requirements of
eldbus networks found in discrete manufacturing appli-
cations such as automotive manufacturing, where large
numbers of discrete sensors are used including motion
sensors, position sensors, and so on. Discrete eldbus
networks are often referred to as device networks.
[9]
7.9 Ethernet and Fieldbus
Recently a number of Ethernet-based industrial commu-
nication systems have been established, most of them
with extensions for real-time communication. These have
the potential to replace the traditional eldbuses in the
long term.
Here is a partial list of the new Ethernet-based industrial
communication systems:
AFDX
EtherCAT
EtherNet/IP
Ethernet Powerlink
FOUNDATION HSE
BACnet
PROFINET IO
PROFINET IRT
SafetyNET p
SERCOS III
TTEthernet
VARAN
RAPIEnet
For details, see the article on Industrial Ethernet
7.14. REFERENCES 27
7.10 Safety
Fieldbus can be used for systems which must meet safety-
relevant standards like IEC61508 or EN954-1. Depend-
ing on the actual protocol, eldbus can provide measures
like counters, CRCs, echo, timeout, unique sender and
receiver IDs or cross check. Ethernet/IP and SERCOS
III both use the CIP Safety protocol,
[10]
Ethernet Power-
link uses openSAFETY, while FOUNDATION Fieldbus
and Probus (PROFIsafe) can address SIL 2 and SIL 3
process safety applications.
In January 2006, the Fieldbus Foundation announced that
TV Rheinland Industrie Service GmbH, Automation,
Software and Information Technology, a global, indepen-
dent and accredited testing agency, had granted Protocol
Type Approval for its Safety Specications. The Founda-
tion Technical Specications - Safety Instrumented Func-
tions are in compliance with International Electrotechni-
cal Commission (IEC) 61508 standard (functional safety
of electrical/electronic/programmable electronic safety-
related systems) requirements up to, and including, Safety
Integrity Level 3 (SIL 3).
[11]
7.11 Market
In process control systems, the market is dominated
by FOUNDATION eldbus and PROFIBUS PA.
[12]
Both technologies use the same physical layer (2-wire
manchester-encoded current modulation at 31.25 kHz)
but are not interchangeable. As a general guide, applica-
tions which are controlled and monitored by PLCs (pro-
grammable logic controllers) tend towards PROFIBUS,
and applications which are controlled and monitored by
a DCS (digital/distributed control system) tend towards
FOUNDATION Fieldbus. PROFIBUS technology is
made available through Probus International with head-
quarters in Karlsruhe, Germany. FOUNDATION Field-
bus technology is owned and distributed by the Fieldbus
Foundation of Austin, Texas.
7.12 See also
Parallel Redundancy Protocol
Media Redundancy Protocol
7.13 Notes
[1] Hunziker, Robin; Schreier, Paul G. (August 1993). Field
buses compete for engineers attention, start gaining com-
mercial support. Personal Engineering & Instrumentation
News (Rye, NH: PEC Inc.) 10 (8): 3537. ISSN 0748-
0016.
[2] Zurawski, Richard, ed. (2005). Industrial Communica-
tion Technology Handbook. Industrial Technology Se-
ries 1. Boca Raton, FL: CRC Press. pp. 710. ISBN
0849330777. LCCN 2004057922. Retrieved 4 Feb
2013.
[3] Bitbus/eldbus community site.
[4] http://www.controlglobal.com/articles/2007/217.html
[5] Bury (1999)
[6] Farsi & Barbosa 2000
[7] Bury 1999
[8] Pfeier & Komischke 1987
[9] http://www.isadenver.org/docs/fieldbus.pps
[10] CIP Safety on SERCOS Specication. Retrieved 2010-
02-05.
[11] http://www.fieldbus.org/images/stories/
enduserresources/technicalreferences/documents/
wp_arc_ff-sif_908.pdf
[12] http://www.fieldbus.org/images/stories/fieldbus_report/
FieldbusReport_Apr08.pdf
7.14 References
Chatha, Andrew. (1994). Fieldbus: The Founda-
tion for Field Control Systems Control Engineer-
ing, May, 4750.
Furness, Harry. (1994). Digital Communications
Provides... Control Engineering, January, 2325.
Furness, Harry. (1994). Fieldbus: The Dierences
Start From the Bottom Up Control Engineering,
March, 4951.
Fouhy, Ken. (1993). Fieldbus Hits The Road
Chemical Engineering, September, 3741.
Johnson, Dick. (1994). The Future of Fieldbus At
Milestone 1995 Control Engineering, December,
4952.
Loose, Graham. (1994). When Can The Process
Industry Use Fieldbus? Control and Instrumenta-
tion, May, 6365.
Spear, Mike. (1993). Fieldbus Faces Up To First
Trials Process Engineering, March, p36.
Lasher, Richard J. (1994). Fieldbus Advancements
and Their Implications Control Engineering, July,
3335.
Pierson, Lynda L. (1994). Broader Fieldbus Stan-
dards Will Improve System Functionality Control
Engineering, November, 3839.
28 CHAPTER 7. FIELDBUS
Powell, James and Henry Vandelinde (2009),
'Catching the Process Fieldbus - An introduc-
tion to PROFIBUS for Process Automation' www.
measuremax.ca.
O'Neill, Mike (2007). Advances in Fieldbus, Pro-
cess Industry Informer, January, 3637.
N.P. Mahalik; P.R. Moore (1997) Fieldbus technol-
ogy based, distributed control in process industries:
a case study with LonWorks Technology
ARC Advisory Group (2008) Foundation Fieldbus
Safety Instrumented Functions Forge the Future of
Process Safety
7.15 Bibliography
Babb, Michael. (1994). Will Maintenance Learn To
Love Fieldbus? Control Engineering, January, 19.
Babb, Michael. (1994). Summer, 1994: Another
Fieldbus Delay, Schneiders DPV, and Open Sys-
tems Control Engineering, July, 29.
Gokorsch, Steve. (1994). Another Scenario: Main-
tenance Will Learn to Love Fieldbus Control Engi-
neering, June, 112114.
Gunnel, Je. (1994). Analyser Links Can Use
Fieldbus Control and Instrumentation, March, 33
35.
Hodgkinson, Geo. (1994). Communications Are
We Listening? Process Engineering, Instrumenta-
tion Supplement 1994, s19s21.
Jones, Jeremy. (1992). Can Fieldbus Survive? Con-
trol and Instrumentation, August, 2526.
Kerridge, Brian. (1994). Network Vendors Aganize
Over Fieldbus StandardEDN, April 28, 4546.
Rathje, J. (1994). Namur Says Yes To Fieldbus
Technology and the Promise of Reduces Costs Con-
trol and Instrumentation, September, 3334.
Reeve, Alan. (1993). Fieldbus Are Users In-
volved? Control and Instrumentation, August, 25
26.
Spear, Mike. (1994). A Plant View of Fieldbus In
Use Process Engineering, April, 3839.
Spear, Mike. (1994). Fieldbus Ready To Start The
Last Lap? Process Engineering, April, 37.
7.16 External links
USA: Fieldbus Foundation
Foundation Fieldbus End User Councils:
Middle East: Foundation Fieldbus End User Coun-
cil - Middle East
Australia: Foundation Fieldbus End User Council
Australia Inc
Independent organizations:
Iran: Iranian Fieldbus Foundation (written in Per-
sian)
Manufacturing Systems Integration Research Insti-
tute at Loughborough, UK
The P-NET Fieldbus
Chapter 8
CAN bus
CAN bus (for controller area network) is a vehicle bus
standard designed to allow microcontrollers and devices
to communicate with each other within a vehicle without
a host computer.
CAN bus is a message-based protocol, designed specif-
ically for automotive applications but now also used in
other areas such as aerospace, maritime, industrial au-
tomation and medical equipment.
Development of the CAN bus started originally in 1983
at Robert Bosch GmbH.
[1]
The protocol was ocially re-
leased in 1986 at the Society of Automotive Engineers
(SAE) congress in Detroit, Michigan. The rst CANcon-
troller chips, produced by Intel and Philips, came on the
market in 1987.
Bosch published several versions of the CAN specica-
tion and the latest is CAN 2.0 published in 1991. This
specication has two parts; part A is for the standard for-
mat with an 11-bit identier, and part B is for the ex-
tended format with a 29-bit identier. A CAN device
that uses 11-bit identiers is commonly called CAN 2.0A
and a CAN device that uses 29-bit identiers is com-
monly called CAN2.0B. These standards are freely avail-
able fromBosch along with other specications and white
papers.
[2]
In 1993 the International Organization for Standardiza-
tion released the CAN standard ISO 11898 which was
later restructured into two parts; ISO11898-1 which cov-
ers the data link layer, and ISO 11898-2 which covers the
CAN physical layer for high-speed CAN. ISO 11898-3
was released later and covers the CAN physical layer for
low-speed, fault-tolerant CAN. The physical layer stan-
dards ISO 11898-2 and ISO 11898-3 are not part of the
Bosch CAN 2.0 specication. These standards may be
purchased from the International Organization for Stan-
dardization (ISO).
[3]
CAN in Automation (CiA) also published CAN stan-
dards; CAN Specication 2.0 part A and part B, but their
status is now obsolete (substituted by ISO 11898-1).
[4]
Bosch is still active in extending the CAN standards. In
2012 Bosch released CAN FD 1.0 or CAN with Flexi-
ble Data-Rate. This specication uses a dierent frame
format that allows a dierent data length as well as op-
tionally switching to a faster bit rate after the arbitration
is decided. CAN FD is compatible with existing CAN
2.0 networks so new CAN FD devices can coexist on the
same network with existing CAN devices.
CAN bus is one of ve protocols used in the on-board
diagnostics (OBD)-II vehicle diagnostics standard. The
OBD-II standard has been mandatory for all cars and
light trucks sold in the United States since 1996, and the
EOBD standard has been mandatory for all petrol vehi-
cles sold in the European Union since 2001 and all diesel
vehicles since 2004.
[5]
8.1 Applications
8.1.1 Automotive
The modern automobile may have as many as 70
electronic control units (ECU) for various subsystems.
[6]
Typically the biggest processor is the engine control unit.
Others are used for transmission, airbags, antilock brak-
ing/ABS, cruise control, electric power steering, audio
systems, power windows, doors, mirror adjustment, bat-
tery and recharging systems for hybrid/electric cars, etc.
Some of these formindependent subsystems, but commu-
nications among others are essential. A subsystem may
need to control actuators or receive feedback from sen-
sors. The CAN standard was devised to ll this need.
8.1.2 Industrial
Today the CAN bus is also used as a eldbus in general
automation environments, primarily due to the low cost
of some CAN controllers and processors.
8.2 Architecture
CAN is a multi-master serial bus standard for connecting
Electronic Control Units [ECUs] also known as nodes.
Two or more nodes are required on the CAN network
to communicate. The complexity of the node can range
from a simple I/O device up to an embedded computer
with a CAN interface and sophisticated software. The
29
30 CHAPTER 8. CAN BUS
node may also be a gateway allowing a standard computer
to communicate over a USB or Ethernet port to the de-
vices on a CAN network.
CANbus Node
Each node requires a:
Central processing unit, microprocessor, or host
processor
The host processor decides what the received
messages mean and what messages it wants to
transmit.
Sensors, actuators and control devices can be
connected to the host processor.
CAN controller; often an integral part of the micro-
controller
Receiving: the CAN controller stores the re-
ceived serial bits from the bus until an en-
tire message is available, which can then be
fetched by the host processor (usually by the
CAN controller triggering an interrupt).
Sending: the host processor sends the transmit
message(s) to a CAN controller, which trans-
mits the bits serially onto the bus when the bus
is free.
Transceiver Dened by ISO11898-2/3 MediumAc-
cess Unit [MAU] standards
Receiving: it converts the data stream from
CANbus levels to levels that the CAN con-
troller uses. It usually has protective circuitry
to protect the CAN controller.
Transmitting: it converts the data stream from
the CAN controller to CANbus levels.
Each node is able to send and receive messages, but not
simultaneously. A message or Frame consists primarily
of the ID (identier), which represents the priority of the
message, and up to eight data bytes. A CRC, acknowl-
edge slot [ACK] and other overhead are also part of the
message. The improved CAN FD extends the length of
the data section to up to 64 bytes per frame. The message
is transmitted serially onto the bus using a non-return-to-
zero (NRZ) format and may be received by all nodes.
The devices that are connected by a CAN network are
typically sensors, actuators, and other control devices.
These devices are connected to the bus through a host
processor, a CAN controller, and a CAN transceiver.
8.3 Data transmission
CANdata transmission uses a lossless bit-wise arbitration
method of contention resolution. This arbitration method
requires all nodes on the CAN network to be synchro-
nized to sample every bit on the CANnetwork at the same
time. This is why some call CAN synchronous. Unfor-
tunately the term synchronous is imprecise since the data
is transmitted without a clock signal in an asynchronous
format.
The exact voltages for a logical 0 or 1 depend on the phys-
ical layer used, but the basic principle of CAN requires
that each node listen to the data on the CAN network in-
cluding the data that the transmitting node is transmitting.
If a logical 1 is transmitted by all transmitting nodes at the
same time a logical 1 is seen by all of the nodes, including
both the transmitting node(s) and receiving node(s). If a
logical 0 is transmitted by all transmitting node(s) at the
same time then a logical 0 is seen by all nodes. If a logical
0 is being transmitted by one or more nodes, and a logical
1 is being transmitted by one or more nodes, then a logical
0 is seen by all nodes including the node(s) transmitting
the logical 1. When a node transmits a logical 1 but sees
a logical 0, it realizes that there is a contention and it quits
transmitting. By using this process, any node that trans-
mits a logical 1 when another node transmits a logical 0
drops out or loses the arbitration. A node that loses ar-
bitration re-queues its message for later transmission and
the CAN frame bit-stream continues without error until
only one node is left transmitting. This means that the
node that transmits the rst 1 loses arbitration. Since the
11 (or 29 for CAN 2.0B) bit identier is transmitted by
all nodes at the start of the CAN frame, the node with the
lowest identier transmits more zeros at the start of the
frame, and that is the node that wins the arbitration or has
the highest priority.
The CAN specications use the terms dominant bits
and recessive bits where dominant is a logical 0 (ac-
tively driven to a voltage by the transmitter) and recessive
is a logical 1 (passively returned to a voltage by a resis-
tor). The idle state is represented by the recessive level
(Logical 1). If one node transmits a dominant bit and an-
other node transmits a recessive bit then the dominant bit
8.5. BIT TIMING 31
wins (a logical AND between the two).
So, if a recessive bit is being transmitted while a domi-
nant bit is sent, the dominant bit is displayed, evidence of
a collision. (All other collisions are invisible.) A domi-
nant bit is asserted by creating a voltage across the wires
while a recessive bit is simply not asserted on the bus.
If any node sets a voltage dierence, all nodes will see it.
Thus there is no delay to the higher priority messages, and
the node transmitting the lower priority message automat-
ically attempts to re-transmit six bit clocks after the end
of the dominant message. This makes CAN very suitable
as a real time prioritized communications system.
During arbitration, each transmitting node monitors the
bus state and compares the received bit with the trans-
mitted bit. If a dominant bit is received when a recessive
bit is transmitted then the node stops transmitting (i.e.,
it lost arbitration). Arbitration is performed during the
transmission of the identier eld. Each node starting to
transmit at the same time sends an ID with dominant as
binary 0, starting from the high bit. As soon as their ID
is a larger number (lower priority) they will be sending 1
(recessive) and see 0 (dominant), so they back o. At the
end of IDtransmission, all nodes but one have backed o,
and the highest priority message gets through unimpeded.
For example, consider an 11-bit ID CAN network,
with two nodes with IDs of 15 (binary represen-
tation, 00000001111) and 16 (binary representation,
00000010000). If these two nodes transmit at the same
time, each will transmit the rst six zeros of their ID with
no arbitration decision being made. When the 7th bit is
transmitted, the node with the ID of 16 transmits a 1 (re-
cessive) for its ID, and the node with the ID of 15 trans-
mits a 0 (dominant) for its ID. When this happens, the
node with the ID of 16 will realize that it lost its arbi-
tration, and allow the node with ID of 15 to continue its
transmission. This ensures that the node with the lower
bit value will always win the arbitration. The ID with the
smaller number will win the right to use.
Bit rates up to 1 Mbit/s are possible at network lengths
below 40 m. Decreasing the bit rate allows longer net-
work distances (e.g., 500 m at 125 kbit/s). The improved
CAN FD extends the speed of the data section by a factor
of up to 8 of the arbitration bit rate.
8.4 ID allocation
Message IDs must be unique on a single CAN bus, other-
wise two nodes would continue transmission beyond the
end of the arbitration eld (ID) causing an error.
In the early 1990s, the choice of IDs for messages was
done simply on the basis of identifying the type of data
and the sending node; however, as the ID is also used
as the message priority, this led to poor real-time per-
formance. In those scenarios, a low CAN bus utilization
of circa 30% was commonly required to ensure that all
messages would meet their deadlines. However, if IDs
are instead determined based on the deadline of the mes-
sage, the lower the numerical ID and hence the higher the
message priority, then bus utilizations of 70 to 80% can
typically be achieved before any message deadlines are
missed.
8.5 Bit timing
Each node in a CAN network has its own clock, and no
clock is sent during data transmission. Synchronization
is done by dividing each bit of the frame into a number
of segments: synchronization, propagation, phase 1 and
phase 2. The length of each phase segment can be ad-
justed based on network and node conditions. The sam-
ple point falls between phase buer segment 1 and phase
buer segment 2, which helps facilitate continuous syn-
chronization. Continuous synchronization in turn enables
the receiver to be able to properly read the messages.
Sync Prop Phase 1 Phase 2
Nominal Bit Time
Time Quanta
Sample Point
previous bit next bit
An example CAN bit timing with 10 time quanta per bit.
8.6 Layers
The CAN protocol, like many networking protocols, can
be decomposed into the following abstraction layers:
Application layer
Object layer
Message ltering
Message and status handling
Transfer layer
Most of the CAN standard applies to the transfer layer.
The transfer layer receives messages from the physi-
cal layer and transmits those messages to the object
layer. The transfer layer is responsible for bit timing and
synchronization, message framing, arbitration, acknowl-
edgement, error detection and signalling, and fault con-
nement. It performs:
Fault Connement
Error Detection
32 CHAPTER 8. CAN BUS
Message Validation
Acknowledgement
Arbitration
Message Framing
Transfer Rate and Timing
Information Routing
Physical layer
CAN-Hi
CAN-Low
SG
1
SG
2
SG
n
CAN bus electrical sample topology with terminator resistors
CAN bus (ISO 118981:2003) originally specied the
link layer protocol with only abstract requirements for
the physical layer, e.g., asserting the use of a medium
with multiple-access at the bit level through the use of
dominant and recessive states. The electrical aspects of
the physical layer (voltage, current, number of conduc-
tors) were specied in ISO 118982:2003, which is now
widely accepted. However, the mechanical aspects of the
physical layer (connector type and number, colors, labels,
pin-outs) have yet to be formally specied. As a result, an
automotive ECU will typically have a particularoften
customconnector with various sorts of cables, of which
two are the CAN bus lines. Nonetheless, several de facto
standards for mechanical implementation have emerged,
the most common being the 9-pin D-sub type male con-
nector with the following pin-out:
pin 2: CAN-Low (CAN-)
pin 3: GND (Ground)
pin 7: CAN-High (CAN+)
pin 9: CAN V+ (Power)
This de facto mechanical standard for CAN could be im-
plemented with the node having both male and female
9-pin D-sub connectors electrically wired to each other
in parallel within the node. Bus power is fed to a nodes
male connector and the bus draws power from the nodes
female connector. This follows the electrical engineering
convention that power sources are terminated at female
connectors. Adoption of this standard avoids the need
to fabricate custom splitters to connect two sets of bus
wires to a single D connector at each node. Such non-
standard (custom) wire harnesses (splitters) that join con-
ductors outside the node reduce bus reliability, eliminate
cable interchangeability, reduce compatibility of wiring
harnesses, and increase cost.
The absence of a complete physical layer specication
(mechanical in addition to electrical) freed the CAN
bus specication from the constraints and complexity of
physical implementation. However it left CAN bus im-
plementations open to inter-interoperability issues due to
mechanical incompatibility.
Noise immunity on ISO 118982:2003 is achieved by
maintaining the dierential impedance of the bus at a
low level with low-value resistors (120 ohms) at each end
of the bus. However, when dormant, a low-impedance
bus such as CAN draws more current (and power) than
other voltage-based signaling busses. On CAN bus sys-
tems, balanced line operation, where current in one signal
line is exactly balanced by current in the opposite direc-
tion in the other signal provides an independent, stable 0
V reference for the receivers. Best practice determines
that CAN bus balanced pair signals be carried in twisted
pair wires in a shielded cable to minimize RF emission
and reduce interference susceptibility in the already noisy
RF environment of an automobile.
ISO118982 provides some immunity to common mode
voltage between transmitter and receiver by having a 0 V
rail running along the bus to maintain a high degree of
voltage association between the nodes. Also, in the de
facto mechanical conguration mentioned above, a sup-
ply rail is included to distribute power to each of the
transceiver nodes. The design provides a common supply
for all the transceivers. The actual voltage to be applied
by the bus and which nodes apply to it are application-
specic and not formally specied. Common practice
node design provides each node with transceivers which
are optically isolated from their node host and derive a
5 V linearly regulated supply voltage for the transceivers
from the universal supply rail provided by the bus. This
usually allows operating margin on the supply rail su-
cient to allow interoperability across many node types.
Typical values of supply voltage on such networks are 7
to 30 V. However, the lack of a formal standard means
that system designers are responsible for supply rail com-
patibility.
ISO 118982 describes the electrical implementation
formed from a multi-dropped single-ended balanced line
conguration with resistor termination at each end of the
bus. In this conguration a dominant state is asserted by
one or more transmitters switching the CAN- to supply
0 V and (simultaneously) switching CAN+ to the +5 V
bus voltage thereby forming a current path through the
resistors that terminate the bus. As such the terminating
resistors form an essential component of the signalling
system and are included not just to limit wave reection
at high frequency.
8.7. FRAMES 33
During a recessive state the signal lines and resistor(s) re-
main in a high impedances state with respect to both rails.
Voltages on both CAN+ and CAN- tend (weakly) towards
rail voltage. A recessive state is only present on the bus
when none of the transmitters on the bus is asserting a
dominant state.
During a dominant state the signal lines and resistor(s)
move to a low impedance state with respect to the rails
so that current ows through the resistor. CAN+ voltage
tends to +5 V and CAN- tends to 0 V.
Irrespective of signal state the signals lines are always in
low impedance state with respect to one another by virtue
of the terminating resistors at the end of the bus.
This signalling strategy diers signicantly from other
balanced line transmission technologies such as RS-
422/3, RS-485, etc. which employ dierential line
drivers/ receivers and use a signalling systembased on the
dierential mode voltage of the balanced line crossing a
notional 0 V. Multiple access on such systems normally
relies on the media supporting three states (active high,
active low and inactive tri-state) and is dealt with in the
time domain. Multiple access on CAN bus is achieved
by the electrical logic of the system supporting just two
states that are conceptually analogous to a wired OR net-
work.
8.7 Frames
A CAN network can be congured to work with two dif-
ferent message (or frame) formats: the standard or base
frame format (described in CAN 2.0 A and CAN 2.0 B),
and the extended frame format (only described by CAN
2.0 B). The only dierence between the two formats is
that the CAN base frame supports a length of 11 bits
for the identier, and the CAN extended frame sup-
ports a length of 29 bits for the identier, made up of
the 11-bit identier (base identier) and an 18-bit ex-
tension (identier extension). The distinction between
CAN base frame format and CAN extended frame for-
mat is made by using the IDE bit, which is transmitted as
dominant in case of an 11-bit frame, and transmitted as
recessive in case of a 29-bit frame. CAN controllers that
support extended frame format messages are also able to
send and receive messages in CAN base frame format.
All frames begin with a start-of-frame (SOF) bit that de-
notes the start of the frame transmission.
CAN has four frame types:
Data frame: a frame containing node data for trans-
mission
Remote frame: a frame requesting the transmission
of a specic identier
Error frame: a frame transmitted by any node de-
tecting an error
Overload frame: a frame to inject a delay between
data and/or remote frame
8.7.1 Data frame
The data frame is the only frame for actual data transmis-
sion. There are two message formats:
Base frame format: with 11 identier bits
Extended frame format: with 29 identier bits
The CAN standard requires the implementation must ac-
cept the base frame format and may accept the extended
frame format, but must tolerate the extended frame for-
mat.
Base frame format
DATA
CAN
HI
CAN
LO
Arbitration Field Control Data CRC Field End of Frame
Complete CAN Frame
0000000101000000001000000010100001100000001011111111111
11 4 8 15
S
ta
rt o
f F
ra
m
e
ID
1
0
ID
9
ID
8
ID
7
ID
6
ID
5
ID
4
ID
3
ID
2
ID
1
ID
0
R
e
q
u
. R
e
m
o
te
ID
E
x
t. B
it
R
e
s
e
rv
e
d
D
L
3
D
L
2
D
L
1
D
L
0
D
B
7
D
B
6
D
B
5
D
B
4
D
B
3
D
B
2
D
B
1
D
B
0
C
R
C
1
0
C
R
C
9
C
R
C
8
C
R
C
7
C
R
C
6
C
R
C
5
C
R
C
4
C
R
C
3
C
R
C
2
C
R
C
1
C
R
C
0
C
R
C
1
4
C
R
C
1
3
C
R
C
1
2
C
R
C
1
1
C
R
C
D
e
lim
ite
r
A
c
k
n
o
w
. S
lo
t B
it
A
c
k
n
o
w
. D
e
lim
ite
r
E
O
F
6
E
O
F
5
E
O
F
4
E
O
F
3
E
O
F
2
E
O
F
1
E
O
F
0
IF
S
2
IF
S
1
IF
S
0
CAN-Frame in base format with electrical levels without stubits
The frame format is as follows:
[1] It is physically possible for a value between 915 to be
transmitted in the 4-bit DLC, although the data is still lim-
ited to eight bytes. Certain controllers allow the transmis-
sion and/or reception of a DLC greater than eight, but the
actual data length is always limited to eight bytes.
Extended frame format
The frame format is as follows:
[1] It is physically possible for a value between 915 to be
transmitted in the 4-bit DLC, although the data is still lim-
ited to eight bytes. Certain controllers allow the transmis-
sion and/or reception of a DLC greater than eight, but the
actual data length is always limited to eight bytes.
The two identier elds (A&B) combine to forma 29-bit
identier.
8.7.2 Remote frame
Generally data transmission is performed on an au-
tonomous basis with the data source node (e.g., a
sensor) sending out a Data Frame. It is also possi-
ble, however, for a destination node to request the
data from the source by sending a Remote Frame.
34 CHAPTER 8. CAN BUS
There are two dierences between a Data Frame and
a Remote Frame. Firstly the RTR-bit is transmitted
as a dominant bit in the Data Frame and secondly in
the Remote Frame there is no Data Field.
i.e.,
RTR = 0 ; DOMINANT in data frame
RTR = 1 ; RECESSIVE in remote frame
In the very unlikely event of a Data Frame and a Remote
Frame with the same identier being transmitted at the
same time, the Data Frame wins arbitration due to the
dominant RTR bit following the identier. In this way,
the node that transmitted the Remote Frame receives the
desired data immediately.
8.7.3 Error frame
The error frame consists of two dierent elds:
The rst eld is given by the superposition of ER-
ROR FLAGS (612 dominant/recessive bits) con-
tributed from dierent stations.
The following second eld is the ERROR DELIM-
ITER (8 recessive bits).
There are two types of error ags:
Active Error Flag six dominant bits Transmitted by
a node detecting an error on the network that is in
error state error active.
Passive Error Flag six recessive bits Transmitted by a
node detecting an active error frame on the network
that is in error state error passive.
8.7.4 Overload frame
The overload frame contains the two bit elds Overload
Flag and Overload Delimiter. There are two kinds of
overload conditions that can lead to the transmission of
an overload ag:
1. The internal conditions of a receiver, which requires
a delay of the next data frame or remote frame.
2. Detection of a dominant bit during intermission.
The start of an overload frame due to case 1 is only al-
lowed to be started at the rst bit time of an expected
intermission, whereas overload frames due to case 2 start
one bit after detecting the dominant bit. Overload Flag
consists of six dominant bits. The overall form corre-
sponds to that of the active error ag. The overload ags
form destroys the xed form of the intermission eld. As
a consequence, all other stations also detect an overload
condition and on their part start transmission of an over-
load ag. Overload Delimiter consists of eight recessive
bits. The overload delimiter is of the same form as the
error delimiter.
8.8 Interframe spacing
Data frames and remote frames are separated from pre-
ceding frames by a bit eld called interframe space. In-
terframe space consists of at least three consecutive re-
cessive (1) bits. Following that, if a dominant bit is de-
tected, it will be regarded as the Start of frame bit of
the next frame. Overload frames and error frames are not
preceded by an interframe space and multiple overload
frames are not separated by an interframe space. Inter-
frame space contains the bit elds intermission and bus
idle, and suspend transmission for error passive stations,
which have been transmitter of the previous message.
[7]
8.9 Bit stung
In CAN frames, a bit of opposite polarity is inserted af-
ter ve consecutive bits of the same polarity. This prac-
tice is called bit stung, and is due to the non-return to
zero (NRZ) coding adopted. The stued data frames are
destued by the receiver. Since bit stung is used, six
consecutive bits of the same type (111111 or 000000)
are considered an error.
Bit stung implies that sent data frames could be larger
than one would expect by simply enumerating the bits
shown in the tables above.
8.10 Standards
The CAN data link layer protocol is standardized in
ISO 118981 (2003).
[8]
This standard describes mainly
the data link layer (composed of the logical link con-
trol (LLC) sublayer and the media access control (MAC)
sublayer) and some aspects of the physical layer of the
OSI reference model. All the other protocol layers are
the network designers choice.
There are several CANphysical layer and other standards:
ISO 118981: CAN Data Link Layer and Physical
Signalling
ISO 118982: CAN High-Speed Medium Access
Unit
ISO 11898-2 uses a two-wire
balanced signalling scheme. It is
8.11. HIGHER LAYER IMPLEMENTATIONS 35
the most used physical layer in
car powertrain applications and
industrial control networks.
ISO 118983: CAN Low-Speed, Fault-Tolerant,
Medium-Dependent Interface
ISO 118984: CAN Time-Triggered Communica-
tion
ISO 11898-4 standard denes the
time-triggered communication on
CAN (TTCAN). It is based on
the CAN data link layer protocol
providing a system clock for the
scheduling of messages.
ISO 118985: CAN High-Speed Medium Access
Unit with Low-Power Mode
ISO 118986: CAN High-speed medium access
unit with selective wake-up functionality
ISO 119921: CAN fault-tolerant for truck/trailer
communication
ISO 117832: 250 kbit/s, Agricultural Standard
ISO 11783-2 uses four unshielded
twisted wires; two for CANand two
for terminating bias circuit (TBC)
power and ground. This bus is used
on agricultural tractors. This bus is
intended to provide interconnectiv-
ity with any implementation adher-
ing to the standard.
ISO 15765-2, also called ISO-TP, is a standard for
ow control and handling of messages larger than
eight bytes.
SAE J193911: 250 kbit/s, Shielded Twisted Pair
(STP)
SAE J1939-15: 250 kbit/s, Unshielded Twisted Pair
(UTP) (reduced layer)
The SAE J1939 standard uses a
two-wire twisted pair, 11 has a
shield around the pair while 15
does not. SAE 1939 denes also
application data and is widely used
in heavy-duty (truck) and autobus
industry as well as in agricultural &
construction equipment.
SAE J2411: Single-wire CAN (SWC)
8.11 Higher layer implementations
As the CAN standard does not include tasks of applica-
tion layer protocols, such as ow control, device address-
ing, and transportation of data blocks larger than one mes-
sage, and above all, application data, many implementa-
tions of higher layer protocols were created. Several are
standardised for a business area, although all can be ex-
tended by each manufacturer. For passenger cars, each
manufacturer has its own standard. Among these imple-
mentations are:
ARINC 825 (for the aviation industry)
CANaerospace (for the aviation industry)
CAN Kingdom
CANopen (used for industrial automation)
CCP / XCP
DeviceNet (used for industrial automation)
EnergyBus (used for electrical vehicles)
GMLAN (for General Motors)
ISO 15765-4
ISO 11783 or ISOBUS (agriculture)
ISO 14229
SAE J1939 (heavy road vehicles)
ISO 11992 for heavy trailers
MilCAN
NMEA 2000 (marine industry)
RV-C (used for recreational vehicles)
SafetyBUS p (used for industrial automation)
SmartCraft
Smart Distributed System (SDS)
VSCP (used for building automation)
8.12 Security
CAN is a low-level protocol, and does not support any
security features intrinsically. Applications are expected
to deploy their own security mechanisms; e.g., to authen-
ticate each other. Failure to do so may result in various
sorts of attacks, if the opponent manages to insert mes-
sages on the bus.
[9]
Password mechanisms exist for data
transfer that can modify the control unit software, like
software download or ignition key codes, but usually not
for standard communication.
36 CHAPTER 8. CAN BUS
8.13 Development tools
When developing and/or troubleshooting the CAN bus,
examination of hardware signals can be very important.
Logic analyzers and bus analyzers are tools which collect,
analyse, decode and store signals so people can view the
high-speed waveforms at their leisure. There are also spe-
cialist tools as well as CAN bus monitors.
8.14 Licensing
Bosch holds patents on the technology, and manufactur-
ers of CAN-compatible microprocessors pay license fees
to Bosch, which are normally passed on to the customer in
the price of the chip. Manufacturers of products with cus-
tom ASICs or FPGAs containing CAN-compatible mod-
ules may need to pay a fee for the CAN Protocol License.
8.15 See also
Byteight
Car audio
CAN bus monitor - List of software applications to
monitor the activity on the CAN bus
can4linux Open Source Linux device driver for
CAN
FlexCAN An alternative implementation.
FlexRay A possible future direction
List of network buses
Local Interconnect Network A low cost alterna-
tive.
OBD-II PIDs - List of Parameter IDs
OSEK
SocketCAN a set of open source CAN drivers and
a networking stack contributed by Volkswagen Re-
search to the Linux kernel.
8.16 References
[1] CAN History. CAN in Automation.
[2] Bosch Semiconductor CAN Literature
[3] International Organization for Standardization
[4] CAN in Automation (CiA) Other specications
[5] Building Adapter for Vehicle On-board Diagnostic, obd-
diag.net, accessed 2009-09-09
[6] Comparison of Event-Triggered and Time-Triggered
Concepts with Regard to Distributed Control Systems A.
Albert, Robert Bosch GmbH Embedded World, 2004,
Nrnberg
[7] CANBUS MESSAGE FRAMES Overload Frame, In-
terframe Space.
[8] ISO 11898-1:2003 abtract
[9] We Drove a Car While It Was Being Hacked
8.17 External links
Wiki on CAN technology and products
Bosch specication (old document slightly am-
biguous/unclear in some points, superseded by the
standard ISO 11898)
Bosch CAN FD Specication Version 1.0
Controller Area Network (CAN) Schedulability
Analysis: Refuted, Revisited and Revised
Pinouts for common CAN bus connectors
Independent discussion platform CANLIST
Free Tutorials and Low cost development tools
A webpage about CAN in automotive
Controller Area Network (CAN) Schedulability
Analysis with FIFO Queues
Controller Area Network (CAN) Implementation
Guide
Free Tutorial: Controller Area Network (CAN) In-
troduction and Fundamentals
Freeware Bit-Timing calculator for Windows, sup-
ports a lot of microcontrollers, e.g. Atmel, STM32,
Microchip, Renesas, ... (ZIPle)
CAN Protocol Tutorial
Chapter 9
Ethernet
A Cat 5e connection on a laptop, used for Ethernet
Ethernet /irnt/ is a family of computer networking
technologies for local area (LAN) and larger networks.
It was commercially introduced in 1980 while it was rst
standardized in 1983 as IEEE802.3,
[1]
and has since been
rened to support higher bit rates and longer link dis-
tances. Over time, Ethernet has largely replaced compet-
ing wired LAN technologies such as token ring, FDDI,
and ARCNET. The primary alternative for contemporary
LANs is not a wired standard, but instead a wireless LAN
standardized as IEEE 802.11 and also known as Wi-Fi.
The Ethernet standards comprise several wiring and sig-
naling variants of the OSI physical layer in use with Eth-
ernet. The original 10BASE5 Ethernet used coaxial ca-
ble as a shared medium. Later the coaxial cables were
replaced with twisted pair and ber optic links in con-
junction with hubs or switches. Data rates have been in-
crementally increased from the original 3 megabits per
second experimental version to a 100 gigabits per second
standard over its history.
Systems communicating over Ethernet divide a stream of
data into shorter pieces called frames. Each frame con-
tains source and destination addresses and error-checking
data so that damaged data can be detected and re-
transmitted. As per the OSI model, Ethernet provides
services up to and including the data link layer.
Since its commercial release, Ethernet has retained a
good degree of backward compatibility. Features such
as the 48-bit MAC address and Ethernet frame format
have inuenced other networking protocols.
9.1 History
An 8P8C modular connector (often called RJ45) commonly used
on Cat 5 cables in Ethernet networks
Ethernet was developed at Xerox PARC between 1973
and 1974.
[2][3]
It was inspired by ALOHAnet, which
Robert Metcalfe had studied as part of his PhD
dissertation.
[4]
The idea was rst documented in a memo
that Metcalfe wrote on May 22, 1973, where he named
it after the disproven luminiferous ether as an om-
nipresent, completely-passive medium for the propaga-
tion of electromagnetic waves.
[2][5][6]
In 1975, Xerox
led a patent application listing Metcalfe, David Boggs,
Chuck Thacker, and Butler Lampson as inventors.
[7]
In
1976, after the system was deployed at PARC, Metcalfe
and Boggs published a seminal paper.
[8][lower-alpha 1]
Metcalfe left Xerox in June 1979 to form 3Com.
[2][10]
He convinced Digital Equipment Corporation (DEC),
Intel, and Xerox to work together to promote Ethernet
as a standard. The so-called DIX standard, for Digi-
tal/Intel/Xerox, specied 10 Mbit/s Ethernet, with 48-
bit destination and source addresses and a global 16-
bit Ethertype-type eld. It was published on Septem-
37
38 CHAPTER 9. ETHERNET
ber 30, 1980 as The Ethernet, A Local Area Network.
Data Link Layer and Physical Layer Specications.
[11]
Version 2 was published in November, 1982
[12]
and de-
nes what has become known as Ethernet II. Formal
standardization eorts proceeded at the same time and
resulted in the publication of IEEE 802.3 on June 23,
1983.
[1]
Ethernet initially competed with two largely proprietary
systems, Token Ring and Token Bus. Because Ether-
net was able to adapt to market realities and shift to
inexpensive and ubiquitous twisted pair wiring, these
proprietary protocols soon found themselves competing
in a market inundated by Ethernet products, and, by
the end of the 1980s, Ethernet was clearly the domi-
nant network technology.
[2]
In the process, 3Com be-
came a major company. 3Com shipped its rst 10 Mbit/s
Ethernet 3C100 transceiver in March 1981, and that
year started selling adapters for PDP-11s and VAXes,
as well as Multibus-based Intel and Sun Microsystems
computers.
[13]:9
This was followed quickly by DECs
Unibus to Ethernet adapter, which DEC sold and used
internally to build its own corporate network, which
reached over 10,000 nodes by 1986, making it one of the
largest computer networks in the world at that time.
[14]
An Ethernet adapter card for the IBM PC was released in
1982, and, by 1985, 3Com had sold 100,000.
[10]
Since then, Ethernet technology has evolved to meet
new bandwidth and market requirements.
[15]
In addi-
tion to computers, Ethernet is now used to interconnect
appliances and other personal devices.
[2]
It is used in
industrial applications and is quickly replacing legacy data
transmission systems in the worlds telecommunications
networks.
[16]
By 2010, the market for Ethernet equipment
amounted to over $16 billion per year.
[17]
9.2 Standardization
An Intel 82574L Gigabit Ethernet NIC, PCI Express x1 card
In February 1980, the Institute of Electrical and Electron-
ics Engineers (IEEE) started project 802 to standardize
local area networks (LAN).
[10][18]
The DIX-group with
Gary Robinson (DEC), Phil Arst (Intel), and Bob Printis
(Xerox) submitted the so-called Blue Book CSMA/CD
specication as a candidate for the LAN specication.
[11]
In addition to CSMA/CD, Token Ring (supported by
IBM) and Token Bus (selected and henceforward sup-
ported by General Motors) were also considered as can-
didates for a LAN standard. Competing proposals and
broad interest in the initiative led to strong disagree-
ment over which technology to standardize. In December
1980, the group was split into three subgroups, and stan-
dardization proceeded separately for each proposal.
[10]
Delays in the standards process put at risk the market
introduction of the Xerox Star workstation and 3Coms
Ethernet LAN products. With such business implications
in mind, David Liddle (General Manager, Xerox Oce
Systems) and Metcalfe (3Com) strongly supported a pro-
posal of Fritz Rscheisen (Siemens Private Networks)
for an alliance in the emerging oce communication
market, including Siemens support for the international
standardization of Ethernet (April 10, 1981). Ingrid
Fromm, Siemens representative to IEEE 802, quickly
achieved broader support for Ethernet beyond IEEE by
the establishment of a competing Task Group Local
Networks within the European standards body ECMA
TC24. As early as March 1982 ECMA TC24 with its
corporate members reached agreement on a standard for
CSMA/CD based on the IEEE 802 draft.
[13]:8
Because
the DIX proposal was most technically complete and be-
cause of the speedy action taken by ECMA which de-
cisively contributed to the conciliation of opinions within
IEEE, the IEEE802.3 CSMA/CDstandard was approved
in December 1982.
[10]
IEEE published the 802.3 stan-
dard as a draft in 1983 and as a standard in 1985.
[19]
Approval of Ethernet on the international level was
achieved by a similar, cross-partisan action with Fromm
as liaison ocer working to integrate International Elec-
trotechnical Commission, TC83 and International Orga-
nization for Standardization (ISO) TC97SC6, and the
ISO/IEEE 802/3 standard was approved in 1984.
9.3 Evolution
Ethernet evolved to include higher bandwidth, improved
media access control methods, and dierent physical me-
dia. The coaxial cable was replaced with point-to-point
links connected by Ethernet repeaters or switches to re-
duce installation costs, increase reliability, and improve
management and troubleshooting. Many variants of Eth-
ernet remain in common use.
Ethernet stations communicate by sending each other
data packets: blocks of data individually sent and deliv-
ered. As with other IEEE 802 LANs, each Ethernet sta-
tion is given a 48-bit MAC address. The MAC addresses
are used to specify both the destination and the source of
9.3. EVOLUTION 39
each data packet. Ethernet establishes link level connec-
tions, which can be dened using both the destination and
source addresses. On reception of a transmission, the re-
ceiver uses the destination address to determine whether
the transmission is relevant to the station or should be ig-
nored. Network interfaces normally do not accept pack-
ets addressed to other Ethernet stations. Adapters come
programmed with a globally unique address.
[lower-alpha 2]
An EtherType eld in each frame is used by the operat-
ing system on the receiving station to select the appro-
priate protocol module (e.g., an Internet Protocol ver-
sion such as IPv4). Ethernet frames are said to be self-
identifying, because of the frame type. Self-identifying
frames make it possible to intermix multiple protocols on
the same physical network and allow a single computer to
use multiple protocols together.
[20]
Despite the evolution
of Ethernet technology, all generations of Ethernet (ex-
cluding early experimental versions) use the same frame
formats
[21]
(and hence the same interface for higher lay-
ers), and can be readily interconnected through bridging.
Due to the ubiquity of Ethernet, the ever-decreasing cost
of the hardware needed to support it, and the reduced
panel space needed by twisted pair Ethernet, most man-
ufacturers now build Ethernet interfaces directly into PC
motherboards, eliminating the need for installation of a
separate network card.
[22]
9.3.1 Shared media
Ethernet was originally based on the idea of computers
communicating over a shared coaxial cable acting as a
broadcast transmission medium. The methods used were
similar to those used in radio systems,
[lower-alpha 3]
with
the common cable providing the communication chan-
nel likened to the Luminiferous aether in 19th century
physics, and it was fromthis reference that the name Eth-
ernet was derived.
[23]
Original Ethernets shared coaxial cable (the shared
medium) traversed a building or campus to every at-
tached machine. A scheme known as carrier sense multi-
ple access with collision detection (CSMA/CD) governed
the way the computers shared the channel. This scheme
was simpler than the competing token ring or token bus
technologies.
[lower-alpha 4]
Computers were connected to an
Attachment Unit Interface (AUI) transceiver, which was
in turn connected to the cable (later with thin Ethernet
the transceiver was integrated into the network adapter).
While a simple passive wire was highly reliable for small
networks, it was not reliable for large extended networks,
where damage to the wire in a single place, or a single
bad connector, could make the whole Ethernet segment
unusable.
[lower-alpha 5]
Through the rst half of the 1980s, Ethernets 10BASE5
implementation used a coaxial cable 0.375 inches (9.5
mm) in diameter, later called thick Ethernet or thick-
net. Its successor, 10BASE2, called thin Ethernet or
10BASE5 Ethernet equipment. Clockwise from top-left: A late-
model transceiver with an in-line 10BASE2 adapter, a simi-
lar model transceiver with a 10BASE5 adapter, an AUI ca-
ble, a dierent style of transceiver with 10BASE2 T-connector,
two 10BASE5 end ttings, an orange vampire tap installa-
tion tool (which includes a specialized drill bit at one end and
a socket wrench at the other), and an early model 10BASE5
transceiver (h4000) manufactured by DEC. The short length of
yellow 10BASE5 cable has one end terminated and the other end
prepared to have a termination tting installed; the half-black,
half-grey rectangular object through which the cable passes is an
installed vampire tap.
thinnet, used a cable similar to cable television cable of
the era. The emphasis was on making installation of the
cable easier and less costly.
Since all communications happen on the same wire,
any information sent by one computer is received by
all, even if that information is intended for just one
destination.
[lower-alpha 6]
The network interface card in-
terrupts the CPU only when applicable packets are re-
ceived: The card ignores information not addressed to
it.
[lower-alpha 7]
Use of a single cable also means that the
bandwidth is shared, such that, for example, available
bandwidth to each device is halved when two stations are
simultaneously active.
Collisions happen when two stations attempt to transmit
at the same time. They corrupt transmitted data and re-
quire stations to retransmit. The lost data and retransmis-
sions reduce throughput. In the worst case where multi-
ple active hosts connected with maximum allowed cable
length attempt to transmit many short frames, excessive
collisions can reduce throughput dramatically. However,
a Xerox report in 1980 studied performance of an ex-
isting Ethernet installation under both normal and arti-
cially generated heavy load. The report claims that 98%
throughput on the LAN was observed.
[24]
This is in con-
trast with token passing LANs (token ring, token bus), all
40 CHAPTER 9. ETHERNET
of which suer throughput degradation as each new node
comes into the LAN, due to token waits. This report was
controversial, as modeling showed that collision-based
networks theoretically became unstable under loads as
low as 37% of nominal capacity. Many early researchers
failed to understand these results. Performance on real
networks is signicantly better.
[25]
In a modern Ethernet, the stations do not all share one
channel through a shared cable or a simple repeater hub;
instead, each station communicates with a switch, which
in turn forwards that trac to the destination station. In
this topology, collisions are only possible if station and
switch attempt to communicate with each other at the
same time, and collisions are limited to this link. Further-
more, the 10BASE-T standard introduced a full duplex
mode of operation which has become extremely com-
mon. In full duplex, switch and station can communi-
cate with each other simultaneously, and therefore mod-
ern Ethernets are completely collision-free.
9.3.2 Repeaters and hubs
A 1990s network interface card supporting both coaxial cable-
based 10BASE2 (BNC connector, left) and twisted pair-based
10BASE-T (8P8C connector, right)
Main article: Ethernet hub
For signal degradation and timing reasons, coaxial
Ethernet segments had a restricted size. Somewhat larger
networks could be built by using an Ethernet repeater.
Early repeaters had only two ports, allowing, at most,
a doubling of network size. Once repeaters with more
than two ports became available, it was possible to wire
the network in a star topology. Early experiments with
star topologies (called Fibernet) using optical ber were
published by 1978.
[26]
Shared cable Ethernet was always hard to install in of-
ces because its bus topology was in conict with the
star topology cable plans designed into buildings for tele-
phony. Modifying Ethernet to conform to twisted pair
telephone wiring already installed in commercial build-
ings provided another opportunity to lower costs, expand
the installed base, and leverage building design, and, thus,
twisted-pair Ethernet was the next logical development in
the mid-1980s.
Ethernet on unshielded twisted-pair cables (UTP) began
with StarLAN at 1 Mbit/s in the mid-1980s. In 1987
SynOptics introduced the rst twisted-pair Ethernet at
10 Mbit/s in a star-wired cabling topology with a cen-
tral hub, later called LattisNet.
[10][27][28]
These evolved
into 10BASE-T, which was designed for point-to-point
links only, and all termination was built into the device.
This changed repeaters from a specialist device used at
the center of large networks to a device that every twisted
pair-based network with more than two machines had
to use. The tree structure that resulted from this made
Ethernet networks easier to maintain by preventing most
faults with one peer or its associated cable from aecting
other devices on the network.
Despite the physical star topology and the presence of
separate transmit and receive channels in the twisted pair
and ber media, repeater based Ethernet networks still
use half-duplex and CSMA/CD, with only minimal activ-
ity by the repeater, primarily the Collision Enforcement
signal, in dealing with packet collisions. Every packet is
sent to every port on the repeater, so bandwidth and se-
curity problems are not addressed. The total throughput
of the repeater is limited to that of a single link, and all
links must operate at the same speed.
9.3.3 Bridging and switching
Patch cables with patch elds of two Ethernet switches
Main articles: Ethernet switch and Bridging (networking)
While repeaters could isolate some aspects of Ethernet
segments, such as cable breakages, they still forwarded
all trac to all Ethernet devices. This created practical
limits on how many machines could communicate on an
Ethernet network. The entire network was one collision
domain, and all hosts had to be able to detect collisions
anywhere on the network. This limited the number of
repeaters between the farthest nodes. Segments joined
9.3. EVOLUTION 41
by repeaters had to all operate at the same speed, making
phased-in upgrades impossible.
To alleviate these problems, bridging was created to com-
municate at the data link layer while isolating the physical
layer. With bridging, only well-formed Ethernet packets
are forwarded fromone Ethernet segment to another; col-
lisions and packet errors are isolated. At initial startup,
Ethernet bridges (and switches) work somewhat like Eth-
ernet repeaters, passing all trac between segments. By
observing the source addresses of incoming frames, the
bridge then builds an address table associating addresses
to segments. Once an address is learned, the bridge for-
wards network trac destined for that address only to
the associated segment, improving overall performance.
Broadcast trac is still forwarded to all network seg-
ments. Bridges also overcame the limits on total segments
between two hosts and allowed the mixing of speeds, both
of which are critical to deployment of Fast Ethernet.
In 1989, the networking company Kalpana introduced
their EtherSwitch, the rst Ethernet switch.
[lower-alpha 8]
This worked somewhat dierently from an Ethernet
bridge, where only the header of the incoming packet
would be examined before it was either dropped or for-
warded to another segment. This greatly reduced the
forwarding latency and the processing load on the net-
work device. One drawback of this cut-through switching
method was that packets that had been corrupted would
still be propagated through the network, so a jabber-
ing station could continue to disrupt the entire network.
The eventual remedy for this was a return to the orig-
inal store and forward approach of bridging, where the
packet would be read into a buer on the switch in its en-
tirety, veried against its checksum and then forwarded,
but using more powerful application-specic integrated
circuits. Hence, the bridging is then done in hardware,
allowing packets to be forwarded at full wire speed.
When a twisted pair or ber link segment is used and
neither end is connected to a repeater, full-duplex Eth-
ernet becomes possible over that segment. In full-duplex
mode, both devices can transmit and receive to and from
each other at the same time, and there is no collision do-
main. This doubles the aggregate bandwidth of the link
and is sometimes advertised as double the link speed (for
example, 200 Mbit/s).
[lower-alpha 9]
The elimination of the
collision domain for these connections also means that all
the links bandwidth can be used by the two devices on
that segment and that segment length is not limited by
the need for correct collision detection.
Since packets are typically delivered only to the port they
are intended for, trac on a switched Ethernet is less
public than on shared-medium Ethernet. Despite this,
switched Ethernet should still be regarded as an insecure
network technology, because it is easy to subvert switched
Ethernet systems by means such as ARP spoong and
MAC ooding.
The bandwidth advantages, the improved isolation of de-
vices from each other, the ability to easily mix dierent
speeds of devices and the elimination of the chaining lim-
its inherent in non-switched Ethernet have made switched
Ethernet the dominant network technology.
[29]
9.3.4 Advanced networking
A core Ethernet switch
Simple switched Ethernet networks, while a great im-
provement over repeater-based Ethernet, suer from sin-
gle points of failure, attacks that trick switches or hosts
into sending data to a machine even if it is not in-
tended for it, scalability and security issues with regard to
broadcast radiation and multicast trac, and bandwidth
choke points where a lot of trac is forced down a single
link.
Advanced networking features in switches and routers
combat these issues through means including spanning-
tree protocol to maintain the active links of the network as
a tree while allowing physical loops for redundancy, port
security and protection features such as MAC lock down
and broadcast radiation ltering, virtual LANs to keep
dierent classes of users separate while using the same
physical infrastructure, multilayer switching to route be-
tween dierent classes and link aggregation to add band-
width to overloaded links and to provide some measure
of redundancy.
IEEE 802.1aq (shortest path bridging) includes the use
of the link-state routing protocol IS-IS to allowlarger net-
works with shortest path routes between devices. In 2012,
it was stated by David Allan and Nigel Bragg, in 802.1aq
42 CHAPTER 9. ETHERNET
Shortest Path Bridging Design and Evolution: The Archi-
tects Perspective that shortest path bridging is one of the
most signicant enhancements in Ethernets history.
[30]
9.4 Varieties of Ethernet
Main article: Ethernet physical layer
The Ethernet physical layer evolved over a considerable
time span and encompasses coaxial, twisted pair and ber
optic physical media interfaces and speeds from 10 Mbit
to 100 Gbit. The most common forms used are 10BASE-
T, 100BASE-TX, and 1000BASE-T. All three utilize
twisted pair cables and 8P8C modular connectors. They
run at 10 Mbit/s, 100 Mbit/s, and 1 Gbit/s, respectively.
Fiber optic variants of Ethernet oer high performance,
electrical isolation and distance (tens of kilometers with
some versions). In general, network protocol stack soft-
ware will work similarly on all varieties.
9.5 Layer 2 Datagrams
A close-up of the SMSC LAN91C110 (SMSC 91x) chip, an em-
bedded Ethernet chip.
Main article: Ethernet frame
In IEEE 802.3, a datagram is called a packet or frame.
Packet is used to describe the overall transmission unit
and includes the preamble, start frame delimiter (SFD)
and carrier extension (if present).
[lower-alpha 10]
The frame
begins after the start frame delimiter with a frame header
featuring source and destination MAC addresses. The
middle section of the frame consists of payload data in-
cluding any headers for other protocols (for example,
Internet Protocol) carried in the frame. The frame ends
with a 32-bit cyclic redundancy check, which is used to
detect corruption of data in transit.
[31]:sections 3.1.1 and 3.2
9.6 Autonegotiation
Main article: Autonegotiation
Autonegotiation is the procedure by which two connected
devices choose common transmission parameters, e.g.
speed and duplex mode. Autonegotiation was an optional
feature on rst introduction of 100BASE-TX, while it is
also backward compatible with 10BASE-T. Autonegoti-
ation is mandatory for 1000BASE-T.
9.7 See also
ARCNET
Chaosnet
Sneakernet
Ethernet over twisted pair
Ethernet crossover cable
Fiber media converter
Gigabit Ethernet
Gigabit interface converter
Industrial Ethernet
List of device bit rates
LocalTalk
Metro Ethernet
Media Independent Interface
PHY (chip)
Power over Ethernet
Point-to-Point Protocol over Ethernet
Small form-factor pluggable transceiver
Terabit Ethernet
Wake-on-LAN
10-gigabit Ethernet
100-gigabit Ethernet
5-4-3 rule
9.9. REFERENCES 43
9.8 Notes
[1] The experimental Ethernet described in the 1976 paper
ran at 2.94 Mbit/s and had eight-bit destination and source
address elds, so the original Ethernet addresses were not
the MACaddresses they are today.
[9]
By software conven-
tion, the 16 bits after the destination and source address
elds specied a packet type, but, as the paper says,
dierent protocols use disjoint sets of packet types.
Thus the original packet types could vary within each dif-
ferent protocol. This is in contrast to the EtherType in
the IEEE Ethernet standard, which species the protocol
being used.
[2] In some cases, the factory-assigned address can be over-
ridden, either to avoid an address change when an adapter
is replaced or to use locally administered addresses.
[3] There are fundamental dierences between wireless and
wired shared-medium communications, such as the fact
that it is much easier to detect collisions in a wired system
than a wireless system.
[4] In a CSMA/CD system packets must be large enough to
guarantee that the leading edge of the propagating wave
of the message got to all parts of the medium before the
transmitter could stop transmitting, thus guaranteeing that
collisions (two or more packets initiated within a window
of time that forced them to overlap) would be discov-
ered. Minimum packet size and the physical mediums
total length were, thus, closely linked.
[5] Multipoint systems are also prone to strange failure modes
when an electrical discontinuity reects the signal in such
a manner that some nodes would work properly, while oth-
ers work slowly because of excessive retries or not at all.
See standing wave for an explanation. These could be
much more dicult to diagnose than a complete failure
of the segment.
[6] This one speaks, all listen property is a security weak-
ness of shared-medium Ethernet, since a node on an Eth-
ernet network can eavesdrop on all trac on the wire if it
so chooses.
[7] Unless it is put into promiscuous mode.
[8] The termswitch was invented by device manufacturers and
does not appear in the 802.3 standard.
[9] This is misleading, as performance will double only if traf-
c patterns are symmetrical.
[10] The carrier extension is dened to assist collision detection
on shared-media gigabit Ethernet.
9.9 References
[1] IEEE 802.3 'Standard for Ethernet' Marks 30 Years of
Innovation and Global Market Growth (Press release).
IEEE. June 24, 2013. Retrieved January 11, 2014.
[2] The History of Ethernet. NetEvents.tv. 2006. Retrieved
September 10, 2011.
[3] Ethernet Prototype Circuit Board. Smithsonian Na-
tional Museum of American History. 1973. Retrieved
September 2, 2007.
[4] Gerald W. Brock (September 25, 2003). The Second In-
formation Revolution. Harvard University Press. p. 151.
ISBN 0-674-01178-3.
[5] Cade Metz (March 13, 2009). Ethernet a network-
ing protocol name for the ages: Michelson, Morley, and
Metcalfe. The Register. p. 2. Retrieved March 4, 2013.
[6] Mary Bellis. Inventors of the Modern Computer.
About.com. Retrieved September 10, 2011.
[7] U.S. Patent 4,063,220 Multipoint data communication
system (with collision detection)"
[8] Robert Metcalfe; David Boggs (July 1976). Ethernet:
Distributed Packet Switching for Local Computer Net-
works. Communications of the ACM 19 (7): 395405.
doi:10.1145/360248.360253.
[9] John F. Shoch; Yogen K. Dalal; David D. Redell; Ronald
C. Crane (August 1982). Evolution of the Ethernet Lo-
cal Computer Network. IEEE Computer 15 (8): 1426.
doi:10.1109/MC.1982.1654107.
[10] von Burg, Urs; Kenney, Martin (December 2003).
Sponsors, Communities, and Standards: Ethernet vs.
Token Ring in the Local Area Networking Busi-
ness. Industry & Innovation 10 (4): 351375.
doi:10.1080/1366271032000163621. Archived from the
original on 2012-03-21. Retrieved 17 February 2014.
[11] Digital Equipment Corporation, Intel Corporation and
Xerox Corporation (30 September 1980). The Ethernet,
A Local Area Network. Data Link Layer and Physical
Layer Specications, Version 1.0. Xerox Corporation.
Retrieved 2011-12-10.
[12] Digital Equipment Corporation, Intel Corporation and
Xerox Corporation (November 1982). The Ethernet, A
Local Area Network. Data Link Layer and Physical Layer
Specications, Version 2.0. Xerox Corporation. Re-
trieved 2011-12-10.
[13] Robert Breyer & Sean Riley (1999). Switched, Fast, and
Gigabit Ethernet. Macmillan. ISBN 1-57870-073-6.
[14] Jamie Parker Pearson (1992). Digital at Work. Digital
Press. p. 163. ISBN 1-55558-092-0.
[15] Rick Merritt (December 20, 2010). Shifts, growth ahead
for 10G Ethernet. E Times. Retrieved September 10,
2011.
[16] My oh My Ethernet Growth Continues to Soar; Sur-
passes Legacy. Telecom News Now. July 29, 2011. Re-
trieved September 10, 2011.
[17] JimDuy (February 22, 2010). Cisco, Juniper, HP drive
Ethernet switch market in Q4. Network World. Re-
trieved September 10, 2011.
[18] Vic Hayes (August 27, 2001). Letter to FCC. Retrieved
October 22, 2010. IEEE 802 has the basic charter to
develop and maintain networking standards... IEEE 802
was formed in February 1980...
44 CHAPTER 9. ETHERNET
[19] IEEE 802.3-2008, p.iv
[20] Douglas E. Comer (2000). Internetworking with TCP/IP
Principles, Protocols and Architecture (4th ed.). Prentice
Hall. ISBN 0-13-018380-6. 2.4.9 Ethernet Hardware
Addresses, p. 29, explains the ltering.
[21] Iljitsch van Beijnum. Speed matters: how Ethernet went
from 3Mbps to 100Gbps... and beyond. Ars Tech-
nica. Retrieved July 15, 2011. All aspects of Ethernet
were changed: its MAC procedure, the bit encoding, the
wiring... only the packet format has remained the same.
[22] Geetaj Channana (November 1, 2004). Motherboard
Chipsets Roundup. PCQuest. Retrieved October 22,
2010. While comparing motherboards in the last issue
we found that all motherboards support Ethernet connec-
tion on board.
[23] Charles E. Spurgeon (2000). Ethernet: The Denitive
Guide. O'Reilly. ISBN 978-1-56592-660-8.
[24] Shoch, John F. and Hupp, Jon A. (December 1980).
Measured performance of an Ethernet local network.
Communications of the ACM (ACM Press) 23 (12): 711
721. doi:10.1145/359038.359044. ISSN 0001-0782.
[25] Boggs, D.R., Mogul, J.C., and Kent, C.A. (September
1988). Measured capacity of an Ethernet: myths and
reality. DEC WRL.
[26] Eric G. Rawson; Robert M. Metcalfe (July 1978).
Fibemet: Multimode Optical Fibers for Local Computer
Networks. IEEE transactions on communications 26 (7):
983990. doi:10.1109/TCOM.1978.1094189. Retrieved
June 11, 2011.
[27] Spurgeon, Charles E. (2000). Ethernet; The Denitive
Guide. Nutshell Handbook. O'Reilly. p. 29. ISBN 1-
56592-660-9.
[28] Urs von Burg (2001). The Triumph of Ethernet: techno-
logical communities and the battle for the LAN standard.
Stanford University Press. p. 175. ISBN 0-8047-4094-1.
[29] Token Ring-to-Ethernet Migration. Cisco. Retrieved
October 22, 2010. Respondents were rst asked about
their current and planned desktop LAN attachment stan-
dards. The results were clearswitched Fast Ethernet is
the dominant choice for desktop connectivity to the net-
work
[30] Allan, David; Bragg, Nigel (2012). 802.1aq Shortest Path
Bridging Design and Evolution : The Architects Perspec-
tive. New York: Wiley. ISBN 978-1-118-14866-2.
[31] 802.3-2012 - IEEE Standard for Ethernet (PDF).
ieee.org. IEEE Standards Association. 2012-12-28. Re-
trieved 2014-02-08.
9.10 Further reading
Digital Equipment Corporation, Intel Corporation,
Xerox Corporation (September 1980). The Eth-
ernet: A Local Area Network. ACM SIG-
COMM Computer Communication Review 11 (3):
20. doi:10.1145/1015591.1015594. Version 1.0
of the DIX specication.
Ethernet. Internetworking Technology Hand-
book. Cisco Systems. Retrieved April 11, 2011.
Charles E. Spurgeon (2000). Ethernet: The Deni-
tive Guide. O'Reilly Media. ISBN 978-1565-9266-
08.
9.11 External links
IEEE 802.3 Ethernet working group
IEEE 802.3-2012 standard
Chapter 10
Ethernet physical layer
The Ethernet physical layer is the physical layer com-
ponent of the Ethernet family of computer network stan-
dards.
The Ethernet physical layer evolved over a considerable
time span and encompasses quite a few physical media
interfaces and several magnitudes of speed. The speed
ranges from 1 Mbit/s to 100 Gbit/s, while the physical
medium can range from bulky coaxial cable to twisted
pair and optical ber. In general, network protocol stack
software will work similarly on all physical layers.
10-gigabit Ethernet was already used in both enterprise
and carrier networks by 2007, with 40 Gbit/s
[1][2]
and
100 Gbit/s Ethernet
[3]
ratied.
[4]
Higher speeds are under
development.
[5]
Robert Metcalfe, one of the co-inventors
of Ethernet, in 2008 said he believed commercial appli-
cations using Terabit Ethernet may occur by 2015, though
it might require new Ethernet standards.
[6]
Many Ethernet adapters and switch ports support mul-
tiple speeds, using autonegotiation to set the speed and
duplex for the best values supported by both connected
devices. If auto-negotiation fails, a multiple-speed device
will sense the speed used by its partner, but will assume
half-duplex. A 10/100 Ethernet port supports 10BASE-
T and 100BASE-TX. A 10/100/1000 Ethernet port sup-
ports 10BASE-T, 100BASE-TX, and 1000BASE-T.
10.1 Physical layers
10.1.1 Xerox experimental Ethernet
The following sections provide a brief summary of of-
cial Ethernet media types (section numbers from the
IEEE 802.3-2008 standard are parenthesized). In addi-
tion to these ocial standards, many vendors have im-
plemented proprietary media types for various reasons
often to support longer distances over ber optic cabling.
10.1.2 Early implementations
Early Ethernet standards used Manchester coding so that
the signal was self-clocking not adversely aected by
high-pass lters.
10.1.3 Fast Ethernet
Main article: Fast Ethernet
10.1.4 1 Gbit/s
Main article: Gigabit Ethernet
All gigabit Ethernet variants use a star topology.
10.1.5 10 Gbit/s
Main article: 10-gigabit Ethernet
10-gigabit Ethernet denes a version of Ethernet with a
nominal data rate of 10 Gbit/s, ten times as fast as gigabit
Ethernet. In 2002, the rst 10-gigabit Ethernet standard
was published as IEEE Std 802.3ae-2002. Subsequent
standards encompassed media types for single-mode bre
(long haul), multi-mode bre (up to 300 m), copper back-
plane (up to 1 m) and copper twisted pair (up to 100 m).
All 10-gigabit varieties were consolidated into IEEE Std
802.3-2008. As of 2009, 10-gigabit Ethernet is predom-
inantly deployed in carrier networks, where 10GBASE-
LR and 10GBASE-ER enjoy signicant market shares.
10.1.6 25 and 50 Gbit/s
Main article: 25-gigabit Ethernet
An IEEE 802.3 workgroup has been formed to develop
a 25-gigabit Ethernet standard based on one lane of the
4 by 25-Gbit/s 100-gigabit standard and is expected to
progress quickly.
[10]
A 50-Gbit/s option is also being
discussed.
[11]
45
46 CHAPTER 10. ETHERNET PHYSICAL LAYER
10.1.7 40 and 100 Gbit/s
Main article: 100-gigabit Ethernet
This version of Ethernet specied two speeds and was
standardized in June 2010 as IEEE 802.3ba, with one
addition in March 2011 as IEEE 802.3bg.
[12][13]
The
nomenclature is as follows:
[14]
10.2 Terabit and beyond
Main article: Terabit Ethernet
The standards body the Institute of Electrical and Elec-
tronic Engineers (IEEE) wants to dene a new Ethernet
standard capable of 400 Gbit/s and 1 Tbit/s.
[15][16]
They believe that Terabit Ethernet may make a debut as
early as 2015, and will be followed rapidly by a scaling
to 100 Terabit, possibly as early as 2020. It is worth not-
ing that these are theoretical predictions of technological
ability, rather than estimates of when such speeds would
actually become available at a practical price point.
[17]
10.3 First mile
Main article: Ethernet in the rst mile
For providing Internet access service directly from
providers to homes and small businesses:
10.4 Twisted-pair cable
Main article: Ethernet over twisted pair
Several varieties of Ethernet were specically designed to
run over 4-pair copper structured cabling already installed
in many locations. ANSI recommends using Category 6
cable for new installations.
Combining 10Base-T (or 100BASE-TX) with "IEEE
802.3af mode A allows a hub to transmit both power and
data over only two pairs. This was designed to leave the
other two pairs free for analog telephone signals.
[20]
The
pins used in IEEE 802.3af Mode B supply power over
the spare pairs not used by 10BASE-T and 100BASE-
TX.
In a departure from both 10BASE-T and 100BASE-TX,
1000BASE-T uses all four cable pairs for simultaneous
transmission in both directions through the use of echo
cancellation.
10.5 Minimum cable lengths
Fiber connections have minimum cable lengths due to
level requirements on received signals.
[21]
Fiber ports de-
signed for long-haul wavelengths require a signal attenu-
ator if used within a building.
10BASE2 installations, running on RG-58 coaxial cable,
require a minimum of 0.5 m between stations tapped into
the network cable, this is to minimize reections.
[22]
10BASE-T, 100BASE-T, and 1000BASE-T installations
running on twisted pair cable use a star topology. No
minimum cable length is required for these networks.
[23]
[24]
10.6 Related standards
Some networking standards are not part of the IEEE
802.3 Ethernet standard, but support the Ethernet frame
format, and are capable of interoperating with it.
LattisNetA SynOptics pre-standard twisted-pair
10 Mbit/s variant.
100BaseVGAn early contender for 100 Mbit/s
Ethernet. It runs over Category 3 cabling. Uses four
pairs. Commercial failure.
TIA 100BASE-SXPromoted by the
Telecommunications Industry Association.
100BASE-SX is an alternative implementation
of 100 Mbit/s Ethernet over ber; it is incompat-
ible with the ocial 100BASE-FX standard. Its
main feature is interoperability with 10BASE-FL,
supporting autonegotiation between 10 Mbit/s and
100 Mbit/s operation a feature lacking in the
ocial standards due to the use of diering LED
wavelengths. It is targeted at the installed base of
10 Mbit/s ber network installations.
TIA 1000BASE-TXPromoted by the
Telecommunications Industry Association, it
was a commercial failure, and no products exist.
1000BASE-TX uses a simpler protocol than the
ocial 1000BASE-T standard so the electronics
can be cheaper, but requires Category 6 cabling.
G.hnA standard developed by ITU-T and pro-
moted by HomeGrid Forum for high-speed (up to
1 Gbit/s) local area networks over existing home
wiring (coaxial cables, power lines and phone lines).
G.hn denes an Application Protocol Convergence
(APC) layer that accepts Ethernet frames and en-
capsulates them into G.hn MSDUs.
Other networking standards do not use the Ethernet frame
format but can still be connected to Ethernet using MAC-
based bridging.
10.8. EXTERNAL LINKS 47
802.11Standards for wireless local area networks
(LANs), sold with brand name Wi-Fi
802.16Standards for wireless metropolitan area
networks (MANs), sold with brand name WiMAX
Other special-purpose physical layers include Avionics
Full-Duplex Switched Ethernet and TTEthernet Time-
Triggered Ethernet for embedded systems.
10.7 References
[1] Consideration for 40 gigabit Ethernet (PDF). IEEE
HSSG. May 2007.
[2] 40 gigabit Ethernet answers (PDF). IEEE HSSG. May
2007.
[3] HECTO: High-Speed Electro-Optical Components for
Integrated Transmitter and Receiver in Optical Commu-
nication. Hecto.eu. Retrieved December 17, 2011.
[4] IEEE P802.3ba 40Gb/s and 100Gb/s Ethernet Task
Force. IEEE. 2010-06-19.
[5] Yiran Ma, Qi Yang, Yan Tang, Simin Chen, and William
Shieh, 1-Tb/s single-channel coherent optical OFDMtrans-
mission over 600-kmSSMFber with subwavelength band-
width access, retrieved 2010-07-30
[6] Bob Metcalfe on the Terabit Ethernet. Light Reading.
February 15, 2008. Retrieved August 27, 2013.
[7] John F. Shoch; Yogen K. Dalal; David D. Redell; Ronald
C. Crane (August 1982). Evolution of the Ethernet Lo-
cal Computer Network. IEEE Computer 15 (8): 1426.
doi:10.1109/MC.1982.1654107.
[8] L-com Introduces Commercial-Grade Thinnet (10Base-
2) and Thicknet (10Base-5) Converters for Legacy In-
stalls. Virtual-Strategy Magazine. 2012-06-11. Re-
trieved 2012-07-01.
[9] Cisco Gigabit Ethernet Solutions for Cisco 7x00 Series
Routers, undated, URL retrieved on 17 February 2008
[10] Jim Duy (9/3/2014). 25G Ethernet moving fast.
Network World. Check date values in: |date= (help)
[11] Rick Merritt (9/3/2014). 50G Ethernet Debate Brew-
ing. EE Times. Check date values in: |date= (help)
[12] Reimer, Jeremy (July 25, 2007). New Ethernet standard:
not 40Gbps, not 100, but both. Ars Technica. Retrieved
December 17, 2011.
[13] IEEE P802.3bg 40Gb/s Ethernet: Single-mode Fibre
PMD Task Force. ocial task force web site. IEEE 802.
April 12, 2011. Retrieved June 17, 2011.
[14] Ilango Ganga (May 13, 2009). Chief Editors Report.
IEEE P802.3ba 40Gb/s and 100Gb/s Ethernet Task Force
public record. p. 8. Retrieved June 7, 2011.
[15] http://www.proavbiz-europe.com/index.php?
option=com_content&view=article&id=6151:
ieee-begins-work-on-new-ethernet-standard&catid=
15&Itemid=401979
[16] http://www.ieee802.org/3/ad_hoc/bwa/BWA_Report.
pdf
[17] http://www.electronista.com/articles/12/08/20/aging.
standard.is.still.ahead.of.most.core.networking/
[18] Inneon Strengthens Leadership in MDU/MTU Mar-
ket with Ethernet over VDSL Technology Patent Award.
News release (Inneon Technologies AG). January 8,
2001. Archived from the original on April 13, 2001. Re-
trieved August 27, 2011.
[19] Inneon Announces Second Quarter Results. News re-
lease (Inneon Technologies). April 24, 2001. Retrieved
August 28, 2011. "...strategic design-win with Cisco
for new long range Ethernet products incorporating In-
neon's 10BaseS technology
[20] Tech Info - LAN and Telephones. Zytrax.com. Re-
trieved December 17, 2011.
[21] Cisco 100BASE-FX SFP Fast Ethernet Interface Con-
verter on Gigabit SFP Ports. Cisco Systems. Archived
from the original on 2007-10-13.
[22] IEEE Standard for Ethernet 802.3-2008 Clauses
10.7.2.1-2.
[23] http://www.cisco.com/c/en/us/support/docs/
interfaces-modules/port-adapters/12768-eth-collisions.
html
[24] http://web.cs.dal.ca/~{}yongzhen/course/6704/report.
pdf
10.8 External links
Get IEEE 802.3
IEEE 802.3
How to make an Ethernet cable
Chapter 11
Ethernet frame
A data packet on an Ethernet link is called an Eth-
ernet packet, which transports an Ethernet frame as
payload.
[1]
An Ethernet frame is preceded by a preamble and start
frame delimiter (SFD), which are both part of the layer
1 Ethernet packet. Each Ethernet frame starts with an
Ethernet header, which contains destination and source
MAC addresses as its rst two elds. The middle section
of the frame is payload data including any headers for
other protocols (for example Internet Protocol) carried in
the frame. The frame ends with a frame check sequence
(FCS), which is a 32-bit cyclic redundancy check used to
detect any in-transit corruption of data.
11.1 Structure
See also: Physical Coding Sublayer
A data packet on the wire and the frame as its payload
consist of binary data. Data on Ethernet is transmit-
ted most-signicant octet (byte) rst. Within each octet,
however, the least-signicant bit is transmitted rst.
[2]
The table below shows the complete Ethernet frame, as
transmitted, for the payload size up to the MTU of 1500
octets.
[lower-alpha 1]
Some implementations of Gigabit Eth-
ernet (and higher speed ethernets) support larger frames,
known as jumbo frames.
The internal structure of an Ethernet frame is specied in
IEEE 802.3-2012.
[1]
11.1.1 Preamble and start frame delimiter
See also: Syncword
An Ethernet frame starts following a 7-octet pream-
Preamble SFD
Source
MAC
Address
Destination
MAC
Address
EtherType FCS Payload
An Ethernet frame inside an Ethernet packet, with SFD marking
the end of the packet preamble and indicating the beginning of
the frame.
[4]
ble and 1-octet start frame delimiter (SFD), both of
which are part of the Ethernet packet enveloping the
frame.
[lower-alpha 3]
Prior to Fast Ethernet, the on-the-wire
bit pattern for this portion of the frame is 10101010
10101010 10101010 10101010 10101010 10101010
10101010 10101011.
[4]:sections 4.2.5 and 3.2.2
Since octets are
transmitted least-signicant bit rst, the corresponding
hexadecimal representation is 0x55 0x55 0x55 0x55
0x55 0x55 0x55 0xD5.
The SFDis an 8-bit (1-byte) value marking the end of the
preamble, which is the rst eld of an Ethernet packet,
and indicating the beginning of the Ethernet frame. The
SFD is immediately followed by the destination MAC
address, which is the rst eld in an Ethernet frame.
SFD has the value of 171 (10101011 in binary notation),
which is transmitted with least-signicant bit rst as 213
(0xD5).
[4]:sections 3.1.1 and 3.2
The preamble of an Ethernet packet consists of a 56-bit
(7-byte) pattern of alternating 1 and 0 bits, which allows
devices on the network to easily detect a new incoming
frame. The SFD is designed to break this pattern and
signal the start of the actual frame.
[4]:section 4.2.5
Physical layer transceiver chips (PHYs for short) are
necessary to connect the Ethernet MAC to the physi-
cal medium. The connection between a PHY and MAC
is independent of the physical medium and uses a bus
fromthe media independent interface family (MII, GMII,
RGMII, SGMII, XGMII).
Fast Ethernet transceiver chips utilize the MII bus, which
is a 4-bit (one nibble) wide bus, therefore the pream-
ble is represented as 14 instances of 0x5, and the start
frame delimiter is 0x5 0xD (as nibbles). Gigabit Ether-
net transceiver chips use the GMII bus, which is an 8-bit
wide interface, thus the sequence would be 0x55 0x55
0x55 0x55 0x55 0x55 0x55 0xD5 (as bytes).
11.1.2 Header
The header features destination and source MAC ad-
dresses (each six octets in length), the EtherType eld
and, optionally, a IEEE 802.1Q tag.
The EtherType eld is two octets long and it can be used
48
11.2. ETHERNET FRAME TYPES 49
for two dierent purposes. Values of 1500 and below
mean that it is used to indicate the size of the payload in
octets, while values of 1536 and above indicate that it is
used as an EtherType, to indicate which protocol is en-
capsulated in the payload of the frame. When used as
EtherType, the length of the frame is determined by the
location of the interpacket gap and valid frame check se-
quence (FCS).
The IEEE 802.1Q tag, if present, is a four-octet eld that
indicates Virtual LAN (VLAN) membership and IEEE
802.1p priority.
11.1.3 Payload
The minimum payload is 42 octets when an
802.1Q tag is present and 46 octets when
absent.
[3][lower-alpha 4][lower-alpha 5]
The maximum pay-
load is 1500 octets. Non-standard jumbo frames allow
for larger maximum payload size.
11.1.4 Frame check sequence
The frame check sequence (FCS) is a 4-octet cyclic re-
dundancy check which allows detection of corrupted data
within the entire frame. Running the FCS algorithm over
the received frame data including the FCS will always re-
sult in the magic number or CRC32 residue 0xC704DD7B
when data has been transmitted correctly. This allows for
receiving a frame and validating the FCS without know-
ing where the FCS eld actually starts.
[6]
11.1.5 End of frame
The end of a frame is usually indicated by the end of
data stream at the physical layer or by loss of the carrier
signal; an example is 10BASE-T, where the receiving sta-
tion detects the end of a transmitted frame by loss of the
carrier. Some physical layers use an explicit end of data
or end of stream symbol or sequence to avoid ambiguity;
an example is Gigabit Ethernet with its 8b/10b encoding
scheme that uses special symbols which are transmitted
before and after a frame is transmitted.
[7][8]
11.1.6 Interpacket gap
Interpacket gap is idle time between packets. After a
packet has been sent, transmitters are required to transmit
a minimum of 96 bits (12 octets) of idle line state before
transmitting the next packet.
11.2 Ethernet frame types
There are several types of Ethernet frames:
Ethernet II frame, or Ethernet Version 2,
[lower-alpha 6]
or DIXframe is the most common type in use today,
as it is often used directly by the Internet Protocol.
Novell raw IEEE 802.3 non-standard variation
frame
IEEE 802.2 Logical Link Control (LLC) frame
IEEE 802.2 Subnetwork Access Protocol (SNAP)
frame
The dierent frame types have dierent formats and
MTU values, but can coexist on the same physical
medium. Dierentiation between frame types is possi-
ble based on the table on the right.
In addition, all four Ethernet frames types may optionally
contain an IEEE 802.1Q tag to identify what VLAN it
belongs to and its priority (quality of service). This en-
capsulation is dened in the IEEE 802.3ac specication
and increases the maximum frame by 4 octets.
The IEEE 802.1Q tag, if present, is placed between the
Source Address and the EtherType or Length elds. The
rst two octets of the tag are the Tag Protocol Identier
(TPID) value of 0x8100. This is located in the same place
as the EtherType/Length eld in untagged frames, so an
EtherType value of 0x8100 means the frame is tagged,
and the true EtherType/Length is located after the Q-
tag. The TPID is followed by two octets containing the
Tag Control Information (TCI) (the IEEE 802.1p priority
(quality of service) and VLAN id). The Q-tag is followed
by the rest of the frame, using one of the types described
above.
11.2.1 Ethernet II
Ethernet II framing (also known as DIX Ethernet,
named after DEC, Intel and Xerox, the major partici-
pants in its design
[9]
), denes the two-octet EtherType
eld in an Ethernet frame, preceded by destination and
source MAC addresses, that identies an upper layer
protocol encapsulating the frame data. For example,
an EtherType value of 0x0800 signals that the frame
contains an IPv4 datagram. Likewise, an EtherType
of 0x0806 indicates an ARP frame, 0x8100 indicates
an IEEE 802.1Q frame and 0x86DD indicates an IPv6
frame.
80 00 20 7A 3F 3E
Destination MAC Address
80 00 20 20 3A AE
Source MAC Address
08 00
EtherType
MAC Header
(14 bytes)
IP, ARP, etc.
Payload
Data
(46 - 1500 bytes)
00 20 20 3A
CRC Checksum
Ethernet Type II Frame
(64 to 1518 bytes)
(4 bytes)
The most common Ethernet Frame format, type II
As this industry-developed standard went through a for-
mal IEEE standardization process, the EtherType eld
was changed to a (data) length eld in the new 802.3
standard.
[lower-alpha 7]
Since the recipient still needs to
50 CHAPTER 11. ETHERNET FRAME
knowhowto interpret the frame, the standard required an
IEEE 802.2 header to follow the length and specify the
type. Many years later, the 802.3x-1997 standard, and
later versions of the 802.3 standard, formally approved
of both types of framing. In practice, both formats are in
wide use, with original Ethernet framing the most com-
mon in Ethernet local area networks, due to its simplicity
and lower overhead.
In order to allow some frames using Ethernet v2 framing
and some using the original version of 802.3 framing to
be used on the same Ethernet segment, EtherType values
must be greater than or equal to 1536 (0x0600). That
value was chosen because the maximum length of the
payload eld of an Ethernet 802.3 frame is 1500 octets
(0x05DC). Thus if the elds value is greater than or equal
to 1536, the frame must be an Ethernet v2 frame, with
that eld being a type eld.
[10]
If its less than or equal to
1500, it must be an IEEE 802.3 frame, with that eld be-
ing a length eld. Values between 1500 and 1536, exclu-
sive, are undened.
[11]
This convention allows software
to determine whether a frame is an Ethernet II frame or
an IEEE 802.3 frame, allowing the coexistence of both
standards on the same physical medium.
11.2.2 Novell raw IEEE 802.3
Novells raw 802.3 frame format was based on early
IEEE 802.3 work. Novell used this as a starting point
to create the rst implementation of its own IPXNetwork
Protocol over Ethernet. They did not use any LLCheader
but started the IPX packet directly after the length eld.
This does not conform to the IEEE 802.3 standard, but
since IPX has always FF at the rst two octets (while in
IEEE 802.2 LLC that pattern is theoretically possible but
extremely unlikely), in practice this mostly coexists on
the wire with other Ethernet implementations, with the
notable exception of some early forms of DECnet which
got confused by this.
Novell NetWare used this frame type by default un-
til the mid-nineties, and since NetWare was then very
widespread, while IP was not, at some point in time most
of the worlds Ethernet trac ran over raw 802.3 car-
rying IPX. Since NetWare 4.10, NetWare now defaults
to IEEE 802.2 with LLC (NetWare Frame Type Ether-
net_802.2) when using IPX.
[12]
11.2.3 IEEE 802.2 LLC
Main article: IEEE 802.2
Some protocols, those designed for the OSI stack, op-
erate directly on top of IEEE 802.2 LLC encapsulation,
which provides both connection-oriented and connection-
less network services.
IEEE 802.2 LLC encapsulation is not in widespread use
on common networks currently, with the exception of
large corporate NetWare installations that have not yet
migrated to NetWare over IP. In the past, many corporate
networks used IEEE 802.2 to support transparent trans-
lating bridges between Ethernet and Token Ring or FDDI
networks.
There exists an Internet standard for encapsulating IPv4
trac in IEEE 802.2 LLCSAP/SNAP frames.
[13]
It is al-
most never implemented on Ethernet, although it is used
on FDDI, Token Ring, IEEE 802.11 and other IEEE 802
LANs. IP trac cannot be encapsulated in IEEE 802.2
LLC frames without SNAP because, although there is a
LLC SAP protocol type for IP, there is no such type for
ARP, which is required for operation of any medium to
large network. IPv6 can also be transmitted over Ether-
net using IEEE 802.2 LLC SAP/SNAP, but, again, thats
almost never used.
11.2.4 IEEE 802.2 SNAP
Main article: Subnetwork Access Protocol
By examining the 802.2 LLC header, it is possible to
determine whether it is followed by a SNAP header.
The LLC header includes two additional eight-bit address
elds, called service access points (SAPs) in OSI terminol-
ogy; when both source and destination SAP are set to the
value 0xAA, the SNAP service is requested. The SNAP
header allows EtherType values to be used with all IEEE
802 protocols, as well as supporting private protocol ID
spaces. In IEEE 802.3x-1997, the IEEE Ethernet stan-
dard was changed to explicitly allow the use of the 16-bit
eld after the MAC addresses to be used as a length eld
or a type eld.
Mac OS uses IEEE 802.2 LLC SAP/SNAP encapsu-
lation for the AppleTalk v2 protocol suite on Ethernet
(EtherTalk).
11.3 Maximum throughput
We may calculate the protocol overhead for Ethernet as a
percentage (packet size including IPG)
overhead Protocol =
size Packet size Payload
size Packet
We may calculate the protocol eciency for Ethernet
eciency Protocol =
size Payload
size Packet
Maximumeciency is achieved with largest allowed pay-
load size and is:
11.6. REFERENCES 51
1500
1538
= 97.53%
for untagged frames, since the packet size is maximum
1500 octet payload + 8 octet preamble + 14 octet header +
4 octet trailer + minimum interpacket gap corresponding
to 12 octets = 1538 octets. The maximum eciency is:
1500
1542
= 97.28%
when 802.1Q VLAN tagging is used.
The throughput may be calculated from the eciency
Throughput = Eciency rate bit Net
where the physical layer net bit rate (the wire bit rate) de-
pends on the Ethernet physical layer standard, and may be
10 Mbit/s, 100 Mbit/s, 1 Gbit/s or 10 Gbit/s. Maximum
throughput for 100BASE-TX Ethernet is consequently
97.53 Mbit/s without 802.1Q, and 97.28 Mbit/s with
802.1Q.
Channel utilization is a concept often confused with pro-
tocol eciency. It considers only the use of the channel
disregarding the nature of the data transmitted either
payload or overhead. At the physical layer, the link chan-
nel and equipment do not know the dierence between
data and control frames. We may calculate the channel
utilization:
utilization Channel =
data transmitting spent Time
time Total
The total time considers the round trip time along the
channel, the processing time in the hosts and the time
transmitting data and acknowledgements. The time spent
transmitting data includes data and acknowledgements.
11.4 Runt frames
A runt frame is an Ethernet frame that is less than the
IEEE 802.3s minimum length of 64 octets. Runt frames
are most commonly caused by collisions; other possible
causes are underruns, a bad network card, or software
bugs.
[14]
11.5 Notes
[1] The bit patterns in the preamble and start of frame delim-
iter are written as bit strings, with the rst bit transmitted
on the left (not as octet values, which in Ethernet are trans-
mitted least signicant bit(s) rst). This notation matches
the one used in the IEEE 802.3 standard.
[2] 42 octet minimum applies when 802.1Q is present. When
absent, 46 octet minimum applies.
[3]
[3] Preamble and start frame delimiter are not displayed by
packet sning software because these bits are stripped
away at OSI Layer 1 by the network interface controller
before being passed on to the OSI layer 2 which is where
packet sniers collect their data. There are layer-2 snif-
fers which can capture and display the preamble and start
frame delimiter but they are expensive and mainly used to
detect physical related problems.
[4] Minimum payload size is dictated by the 512-bit slot time
used for collision detection in the Ethernet LAN architec-
ture.
[5] Both 42 and 46 octet minimums are valid when 802.1Q is
present.
[5]
[6] A version 1 Ethernet frame was used for early Ethernet
prototypes and featured 8-bit MAC addresses and was
never commercially deployed.
[7] Original Ethernet frames dene their length with the fram-
ing that surrounds it, rather than with an explicit length
count.
11.6 References
[1] 3.1.1 Packet format (PDF). IEEE Standard for Ethernet,
802.3-2012 section one. 2012-12-28. p. 53. Retrieved
2014-07-06.
[2] Ethernet Frame. Retrieved 2012-03-20. Ethernet
transmission is strange, in that the octet order is big-endian
(leftmost octet is sent rst), but bit order little-endian
(rightmost, or LSB (Least Signicant Bit) of the octet is
sent rst).
[3] IEEE 802.3-2005 Clause 3.5
[4] 802.3-2012 - IEEE Standard for Ethernet (PDF).
ieee.org. IEEE Standards Association. 2012-12-28. Re-
trieved 2014-02-09.
[5] IEEE 802.1Q-2011, Annex G
[6] Nanditha Jayarajan (2007-04-20). Congurable LocalL-
ink CRC Reference Design (PDF). xilinx.com. p. 14.
Retrieved 2014-06-30.
[7] Charles E. Spurgeon (February 2000). Ethernet: The
Denitive Guide. O'Reilly. pp. 41, 47. Retrieved 2014-
06-30.
[8] 40.1.3.1 Physical Coding Sublayer (PCS)" (PDF). IEEE
Standard for Ethernet, 802.3-2012 section three. 2012-
12-28. p. 183. Retrieved 2014-07-06.
[9] Drew Heywood; Zubair Ahmad (2001). Drew Heywoods
Windows 2000 Network Services. Sams. p. 53. ISBN
0-672-31741-9.
[10] LAN MAN Standards Committee of the IEEE Computer
Society (20 March 1997). IEEE Std 802.3x-1997 and
IEEE Std 802.3y-1997. The Institute of Electrical and
Electronics Engineers, Inc. pp. 2831.
52 CHAPTER 11. ETHERNET FRAME
[11] IEEE Std 802.3-2005, 3.2.6
[12] Don Provan (17 September 1993). "Ethernet Framing".
comp.sys.novell. Web link. (HTML-formatted version)
a classic series of Usenet postings by Novells Don
Provan that have found their way into numerous FAQs and
are widely considered the denitive answer to the Novell
Frame Type usage.
[13] RFC1042: A Standard for the Transmission of IP Data-
grams over IEEE 802 Networks. Network Working
Group of the IETF. February 1988.
[14] Troubleshooting Ethernet. Cisco Systems.
11.7 Further reading
Play media
Video which explains how to build an Ethernet
Frame
Play media
Minimum Frame Length in Ethernet explained
Chapter 12
Autonegotiation
Autonegotiation is an Ethernet procedure by which two
connected devices choose common transmission param-
eters, such as speed, duplex mode, and ow control. In
this process, the connected devices rst share their capa-
bilities regarding these parameters and then choose the
highest performance transmission mode they both sup-
port. In the OSI model, autonegotiation resides in the
physical layer. For Ethernet over twisted pair it is dened
in clause 28 of IEEE 802.3.
[1]
Autonegotiation was originally dened as an optional
component in the fast Ethernet standard. It is back-
wards compatible with 10BASE-T. The protocol was
signicantly extended in the gigabit Ethernet standard,
and is mandatory for 1000BASE-T gigabit Ethernet over
twisted pair.
[2]
12.1 Overview
In 1995, a standard was released to allow connected net-
work adapters to negotiate the best possible shared mode
of operation. The initial autonegotiation standard con-
tained a mechanism for detecting the speed but not the
duplex setting of Ethernet peers that did not use autone-
gotiation.
Autonegotiation can be used by devices that are capable
of dierent transmission rates, dierent duplex modes
(half duplex and full duplex), and/or dierent standards
at the same speed (though in practice only one standard
at each speed is widely supported). Each device declares
its technology abilities, that is, its possible modes of op-
eration, and the best mode is chosen from those shared
by them, with higher speed preferred over lower, and full
duplex preferred over half duplex at the same speed.
Parallel detection is used when a device that is capable
of autonegotiation is connected to one that is not. This
happens if the other device does not support autonegoti-
ation or autonegotiation is administratively disabled. In
this condition, the device that is capable of autonegoti-
ation can determine and match speed with the other de-
vice. This procedure cannot determine the presence of
full duplex, so half duplex is always assumed.
The standards for 1000BASE-T, 1000BASE-TX and
10GBASE-T require autonegotiation to be always present
and enabled. Other than speed and duplex mode, au-
tonegotiation is used to communicate the port type (sin-
gle port or multiport) and the master-slave parameters
(whether it is manually congured or not, whether the de-
vice is master or slave if this is the case, and the master-
slave seed bit otherwise).
12.2 Electrical signals
16ms +/- 8ms
A sequence of normal link pulses, used by 10BASE-T devices to
establish link integrity.
Auto-negotiation (formerly NWay) is based on pulses
similar to those used by 10BASE-T devices to detect the
presence of a connection to another device. These con-
nection present pulses are sent by Ethernet devices when
they are not sending or receiving any frames. They are
unipolar positive-only electrical pulses of a nominal du-
ration of 100 ns, with a maximum pulse width of 200
ns,
[3]
generated at a 16 ms time interval (with a timing
variation tolerance of 8 ms). These pulses are called link
integrity test (LIT) pulses in the 10BASE-T terminology,
and are referred to as normal link pulses (NLP) in the
auto-negotiation specication.
Adevice detects the failure of a link if neither a frame nor
two of the LIT pulses is received for 50-150 ms. For this
scheme to work, devices must send LIT pulses regardless
of receiving any.
Auto-negotiation uses similar pulses labeled as NLP.
NLP are still unipolar, positive-only, and of the nominal
duration of 100 ns; but each LIT is replaced by a pulse
burst consisting of 17 to 33 pulses sent 125 s apart. Each
such pulse burst is called a fast link pulse (FLP) burst.
53
54 CHAPTER 12. AUTONEGOTIATION
max 33 pulses
2ms
16ms +/- 8ms
Three bursts of Fast Link Pulses, used by autonegotiating devices
to declare their capabilities.
The time interval between the start of each FLP burst is
the same 16 milliseconds as between normal link pulses
(variation tolerance of 8 ms).
...
125microsec +/- 14microsec
2ms
0 0 1 0 0 0 0 0 0 1 0
How a link code word (a 16 bit word) is encoded in a fast link
pulse burst
The FLP burst consists of 17 NLP at a 125 s time inter-
val (with a tolerance of 14 s). Between each pair of two
consecutive NLP (i.e. at 62.5 s after rst NLP of the
pulse pair) an additional positive pulse may be present.
The presence of this additional pulse indicates a logical
1, its absence a logical 0. As a result, every FLP contains
a data word of 16 bits. This data word is called a link
code word (LCW). The bits of the link code word are
numbered from 0 to 15, where bit 0 corresponds to the
rst possible pulse in time and bit 15 to the last.
12.3 The base link code word
Every fast link pulse burst transmits a word of 16 bits
known as a link code word. The rst such word is known
as a base link code word, and its bits are used as follows:
04: selector eld: it indicates which standard is
used between IEEE 802.3 and IEEE 802.9;
512: technology ability eld: this is a sequence of
bits that encode the possible modes of operations
among the 100BASE-T and 10BASE-T modes;
13: remote fault: this is set to one when the device
is detecting a link failure;
14: acknowledgement: the device sets this to one to
indicate the correct reception of the base link code
word from the other party; this is detected by the
reception of at least three identical base code words;
15: next page: this bit is used to indicate the inten-
tion of sending other link code words after the base
link code word;
The technology ability eld is composed of eight bits. For
IEEE 802.3, these are as follows:
bit 0: device supports 10BASE-T
bit 1: device supports 10BASE-T in full duplex
bit 2: device supports 100BASE-TX
bit 3: device supports 100BASE-TX in full duplex
bit 4: device supports 100BASE-T4
bit 5: pause
bit 6: asymmetric pause for full duplex
bit 7: reserved
The acknowledgement bit is used to signal the correct re-
ception of the base code word. This corresponds to hav-
ing received three identical copies of the base code word.
Upon receiving these three identical copies, the device
sends a link code word with the acknowledge bit set to
one from six times to eight times.
The link code words are also called pages. The base link
code word is therefore called a base page. The next page
bit of the base page is 1 when the device intends to send
other pages, which can be used to communicate other
abilities. These additional pages are sent only if both de-
vices have sent base pages with a next page bit set to 1.
The additional pages are still encoded as link code words
(using 17 clock pulses and up to 16 bit pulses).
12.4 Message and unformatted
next page
The base page (the base link code word) is sucient
for devices to advertise which ones among the 10BASE-
T, 100BASE-TX and 100BASE-T4 modes they support.
For gigabit Ethernet, two other pages are required. These
pages are sent if both devices have sent base pages with
a next page bit set to one.
The additional pages are of two kinds: message pages and
unformatted pages. These pages are still 16-bit words en-
coded as pulses in the same way as the base page. Their
rst eleven bits are data, while their second-to-last bit in-
dicates whether the page is a message page or an unfor-
matted page. The last bit of each page indicates the pres-
ence of an additional page.
The 1000BASE-T supported modes and master-slave
data (which is used to decide which of the two devices
acts as the master, and which one acts as the slave) are
12.7. DUPLEX MISMATCH 55
sent using a single message page, followed by a single un-
formatted page. The message page contains:
half duplex capability
whether the device is single port or multiport
whether master/slave is manually congured or not
whether the device is manually congured as master
or slave
The unformatted page contains a 10-bit word, called a
master-slave seed value.
12.5 Priority
Upon receipt of the technology abilities of the other de-
vice, both devices decide the best possible mode of op-
eration supported by both devices. The priority among
modes specied in the 2012 edition of 802.3 is as
follows:
[4]
1. 10GBASE-T full duplex
2. 1000BASE-T full duplex
3. 1000BASE-T half duplex
4. 100BASE-T2 full duplex
5. 100BASE-TX full duplex
6. 100BASE-T2 half duplex
7. 100BASE-T4 half duplex
8. 100BASE-TX half duplex
9. 10BASE-T full duplex
10. 10BASE-T half duplex
In other words, among the modes that are supported by
both devices, each device chooses the one that is the top-
most in this list.
12.6 Interoperability problems
The rst version of the autonegotiation specication,
IEEE 802.3u, was open to dierent interpretations. Al-
though most manufacturers implemented this standard in
one way, some others, including network giant Cisco, im-
plemented it in a dierent way. Autonegotiation between
devices that implemented it dierently failed. Problems
like this with autonegotiation led many network adminis-
trators to manually set the speed and duplex mode of each
network interface card, and even Cisco recommended its
customers not to use autonegotiation. However, the use
of manually set conguration may also lead to duplex mis-
matches, in particular when two connected devices are:
One manually set to half duplex and one manually
set to full duplex
One set to autonegotiation and one manually set to
full duplex
Both sides manually set to full duplex where one side
still expects an autonegotiating link partner and the
other side has autonegotiation completely disabled
(the side that expects an autonegotiating link part-
ner will fall back to half duplex because it does not
detect a partner capable of full duplex)
Duplex mismatch problems are dicult to diagnose be-
cause the network is apparently working, and simple pro-
grams used for network tests such as ping report a valid
connection; however, the network is much slower than
expected.
The debatable portions of the autonegotiation specica-
tions were eliminated by the 1998 release of 802.3. This
was later followed by the release of IEEE 802.3ab in
1999. The new standard specied that gigabit Ethernet
over copper wiring requires autonegotiation. Currently,
many network equipment manufacturers recommend us-
ing autonegotiation on all access ports.
12.7 Duplex mismatch
Main article: Duplex mismatch
A duplex mismatch occurs when two connected devices
are congured in dierent duplex modes. This may hap-
pen for example if one is congured for autonegotiation
while the other one has a xed mode of operation that is
full duplex (no autonegotiation). In such conditions, the
autonegotiation device correctly detects the speed of op-
eration, but is unable to correctly detect the duplex mode.
As a result, it sets the correct speed but starts using the
half duplex mode.
When a device is operating in full duplex while the other
one operates in half duplex, the connection works at a
very low speed if both devices attempt to send frames at
the same time. This is because data can be sent in both di-
rections at the same time in full duplex mode, but only in
one direction at a time in half duplex mode. As a result, a
full duplex device may transmit data while it is receiving.
However, if the other device is working in half duplex,
it does not expect to receive data (because it is currently
sending); therefore, it senses a collision and attempts to
resend the frame it was sending. Depending on timing
the half duplex device may sense a late collision, which it
will interpret as a hard error rather than a normal conse-
quence of CSMA/CD and will not attempt to resend the
frame. On the other hand, the full duplex device does not
detect any collision and does not resend the frame, even
56 CHAPTER 12. AUTONEGOTIATION
if the other device has discarded it as corrupted by colli-
sion. Still, the full duplex device, not expecting incoming
frames to be truncated by collision detection, will report
frame check sequence errors. This combination of late
collisions reported at the half-duplex end and FCS errors
reported by the full duplex end can be used as an indica-
tion that a duplex mismatch is present.
This packet loss happens when both devices are transmit-
ting at the same time. This may happen even when the
link is used, from the users perspective, in one direction
only. A TCP stream requires all packets sent to be ac-
knowledged by the receiving device. As a result, even if
actual data is sent in one direction only, collision may be
generated with acknowledgement packets traveling in the
other direction.
12.8 History
The protocol that became IEEE 802.3 clause 28 was de-
veloped from a patented technology by National Semi-
conductor known as NWay. The company gave a letter of
assurance for anyone to use their system for a one time li-
cense fee.
[5]
Another company has since bought the rights
to that patent.
[6]
12.9 Patents
Autonegotiation is covered by the US patents U.S.
Patent 5,617,418; U.S. Patent 5,687,174; E U.S. Patent
RE39,405 E; E U.S. Patent RE39,116 E; 971,018 (led
1992-11-02); 146,729 (led 1993-11-01); 430,143 (led
1995-04-26)
[6]
European Patent Applications SN 93308568.0 (DE, FR,
GB, IT, NL); Korean Patent No. 286791, Taiwanese
Patent No. 098359, Japanese Patent No. 3705610;
Japanese Patent 4234. Applications SN H5-274147; Ko-
rean Patent Applications SN22995/93; Taiwanese Patent
Applications SN 83104531;
12.10 See also
Auto MDI-X for automatic conguration of
straight-through or crossover-cable connection
12.11 References
[1] http://standards.ieee.org/getieee802/download/802.
3-2012_section2.pdf IEEE 802.3, clause 28, page 221,
Physical Layer link signaling for Auto-Negotiation on
twisted pair Note: Download of PDF is free, but behind
a Captive portal.
[2] IEEE. Part 3: Carrier Sense Multiple Access with Col-
lision Detection (CSMA/CD) access method and Phys-
ical Layer specications. SECTION TWO: This sec-
tion includes Clause21 through Clause 33 and Annex 22A
through Annex 33E. Retrieved 2014-06-03.
[3] IEEE Link Task Force Autodetect, Specication for
NWay Autodetect. p. 57. Archived from the original
on 2011-07-14.
[4] IEEE 802.3 Annex 28B
[5] http://www.negotiateddata.com/files/Grant_Letter_
060794.pdf
[6] Negotiated Data Solutions LLC. NWay/IEEE Standard
Patent License Oer | Negotiated Data Solutions LLC.
Negotiateddata.com. Retrieved 2010-02-02.
12.12 External links
Ethernet Autonegotiation Best Practices
Gigabit Ethernet autonegotiation
What is autonegotiation?
Cisco Catalyst Cong Guide
How does Autonegotiation work
Autoneg Timing
Chapter 13
Internet protocol suite
The Internet protocol suite is the computer networking
model and set of communications protocols used on the
Internet and similar computer networks. It is commonly
known as TCP/IP, because its most important protocols,
the Transmission Control Protocol (TCP) and the Internet
Protocol (IP), were the rst networking protocols dened
in this standard. Often also called the Internet model, it
was originally also known as the DoD model, because
the development of the networking model was funded by
DARPA, an agency of the United States Department of
Defense.
TCP/IP provides end-to-end connectivity specifying how
data should be packetized, addressed, transmitted, routed
and received at the destination. This functionality is or-
ganized into four abstraction layers which are used to sort
all related protocols according to the scope of networking
involved.
[1][2]
From lowest to highest, the layers are the
link layer, containing communication technologies for a
single network segment (link), the internet layer, connect-
ing hosts across independent networks, thus establishing
internetworking, the transport layer handling host-to-host
communication, and the application layer, which provides
process-to-process application data exchange.
The TCP/IP model and related protocol models are main-
tained by the Internet Engineering Task Force (IETF).
13.1 History
13.1.1 Early research
The Internet protocol suite resulted fromresearch and de-
velopment conducted by the Defense Advanced Research
Projects Agency (DARPA) in the late 1960s.
[3]
After
initiating the pioneering ARPANET in 1969, DARPA
started work on a number of other data transmission tech-
nologies. In 1972, Robert E. Kahn joined the DARPA
Information Processing Technology Oce, where he
worked on both satellite packet networks and ground-
based radio packet networks, and recognized the value
of being able to communicate across both. In the spring
of 1973, Vinton Cerf, the developer of the existing
ARPANET Network Control Program (NCP) protocol,
Diagram of the rst internetworked connection
A Stanford Research Institute packet radio van, site of the rst
three-way internetworked transmission.
joined Kahn to work on open-architecture interconnec-
tion models with the goal of designing the next protocol
generation for the ARPANET.
By the summer of 1973, Kahn and Cerf had worked out a
fundamental reformulation, in which the dierences be-
tween network protocols were hidden by using a common
internetwork protocol, and, instead of the network being
responsible for reliability, as in the ARPANET, the hosts
became responsible. Cerf credits Hubert Zimmermann
and Louis Pouzin, designer of the CYCLADES network,
with important inuences on this design.
The design of the network included the recognition that
it should provide only the functions of eciently trans-
57
58 CHAPTER 13. INTERNET PROTOCOL SUITE
mitting and routing trac between end nodes and that
all other intelligence should be located at the edge of
the network, in the end nodes. Using a simple design,
it became possible to connect almost any network to
the ARPANET, irrespective of the local characteristics,
thereby solving Kahns initial problem. One popular ex-
pression is that TCP/IP, the eventual product of Cerf and
Kahns work, will run over "two tin cans and a string."
(Years later, as a joke, the IP over Avian Carriers for-
mal protocol specication was created and successfully
tested.)
A computer called a router is provided with an interface
to each network. It forwards packets back and forth be-
tween them.
[4]
Originally a router was called gateway, but
the term was changed to avoid confusion with other types
of gateways.
13.1.2 Specication
From 1973 to 1974, Cerfs networking research group
at Stanford worked out details of the idea, resulting in
the rst TCP specication.
[5]
A signicant technical in-
uence was the early networking work at Xerox PARC,
which produced the PARC Universal Packet protocol
suite, much of which existed around that time.
DARPA then contracted with BBN Technologies,
Stanford University, and the University College London
to develop operational versions of the protocol on dier-
ent hardware platforms. Four versions were developed:
TCP v1, TCP v2, TCP v3 and IP v3, and TCP/IP v4.
The last protocol is still in use today.
In 1975, a two-network TCP/IP communications test was
performed between Stanford and University College Lon-
don (UCL). In November, 1977, a three-network TCP/IP
test was conducted between sites in the US, the UK,
and Norway. Several other TCP/IP prototypes were de-
veloped at multiple research centers between 1978 and
1983. The migration of the ARPANET to TCP/IP was
ocially completed on ag day January 1, 1983, when
the new protocols were permanently activated.
[6]
13.1.3 Adoption
In March 1982, the US Department of Defense de-
clared TCP/IP as the standard for all military computer
networking.
[7]
In 1985, the Internet Advisory Board (later
renamed the Internet Architecture Board) held a three-
day workshop on TCP/IP for the computer industry, at-
tended by 250 vendor representatives, promoting the pro-
tocol and leading to its increasing commercial use.
In 1985, the rst Interop conference focused on network
interoperability by broader adoption of TCP/IP. The con-
ference was founded by Dan Lynch, an early Internet ac-
tivist. From the beginning, large corporations, such as
IBM and DEC, attended the meeting. Interoperability
conferences have been held every year since then. Every
year from 1985 through 1993, the number of attendees
tripled.
IBM, AT&T and DEC were the rst major corporations
to adopt TCP/IP, despite having competing internal pro-
tocols (SNA, XNS, etc.). In IBM, from 1984, Barry Ap-
pelman's group did TCP/IP development. (Appelman
later moved to AOL to be the head of all its development
eorts.) They navigated the corporate politics to get a
stream of TCP/IP products for various IBM systems, in-
cluding MVS, VM, and OS/2. At the same time, sev-
eral smaller companies began oering TCP/IP stacks for
DOS and MS Windows, such as the company FTP Soft-
ware, and the Wollongong Group.
[8]
The rst VM/CMS
TCP/IP stack came from the University of Wisconsin.
[9]
Back then, most of these TCP/IP stacks were written
single-handedly by a few talented programmers. For ex-
ample, John Romkey of FTP Software was the author of
the MIT PC/IP package.
[10]
John Romkeys PC/IP im-
plementation was the rst IBM PC TCP/IP stack. Jay
Elinsky and Oleg Vishnepolsky of IBM Research wrote
TCP/IP stacks for VM/CMS and OS/2, respectively.
[11]
The spread of TCP/IP was fueled further in June 1989,
when AT&T agreed to place the TCP/IP code devel-
oped for UNIX into the public domain. Various ven-
dors, including IBM, included this code in their own
TCP/IP stacks. Many companies sold TCP/IP stacks
for Windows until Microsoft released a native TCP/IP
stack in Windows 95. This event was a little late in
the evolution of the Internet, but it cemented TCP/IPs
dominance over other protocols, which eventually dis-
appeared. These protocols included IBM Systems Net-
work Architecture (SNA), Open Systems Interconnec-
tion (OSI), Microsofts native NetBIOS, and Xerox Net-
work Systems (XNS).
13.2 Key architectural principles
An early architectural document, RFC 1122, emphasizes
architectural principles over layering.
[12]
End-to-end principle: This principle has evolved
over time. Its original expression put the mainte-
nance of state and overall intelligence at the edges,
and assumed the Internet that connected the edges
retained no state and concentrated on speed and sim-
plicity. Real-world needs for rewalls, network ad-
dress translators, web content caches and the like
have forced changes in this principle.
[13]
Robustness Principle: In general, an implementa-
tion must be conservative in its sending behavior,
and liberal in its receiving behavior. That is, it must
be careful to send well-formed datagrams, but must
accept any datagram that it can interpret (e.g., not
object to technical errors where the meaning is still
13.3. ABSTRACTION LAYERS 59
clear).
[14]
The second part of the principle is al-
most as important: software on other hosts may con-
tain deciencies that make it unwise to exploit legal
but obscure protocol features.
[15]
13.3 Abstraction layers
The Internet protocol suite uses encapsulation to provide
abstraction of protocols and services. Encapsulation is
usually aligned with the division of the protocol suite into
layers of general functionality. In general, an application
(the highest level of the model) uses a set of protocols to
send its data down the layers, being further encapsulated
at each level.
The layers of the protocol suite near the top are logically
closer to the user application, while those near the bot-
tomare logically closer to the physical transmission of the
data. Viewing layers as providing or consuming a service
is a method of abstraction to isolate upper layer protocols
from the details of transmitting bits over, for example,
Ethernet and collision detection, while the lower layers
avoid having to know the details of each and every appli-
cation and its protocol.
Even when the layers are examined, the assorted architec-
tural documentsthere is no single architectural model
such as ISO 7498, the Open Systems Interconnection
(OSI) modelhave fewer and less rigidly dened layers
than the OSI model, and thus provide an easier t for real-
world protocols. One frequently referenced document,
RFC 1958, does not contain a stack of layers. The lack
of emphasis on layering is a major dierence between the
IETF and OSI approaches. It only refers to the existence
of the internetworking layer and generally to upper layers;
this document was intended as a 1996 snapshot of the ar-
chitecture: The Internet and its architecture have grown
in evolutionary fashion from modest beginnings, rather
than from a Grand Plan. While this process of evolution
is one of the main reasons for the technologys success,
it nevertheless seems useful to record a snapshot of the
current principles of the Internet architecture.
RFC 1122, entitled Host Requirements, is structured in
paragraphs referring to layers, but the document refers
to many other architectural principles not emphasizing
layering. It loosely denes a four-layer model, with the
layers having names, not numbers, as follows:
The Application layer is the scope within which ap-
plications create user data and communicate this
data to other applications on another or the same
host. The applications, or processes, make use of the
services provided by the underlying, lower layers,
especially the Transport Layer which provides reli-
able or unreliable pipes to other processes. The com-
munications partners are characterized by the appli-
cation architecture, such as the client-server model
and peer-to-peer networking. This is the layer in
which all higher level protocols, such as SMTP, FTP,
SSH, HTTP, operate. Processes are addressed via
ports which essentially represent services.
The Transport Layer performs host-to-host commu-
nications on either the same or dierent hosts and
on either the local network or remote networks sep-
arated by routers. It provides a channel for the com-
munication needs of applications. UDP is the ba-
sic transport layer protocol, providing an unreliable
datagram service. The Transmission Control Proto-
col provides ow-control, connection establishment,
and reliable transmission of data.
The Internet layer has the task of exchanging data-
grams across network boundaries. It provides a
uniform networking interface that hides the actual
topology (layout) of the underlying network connec-
tions. It is therefore also referred to as the layer that
establishes internetworking, indeed, it denes and
establishes the Internet. This layer denes the ad-
dressing and routing structures used for the TCP/IP
protocol suite. The primary protocol in this scope
is the Internet Protocol, which denes IP addresses.
Its function in routing is to transport datagrams to
the next IP router that has the connectivity to a net-
work closer to the nal data destination.
The Link layer denes the networking methods
within the scope of the local network link on which
hosts communicate without intervening routers.
This layer includes the protocols used to describe
the local network topology and the interfaces needed
to eect transmission of Internet layer datagrams to
next-neighbor hosts.
The Internet protocol suite and the layered protocol stack
design were in use before the OSI model was established.
Since then, the TCP/IP model has been compared with
the OSI model in books and classrooms, which often re-
sults in confusion because the two models use dierent
assumptions and goals, including the relative importance
of strict layering.
This abstraction also allows upper layers to provide ser-
vices that the lower layers do not provide. While the orig-
inal OSI model was extended to include connectionless
services (OSIRM CL),
[16]
IP is not designed to be reli-
able and is a best eort delivery protocol. This means that
all transport layer implementations must choose whether
or how to provide reliability. UDP provides data integrity
via a checksumbut does not guarantee delivery; TCP pro-
vides both data integrity and delivery guarantee by re-
transmitting until the receiver acknowledges the recep-
tion of the packet.
This model lacks the formalism of the OSI model and as-
sociated documents, but the IETF does not use a formal
model and does not consider this a limitation, as illus-
trated in the comment by David D. Clark, We reject:
60 CHAPTER 13. INTERNET PROTOCOL SUITE
kings, presidents and voting. We believe in: rough con-
sensus and running code. Criticisms of this model, which
have been made with respect to the OSI model, often do
not consider ISOs later extensions to that model.
For multiaccess links with their own addressing systems
(e.g. Ethernet) an address mapping protocol is needed.
Such protocols can be considered to be below IP but
above the existing link system. While the IETF does
not use the terminology, this is a subnetwork depen-
dent convergence facility according to an extension to the
OSI model, the internal organization of the network layer
(IONL).
[17]
ICMP & IGMP operate on top of IP but do not transport
data like UDP or TCP. Again, this functionality exists
as layer management extensions to the OSI model, in its
Management Framework (OSIRM MF)
[18]
The SSL/TLS library operates above the transport layer
(uses TCP) but below application protocols. Again, there
was no intention, on the part of the designers of these
protocols, to comply with OSI architecture.
The link is treated like a black box. The IETF explicitly
does not intend to discuss transmission systems, which is
a less academic but practical alternative to the OSI model.
The following is a description of each layer in the TCP/IP
networking model starting from the lowest level.
13.3.1 Link layer
The link layer has the networking scope of the local net-
work connection to which a host is attached. This regime
is called the link in TCP/IP literature. It is the lowest
component layer of the Internet protocols, as TCP/IP is
designed to be hardware independent. As a result TCP/IP
may be implemented on top of virtually any hardware net-
working technology.
The link layer is used to move packets between the In-
ternet layer interfaces of two dierent hosts on the same
link. The processes of transmitting and receiving pack-
ets on a given link can be controlled both in the software
device driver for the network card, as well as on rmware
or specialized chipsets. These performdata link functions
such as adding a packet header to prepare it for trans-
mission, then actually transmit the frame over a physical
medium. The TCP/IP model includes specications of
translating the network addressing methods used in the
Internet Protocol to data link addressing, such as Media
Access Control (MAC). All other aspects below that
level, however, are implicitly assumed to exist in the link
layer, but are not explicitly dened.
This is also the layer where packets may be selected to be
sent over a virtual private network or other networking
tunnel. In this scenario, the link layer data may be con-
sidered application data which traverses another instanti-
ation of the IP stack for transmission or reception over
another IP connection. Such a connection, or virtual
link, may be established with a transport protocol or even
an application scope protocol that serves as a tunnel in
the link layer of the protocol stack. Thus, the TCP/IP
model does not dictate a strict hierarchical encapsulation
sequence.
The TCP/IP models link layer corresponds to the Open
Systems Interconnection (OSI) model physical and data
link layers, layers one and two of the OSI model.
13.3.2 Internet layer
The internet layer has the responsibility of sending pack-
ets across potentially multiple networks. Internetworking
requires sending data from the source network to the des-
tination network. This process is called routing.
[19]
The Internet Protocol performs two basic functions:
Host addressing and identication: This is accom-
plished with a hierarchical IP addressing system.
Packet routing: This is the basic task of sending
packets of data (datagrams) from source to destina-
tion by forwarding them to the next network router
closer to the nal destination.
The internet layer is not only agnostic of data structures
at the transport layer, but it also does not distinguish be-
tween operation of the various transport layer protocols.
IP carries data for a variety of dierent upper layer pro-
tocols. These protocols are each identied by a unique
protocol number: for example, Internet Control Message
Protocol (ICMP) and Internet Group Management Pro-
tocol (IGMP) are protocols 1 and 2, respectively.
Some of the protocols carried by IP, such as ICMP which
is used to transmit diagnostic information, and IGMP
which is used to manage IP Multicast data, are layered on
top of IP but perform internetworking functions. This il-
lustrates the dierences in the architecture of the TCP/IP
stack of the Internet and the OSI model. The TCP/IP
models internet layer corresponds to layer three of the
Open Systems Interconnection (OSI) model, where it is
referred to as the network layer.
The internet layer provides only an unreliable datagram
transmission facility between hosts located on potentially
dierent IP networks by forwarding the transport layer
datagrams to an appropriate next-hop router for further
relaying to its destination. With this functionality, the
internet layer makes possible internetworking, the inter-
working of dierent IP networks, and it essentially es-
tablishes the Internet. The Internet Protocol is the prin-
cipal component of the internet layer, and it denes two
addressing systems to identify network hosts computers,
and to locate them on the network. The original address
system of the ARPANET and its successor, the Inter-
net, is Internet Protocol version 4 (IPv4). It uses a 32-
13.3. ABSTRACTION LAYERS 61
bit IP address and is therefore capable of identifying ap-
proximately four billion hosts. This limitation was elimi-
nated by the standardization of Internet Protocol version
6 (IPv6) in 1998, and beginning production implementa-
tions in approximately 2006.
13.3.3 Transport layer
The transport layer establishes a basic data channel that
an application uses in its task-specic data exchange. The
layer establishes process-to-process connectivity, mean-
ing it provides end-to-end services that are independent
of the structure of user data and the logistics of exchang-
ing information for any particular specic purpose. Its
responsibility includes end-to-end message transfer in-
dependent of the underlying network, along with error
control, segmentation, ow control, congestion control,
and application addressing (port numbers). End-to-end
message transmission or connecting applications at the
transport layer can be categorized as either connection-
oriented, implemented in TCP, or connectionless, imple-
mented in UDP.
For the purpose of providing process-specic transmis-
sion channels for applications, the layer establishes the
concept of the port. This is a numbered logical con-
struct allocated specically for each of the communica-
tion channels an application needs. For many types of
services, these port numbers have been standardized so
that client computers may address specic services of a
server computer without the involvement of service an-
nouncements or directory services.
Because IP provides only a best eort delivery, some
transport layer protocols oer reliability. However, IP
can run over a reliable data link protocol such as the High-
Level Data Link Control (HDLC).
For example, the TCP is a connection-oriented protocol
that addresses numerous reliability issues in providing a
reliable byte stream:
data arrives in-order
data has minimal error (i.e., correctness)
duplicate data is discarded
lost or discarded packets are resent
includes trac congestion control
The newer Stream Control Transmission Protocol
(SCTP) is also a reliable, connection-oriented trans-
port mechanism. It is message-stream-orientednot
byte-stream-oriented like TCPand provides multiple
streams multiplexed over a single connection. It also pro-
vides multi-homing support, in which a connection end
can be represented by multiple IP addresses (represent-
ing multiple physical interfaces), such that if one fails, the
connection is not interrupted. It was developed initially
for telephony applications (to transport SS7 over IP), but
can also be used for other applications.
The User Datagram Protocol is a connectionless
datagramprotocol. Like IP, it is a best eort, unreliable
protocol. Reliability is addressed through error detection
using a weak checksum algorithm. UDP is typically used
for applications such as streaming media (audio, video,
Voice over IP etc.) where on-time arrival is more im-
portant than reliability, or for simple query/response ap-
plications like DNS lookups, where the overhead of set-
ting up a reliable connection is disproportionately large.
Real-time Transport Protocol (RTP) is a datagram pro-
tocol that is designed for real-time data such as streaming
audio and video.
The applications at any given network address are distin-
guished by their TCP or UDP port. By convention certain
well known ports are associated with specic applications.
The TCP/IP models transport or host-to-host layer cor-
responds to the fourth layer in the Open Systems Inter-
connection (OSI) model, also called the transport layer.
13.3.4 Application layer
The application layer includes the protocols used by most
applications for providing user services or exchanging ap-
plication data over the network connections established
by the lower level protocols, but this may include some
basic network support services, such as many routing pro-
tocols, and host conguration protocols. Examples of ap-
plication layer protocols include the Hypertext Transfer
Protocol (HTTP), the File Transfer Protocol (FTP), the
Simple Mail Transfer Protocol (SMTP), and the Dynamic
Host Conguration Protocol (DHCP).
[20]
Data coded ac-
cording to application layer protocols are encapsulated
into transport layer protocol units (such as TCP or UDP
messages), which in turn use lower layer protocols to ef-
fect actual data transfer.
The IP model does not consider the specics of format-
ting and presenting data, and does not dene additional
layers between the application and transport layers as in
the OSI model (presentation and session layers). Such
functions are the realm of libraries and application pro-
gramming interfaces.
Application layer protocols generally treat the transport
layer (and lower) protocols as black boxes which pro-
vide a stable network connection across which to com-
municate, although the applications are usually aware of
key qualities of the transport layer connection such as
the end point IP addresses and port numbers. Appli-
cation layer protocols are often associated with particu-
lar clientserver applications, and common services have
well-known port numbers reserved by the Internet As-
signed Numbers Authority (IANA). For example, the
HyperText Transfer Protocol uses server port 80 and
62 CHAPTER 13. INTERNET PROTOCOL SUITE
Telnet uses server port 23. Clients connecting to a service
usually use ephemeral ports, i.e., port numbers assigned
only for the duration of the transaction at random or from
a specic range congured in the application.
The transport layer and lower-level layers are uncon-
cerned with the specics of application layer protocols.
Routers and switches do not typically examine the en-
capsulated trac, rather they just provide a conduit for it.
However, some rewall and bandwidth throttling applica-
tions must interpret application data. An example is the
Resource Reservation Protocol (RSVP). It is also some-
times necessary for network address translator (NAT)
traversal to consider the application payload.
The application layer in the TCP/IP model is often com-
pared as equivalent to a combination of the fth (Session),
sixth (Presentation), and the seventh (Application) layers
of the Open Systems Interconnection (OSI) model.
13.4 Layer names and number of
layers in the literature
The following table shows various networking models.
The number of layers varies between three and seven.
Some of the networking models are from textbooks,
which are secondary sources that may conict with the
intent of RFC 1122 and other IETF primary sources.
[28]
13.5 Comparison of TCP/IP and
OSI layering
The three top layers in the OSI modelthe application
layer, the presentation layer and the session layerare
not distinguished separately in the TCP/IP model where
it is just the application layer. While some pure OSI pro-
tocol applications, such as X.400, also combined them,
there is no requirement that a TCP/IP protocol stack
must impose monolithic architecture above the transport
layer. For example, the NFS application protocol runs
over the eXternal Data Representation (XDR) presenta-
tion protocol, which, in turn, runs over a protocol called
Remote Procedure Call (RPC). RPC provides reliable
record transmission, so it can safely use the best-eort
UDP transport.
Dierent authors have interpreted the RFCs dierently,
about whether the link layer (and the TCP/IP model) cov-
ers OSI model layer 1 (physical layer) issues, or whether
a hardware layer is assumed below the link layer.
Several authors have attempted to incorporate the OSI
models layers 1 and 2 into the TCP/IP model, since these
are commonly referred to in modern standards (for exam-
ple, by IEEE and ITU). This often results in a model with
ve layers, where the link layer or network access layer is
split into the OSI models layers 1 and 2.
The session layer roughly corresponds to the Telnet
virtual terminal functionality, which is part of text based
protocols such as the HTTP and SMTP TCP/IP model
application layer protocols. It also corresponds to TCP
and UDP port numbering, which is considered as part of
the transport layer in the TCP/IP model. Some functions
that would have been performed by an OSI presentation
layer are realized at the Internet application layer using
the MIME standard, which is used in application layer
protocols such as HTTP and SMTP.
The IETF protocol development eort is not concerned
with strict layering. Some of its protocols may not
t cleanly into the OSI model, although RFCs some-
times refer to it and often use the old OSI layer num-
bers. The IETF has repeatedly stated that Internet pro-
tocol and architecture development is not intended to be
OSI-compliant. RFC 3439, addressing Internet architec-
ture, contains a section entitled: Layering Considered
Harmful.
[28]
Conicts are apparent also in the original OSI model, ISO
7498, when not considering the annexes to this model
(e.g., ISO 7498/4 Management Framework), or the ISO
8648 Internal Organization of the Network layer (IONL).
When the IONL and Management Framework docu-
ments are considered, the ICMP and IGMP are neatly
dened as layer management protocols for the network
layer. In like manner, the IONL provides a structure
for subnetwork dependent convergence facilities such
as ARP and RARP.
IETF protocols can be encapsulated recursively, as
demonstrated by tunneling protocols such as Generic
Routing Encapsulation (GRE). GREuses the same mech-
anism that OSI uses for tunneling at the network layer.
13.6 Implementations
The Internet protocol suite does not presume any specic
hardware or software environment. It only requires that
hardware and a software layer exists that is capable of
sending and receiving packets on a computer network.
As a result, the suite has been implemented on essen-
tially every computing platform. A minimal implemen-
tation of TCP/IP includes the following: Internet Pro-
tocol (IP), Address Resolution Protocol (ARP), Internet
Control Message Protocol (ICMP), Transmission Con-
trol Protocol (TCP), User DatagramProtocol (UDP), and
IGMP. In addition to IP, ICMP, TCP, UDP, Internet
Protocol version 6 requires NDP, ICMPv6, and IGMPv6
and is often accompanied by an integrated IPSec security
layer.
Application programmers are typically concerned only
with interfaces in the application layer and often also in
the transport layer, while the layers below are services
provided by the TCP/IP stack in the operating system.
13.9. BIBLIOGRAPHY 63
Most IP implementations are accessible to programmers
through sockets and APIs.
Unique implementations include Lightweight TCP/IP, an
open source stack designed for embedded systems, and
KA9QNOS, a stack and associated protocols for amateur
packet radio systems and personal computers connected
via serial lines.
Microcontroller rmware in the network adapter typi-
cally handles link issues, supported by driver software
in the operating system. Non-programmable analog and
digital electronics are normally in charge of the physi-
cal components below the link layer, typically using an
application-specic integrated circuit (ASIC) chipset for
each network interface or other physical standard. High-
performance routers are to a large extent based on fast
non-programmable digital electronics, carrying out link
level switching.
13.7 See also
BBN Report 1822
FLIP (protocol) (fast local Internet protocol stack)
List of automation protocols
List of information technology acronyms
List of network protocols
List of TCP and UDP port numbers
13.8 References
[1] RFC 1122, Requirements for Internet Hosts Communi-
cation Layers, R. Braden (ed.), October 1989.
[2] RFC 1123, Requirements for Internet Hosts Application
and Support, R. Braden (ed.), October 1989
[3] The DoD Internet Architecture Model, Vinton G. Cerf
and Edward Cain, Computer Networks, 7 (1983), North-
Holland, pp. 307-318
[4] RFC 1812, Requirements for IP Version 4 Routers, F.
Baker (June 1995)
[5] RFC 675, Specication of Internet Transmission Control
Protocol, V. Cerf et al. (December 1974)
[6] Internet History
[7] Ronda Hauben. From the ARPANET to the Internet.
TCP Digest (UUCP). Retrieved 2007-07-05.
[8] Wollongong
[9] A Short History of Internet Protocols at CERN
[10] About | romkey
[11] Barry Appelman
[12] RFC1958, Architectural Principles of the Internet, B. Car-
penter (June 1996)
[13] Rethinking the design of the Internet: The end-to-end ar-
guments vs. the brave new world, Marjory S. Blumenthal,
David D. Clark, August 2001
[14] p.23 INTERNET PROTOCOL DARPA INTERNET
PROGRAMPROTOCOL SPECIFICATIONSeptember
1981 Jon Postel Editor
[15] Requirements for Internet Hosts -- Communication Lay-
ers p.13 October 1989 R. Braden, Editor
[16] [ OSI: Reference Model Addendum 1: Connectionless-
mode Transmission,ISO7498/AD1],ISO7498/AD1, May
1986
[17] Information processing systems -- Open Systems In-
terconnection -- Internal organization of the Network
Layer, ISO 8648:1988.
[18] Information processing systems -- Open Systems Inter-
connection -- Basic Reference Model -- Part 4: Manage-
ment framework, ISO 7498-4:1989.
[19] IP Packet Structure
[20] TCP/IP Illustrated: the protocols, ISBN 0-201-63346-9,
W. Richard Stevens, February 1994
[21] Mark A. Dye, Rick McDonald, Antoon W. Ru, Network
Fundamentals: CCNA Exploration Companion Guide,
2007, ISBN 1-58713-208-7
[22] James F. Kurose, Keith W. Ross, Computer Networking:
A Top-Down Approach, 2008, ISBN 0-321-49770-8
[23] Behrouz A. Forouzan, Data Communications and Net-
working, 2003
[24] Douglas E. Comer, Internetworking with TCP/IP: Prin-
ciples, Protocols and Architecture, Pearson Prentice Hall
2005, ISBN 0-13-187671-6
[25] Charles M. Kozierok, The TCP/IP Guide, No Starch
Press 2005
[26] William Stallings, Data and Computer Communications,
Prentice Hall 2006, ISBN 0-13-243310-9
[27] Andrew S. Tanenbaum, Computer Networks, Prentice
Hall 2002, ISBN 0-13-066102-3
[28] R. Bush; D. Meyer (December 2002), Some Internet Ar-
chitectural Guidelines and Philosophy, Internet Engineer-
ing Task Force
13.9 Bibliography
Douglas E. Comer. Internetworking with TCP/IP
- Principles, Protocols and Architecture. ISBN 86-
7991-142-9
64 CHAPTER 13. INTERNET PROTOCOL SUITE
Joseph G. Davies and Thomas F. Lee. Microsoft
Windows Server 2003 TCP/IP Protocols and Ser-
vices. ISBN 0-7356-1291-9
Forouzan, Behrouz A. (2003). TCP/IPProtocol Suite
(2nd ed.). McGraw-Hill. ISBN 0-07-246060-1.
Craig Hunt TCP/IP Network Administration.
O'Reilly (1998) ISBN 1-56592-322-7
Maufer, Thomas A. (1999). IP Fundamentals.
Prentice Hall. ISBN 0-13-975483-0.
Ian McLean. Windows(R) 2000 TCP/IP Black Book.
ISBN 1-57610-687-X
Ajit Mungale Pro .NET 1.1 Network Programming.
ISBN 1-59059-345-6
W. Richard Stevens. TCP/IP Illustrated, Volume 1:
The Protocols. ISBN 0-201-63346-9
W. Richard Stevens and Gary R. Wright. TCP/IP
Illustrated, Volume 2: The Implementation. ISBN 0-
201-63354-X
W. Richard Stevens. TCP/IP Illustrated, Volume 3:
TCP for Transactions, HTTP, NNTP, and the UNIX
Domain Protocols. ISBN 0-201-63495-3
Andrew S. Tanenbaum. Computer Networks. ISBN
0-13-066102-3
Clark, D. (1988). The Design Philosophy of
the DARPA Internet Protocols. SIGCOMM
'88 Symposium proceedings on Communications
architectures and protocols (ACM): 106114.
doi:10.1145/52324.52336. Retrieved 2011-10-16.
13.10 External links
Internet HistoryPages on Robert Kahn, Vinton
Cerf, and TCP/IP (reviewed by Cerf and Kahn).
RFC 675 - Specication of Internet Transmission
Control Program, December 1974 Version
TCP/IP State Transition Diagram (PDF)
RFC 1180 A TCP/IP Tutorial - from the Internet
Engineering Task Force (January 1991)
TCP/IP FAQ
The TCP/IP Guide - A comprehensive look at the
protocols and the procedures/processes involved
A Study of the ARPANET TCP/IP Digest
TCP/IP Sequence Diagrams
Daryls TCP/IP Primer - Intro to TCP/IP LAN ad-
ministration, conversational style
Introduction to TCP/IP
Chapter 14
IPv4
Internet Protocol version 4 (IPv4) is the fourth version
in the development of the Internet Protocol (IP) Internet,
and routes most trac on the Internet.
[1]
However, a suc-
cessor protocol, IPv6, has been dened and is in various
stages of production deployment. IPv4 is described in
IETF publication RFC 791 (September 1981), replacing
an earlier denition (RFC 760, January 1980).
IPv4 is a connectionless protocol for use on packet-
switched networks. It operates on a best eort delivery
model, in that it does not guarantee delivery, nor does it
assure proper sequencing or avoidance of duplicate de-
livery. These aspects, including data integrity, are ad-
dressed by an upper layer transport protocol, such as the
Transmission Control Protocol (TCP).
14.1 Addressing
An IPv4 address
172 16 1 254 . . .
10101100 00010000 11111110 00000001 . . .
One byte Eight bits =
Thirty-two bits (4 x 8), or 4 bytes
(dotted-decimal notation)
Decomposition of the quad-dotted IPv4 address representation to
its binary value
IPv4 uses 32-bit (four-byte) addresses, which limits the
address space to 4294967296 (2
32
) addresses. As ad-
dresses were assigned to users, the number of unassigned
addresses decreased. IPv4 address exhaustion occurred
on February 3, 2011, although it had been signicantly
delayed by address changes such as classful network de-
sign, Classless Inter-Domain Routing, and network ad-
dress translation (NAT).
This limitation of IPv4 stimulated the development of
IPv6 in the 1990s, which has been in commercial deploy-
ment since 2006.
IPv4 reserves special address blocks for private networks
(~18 million addresses) and multicast addresses (~270
million addresses).
14.1.1 Address representations
IPv4 addresses may be written in any notation expressing
a 32-bit integer value, but for human convenience, they
are most often written in the dot-decimal notation, which
consists of four octets of the address expressed individu-
ally in decimal and separated by periods.
An IP address followed by a slash(/) and a number (i.e.
127.0.0.1/8 ) indicates a block of addresses using a subnet
mask. See CIDR_notation.
The following table shows several representation formats:
Mixing decimal, octal and hexadecimal is allowed in dot-
ted format per octet.
Note that in non-dotted formats, numbers bigger than 32-
bit, can be given in some cases (e.g. Firefox) and will get
converted mod 2
32
.
[3]
14.1.2 Allocation
Originally, an IP address was divided into two parts: the
network identier was the most signicant (highest order)
octet of the address, and the host identier was the rest of
the address. The latter was therefore also called the rest
eld. This enabled the creation of a maximum of 256
networks. This was quickly found to be inadequate.
To overcome this limit, the high order octet of the ad-
dresses was redened to create a set of classes of net-
works, in a system which later became known as classful
networking. The system dened ve classes, Class A, B,
C, D, and E. The Classes A, B, and C had dierent bit
lengths for the new network identication. The rest of an
address was used as previously to identify a host within a
network, which meant that each network class had a dif-
ferent capacity to address hosts. Class Dwas allocated for
multicast addressing and Class E was reserved for future
applications.
Starting around 1985, methods were devised to subdivide
65
66 CHAPTER 14. IPV4
IP networks. One method that has proved exible is the
use of the variable-length subnet mask (VLSM).
[4][5]
Based on the IETF standard RFC 1517 published in
1993, this system of classes was ocially replaced
with Classless Inter-Domain Routing (CIDR), which ex-
pressed the number of bits (from the most signicant) as,
for instance, /24, and the class-based scheme was dubbed
classful, by contrast. CIDRwas designed to permit repar-
titioning of any address space so that smaller or larger
blocks of addresses could be allocated to users. The hi-
erarchical structure created by CIDR is managed by the
Internet Assigned Numbers Authority (IANA) and the
regional Internet registries (RIRs). Each RIR maintains
a publicly searchable WHOIS database that provides in-
formation about IP address assignments.
14.1.3 Special-use addresses
Main article: Reserved IP addresses Reserved IPv4
addresses
Private networks
Of the approximately four billion addresses allowed in
IPv4, three ranges of address are reserved for use in
private networks. These ranges are not routable outside
of private networks, and private machines cannot directly
communicate with public networks. They can, however,
do so through network address translation.
The following are the three ranges reserved for private
networks (RFC 1918):
Virtual private networks Packets with a private des-
tination address are ignored by all public routers. Two
private networks (e.g., two branch oces) cannot com-
municate via the public internet, unless they use an IP
tunnel or a virtual private network (VPN). When one pri-
vate network wants to send a packet to another private
network, the rst private network encapsulates the packet
in a protocol layer so that the packet can travel through
the public network. Then the packet travels through the
public network. When the packet reaches the other pri-
vate network, its protocol layer is removed, and the packet
travels to its destination.
Optionally, encapsulated packets may be encrypted to se-
cure the data while it travels over the public network.
14.1.4 Link-local addressing
Main article: Link-local address
RFC 6890 denes the special address block
169.254.0.0/16 for link-local addressing. These
addresses are only valid on links (such as a local network
segment or point-to-point connection) connected to a
host. These addresses are not routable. Like private
addresses, these addresses cannot be the source or
destination of packets traversing the internet. These ad-
dresses are primarily used for address autoconguration
(Zeroconf) when a host cannot obtain an IP address from
a DHCP server or other internal conguration methods.
When the address block was reserved, no standards ex-
isted for address autoconguration. Microsoft created an
implementation called Automatic Private IP Addressing
(APIPA), which was deployed on millions of machines
and became a de facto standard. Many years later, in May
2005, the IETF dened a formal standard in RFC 3927,
entitled Dynamic Conguration of IPv4 Link-Local Ad-
dresses.
14.1.5 Loopback
Main article: Loopback
The class A network 127.0.0.0 (classless network
127.0.0.0/8) is reserved for loopback. IP packets whose
source addresses belong to this network should never ap-
pear outside a host. The modus operandi of this network
expands upon that of a loopback interface:
IP packets whose source and destination addresses
belong to the network (or subnetwork) of the same
loopback interface are returned to that interface;
IP packets whose source and destination addresses
belong to networks (or subnetworks) of dierent in-
terfaces of the same host, one of them being a loop-
back interface, are forwarded regularly.
14.1.6 Addresses ending in 0 or 255
Main article: IPv4 subnetting reference
Networks with subnet masks of at least 24 bits, i.e.
Class C networks in classful networking, and net-
works with CIDR suxes /24 to /32 (255.255.255.0
255.255.255.255) may not have an address ending in 0
or 255.
Classful addressing prescribed only three possible subnet
masks: Class A, 255.0.0.0 or /8; Class B, 255.255.0.0 or
/16; and Class C, 255.255.255.0 or /24. For example, in
the subnet 192.168.5.0/255.255.255.0 (192.168.5.0/24)
the identier 192.168.5.0 commonly is used to refer to
the entire subnet. To avoid ambiguity in representation,
the address ending in the octet 0 is reserved.
A broadcast address is an address that allows information
to be sent to all interfaces in a given subnet, rather than
a specic machine. Generally, the broadcast address is
14.3. PACKET STRUCTURE 67
found by obtaining the bit complement of the subnet mask
and performing a bitwise OR operation with the network
identier. In other words, the broadcast address is the
last address in the address range of the subnet. For exam-
ple, the broadcast address for the network 192.168.5.0 is
192.168.5.255. For networks of size /24 or larger, the
broadcast address always ends in 255.
However, this does not mean that every address ending in
0 or 255 cannot be used as a host address. For example, in
the /16 subnet 192.168.0.0/255.255.0.0, which is equiva-
lent to the address range 192.168.0.0192.168.255.255,
the broadcast address is 192.168.255.255. One can use
the following addresses for hosts, even though they end
with 255: 192.168.1.255, 192.168.2.255, etc. Also,
192.168.0.0 is the network identier and must not be
assigned to an interface.
[6]
The addresses 192.168.1.0,
192.168.2.0, etc., may be assigned, despite ending with
0.
In the past, conict between network addresses and
broadcast addresses arose because some software used
non-standard broadcast addresses with zeros instead of
ones.
[7]
In networks smaller than /24, broadcast addresses do not
necessarily end with 255. For example, a CIDR subnet
203.0.113.16/28 has the broadcast address 203.0.113.31.
14.1.7 Address resolution
Main article: Domain Name System
Hosts on the Internet are usually known by names, e.g.,
www.example.com, not primarily by their IP address,
which is used for routing and network interface identi-
cation. The use of domain names requires translating,
called resolving, them to addresses and vice versa. This is
analogous to looking up a phone number in a phone book
using the recipients name.
The translation between addresses and domain names is
performed by the Domain Name System (DNS), a hier-
archical, distributed naming system which allows for sub-
delegation of name spaces to other DNS servers.
14.2 Address space exhaustion
Main article: IPv4 address exhaustion
Since the 1980s, it was apparent that the pool of avail-
able IPv4 addresses was being depleted at a rate that was
not initially anticipated in the original design of the net-
work address system.
[8]
The threat of exhaustion was the
motivation for remedial technologies, such as classful net-
works, Classless Inter-Domain Routing (CIDR) methods,
and network address translation (NAT). Eventually, IPv6
was created, which has many more addresses available.
Several market forces accelerated IPv4 address exhaus-
tion:
Rapidly growing number of Internet users
Always-on devices ADSL modems, cable
modems
Mobile devices laptop computers, PDAs, mobile
phones
Some technologies mitigated IPv4 address exhaustion:
Network address translation (NAT) is a technology
that allows a private network to use one public IP
address. It permits private addresses in the private
network.
Use of private networks
Dynamic Host Conguration Protocol (DHCP)
Name-based virtual hosting of web sites
Tighter control by regional Internet registries over
the allocation of addresses to local Internet registries
Network renumbering to reclaim large blocks of ad-
dress space allocated in the early days of the Internet
The primary address pool of the Internet, maintained by
IANA, was exhausted on 3 February 2011, when the last
5 blocks were allocated to the 5 RIRs.
[9][10]
APNIC was
the rst RIRto exhaust its regional pool on 15 April 2011,
except for a small amount of address space reserved for
the transition to IPv6, which will be allocated under a
much more restricted policy.
[11]
The accepted and standard long term solution is to use
Internet Protocol Version 6. The address size was in-
creased in IPv6 to 128 bits, providing a vastly increased
address space that also allows improved route aggrega-
tion across the Internet and oers large subnetwork allo-
cations of a minimum of 2
64
host addresses to end-users.
However IPv4 only hosts cannot directly communicate
with IPv6 only hosts so IPv6 alone does not provide an
immediate solution to the IPv4 exhaustion problem. Mi-
gration to IPv6 is in progress but completion is expected
to take considerable time.
14.3 Packet structure
An IP packet consists of a header section and a data sec-
tion.
An IP packet has no data checksumor any other footer af-
ter the data section. Typically the link layer encapsulates
IP packets in frames with a CRC footer that detects most
errors, and typically the end-to-end TCP layer checksum
detects most other errors.
[12]
68 CHAPTER 14. IPV4
14.3.1 Header
The IPv4 packet header consists of 14 elds, of which
13 are required. The 14th eld is optional (red back-
ground in table) and aptly named: options. The elds
in the header are packed with the most signicant byte
rst (big endian), and for the diagram and discussion, the
most signicant bits are considered to come rst (MSB
0 bit numbering). The most signicant bit is numbered
0, so the version eld is actually found in the four most
signicant bits of the rst byte, for example.
Version The rst header eld in an IP packet is the four-
bit version eld. For IPv4, this has a value of 4
(hence the name IPv4).
Internet Header Length (IHL) The second eld (4
bits) is the Internet Header Length (IHL), which is
the number of 32-bit words in the header. Since an
IPv4 header may contain a variable number of op-
tions, this eld species the size of the header (this
also coincides with the oset to the data). The min-
imum value for this eld is 5 (RFC 791), which is a
length of 532 = 160 bits = 20 bytes. Being a 4-bit
value, the maximumlength is 15 words (1532 bits)
or 480 bits = 60 bytes.
Dierentiated Services Code Point (DSCP)
Originally dened as the Type of service (ToS) eld. This
eld is now dened by RFC 2474 for Dierentiated ser-
vices (DiServ). New technologies are emerging that re-
quire real-time data streaming and therefore make use of
the DSCP eld. An example is Voice over IP (VoIP),
which is used for interactive data voice exchange.
Explicit Congestion Notication (ECN)
This eld is dened in RFC 3168 and allows end-to-
end notication of network congestion without dropping
packets. ECN is an optional feature that is only used
when both endpoints support it and are willing to use it.
It is only eective when supported by the underlying net-
work.
Total Length
This 16-bit eld denes the entire packet (fragment) size,
including header and data, in bytes. The minimum-length
packet is 20 bytes (20-byte header + 0 bytes data) and the
maximumis 65,535 bytes the maximumvalue of a 16-
bit word. All hosts are required to be able to reassemble
datagrams of size up to 576 bytes, but most modern hosts
handle much larger packets. Sometimes subnetworks im-
pose further restrictions on the packet size, in which case
datagrams must be fragmented. Fragmentation is han-
dled in either the host or router in IPv4.
Identication
This eld is an identication eld and is primarily used for
uniquely identifying the group of fragments of a single IP
datagram. Some experimental work has suggested using
the ID eld for other purposes, such as for adding packet-
tracing information to help trace datagrams with spoofed
source addresses,
[13]
but RFC 6864 now prohibits any
such use.
Flags
A three-bit eld follows and is used to control or identify
fragments. They are (in order, from high order to low
order):
bit 0: Reserved; must be zero.
[note 1]
bit 1: Don't Fragment (DF)
bit 2: More Fragments (MF)
If the DF ag is set, and fragmentation is required to route
the packet, then the packet is dropped. This can be used
when sending packets to a host that does not have suf-
cient resources to handle fragmentation. It can also be
used for Path MTU Discovery, either automatically by
the host IP software, or manually using diagnostic tools
such as ping or traceroute. For unfragmented packets, the
MF ag is cleared. For fragmented packets, all fragments
except the last have the MF ag set. The last fragment has
a non-zero Fragment Oset eld, dierentiating it from
an unfragmented packet.
Fragment Oset
The fragment oset eld, measured in units of eight-byte
blocks (64 bits), is 13 bits long and species the oset of
a particular fragment relative to the beginning of the orig-
inal unfragmented IP datagram. The rst fragment has an
oset of zero. This allows a maximum oset of (2
13
1)
8 = 65,528 bytes, which would exceed the maximum
IP packet length of 65,535 bytes with the header length
included (65,528 + 20 = 65,548 bytes).
Time To Live (TTL)
An eight-bit time to live eld helps prevent datagrams
from persisting (e.g. going in circles) on an internet. This
eld limits a datagrams lifetime. It is specied in sec-
onds, but time intervals less than 1 second are rounded up
to 1. In practice, the eld has become a hop countwhen
the datagram arrives at a router, the router decrements
the TTL eld by one. When the TTL eld hits zero, the
router discards the packet and typically sends an ICMP
Time Exceeded message to the sender.
The programtraceroute uses these ICMP Time Exceeded
messages to print the routers used by packets to go from
the source to the destination.
14.4. FRAGMENTATION AND REASSEMBLY 69
Protocol
This eld denes the protocol used in the data portion of
the IP datagram. The Internet Assigned Numbers Au-
thority maintains a list of IP protocol numbers which was
originally dened in RFC 790.
Header Checksum
Main article: IPv4 header checksum
The 16-bit checksum eld is used for error-checking of
the header. When a packet arrives at a router, the router
calculates the checksum of the header and compares it
to the checksum eld. If the values do not match, the
router discards the packet. Errors in the data eld must
be handled by the encapsulated protocol. Both UDP and
TCP have checksum elds. When a packet arrives at a
router, the router decreases the TTL eld. Consequently,
the router must calculate a new checksum. RFC 1071
denes the checksum calculation:
The checksum eld is the 16-bit ones comple-
ment of the ones complement sum of all 16-bit
words in the header. For purposes of computing
the checksum, the value of the checksum eld is
zero.
For example, consider Hex
4500003044224000800600008c7c19acae241e2b
(20 bytes IP header), using a machine which uses
standard twos complement arithmetic:
Step 1) 4500 + 0030 + 4422 + 4000 + 8006
+ 0000 + 8c7c + 19ac + ae24 + 1e2b =
0002BBCF (32-bit sum)
Step 2) 0002 + BBCF = BBD1 =
1011101111010001 (1s complement 16-
bit sum, formed by end around carry of
32-bit 2s complement sum)
Step 3) ~BBD1 = 0100010000101110 = 442E
(1s complement of 1s complement 16-bit
sum)
To validate a headers checksum the same algorithm may
be used the checksum of a header which contains a cor-
rect checksum eld is a word containing all zeros (value
0):
2BBCF + 442E = 2FFFD. 2 + FFFD = FFFF.
the 1'S of FFFF = 0.
Source address
This eld is the IPv4 address of the sender of the packet.
Note that this address may be changed in transit by a
network address translation device.
Destination address
This eld is the IPv4 address of the receiver of the packet.
As with the source address, this may be changed in transit
by a network address translation device.
Options
The options eld is not often used. Note that the value
in the IHL eld must include enough extra 32-bit words
to hold all the options (plus any padding needed to en-
sure that the header contains an integer number of 32-
bit words). The list of options may be terminated with
an EOL (End of Options List, 0x00) option; this is only
necessary if the end of the options would not otherwise
coincide with the end of the header. The possible options
that can be put in the header are as follows:
Note: If the header length is greater than 5, i.e. it is
from6 to 15, it means that the options eld is present
and must be considered.
Note: Copied, Option Class, and Option Number
are sometimes referred to as a single eight-bit eld
the Option Type.
The following two options are discouraged because they
create security concerns: Loose Source and Record
Route (LSRR) and Strict Source and Record Route
(SSRR). Many routers block packets containing these
options.
[14]
14.3.2 Data
The data portion of the packet is not included in the
packet checksum. Its contents are interpreted based on
the value of the Protocol header eld.
Some of the common protocols for the data portion are
listed below:
See List of IP protocol numbers for a complete list.
14.4 Fragmentation and reassem-
bly
Main article: IP fragmentation
The Internet Protocol enables networks to communicate
with one another. The design accommodates networks
of diverse physical nature; it is independent of the un-
derlying transmission technology used in the Link Layer.
Networks with dierent hardware usually vary not only
in transmission speed, but also in the maximum trans-
mission unit (MTU). When one network wants to trans-
mit datagrams to a network with a smaller MTU, it may
70 CHAPTER 14. IPV4
fragment its datagrams. In IPv4, this function was placed
at the Internet Layer, and is performed in IPv4 routers,
which thus only require this layer as the highest one im-
plemented in their design.
In contrast, IPv6, the next generation of the Internet Pro-
tocol, does not allow routers to perform fragmentation;
hosts must determine the path MTU before sending data-
grams.
14.4.1 Fragmentation
When a router receives a packet, it examines the desti-
nation address and determines the outgoing interface to
use and that interfaces MTU. If the packet size is big-
ger than the MTU, and the Do not Fragment (DF) bit in
the packets header set to 0; the router may fragment the
packet.
The router divides the packet into segments. The max
size of each segment is the MTUminus the IP header size
(20 bytes minimum; 60 bytes maximum). The router puts
each segment into its own packet, each fragment packet
having following changes:
The total length eld is the segment size.
The more fragments (MF) ag is set for all segments
except the last one, which is set to 0.
The fragment oset eld is set, based on the oset
of the segment in the original data payload. This is
measured in units of eight-byte blocks.
The header checksum eld is recomputed.
For example, for an MTU of 1,500 bytes and a header
size of 20 bytes, the fragment osets would be multiples
of (150020)/8 = 185. These multiples are 0, 185, 370,
555, 740, ...
It is possible for a packet to be fragmented at one router,
and for the fragments to be fragmented at another router.
For example, consider a packet with a data size of 4,500
bytes, no options, and a header size of 20 bytes. So the
packet size is 4,520 bytes. Assume that the packet travels
over a link with an MTU of 2,500 bytes. Then it will
become two fragments:
Note that the fragments preserve the data size: 2480 +
2020 = 4500.
Note how we get the osets from the data sizes:
0.
0 + 2480/8 = 310.
Assume that these fragments reach a link with an MTUof
1,500 bytes. Each fragment will become two fragments:
Note that the fragments preserve the data size: 1480 +
1000 = 2480, and 1480 + 540 = 2020.
Note how we get the osets from the data sizes:
0.
0 + 1480/8 = 185
185 + 1000/8 = 310
310 + 1480/8 = 495
We can use the last oset and last data size to calculate
the total data size: 495*8 + 540 = 3960 + 540 = 4500.
14.4.2 Reassembly
A receiver knows that a packet is a fragment if at least
one of the following conditions is true:
The more fragments ag is set. (This is true for all
fragments except the last.)
The fragment oset eld is nonzero. (This is true
for all fragments except the rst.)
The receiver identies matching fragments using the
identication eld. The receiver will reassemble the data
from fragments with the same identication eld using
both the fragment oset and the more fragments ag.
When the receiver receives the last fragment (which has
the more fragments ag set to 0), it can calculate the
length of the original data payload, by multiplying the
last fragments oset by eight, and adding the last frag-
ments data size. In the example above, this calculation
was 495*8 + 540 = 4500 bytes.
When the receiver has all the fragments, it can put them
in the correct order, by using their osets. It can then pass
their data up the stack for further processing.
14.5 Assistive protocols
The Internet Protocol is the protocol that denes and en-
ables internetworking at the Internet Layer and thus forms
the Internet. It uses a logical addressing system. IP ad-
dresses are not tied in any permanent manner to hard-
ware identications and, indeed, a network interface can
have multiple IP addresses. Hosts and routers need ad-
ditional mechanisms to identify the relationship between
device interfaces and IP addresses, in order to properly
deliver an IP packet to the destination host on a link.
The Address Resolution Protocol (ARP) performs this
IP-address-to-hardware-address translation for IPv4. (A
hardware address is also called a MAC address.) In addi-
tion, the reverse correlation is often necessary. For exam-
ple, when an IP host is booted or connected to a network
14.9. EXTERNAL LINKS 71
it needs to determine its IP address, unless an address
is precongured by an administrator. Protocols for such
inverse correlations exist in the Internet Protocol Suite.
Currently used methods are Dynamic Host Conguration
Protocol (DHCP), Bootstrap Protocol (BOOTP) and, in-
frequently, reverse ARP.
14.6 See also
Classful network
Classless Inter-Domain Routing
Internet Assigned Numbers Authority
Legacy internet
IPv6
List of assigned /8 IPv4 address blocks
List of IP protocol numbers
Regional Internet Registry
14.7 Notes
[1] As an April Fools joke, proposed for use in RFC 3514 as
the "Evil bit".
14.8 References
[1] BGP Analysis Reports. Retrieved 2013-01-09.
[2] INET(3) man page. Retrieved 2010-11-28.
[3] http://superuser.com/questions/736583/
strange-dotless-decimal-notation-of-ip-address-how-does-it-work
[4] Planning Classless Routing: TCP/IP. Tech-
net.microsoft.com. 2003-03-28. Retrieved 2012-01-20.
[5] HP Networking: switches, routers, wired, wireless, HP
TippingPoint Security. 3com.com. Retrieved 2012-01-
20.
[6] Robert Braden (October 1989). Requirements for Inter-
net Hosts Communication Layers. IETF. p. 31. RFC
1122.
[7] Robert Braden (October 1989). Requirements for Inter-
net Hosts Communication Layers. IETF. p. 66. RFC
1122.
[8] World 'running out of Internet addresses". Retrieved
2011-01-23.
[9] Smith, Lucie; Lipner, Ian (3 February 2011). Free Pool
of IPv4 Address Space Depleted. Number Resource Or-
ganization. Retrieved 3 February 2011.
[10] ICANN,nanog mailing list. Five /8s allocated to RIRs
no unallocated IPv4 unicast /8s remain.
[11] Asia-Pacic Network Information Centre (15 April
2011). APNIC IPv4 Address Pool Reaches Final /8.
Retrieved 15 April 2011.
[12] RFC 1726 section 6.2
[13] Savage, Stefan. Practical network support for IP trace-
back. Retrieved 2010-09-06.
[14] Cisco unocial FAQ. Retrieved 2012-05-10.
14.9 External links
RFC 791Internet Protocol
http://www.iana.org Internet Assigned Numbers
Authority (IANA)
http://www.networksorcery.com/enp/protocol/ip.
htm IP Header Breakdown, including specic
options
RFC 3344 IPv4 Mobility
IPv6 vs. carrier-grade NAT/squeezing more out of
IPv4
Address exhaustion:
RIPE report on address consumption as of October
2003
Ocial current state of IPv4 /8 allocations, as main-
tained by IANA
Dynamically generated graphs of IPv4 address con-
sumption with predictions of exhaustion dates
Geo Huston
IP addressing in China and the myth of address
shortage
Countdown of remaining IPv4 available addresses
(estimated)
14.10 Further Reading
Play media
Internet-Protocol-Header explained
Chapter 15
IP address
For the Wikipedia user access level, see Wikipedia:User
access levels#Unregistered_users.
An Internet Protocol address (IP address) is a nu-
merical label assigned to each device (e.g., computer,
printer) participating in a computer network that uses the
Internet Protocol for communication.
[1]
An IP address
serves two principal functions: host or network inter-
face identication and location addressing. Its role has
been characterized as follows: A name indicates what
we seek. An address indicates where it is. A route indi-
cates how to get there.
[2]
The designers of the Internet Protocol dened an IP ad-
dress as a 32-bit number
[1]
and this system, known as
Internet Protocol Version 4 (IPv4), is still in use today.
However, due to the enormous growth of the Internet and
the predicted depletion of available addresses, a new ver-
sion of IP (IPv6), using 128 bits for the address, was de-
veloped in 1995.
[3]
IPv6 was standardized as RFC 2460
in 1998,
[4]
and its deployment has been ongoing since the
mid-2000s.
IP addresses are binary numbers, but they are usually
stored in text les and displayed in human-readable nota-
tions, such as 172.16.254.1 (for IPv4), and 2001:db8:0:
1234:0:567:8:1 (for IPv6).
The Internet Assigned Numbers Authority (IANA) man-
ages the IP address space allocations globally and dele-
gates ve regional Internet registries (RIRs) to allocate IP
address blocks to local Internet registries (Internet service
providers) and other entities.
15.1 IP versions
Two versions of the Internet Protocol (IP) are in use: IP
Version 4 and IP Version 6. Each version denes an IP
address dierently. Because of its prevalence, the generic
term IP address typically still refers to the addresses de-
ned by IPv4. The gap in version sequence between IPv4
and IPv6 resulted from the assignment of number 5 to
the experimental Internet StreamProtocol in 1979, which
however was never referred to as IPv5.
15.1.1 IPv4 addresses
Main article: IPv4 Addressing
In IPv4 an address consists of 32 bits which limits the
An IPv4 address
172 16 1 254 . . .
10101100 00010000 11111110 00000001 . . .
One byte Eight bits =
Thirty-two bits (4 x 8), or 4 bytes
(dotted-decimal notation)
Decomposition of an IPv4 address from dot-decimal notation to
its binary value.
address space to 4294967296 (2
32
) possible unique ad-
dresses. IPv4 reserves some addresses for special pur-
poses such as private networks (~18 million addresses) or
multicast addresses (~270 million addresses).
IPv4 addresses are canonically represented in dot-
decimal notation, which consists of four decimal num-
bers, each ranging from 0 to 255, separated by dots, e.g.,
172.16.254.1. Each part represents a group of 8 bits
(octet) of the address. In some cases of technical writing,
IPv4 addresses may be presented in various hexadecimal,
octal, or binary representations.
IPv4 subnetting
In the early stages of development of the Internet
Protocol,
[1]
network administrators interpreted an IP ad-
dress in two parts: network number portion and host
number portion. The highest order octet (most signi-
cant eight bits) in an address was designated as the net-
work number and the remaining bits were called the rest
eld or host identier and were used for host numbering
within a network.
This early method soon proved inadequate as additional
networks developed that were independent of the exist-
ing networks already designated by a network number.
72
15.1. IP VERSIONS 73
In 1981, the Internet addressing specication was revised
with the introduction of classful network architecture.
[2]
Classful network design allowed for a larger num-
ber of individual network assignments and ne-grained
subnetwork design. The rst three bits of the most sig-
nicant octet of an IP address were dened as the class
of the address. Three classes (A, B, and C) were de-
ned for universal unicast addressing. Depending on the
class derived, the network identication was based on
octet boundary segments of the entire address. Each class
used successively additional octets in the network identi-
er, thus reducing the possible number of hosts in the
higher order classes (B and C). The following table gives
an overview of this now obsolete system.
Classful network design served its purpose in the startup
stage of the Internet, but it lacked scalability in the face
of the rapid expansion of the network in the 1990s.
The class system of the address space was replaced with
Classless Inter-Domain Routing (CIDR) in 1993. CIDR
is based on variable-length subnet masking (VLSM) to al-
low allocation and routing based on arbitrary-length pre-
xes.
Today, remnants of classful network concepts function
only in a limited scope as the default conguration pa-
rameters of some network software and hardware com-
ponents (e.g. netmask), and in the technical jargon used
in network administrators discussions.
IPv4 private addresses
Early network design, when global end-to-end connectiv-
ity was envisioned for communications with all Internet
hosts, intended that IP addresses be uniquely assigned to
a particular computer or device. However, it was found
that this was not always necessary as private networks de-
veloped and public address space needed to be conserved.
Computers not connected to the Internet, such as fac-
tory machines that communicate only with each other
via TCP/IP, need not have globally unique IP addresses.
Three ranges of IPv4 addresses for private networks were
reserved in RFC1918. These addresses are not routed on
the Internet and thus their use need not be coordinated
with an IP address registry.
Today, when needed, such private networks typically con-
nect to the Internet through network address translation
(NAT).
Any user may use any of the reserved blocks. Typically, a
network administrator will divide a block into subnets; for
example, many home routers automatically use a default
address range of 192.168.0.0 through 192.168.0.255
(192.168.0.0/24 block).
15.1.2 IPv4 address exhaustion
IPv4 address exhaustion is the decreasing supply of un-
allocated Internet Protocol Version 4 (IPv4) addresses
available at the Internet Assigned Numbers Authority
(IANA) and the regional Internet registries (RIRs) for as-
signment to end users and local Internet registries, such as
Internet service providers. IANAs primary address pool
was exhausted on 3 February 2011, when the last 5 blocks
were allocated to the 5 RIRs.
[5][6]
APNIC was the rst
RIR to exhaust its regional pool on 15 April 2011, ex-
cept for a small amount of address space reserved for the
transition to IPv6, intended to be allocated in a restricted
process.
[7]
15.1.3 IPv6 addresses
Main article: IPv6 address
The rapid exhaustion of IPv4 address space, despite con-
An IPv6 address
2001:0DB8:AC10:FE01:0000:0000:0000:0000
Zeroes can be omitted
2001:0DB8:AC10:FE01::
(in hexadecimal)
10000000000001:0000110110111000:1010110000010000:1111111000000001:
0000000000000000:0000000000000000:0000000000000000:0000000000000000
Decomposition of an IPv6 address from hexadecimal represen-
tation to its binary value.
servation techniques, prompted the Internet Engineering
Task Force (IETF) to explore newtechnologies to expand
the addressing capability in the Internet. The permanent
solution was deemed to be a redesign of the Internet Pro-
tocol itself. This next generation of the Internet Protocol,
intended to replace IPv4 on the Internet, was eventually
named Internet Protocol Version 6 (IPv6) in 1995.
[3][4]
The address size was increased from 32 to 128 bits or
16 octets. This, even with a generous assignment of net-
work blocks, is deemed sucient for the foreseeable fu-
ture. Mathematically, the new address space provides the
potential for a maximum of 2
128
, or about 3.40310
38
addresses.
The primary intent of the new design is not to provide
just a sucient quantity of addresses, but rather to allow
an ecient aggregation of subnetwork routing prexes at
routing nodes. As a result, routing table sizes are smaller,
and the smallest possible individual allocation is a subnet
for 2
64
hosts, which is the square of the size of the entire
IPv4 Internet. At these levels, actual address utilization
rates will be small on any IPv6 network segment. The
new design also provides the opportunity to separate the
addressing infrastructure of a network segment, that is
74 CHAPTER 15. IP ADDRESS
the local administration of the segments available space,
from the addressing prex used to route external traf-
c for a network. IPv6 has facilities that automatically
change the routing prex of entire networks, should the
global connectivity or the routing policy change, without
requiring internal redesign or manual renumbering.
The large number of IPv6 addresses allows large blocks
to be assigned for specic purposes and, where appropri-
ate, to be aggregated for ecient routing. With a large
address space, there is no need to have complex address
conservation methods as used in CIDR.
Many modern desktop and enterprise server operating
systems include native support for the IPv6 protocol, but
it is not yet widely deployed in other devices, such as
home networking routers, voice over IP (VoIP) and mul-
timedia equipment, and network peripherals.
IPv6 private addresses
Just as IPv4 reserves addresses for private or internal net-
works, blocks of addresses are set aside in IPv6 for pri-
vate addresses. In IPv6, these are referred to as unique
local addresses (ULA). RFC 4193 sets aside the routing
prex fc00::/7 for this block which is divided into two
/8 blocks with dierent implied policies. The addresses
include a 40-bit pseudorandom number that minimizes
the risk of address collisions if sites merge or packets are
misrouted.
[8]
Early designs used a dierent block for this purpose
(fec0::), dubbed site-local addresses.
[9]
However, the def-
inition of what constituted sites remained unclear and the
poorly dened addressing policy created ambiguities for
routing. This address range specication was abandoned
and must not be used in new systems.
[10]
Addresses starting with fe80:, called link-local addresses,
are assigned to interfaces for communication on the link
only. The addresses are automatically generated by the
operating system for each network interface. This pro-
vides instant and automatic network connectivity for any
IPv6 host and means that if several hosts connect to a
common hub or switch, they have a communication path
via their link-local IPv6 address. This feature is used
in the lower layers of IPv6 network administration (e.g.
Neighbor Discovery Protocol).
None of the private address prexes may be routed on the
public Internet.
15.2 IP subnetworks
IP networks may be divided into subnetworks in both
IPv4 and IPv6. For this purpose, an IP address is logi-
cally recognized as consisting of two parts: the network
prex and the host identier, or interface identier (IPv6).
The subnet mask or the CIDR prex determines how the
IP address is divided into network and host parts.
The term subnet mask is only used within IPv4. Both IP
versions however use the CIDR concept and notation. In
this, the IP address is followed by a slash and the num-
ber (in decimal) of bits used for the network part, also
called the routing prex. For example, an IPv4 address
and its subnet mask may be 192.0.2.1 and 255.255.255.0,
respectively. The CIDR notation for the same IP address
and subnet is 192.0.2.1/24, because the rst 24 bits of the
IP address indicate the network and subnet.
15.3 IP address assignment
Internet Protocol addresses are assigned to a host either
anew at the time of booting, or permanently by xed con-
guration of its hardware or software. Persistent cong-
uration is also known as using a static IP address. In con-
trast, in situations when the computers IP address is as-
signed newly each time, this is known as using a dynamic
IP address.
15.3.1 Methods
Static IP addresses are manually assigned to a computer
by an administrator. The exact procedure varies accord-
ing to platform. This contrasts with dynamic IP ad-
dresses, which are assigned either by the computer in-
terface or host software itself, as in Zeroconf, or assigned
by a server using Dynamic Host Conguration Protocol
(DHCP). Even though IP addresses assigned using DHCP
may stay the same for long periods of time, they can gen-
erally change. In some cases, a network administrator
may implement dynamically assigned static IP addresses.
In this case, a DHCP server is used, but it is specically
congured to always assign the same IP address to a par-
ticular computer. This allows static IP addresses to be
congured centrally, without having to specically con-
gure each computer on the network in a manual proce-
dure.
In the absence or failure of static or stateful (DHCP) ad-
dress congurations, an operating system may assign an
IP address to a network interface using state-less auto-
conguration methods, such as Zeroconf.
15.3.2 Uses of dynamic address assign-
ment
IP addresses are most frequently assigned dynamically
on LANs and broadband networks by the Dynamic Host
Conguration Protocol (DHCP). They are used because
it avoids the administrative burden of assigning specic
static addresses to each device on a network. It also al-
lows many devices to share limited address space on a
network if only some of them will be online at a particu-
15.4. IP ADDRESSING 75
lar time. In most current desktop operating systems, dy-
namic IP conguration is enabled by default so that a user
does not need to manually enter any settings to connect
to a network with a DHCP server. DHCP is not the only
technology used to assign IP addresses dynamically. Di-
alup and some broadband networks use dynamic address
features of the Point-to-Point Protocol.
Sticky dynamic IP address
A sticky dynamic IP address is an informal term used by
cable and DSL Internet access subscribers to describe a
dynamically assigned IP address which seldom changes.
The addresses are usually assigned with DHCP. Since the
modems are usually powered on for extended periods of
time, the address leases are usually set to long periods and
simply renewed. If a modem is turned o and powered
up again before the next expiration of the address lease,
it will most likely receive the same IP address.
15.3.3 Address autoconguration
RFC 3330 denes an address block, 169.254.0.0/16, for
the special use in link-local addressing for IPv4 networks.
In IPv6, every interface, whether using static or dynamic
address assignments, also receives a local-link address au-
tomatically in the block fe80::/10.
These addresses are only valid on the link, such as a local
network segment or point-to-point connection, that a host
is connected to. These addresses are not routable and like
private addresses cannot be the source or destination of
packets traversing the Internet.
When the link-local IPv4 address block was reserved, no
standards existed for mechanisms of address autocong-
uration. Filling the void, Microsoft created an imple-
mentation that is called Automatic Private IP Address-
ing (APIPA). APIPA has been deployed on millions of
machines and has, thus, become a de facto standard in
the industry. Many years later, the IETF dened a for-
mal standard for this functionality, RFC 3927, entitled
Dynamic Conguration of IPv4 Link-Local Addresses.
15.3.4 Uses of static addressing
Some infrastructure situations have to use static address-
ing, such as when nding the Domain Name System
(DNS) host that will translate domain names to IP ad-
dresses. Static addresses are also convenient, but not ab-
solutely necessary, to locate servers inside an enterprise.
An address obtained from a DNS server comes with a
time to live, or caching time, after which it should be
looked up to conrm that it has not changed. Even static
IP addresses do change as a result of network administra-
tion (RFC 2072).
15.4 IP addressing
There are four forms of IP addressing, each with its own
unique properties.
Unicast: The most common concept of an IP ad-
dress is in unicast addressing, available in both IPv4
and IPv6. It normally refers to a single sender or
a single receiver, and can be used for both sending
and receiving. Usually, a unicast address is associ-
ated with a single device or host, but it is not a one-
to-one correspondence. Some individual PCs have
several distinct unicast addresses, each for its own
distinct purpose. Sending the same data to multiple
unicast addresses requires the sender to send all the
data many times over, once for each recipient.
Broadcast: In IPv4 it is possible to send data to all
possible destinations (all-hosts broadcast), which
permits the sender to send the data only once, and
all receivers receive a copy of it. In the IPv4 pro-
tocol, the address 255.255.255.255 is used for local
broadcast. In addition, a directed (limited) broad-
cast can be made by combining the network pre-
x with a host sux composed entirely of binary
1s. For example, the destination address used for
a directed broadcast to devices on the 192.0.2.0/24
network is 192.0.2.255. IPv6 does not implement
broadcast addressing and replaces it with multicast
to the specially-dened all-nodes multicast address.
Multicast: A multicast address is associated with
a group of interested receivers. In IPv4, ad-
dresses 224.0.0.0 through 239.255.255.255 (the
former Class D addresses) are designated as multi-
cast addresses.
[11]
IPv6 uses the address block with
the prex 00::/8 for multicast applications. In ei-
ther case, the sender sends a single datagram from
its unicast address to the multicast group address and
the intermediary routers take care of making copies
and sending them to all receivers that have joined
the corresponding multicast group.
Anycast: Like broadcast and multicast, anycast is a
one-to-many routing topology. However, the data
stream is not transmitted to all receivers, just the
one which the router decides is logically closest in
the network. Anycast address is an inherent feature
of only IPv6. In IPv4, anycast addressing imple-
mentations typically operate using the shortest-path
metric of BGP routing and do not take into account
congestion or other attributes of the path. Anycast
methods are useful for global load balancing and are
commonly used in distributed DNS systems.
76 CHAPTER 15. IP ADDRESS
15.5 Public addresses
A public IP address, in common parlance, is synonymous
with a globally routable unicast IP address.
Both IPv4 and IPv6 dene address ranges that are re-
served for private networks and link-local addressing.
The term public IP address often used excludes these
types of addresses.
15.6 Modications to IP address-
ing
15.6.1 IP blocking and rewalls
Firewalls perform Internet Protocol blocking to protect
networks from unauthorized access. They are common
on todays Internet. They control access to networks
based on the IP address of a client computer. Whether us-
ing a blacklist or a whitelist, the IP address that is blocked
is the perceived IP address of the client, meaning that if
the client is using a proxy server or network address trans-
lation, blocking one IP address may block many individ-
ual computers.
15.6.2 IP address translation
Multiple client devices can appear to share IP addresses:
either because they are part of a shared hosting web server
environment or because an IPv4 network address transla-
tor (NAT) or proxy server acts as an intermediary agent
on behalf of its customers, in which case the real origi-
nating IP addresses might be hidden from the server re-
ceiving a request. A common practice is to have a NAT
hide a large number of IP addresses in a private network.
Only the outside interface(s) of the NAT need to have
Internet-routable addresses.
[12]
Most commonly, the NATdevice maps TCP or UDP port
numbers on the side of the larger, public network to indi-
vidual private addresses on the masqueraded network.
In small home networks, NAT functions are usually im-
plemented in a residential gateway device, typically one
marketed as a router. In this scenario, the computers
connected to the router would have private IP addresses
and the router would have a public address to communi-
cate on the Internet. This type of router allows several
computers to share one public IP address.
15.7 Diagnostic tools
Computer operating systems provide various diagnostic
tools to examine their network interface and address con-
guration. Windows provides the command-line inter-
face tools ipcong and netsh and users of Unix-like sys-
tems can use ifcong, netstat, route, lanstat, fstat, or
iproute2 utilities to accomplish the task.
15.8 See also
IP address location
Hierarchical name space
Hostname: a human-readable alpha-numeric desig-
nation that may map to an IP address
IP address spoong
IP aliasing
IP blocking
IP Multicast
IPv4 subnetting reference
IPv6 subnetting reference
List of assigned /8 IPv4 address blocks
MAC address
Ping (networking utility)
Private network
Regional Internet Registry
Subnet address
Virtual IP address
WHOIS
15.9 References
[1] RFC760, DODStandard Internet Protocol (January 1980)
[2] RFC 791, Internet Protocol DARPA Internet Program
Protocol Specication (September 1981)
[3] RFC 1883, Internet Protocol, Version 6 (IPv6) Specica-
tion, S. Deering, R. Hinden (December 1995)
[4] RFC 2460, Internet Protocol, Version 6 (IPv6) Specica-
tion, S. Deering, R. Hinden, The Internet Society (Decem-
ber 1998)
[5] Smith, Lucie; Lipner, Ian (3 February 2011). Free Pool
of IPv4 Address Space Depleted. Number Resource Or-
ganization. Retrieved 3 February 2011.
[6] ICANN,nanog mailing list. Five /8s allocated to RIRs
no unallocated IPv4 unicast /8s remain.
[7] Asia-Pacic Network Information Centre (15 April
2011). APNIC IPv4 Address Pool Reaches Final /8.
Retrieved 15 April 2011.
15.10. EXTERNAL LINKS 77
[8] RFC 4193 section 3.2.1
[9] RFC 3513
[10] RFC 3879
[11] RFC 5771
[12] Comer, Douglas (2000). Internetworking with TCP/IP:
Principles, Protocols, and Architectures 4th ed.. Upper
Saddle River, NJ: Prentice Hall. p. 394. ISBN 0-13-
018380-6.
15.10 External links
IP at DMOZ
Understanding IP Addressing: Everything You
Ever Wanted To Know. Archived from the orig-
inal on 21 August 2010.
Chapter 16
Transmission Control Protocol
For other uses, see TCP (disambiguation).
The Transmission Control Protocol (TCP) is one of
the core protocols of the Internet protocol suite (IP), and
is so common that the entire suite is often called TCP/IP.
TCP provides reliable, ordered and error-checked deliv-
ery of a stream of octets between programs running on
computers connected to a local area network, intranet or
the public Internet. It resides at the transport layer.
Web browsers use TCP when they connect to servers on
the World Wide Web, and it is used to deliver email
and transfer les from one location to another. HTTP,
HTTPS, SMTP, POP3, IMAP, SSH, FTP, Telnet and a
variety of other protocols are typically encapsulated in
TCP.
Applications that do not require the reliability of a TCP
connection may instead use the connectionless User Data-
gram Protocol (UDP), which emphasizes low-overhead
operation and reduced latency rather than error checking
and delivery validation.
16.1 Historical origin
In May 1974 the Institute of Electrical and Electronic
Engineers (IEEE) published a paper titled "A Protocol
for Packet Network Intercommunication."
[1]
The papers
authors, Vint Cerf and Bob Kahn, described an inter-
networking protocol for sharing resources using packet-
switching among the nodes. A central control compo-
nent of this model was the Transmission Control Pro-
gram that incorporated both connection-oriented links
and datagram services between hosts. The monolithic
Transmission Control Program was later divided into a
modular architecture consisting of the Transmission Con-
trol Protocol at the connection-oriented layer and the In-
ternet Protocol at the internetworking (datagram) layer.
The model became known informally as TCP/IP, although
formally it was henceforth called the Internet Protocol
Suite.
16.2 Network function
The protocol corresponds to the transport layer of TCP/IP
suite. TCP provides a communication service at an inter-
mediate level between an application program and the In-
ternet Protocol (IP). That is, when an application program
desires to send a large chunk of data across the Internet
using IP, instead of breaking the data into IP-sized pieces
and issuing a series of IP requests, the software can issue
a single request to TCP and let TCP handle the IP details.
IP works by exchanging pieces of information called
packets. Apacket is a sequence of octets (bytes) and con-
sists of a header followed by a body. The header describes
the packets source, destination and control information.
The body contains the data IP is transmitting.
Due to network congestion, trac load balancing, or
other unpredictable network behavior, IP packets can be
lost, duplicated, or delivered out of order. TCP detects
these problems, requests retransmission of lost data, re-
arranges out-of-order data, and even helps minimize net-
work congestion to reduce the occurrence of the other
problems. Once the TCP receiver has reassembled the se-
quence of octets originally transmitted, it passes them to
the receiving application. Thus, TCP abstracts the appli-
cations communication from the underlying networking
details.
TCP is utilized extensively by many of the Internets most
popular applications, including the World Wide Web
(WWW), E-mail, File Transfer Protocol, Secure Shell,
peer-to-peer le sharing, and some streaming media ap-
plications.
TCP is optimized for accurate delivery rather than timely
delivery, and therefore, TCP sometimes incurs relatively
long delays (on the order of seconds) while waiting for
out-of-order messages or retransmissions of lost mes-
sages. It is not particularly suitable for real-time appli-
cations such as Voice over IP. For such applications, pro-
tocols like the Real-time Transport Protocol (RTP) run-
ning over the User Datagram Protocol (UDP) are usually
recommended instead.
[2]
TCP is a reliable stream delivery service that guarantees
that all bytes received will be identical with bytes sent
and in the correct order. Since packet transfer over many
78
16.3. TCP SEGMENT STRUCTURE 79
networks is not reliable, a technique known as positive
acknowledgment with retransmission is used to guaran-
tee reliability of packet transfers. This fundamental tech-
nique requires the receiver to respond with an acknowl-
edgment message as it receives the data. The sender
keeps a record of each packet it sends. The sender also
maintains a timer from when the packet was sent, and
retransmits a packet if the timer expires before the mes-
sage has been acknowledged. The timer is needed in case
a packet gets lost or corrupted.
[2]
While IP handles actual delivery of the data, TCP keeps
track of the individual units of data transmission, called
segments, that a message is divided into for ecient rout-
ing through the network. For example, when an HTML
le is sent from a web server, the TCP software layer of
that server divides the sequence of octets of the le into
segments and forwards them individually to the IP soft-
ware layer (Internet Layer). The Internet Layer encap-
sulates each TCP segment into an IP packet by adding a
header that includes (among other data) the destination
IP address. When the client program on the destination
computer receives them, the TCP layer (Transport Layer)
reassembles the individual segments and ensures they are
correctly ordered and error free as it streams them to an
application.
16.3 TCP segment structure
Transmission Control Protocol accepts data from a data
stream, divides it into chunks, and adds a TCP header
creating a TCP segment. The TCP segment is then
encapsulated into an Internet Protocol (IP) datagram, and
exchanged with peers.
[3]
The term TCP packet appears in both informal and for-
mal usage, whereas in more precise terminology segment
refers to the TCP Protocol Data Unit (PDU), datagram
[4]
to the IP PDU, and frame to the data link layer PDU:
Processes transmit data by calling on the
TCP and passing buers of data as arguments.
The TCP packages the data from these buers
into segments and calls on the internet module
[e.g. IP] to transmit each segment to the desti-
nation TCP.
[5]
A TCP segment consists of a segment header and a data
section. The TCP header contains 10 mandatory elds,
and an optional extension eld (Options, pink background
in table).
The data section follows the header. Its contents are the
payload data carried for the application. The length of the
data section is not specied in the TCP segment header.
It can be calculated by subtracting the combined length
of the TCP header and the encapsulating IP header from
the total IP datagram length (specied in the IP header).
Source port (16 bits) identies the sending port
Destination port (16 bits) identies the receiving port
Sequence number (32 bits) has a dual role:
If the SYN ag is set (1), then this is the ini-
tial sequence number. The sequence number
of the actual rst data byte and the acknowl-
edged number in the corresponding ACK are
then this sequence number plus 1.
If the SYN ag is clear (0), then this is the
accumulated sequence number of the rst data
byte of this segment for the current session.
Acknowledgment number (32 bits) if the ACK ag is
set then the value of this eld is the next sequence
number that the receiver is expecting. This acknowl-
edges receipt of all prior bytes (if any). The rst
ACK sent by each end acknowledges the other ends
initial sequence number itself, but no data.
Data oset (4 bits) species the size of the TCP header
in 32-bit words. The minimum size header is 5
words and the maximum is 15 words thus giving
the minimum size of 20 bytes and maximum of 60
bytes, allowing for up to 40 bytes of options in the
header. This eld gets its name from the fact that it
is also the oset from the start of the TCP segment
to the actual data.
Reserved (3 bits) for future use and should be set to
zero
Flags (9 bits) (aka Control bits) contains 9 1-bit ags
NS (1 bit) ECN-nonce concealment protec-
tion (added to header by RFC 3540).
CWR (1 bit) Congestion Window Reduced
(CWR) ag is set by the sending host to indi-
cate that it received a TCP segment with the
ECE ag set and had responded in congestion
control mechanism (added to header by RFC
3168).
ECE (1 bit) ECN-Echo has a dual role, de-
pending on the value of the SYN ag. It indi-
cates:
If the SYN ag is set (1), that the
TCP peer is ECN capable.
If the SYN ag is clear (0), that
a packet with Congestion Experi-
enced ag in IP header set is re-
ceived during normal transmission
(added to header by RFC 3168).
URG(1 bit) indicates that the Urgent pointer
eld is signicant
80 CHAPTER 16. TRANSMISSION CONTROL PROTOCOL
ACK (1 bit) indicates that the Acknowledg-
ment eld is signicant. All packets after the
initial SYN packet sent by the client should
have this ag set.
PSH (1 bit) Push function. Asks to push the
buered data to the receiving application.
RST (1 bit) Reset the connection
SYN (1 bit) Synchronize sequence numbers.
Only the rst packet sent fromeach end should
have this ag set. Some other ags and elds
change meaning based on this ag, and some
are only valid for when it is set, and others
when it is clear.
FIN (1 bit) No more data from sender
Window size (16 bits) the size of the receive window,
which species the number of window size units (by
default, bytes) (beyond the sequence number in the
acknowledgment eld) that the sender of this seg-
ment is currently willing to receive (see Flow control
and Window Scaling)
Checksum (16 bits) The 16-bit checksum eld is used
for error-checking of the header and data
Urgent pointer (16 bits) if the URGag is set, then this
16-bit eld is an oset from the sequence number
indicating the last urgent data byte
Options (Variable 0320 bits, divisible by 32) The
length of this eld is determined by the data oset
eld. Options have up to three elds: Option-Kind
(1 byte), Option-Length (1 byte), Option-Data
(variable). The Option-Kind eld indicates the
type of option, and is the only eld that is not
optional. Depending on what kind of option we
are dealing with, the next two elds may be set:
the Option-Length eld indicates the total length
of the option, and the Option-Data eld contains
the value of the option, if applicable. For example,
an Option-Kind byte of 0x01 indicates that this is
a No-Op option used only for padding, and does
not have an Option-Length or Option-Data byte
following it. An Option-Kind byte of 0 is the End
Of Options option, and is also only one byte. An
Option-Kind byte of 0x02 indicates that this is
the Maximum Segment Size option, and will be
followed by a byte specifying the length of the MSS
eld (should be 0x04). Note that this length is the
total length of the given options eld, including
Option-Kind and Option-Length bytes. So while
the MSS value is typically expressed in two bytes,
the length of the eld will be 4 bytes (+2 bytes of
kind and length). In short, an MSS option eld
with a value of 0x05B4 will show up as (0x02 0x04
0x05B4) in the TCP options section.
Some options may only be sent when SYN is set; they
are indicated below as
[SYN]
. Option-Kind and stan-
dard lengths given as (Option-Kind,Option-Length).
0 (8 bits) End of options list
1 (8 bits) No operation (NOP, Padding) This
may be used to align option elds on 32-bit
boundaries for better performance.
2,4,SS (32 bits) Maximum segment size (see
maximum segment size)
[SYN]
3,3,S (24 bits) Window scale (see window
scaling for details)
[SYN][6]
4,2 (16 bits) Selective Acknowledgement
permitted.
[SYN]
(See selective acknowledg-
ments for details)
[7]
5,N,BBBB,EEEE,... (variable bits, N is either
10, 18, 26, or 34)- Selective ACKnowledge-
ment (SACK)
[8]
These rst two bytes are fol-
lowed by a list of 14 blocks being selectively
acknowledged, specied as 32-bit begin/end
pointers.
8,10,TTTT,EEEE (80 bits)- Timestamp and
echo of previous timestamp (see TCP times-
tamps for details)
[9]
14,3,S (24 bits) TCP Alternate Checksum
Request.
[SYN][10]
15,N,... (variable bits) TCP Alternate
Checksum Data.
(The remaining options are obsolete, experimental, not
yet standardized, or unassigned)
Padding The TCP header padding is used to ensure that
the TCP header ends and data begins on a 32 bit
boundary. The padding is composed of zeros.
[11]
16.4 Protocol operation
CLOSED (Start)
LISTEN/-
CLOSE/-
LISTEN
SYN
RECEIVED
SYN
SENT
CONNECT/ (Step 1 of the 3-way-handshake) SYN
SYN/SYN+ACK (Step 2 of the 3-way-handshake)
unusual event
client/receiver path
server/sender path
RST/-
SYN/SYN+ACK (simultaneous open)
SYN+ACK/ACK
(Step 3 of the 3-way-handshake)
Data exchange occurs
ESTABLISHED
FIN/ACK
ACK/-
CLOSE/-
SEND/ SYN
CLOSE/ FIN
CLOSE/ FIN
CLOSING
TIME WAIT
CLOSED
FIN WAIT 1
FIN WAIT 2
CLOSE WAIT
LAST ACK
CLOSE/ FIN
FIN/ACK
FIN+ACK/ACK
ACK/-
FIN/ACK
Timeout
(Go back to start)
Active CLOSE Passive CLOSE
ACK/-
ACK/-
A Simplied TCP State Diagram. See TCP EFSM diagram for
a more detailed state diagram including the states inside the ES-
TABLISHED state.
TCP protocol operations may be divided into three
phases. Connections must be properly established in a
multi-step handshake process (connection establishment)
16.4. PROTOCOL OPERATION 81
before entering the data transfer phase. After data trans-
mission is completed, the connection termination closes
established virtual circuits and releases all allocated re-
sources.
A TCP connection is managed by an operating system
through a programming interface that represents the local
end-point for communications, the Internet socket. Dur-
ing the lifetime of a TCP connection the local end-point
undergoes a series of state changes:
[12]
LISTEN (server) represents waiting for a connection
request from any remote TCP and port.
SYN-SENT (client) represents waiting for a matching
connection request after having sent a connection
request.
SYN-RECEIVED (server) represents waiting for a
conrming connection request acknowledgment af-
ter having both received and sent a connection re-
quest.
ESTABLISHED (both server and client) represents an
open connection, data received can be delivered to
the user. The normal state for the data transfer phase
of the connection.
FIN-WAIT-1 (both server and client) represents wait-
ing for a connection termination request from the
remote TCP, or an acknowledgment of the connec-
tion termination request previously sent.
FIN-WAIT-2 (both server and client) represents wait-
ing for a connection termination request from the
remote TCP.
CLOSE-WAIT (both server and client) represents
waiting for a connection termination request from
the local user.
CLOSING (both server and client) represents waiting
for a connection termination request acknowledg-
ment from the remote TCP.
LAST-ACK (both server and client) represents wait-
ing for an acknowledgment of the connection ter-
mination request previously sent to the remote TCP
(which includes an acknowledgment of its connec-
tion termination request).
TIME-WAIT (either server or client) represents wait-
ing for enough time to pass to be sure the remote
TCP received the acknowledgment of its connection
termination request. [According to RFC 793 a con-
nection can stay in TIME-WAIT for a maximum of
four minutes known as a MSL (maximum segment
lifetime).]
CLOSED (both server and client) represents no con-
nection state at all.
16.4.1 Connection establishment
To establish a connection, TCP uses a three-way
handshake. Before a client attempts to connect with a
server, the server must rst bind to and listen at a port to
open it up for connections: this is called a passive open.
Once the passive open is established, a client may initiate
an active open. To establish a connection, the three-way
(or 3-step) handshake occurs:
1. SYN: The active open is performed by the client
sending a SYN to the server. The client sets the seg-
ments sequence number to a random value A.
2. SYN-ACK: In response, the server replies with
a SYN-ACK. The acknowledgment number is set
to one more than the received sequence number
i.e. A+1, and the sequence number that the server
chooses for the packet is another random number,
B.
3. ACK: Finally, the client sends an ACK back to the
server. The sequence number is set to the received
acknowledgement value i.e. A+1, and the acknowl-
edgement number is set to one more than the re-
ceived sequence number i.e. B+1.
At this point, both the client and server have received an
acknowledgment of the connection. The steps 1, 2 es-
tablish the connection parameter (sequence number) for
one direction and it is acknowledged. The steps 2, 3 es-
tablish the connection parameter (sequence number) for
the other direction and it is acknowledged. With these, a
full-duplex communication is established.
16.4.2 Connection termination
Initiator Receiver
F
I
N
F
I
N
A
C
K
ACK
ESTABLISHED
active close
CLOSED
connection
ESTABLISHED
connection
FIN_WAIT_1
CLOSE_WAIT
passive close
FIN_WAIT_2
LAST_ACK
TIME_WAIT
CLOSED
Connection termination
The connection termination phase uses a four-way
handshake, with each side of the connection terminat-
ing independently. When an endpoint wishes to stop its
half of the connection, it transmits a FIN packet, which
82 CHAPTER 16. TRANSMISSION CONTROL PROTOCOL
the other end acknowledges with an ACK. Therefore, a
typical tear-down requires a pair of FIN and ACK seg-
ments from each TCP endpoint. After both FIN/ACK
exchanges are concluded, the side that sent the rst FIN
before receiving one waits for a timeout before nally
closing the connection, during which time the local port is
unavailable for new connections; this prevents confusion
due to delayed packets being delivered during subsequent
connections.
A connection can be half-open, in which case one side
has terminated its end, but the other has not. The side
that has terminated can no longer send any data into the
connection, but the other side can. The terminating side
should continue reading the data until the other side ter-
minates as well.
It is also possible to terminate the connection by a 3-way
handshake, when host A sends a FIN and host B replies
with a FIN & ACK (merely combines 2 steps into one)
and host A replies with an ACK.
[13]
This is perhaps the
most common method.
It is possible for both hosts to send FINs simultaneously
then both just have to ACK. This could possibly be con-
sidered a 2-way handshake since the FIN/ACK sequence
is done in parallel for both directions.
Some host TCPstacks may implement a half-duplex close
sequence, as Linux or HP-UX do. If such a host actively
closes a connection but still has not read all the incoming
data the stack already received from the link, this host
sends a RST instead of a FIN (Section 4.2.2.13 in RFC
1122). This allows a TCP application to be sure the re-
mote application has read all the data the former sent
waiting the FIN from the remote side, when it actively
closes the connection. But the remote TCP stack cannot
distinguish between a Connection Aborting RST and Data
Loss RST. Both cause the remote stack to lose all the data
received.
Some application protocols may violate the OSI model
layers, using the TCP open/close handshaking for the ap-
plication protocol open/close handshaking these may
nd the RST problem on active close. As an example:
s = connect(remote); send(s, data); close(s);
For a usual program ow like above, a TCP/IP stack like
that described above does not guarantee that all the data
arrives to the other application.
16.4.3 Resource usage
Most implementations allocate an entry in a table that
maps a session to a running operating system process.
Because TCP packets do not include a session identier,
both endpoints identify the session using the clients ad-
dress and port. Whenever a packet is received, the TCP
implementation must perform a lookup on this table to
nd the destination process. Each entry in the table is
known as a Transmission Control Block or TCB. It con-
tains information about the endpoints (IP and port), sta-
tus of the connection, running data about the packets that
are being exchanged and buers for sending and receiv-
ing data.
The number of sessions in the server side is limited only
by memory and can grow as new connections arrive, but
the client must allocate a random port before sending
the rst SYN to the server. This port remains allocated
during the whole conversation, and eectively limits the
number of outgoing connections from each of the clients
IP addresses. If an application fails to properly close un-
required connections, a client can run out of resources
and become unable to establish new TCP connections,
even from other applications.
Both endpoints must also allocate space for unacknowl-
edged packets and received (but unread) data.
16.4.4 Data transfer
There are a fewkey features that set TCP apart fromUser
Datagram Protocol:
Ordered data transfer the destination host rear-
ranges according to sequence number
[2]
Retransmission of lost packets any cumulative
stream not acknowledged is retransmitted
[2]
Error-free data transfer
[14]
Flowcontrol limits the rate a sender transfers data
to guarantee reliable delivery. The receiver contin-
ually hints the sender on how much data can be re-
ceived (controlled by the sliding window). When
the receiving hosts buer lls, the next acknowledg-
ment contains a 0 in the windowsize, to stop transfer
and allow the data in the buer to be processed.
[2]
Congestion control
[2]
Reliable transmission
TCP uses a sequence number to identify each byte of data.
The sequence number identies the order of the bytes
sent from each computer so that the data can be recon-
structed in order, regardless of any fragmentation, disor-
dering, or packet loss that may occur during transmission.
For every payload byte transmitted, the sequence number
must be incremented. In the rst two steps of the 3-way
handshake, both computers exchange an initial sequence
number (ISN). This number can be arbitrary, and should
in fact be unpredictable to defend against TCP sequence
prediction attacks.
TCP primarily uses a cumulative acknowledgment
scheme, where the receiver sends an acknowledgment
16.4. PROTOCOL OPERATION 83
signifying that the receiver has received all data preced-
ing the acknowledged sequence number. The sender
sets the sequence number eld to the sequence number
of the rst payload byte in the segments data eld,
and the receiver sends an acknowledgment specifying
the sequence number of the next byte they expect to
receive. For example, if a sending computer sends a
packet containing four payload bytes with a sequence
number eld of 100, then the sequence numbers of the
four payload bytes are 100, 101, 102 and 103. When this
packet arrives at the receiving computer, it would send
back an acknowledgment number of 104 since that is the
sequence number of the next byte it expects to receive in
the next packet.
In addition to cumulative acknowledgments, TCP re-
ceivers can also send selective acknowledgments to pro-
vide further information.
If the sender infers that data has been lost in the network,
it retransmits the data.
Error detection
Sequence numbers allow receivers to discard duplicate
packets and properly sequence reordered packets. Ac-
knowledgments allow senders to determine when to re-
transmit lost packets.
To assure correctness a checksum eld is included; see
checksum computation section for details on checksum-
ming. The TCP checksum is a weak check by modern
standards. Data Link Layers with high bit error rates may
require additional link error correction/detection capabil-
ities. The weak checksum is partially compensated for
by the common use of a CRC or better integrity check at
layer 2, below both TCP and IP, such as is used in PPP
or the Ethernet frame. However, this does not mean that
the 16-bit TCP checksum is redundant: remarkably, in-
troduction of errors in packets between CRC-protected
hops is common, but the end-to-end 16-bit TCP check-
sum catches most of these simple errors.
[15]
This is the
end-to-end principle at work.
Flow control
TCP uses an end-to-end ow control protocol to avoid
having the sender send data too fast for the TCP receiver
to receive and process it reliably. Having a mechanism
for ow control is essential in an environment where ma-
chines of diverse network speeds communicate. For ex-
ample, if a PC sends data to a smartphone that is slowly
processing received data, the smartphone must regulate
the data ow so as not to be overwhelmed.
[2]
TCP uses a sliding window ow control protocol. In each
TCP segment, the receiver species in the receive window
eld the amount of additionally received data (in bytes)
that it is willing to buer for the connection. The sending
host can send only up to that amount of data before it must
wait for an acknowledgment and window update from the
receiving host.
U
n
fille
d
b
u
ffe
r
Data received,
but not acknowledged
D
a
ta
re
c
e
iv
e
d
, a
c
k
n
o
w
le
d
g
e
d
a
n
d
d
e
liv
e
re
d
to
a
p
p
lic
a
tio
n
Sequence numbers
(Circumference = 0 to 2^32 slots)
Data received, acknowledged,
but not yet delivered to application
Initial
sequence
number
Receiver's window
(Allocation buffer)
Up to 2^16-1 slots
Window
shifts
TCP sequence numbers and receive windows behave very much
like a clock. The receive window shifts each time the receiver
receives and acknowledges a new segment of data. Once it runs
out of sequence numbers, the sequence number loops back to 0.
When a receiver advertises a window size of 0, the sender
stops sending data and starts the persist timer. The persist
timer is used to protect TCP from a deadlock situation
that could arise if a subsequent window size update from
the receiver is lost, and the sender cannot send more data
until receiving a new window size update from the re-
ceiver. When the persist timer expires, the TCP sender
attempts recovery by sending a small packet so that the
receiver responds by sending another acknowledgement
containing the new window size.
If a receiver is processing incoming data in small incre-
ments, it may repeatedly advertise a small receive win-
dow. This is referred to as the silly window syndrome,
since it is inecient to send only a few bytes of data in a
TCP segment, given the relatively large overhead of the
TCP header.
Congestion control
The nal main aspect of TCP is congestion control. TCP
uses a number of mechanisms to achieve high perfor-
mance and avoid congestion collapse, where network per-
formance can fall by several orders of magnitude. These
mechanisms control the rate of data entering the network,
keeping the data ow below a rate that would trigger col-
lapse. They also yield an approximately max-min fair al-
location between ows.
Acknowledgments for data sent, or lack of acknowledg-
ments, are used by senders to infer network conditions be-
tween the TCP sender and receiver. Coupled with timers,
TCP senders and receivers can alter the behavior of the
84 CHAPTER 16. TRANSMISSION CONTROL PROTOCOL
ow of data. This is more generally referred to as con-
gestion control and/or network congestion avoidance.
Modern implementations of TCP contain four inter-
twined algorithms: Slow-start, congestion avoidance, fast
retransmit, and fast recovery (RFC 5681).
In addition, senders employ a retransmission timeout
(RTO) that is based on the estimated round-trip time (or
RTT) between the sender and receiver, as well as the vari-
ance in this round trip time. The behavior of this timer is
specied in RFC6298. There are subtleties in the estima-
tion of RTT. For example, senders must be careful when
calculating RTT samples for retransmitted packets; typi-
cally they use Karns Algorithm or TCP timestamps (see
RFC 1323). These individual RTT samples are then av-
eraged over time to create a Smoothed Round Trip Time
(SRTT) using Jacobson's algorithm. This SRTT value is
what is nally used as the round-trip time estimate.
Enhancing TCP to reliably handle loss, minimize errors,
manage congestion and go fast in very high-speed envi-
ronments are ongoing areas of research and standards de-
velopment. As a result, there are a number of TCP con-
gestion avoidance algorithm variations.
16.4.5 Maximum segment size
The maximum segment size (MSS) is the largest amount
of data, specied in bytes, that TCP is willing to receive in
a single segment. For best performance, the MSS should
be set small enough to avoid IP fragmentation, which can
lead to packet loss and excessive retransmissions. To try
to accomplish this, typically the MSS is announced by
each side using the MSS option when the TCP connec-
tion is established, in which case it is derived from the
maximum transmission unit (MTU) size of the data link
layer of the networks to which the sender and receiver
are directly attached. Furthermore, TCP senders can use
path MTU discovery to infer the minimum MTU along
the network path between the sender and receiver, and
use this to dynamically adjust the MSS to avoid IP frag-
mentation within the network.
MSS announcement is also often called MSS negoti-
ation. Strictly speaking, the MSS is not negotiated
between the originator and the receiver, because that
would imply that both originator and receiver will nego-
tiate and agree upon a single, unied MSS that applies to
all communication in both directions of the connection.
In fact, two completely independent values of MSS are
permitted for the two directions of data ow in a TCP
connection.
[16]
This situation may arise, for example, if
one of the devices participating in a connection has an
extremely limited amount of memory reserved (perhaps
even smaller than the overall discovered Path MTU) for
processing incoming TCP segments.
16.4.6 Selective acknowledgments
Relying purely on the cumulative acknowledgment
scheme employed by the original TCP protocol can lead
to ineciencies when packets are lost. For example, sup-
pose 10,000 bytes are sent in 10 dierent TCP packets,
and the rst packet is lost during transmission. In a pure
cumulative acknowledgment protocol, the receiver can-
not say that it received bytes 1,000 to 9,999 successfully,
but failed to receive the rst packet, containing bytes 0 to
999. Thus the sender may then have to resend all 10,000
bytes.
To solve this problem TCP employs the selective ac-
knowledgment (SACK) option, dened in RFC 2018,
which allows the receiver to acknowledge discontin-
uous blocks of packets which were received correctly,
in addition to the sequence number of the last contiguous
byte received successively, as in the basic TCP acknowl-
edgment. The acknowledgement can specify a number
of SACK blocks, where each SACK block is conveyed
by the starting and ending sequence numbers of a con-
tiguous range that the receiver correctly received. In the
example above, the receiver would send SACK with se-
quence numbers 1000 and 9999. The sender thus retrans-
mits only the rst packet, bytes 0 to 999.
A TCP sender can interpret an out-of-order packet deliv-
ery as a lost packet. If it does so, the TCP sender will
retransmit the packet previous to the out-of-order packet
and slow its data delivery rate for that connection. The
duplicate-SACK option, an extension to the SACK op-
tion that was dened in RFC 2883, solves this problem.
The TCP receiver sends a D-ACK to indicate that no
packets were lost, and the TCP sender can then reinstate
the higher transmission rate.
The SACK option is not mandatory and it is used only if
both parties support it. This is negotiated when connec-
tion is established. SACK uses the optional part of the
TCP header (see TCP segment structure for details). The
use of SACK is widespread all popular TCP stacks
support it. Selective acknowledgment is also used in
Stream Control Transmission Protocol (SCTP).
16.4.7 Window scaling
Main article: TCP window scale option
For more ecient use of high bandwidth networks, a
larger TCP window size may be used. The TCP window
size eld controls the ow of data and its value is limited
to between 2 and 65,535 bytes.
Since the size eld cannot be expanded, a scaling factor is
used. The TCP window scale option, as dened in RFC
1323, is an option used to increase the maximum win-
dow size from 65,535 bytes to 1 gigabyte. Scaling up to
larger window sizes is a part of what is necessary for TCP
16.5. VULNERABILITIES 85
Tuning.
The window scale option is used only during the TCP 3-
way handshake. The window scale value represents the
number of bits to left-shift the 16-bit window size eld.
The window scale value can be set from 0 (no shift) to 14
for each direction independently. Both sides must send
the option in their SYN segments to enable window scal-
ing in either direction.
Some routers and packet rewalls rewrite the window
scaling factor during a transmission. This causes send-
ing and receiving sides to assume dierent TCP window
sizes. The result is non-stable trac that may be very
slow. The problem is visible on some sites behind a de-
fective router.
[17]
16.4.8 TCP timestamps
TCP timestamps, dened in RFC 1323, can help TCP
determine in which order packets were sent. TCP times-
tamps are not normally aligned to the system clock and
start at some random value. Many operating systems will
increment the timestamp for every elapsed millisecond;
however the RFC only states that the ticks should be pro-
portional.
There are two timestamp elds:
a 4-byte sender timestamp value (my timestamp) a 4-byte
echo reply timestamp value (the most recent timestamp
received from you).
TCP timestamps are used in an algorithm known as Pro-
tection Against Wrapped Sequence numbers, or PAWS (see
RFC1323 for details). PAWS is used when the TCP win-
dow size exceeds the possible numbers of sequence num-
bers (2
32
). In the case where a packet was potentially
retransmitted it answers the question: Is this sequence
number in the rst 4 GB or the second?" And the times-
tamp is used to break the tie.
Also, the Eifel detection algorithm(RFC3522) uses TCP
timestamps to determine if retransmissions are occurring
because packets are lost or simply out of order.
16.4.9 Out-of-band data
One is able to interrupt or abort the queued stream in-
stead of waiting for the stream to nish. This is done by
specifying the data as urgent. This tells the receiving pro-
gram to process it immediately, along with the rest of the
urgent data. When nished, TCP informs the application
and resumes back to the stream queue. An example is
when TCP is used for a remote login session, the user
can send a keyboard sequence that interrupts or aborts
the program at the other end. These signals are most of-
ten needed when a program on the remote machine fails
to operate correctly. The signals must be sent without
waiting for the program to nish its current transfer.
[2]
TCP OOB data was not designed for the modern Inter-
net. The urgent pointer only alters the processing on the
remote host and doesn't expedite any processing on the
network itself. When it gets to the remote host there
are two slightly dierent interpretations of the protocol,
which means only single bytes of OOB data are reliable.
This is assuming it is reliable at all as it is one of the least
commonly used protocol elements and tends to be poorly
implemented.
[18][19]
16.4.10 Forcing data delivery
Normally, TCP waits for 200 ms or for a full packet of
data to send (Nagles Algorithm tries to group small mes-
sages into a single packet). This wait creates small, but
potentially serious delays if repeated constantly during a
le transfer. For example, a typical send block would
be 4 KB, a typical MSS is 1460, so 2 packets go out on
a 10 Mbit/s ethernet taking ~1.2 ms each followed by a
third carrying the remaining 1176 after a 197 ms pause
because TCP is waiting for a full buer.
In the case of telnet, each user keystroke is echoed back
by the server before the user can see it on the screen. This
delay would become very annoying.
Setting the socket option TCP_NODELAY overrides the
default 200 ms send delay. Application programs use this
socket option to force output to be sent after writing a
character or line of characters.
The RFC denes the PSH push bit as a message to the
receiving TCP stack to send this data immediately up to
the receiving application.
[2]
There is no way to indicate
or control it in User space using Berkeley sockets and it
is controlled by Protocol stack only.
[20]
16.5 Vulnerabilities
TCP may be attacked in a variety of ways. The results
of a thorough security assessment of TCP, along with
possible mitigations for the identied issues, were pub-
lished in 2009,
[21]
and is currently being pursued within
the IETF.
[22]
16.5.1 Denial of service
By using a spoofed IP address and repeatedly sending
purposely assembled SYN packets, followed by many
ACK packets, attackers can cause the server to consume
large amounts of resources keeping track of the bogus
connections. This is known as a SYN ood attack. Pro-
posed solutions to this problem include SYN cookies
and cryptographic puzzles, though syn cookies come with
their own set of vulnerabilities.
[23]
Sockstress is a simi-
lar attack, that might be mitigated with system resource
management.
[24]
An advanced DoS attack involving the
86 CHAPTER 16. TRANSMISSION CONTROL PROTOCOL
exploitation of the TCP Persist Timer was analyzed in
Phrack #66.
[25]
16.5.2 Connection hijacking
Main article: TCP sequence prediction attack
An attacker who is able to eavesdrop a TCP session and
redirect packets can hijack a TCP connection. To do so,
the attacker learns the sequence number from the ongo-
ing communication and forges a false segment that looks
like the next segment in the stream. Such a simple hi-
jack can result in one packet being erroneously accepted
at one end. When the receiving host acknowledges the ex-
tra segment to the other side of the connection, synchro-
nization is lost. Hijacking might be combined with ARP
or routing attacks that allow taking control of the packet
ow, so as to get permanent control of the hijacked TCP
connection.
[26]
Impersonating a dierent IP address was not dicult
prior to RFC 1948, when the initial sequence number was
easily guessable. That allowed an attacker to blindly send
a sequence of packets that the receiver would believe to
come from a dierent IP address, without the need to
deploy ARP or routing attacks: it is enough to ensure
that the legitimate host of the impersonated IP address is
down, or bring it to that condition using denial-of-service
attacks. This is why the initial sequence number is now
chosen at random.
16.5.3 TCP veto
An attacker who can eavesdrop and predict the size of
the next packet to be sent can cause the receiver to ac-
cept a malicious payload without disrupting the existing
connection. The attacker injects a malicious packet with
the sequence number and a payload size of the next ex-
pected packet. When the legitimate packet is ultimately
received, it is found to have the same sequence number
and length as a packet already received and is silently
dropped as a normal duplicate packetthe legitimate
packet is vetoed by the malicious packet. Unlike in
connection hijacking, the connection is never desynchro-
nized and communication continues as normal after the
malicious payload is accepted. TCP veto gives the at-
tacker less control over the communication, but makes
the attack particularly resistant to detection. The large in-
crease in network trac from the ACK storm is avoided.
The only evidence to the receiver that something is amiss
is a single duplicate packet, a normal occurrence in an IP
network. The sender of the vetoed packet never sees any
evidence of an attack.
[27]
16.6 TCP ports
Main article: TCP and UDP port
TCP uses port numbers to identify sending and receiv-
ing application end-points on a host, or Internet sockets.
Each side of a TCP connection has an associated 16-bit
unsigned port number (0-65535) reserved by the send-
ing or receiving application. Arriving TCP data packets
are identied as belonging to a specic TCP connection
by its sockets, that is, the combination of source host ad-
dress, source port, destination host address, and destina-
tion port. This means that a server computer can pro-
vide several clients with several services simultaneously,
as long as a client takes care of initiating any simultaneous
connections to one destination port from dierent source
ports.
Port numbers are categorized into three basic categories:
well-known, registered, and dynamic/private. The well-
known ports are assigned by the Internet Assigned Num-
bers Authority (IANA) and are typically used by system-
level or root processes. Well-known applications running
as servers and passively listening for connections typically
use these ports. Some examples include: FTP (20 and
21), SSH (22), TELNET (23), SMTP (25), SSL (443)
and HTTP (80). Registered ports are typically used by
end user applications as ephemeral source ports when
contacting servers, but they can also identify named ser-
vices that have been registered by a third party. Dy-
namic/private ports can also be used by end user applica-
tions, but are less commonly so. Dynamic/private ports
do not contain any meaning outside of any particular TCP
connection.
16.7 Development
TCP is a complex protocol. However, while signicant
enhancements have been made and proposed over the
years, its most basic operation has not changed signi-
cantly since its rst specication RFC 675 in 1974, and
the v4 specication RFC 793, published in September
1981. RFC 1122, Host Requirements for Internet Hosts,
claried a number of TCP protocol implementation re-
quirements. RFC 2581, TCP Congestion Control, one
of the most important TCP-related RFCs in recent years,
describes updated algorithms that avoid undue conges-
tion. In 2001, RFC 3168 was written to describe explicit
congestion notication (ECN), a congestion avoidance
signaling mechanism.
The original TCP congestion avoidance algorithm was
known as TCP Tahoe, but many alternative algorithms
have since been proposed (including TCP Reno, TCP Ve-
gas, FAST TCP, TCP New Reno, and TCP Hybla).
TCP Interactive (iTCP)
[28]
is a research eort into TCP
extensions that allows applications to subscribe to TCP
16.9. HARDWARE IMPLEMENTATIONS 87
events and register handler components that can launch
applications for various purposes, including application-
assisted congestion control.
Multipath TCP (MPTCP)
[29][30]
is an ongoing eort
within the IETF that aims at allowing a TCP connection
to use multiple paths to maximise resource usage and in-
crease redundancy. The redundancy oered by Multi-
path TCP in the context of wireless networks
[31]
enables
statistical multiplexing of resources, and thus increases
TCP throughput dramatically. Multipath TCP also brings
performance benets in datacenter environments.
[32]
The
reference implementation
[33]
of Multipath TCP is being
developed in the Linux kernel.
[34][35]
TCP Cookie Transactions (TCPCT) is an extension pro-
posed in December 2009 to secure servers against denial-
of-service attacks. Unlike SYN cookies, TCPCT does
not conict with other TCP extensions such as window
scaling. TCPCT was designed due to necessities of
DNSSEC, where servers have to handle large numbers
of short-lived TCP connections.
tcpcrypt is an extension proposed in July 2010 to provide
transport-level encryption directly in TCP itself. It is de-
signed to work transparently and not require any cong-
uration. Unlike TLS (SSL), tcpcrypt itself does not pro-
vide authentication, but provides simple primitives down
to the application to do that. As of 2010, the rst tcpcrypt
IETF draft has been published and implementations exist
for several major platforms.
TCP Fast Open is an extension to speed up the opening
of successive TCP connections between two endpoints. It
works by skipping the three-way handshake using a cryp-
tographic cookie. It is similar to an earlier proposal
called T/TCP, which was not widely adopted due to se-
curity issues.
[36]
As of July 2012, it is an IETF Internet
draft.
[37]
Proposed in May 2013, Proportional Rate Reduction
(PRR) is a TCP extension developed by Google en-
gineers. PRR ensures that the TCP window size af-
ter recovery is as close to the Slow-start threshold as
possible.
[38]
The algorithm is designed to improve the
speed of recovery and is the default congestion control
algorithm in Linux 3.2+ kernels.
[39]
16.8 TCP over wireless networks
TCP has been optimized for wired networks. Any packet
loss is considered to be the result of network congestion
and the congestion window size is reduced dramatically
as a precaution. However, wireless links are known to
experience sporadic and usually temporary losses due to
fading, shadowing, hand o, and other radio eects, that
cannot be considered congestion. After the (erroneous)
back-o of the congestion window size, due to wireless
packet loss, there can be a congestion avoidance phase
with a conservative decrease in window size. This causes
the radio link to be underutilized. Extensive research has
been done on the subject of how to combat these harm-
ful eects. Suggested solutions can be categorized as
end-to-end solutions (which require modications at the
client or server),
[40]
link layer solutions (such as RLP in
cellular networks), or proxy based solutions (which re-
quire some changes in the network without modifying end
nodes).
[40][41]
A number of alternative congestion control algorithms
have been proposed to help solve the wireless problem,
such as Vegas, Westwood, Veno and Santa Cruz.
16.9 Hardware implementations
One way to overcome the processing power requirements
of TCP is to build hardware implementations of it, widely
known as TCP Ooad Engines (TOE). The main prob-
lem of TOEs is that they are hard to integrate into com-
puting systems, requiring extensive changes in the oper-
ating system of the computer or device. One company to
develop such a device was Alacritech.
16.10 Debugging
A packet snier, which intercepts TCP trac on a net-
work link, can be useful in debugging networks, network
stacks and applications that use TCP by showing the user
what packets are passing through a link. Some network-
ing stacks support the SO_DEBUG socket option, which
can be enabled on the socket using setsockopt. That op-
tion dumps all the packets, TCP states, and events on that
socket, which is helpful in debugging. Netstat is another
utility that can be used for debugging.
16.11 Alternatives
For many applications TCP is not appropriate. One prob-
lem (at least with normal implementations) is that the ap-
plication cannot access the packets coming after a lost
packet until the retransmitted copy of the lost packet is
received. This causes problems for real-time applications
such as streaming media, real-time multiplayer games and
voice over IP (VoIP) where it is generally more useful to
get most of the data in a timely fashion than it is to get all
of the data in order.
For both historical and performance reasons, most
storage area networks (SANs) prefer to use Fibre Chan-
nel protocol (FCP) instead of TCP/IP.
Also, for embedded systems, network booting, and
servers that serve simple requests from huge numbers of
clients (e.g. DNS servers) the complexity of TCP can
be a problem. Finally, some tricks such as transmitting
88 CHAPTER 16. TRANSMISSION CONTROL PROTOCOL
data between two hosts that are both behind NAT (us-
ing STUN or similar systems) are far simpler without a
relatively complex protocol like TCP in the way.
Generally, where TCP is unsuitable, the User Datagram
Protocol (UDP) is used. This provides the application
multiplexing and checksums that TCP does, but does not
handle streams or retransmission, giving the application
developer the ability to code them in a way suitable for
the situation, or to replace them with other methods like
forward error correction or interpolation.
StreamControl Transmission Protocol (SCTP) is another
IP protocol that provides reliable streamoriented services
similar to TCP. It is newer and considerably more com-
plex than TCP, and has not yet seen widespread deploy-
ment. However, it is especially designed to be used in
situations where reliability and near-real-time considera-
tions are important.
Venturi Transport Protocol (VTP) is a patented
proprietary protocol that is designed to replace TCP
transparently to overcome perceived ineciencies
related to wireless data transport.
TCP also has issues in high bandwidth environments. The
TCP congestion avoidance algorithm works very well for
ad-hoc environments where the data sender is not known
in advance, but if the environment is predictable, a tim-
ing based protocol such as Asynchronous Transfer Mode
(ATM) can avoid TCPs retransmits overhead.
Multipurpose Transaction Protocol (MTP/IP) is patented
proprietary software that is designed to adaptively achieve
high throughput and transaction performance in a wide
variety of network conditions, particularly those where
TCP is perceived to be inecient.
16.12 Checksum computation
16.12.1 TCP checksum for IPv4
When TCP runs over IPv4, the method used to compute
the checksum is dened in RFC 793:
The checksum eld is the 16 bit ones com-
plement of the ones complement sum of all 16-
bit words in the header and text. If a seg-
ment contains an odd number of header and
text octets to be checksummed, the last octet is
padded on the right with zeros to form a 16-bit
word for checksum purposes. The pad is not
transmitted as part of the segment. While com-
puting the checksum, the checksum eld itself is
replaced with zeros.
In other words, after appropriate padding, all 16-bit
words are added using ones complement arithmetic.
The sum is then bitwise complemented and inserted as
the checksum eld. A pseudo-header that mimics the
IPv4 packet header used in the checksum computation
is shown in the table below.
The source and destination addresses are those of the
IPv4 header. The protocol value is 6 for TCP (cf. List of
IP protocol numbers). The TCP length eld is the length
of the TCP header and data (measured in octets).
16.12.2 TCP checksum for IPv6
When TCP runs over IPv6, the method used to compute
the checksum is changed, as per RFC 2460:
Any transport or other upper-layer protocol that
includes the addresses from the IP header in its
checksum computation must be modied for use
over IPv6, to include the 128-bit IPv6 addresses
instead of 32-bit IPv4 addresses.
A pseudo-header that mimics the IPv6 header for com-
putation of the checksum is shown below.
Source address the one in the IPv6 header
Destination address the nal destination; if the
IPv6 packet doesn't contain a Routing header, TCP
uses the destination address in the IPv6 header, oth-
erwise, at the originating node, it uses the address in
the last element of the Routing header, and, at the
receiving node, it uses the destination address in the
IPv6 header.
TCP length the length of the TCP header and data
Next Header the protocol value for TCP
16.12.3 Checksum ooad
Many TCP/IP software stack implementations provide
options to use hardware assistance to automatically com-
pute the checksum in the network adapter prior to trans-
mission onto the network or upon reception from the net-
work for validation. This may relieve the OS from using
precious CPU cycles calculating the checksum. Hence,
overall network performance is increased.
This feature may cause packet analyzers detecting out-
bound network trac upstream of the network adapter
that are unaware or uncertain about the use of checksum
ooad to report invalid checksum in outbound packets.
16.13 See also
Connection-oriented protocol
T/TCP variant of TCP
16.14. REFERENCES 89
TCP and UDP port
TCP and UDP port numbers for a long list of
ports/services
TCP congestion avoidance algorithms
Nagles algorithm
Karns algorithm
Maximum transmission unit
IP fragmentation
Maximum segment size
Maximum segment lifetime
Micro-bursting (networking)
Silly window syndrome
TCP segment
TCP Sequence Prediction Attack
SYN ood
SYN cookies
TCP pacing
TCP tuning for high performance networks
Path MTU discovery
Stream Control Transmission Protocol (SCTP)
Multipurpose Transaction Protocol (MTP/IP)
Transport protocol comparison table
Sockstress
TCP global synchronization
16.14 References
[1] Vinton G. Cerf, Robert E. Kahn, (May 1974). "A Pro-
tocol for Packet Network Intercommunication". IEEE
Transactions on Communications 22 (5): 637648.
doi:10.1109/tcom.1974.1092259.
[2] Comer, Douglas E. (2006). Internetworking with TCP/IP:
Principles, Protocols, and Architecture 1 (5th ed.). Pren-
tice Hall. ISBN 0-13-187671-6.
[3] TCP (Linktionary term)
[4] RFC 791 section 2.1
[5] RFC 793
[6] RFC 1323, TCP Extensions for High Performance, Sec-
tion 2.2
[7] RFC 2018, TCP Selective Acknowledgement Options,
Section 2
[8] RFC 2018, TCP Selective Acknowledgement Options,
Section 3
[9] RFC 1323, TCP Extensions for High Performance, Sec-
tion 3.2
[10] RFC 1146, TCP Alternate Checksum Options
[11] RFC 793 section 3.1
[12] RFC 793 Section 3.2
[13] Tanenbaum, Andrew S. (2003-03-17). Computer Net-
works (Fourth ed.). Prentice Hall. ISBN 0-13-066102-3.
[14] TCP Denition. Retrieved 2011-03-12.
[15] Stone; Partridge (2000). When The CRC and TCP
Checksum Disagree. Sigcomm.
[16] RFC 879
[17] TCP window scaling and broken routers [LWN.net]
[18] Gont, Fernando (November 2008). On the implementa-
tion of TCP urgent data. 73rd IETF meeting. Retrieved
2009-01-04.
[19] Peterson, Larry (2003). Computer Networks. Morgan
Kaufmann. p. 401. ISBN 1-55860-832-X.
[20] Richard W. Stevens (2006). TCP/IP Illustrated. Vol. 1,
The protocols. Addison-Wesley. pp. Chapter 20. ISBN
978-0-201-63346-7. Retrieved 14 November 2011.
[21] Security Assessment of the Transmission Control Proto-
col (TCP) at the Wayback Machine (archived March 6,
2009)
[22] Security Assessment of the Transmission Control Proto-
col (TCP)
[23] Jakob Lell. Quick Blind TCP Connection Spoong with
SYN Cookies. Retrieved 2014-02-05.
[24] Some insights about the recent TCP DoS (Denial of Ser-
vice) vulnerabilities
[25] Exploiting TCP and the Persist Timer Inniteness
[26] Laurent Joncheray, Simple Active Attack Against TCP,
1995
[27] John T. Hagen, Barry E. Mullins (2013). TCP veto: A
novel network attack and its application to SCADA pro-
tocols. Innovative Smart Grid Technologies (ISGT), 2013
IEEE PES.
[28] TCP Interactive (iTCP)
[29] RFC 6182
[30] RFC 6824
[31] TCP with feed-forward source coding for wireless down-
link networks
90 CHAPTER 16. TRANSMISSION CONTROL PROTOCOL
[32] Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley
(2011). Improving datacenter performance and robust-
ness with multipath TCP. Sigcomm.
[33] MultiPath TCP - Linux Kernel implementation
[34] Barre; Paasch; Bonaventure (2011). MultiPath TCP:
From Theory to Practice. IFIP Networking.
[35] Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaven-
ture; Handley (2012). How Hard Can It Be? De-
signing and Implementing a Deployable Multipath TCP.
USENIX NSDI.
[36] Michael Kerrisk (2012-08-01). TCP Fast Open: expe-
diting web services. LWN.net.
[37] Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain
(2012-07-16). TCP Fast Open. IETF. I-D draft-
ietf-tcpm-fastopen-01. https://tools.ietf.org/html/
draft-ietf-tcpm-fastopen-01.
[38] "RFC6937 - Proportional Rate Reduction for TCP. http:
//tools.ietf.org/html/rfc6937.
[39] Grigorik, Ilya (2013). High-performance browser net-
working (1. ed. ed.). Beijing: O'Reilly. ISBN
1449344763.
[40] TCP performance over CDMA2000 RLP. Retrieved
2010-08-30
[41] Muhammad Adeel & Ahmad Ali Iqbal (2004). TCP
Congestion Window Optimization for CDMA2000
Packet Data Networks. International Confer-
ence on Information Technology (ITNG'07): 3135.
doi:10.1109/ITNG.2007.190. ISBN 978-0-7695-2776-
5.
16.15 Further reading
Stevens, W. Richard. TCP/IP Illustrated, Volume 1:
The Protocols. ISBN 0-201-63346-9.
Stevens, W. Richard; Wright, Gary R. TCP/IP Illus-
trated, Volume 2: The Implementation. ISBN0-201-
63354-X.
Stevens, W. Richard. TCP/IP Illustrated, Volume 3:
TCP for Transactions, HTTP, NNTP, and the UNIX
Domain Protocols. ISBN 0-201-63495-3.**
16.16 External links
16.16.1 RFC
RFC 675 Specication of Internet Transmission
Control Program, December 1974 Version
RFC 793 TCP v4
RFC 1122 includes some error corrections for
TCP
RFC 1323 TCP-Extensions
RFC 1379 Extending TCP for Transactions
Concepts
RFC 1948 Defending Against Sequence Number
Attacks
RFC 2018 TCP Selective Acknowledgment Op-
tions
RFC 4614 A Roadmap for TCP Specication
Documents
RFC 5681 TCP Congestion Control
RFC 6298 Computing TCPs Retransmission
Timer
RFC 6824 - TCP Extensions for Multipath Opera-
tion with Multiple Addresses
16.16.2 Others
Oral history interviewwith Robert E. Kahn, Charles
Babbage Institute, University of Minnesota, Min-
neapolis. Focuses on Kahns role in the develop-
ment of computer networking from 1967 through
the early 1980s. Beginning with his work at Bolt
Beranek and Newman (BBN), Kahn discusses his
involvement as the ARPANET proposal was be-
ing written, his decision to become active in its
implementation, and his role in the public demon-
stration of the ARPANET. The interview continues
into Kahns involvement with networking when he
moves to IPTO in 1972, where he was responsible
for the administrative and technical evolution of the
ARPANET, including programs in packet radio, the
development of a new network protocol (TCP/IP),
and the switch to TCP/IP to connect multiple net-
works.
IANA Port Assignments
John Kristos Overview of TCP (Fundamental
concepts behind TCP and how it is used to transport
data between two endpoints)
TCP fast retransmit simulation animated: slow start,
sliding window, duplicated Ack, congestion window
TCP, Transmission Control Protocol
Checksum example
Engineer Francesco Buas page about Transmis-
sion Control Protocol
TCP tutorial
Linktionary on TCP segments
TCP Sliding Window simulation animated (ns2)
16.16. EXTERNAL LINKS 91
Multipath TCP
TCP Technology and Testing methodologies
Chapter 17
User Datagram Protocol
The User Datagram Protocol (UDP) is one of the core
members of the Internet protocol suite. The protocol was
designed by David P. Reed in 1980 and formally dened
in RFC 768.
UDP uses a simple connectionless transmission model
with a minimum of protocol mechanism. It has no
handshaking dialogues, and thus exposes any unreliability
of the underlying network protocol to the users program.
There is no guarantee of delivery, ordering, or duplicate
protection. UDP provides checksums for data integrity,
and port numbers for addressing dierent functions at the
source and destination of the datagram.
With UDP, computer applications can send messages, in
this case referred to as datagrams, to other hosts on an
Internet Protocol (IP) network without prior communi-
cations to set up special transmission channels or data
paths. UDP is suitable for purposes where error check-
ing and correction is either not necessary or is performed
in the application, avoiding the overhead of such process-
ing at the network interface level. Time-sensitive applica-
tions often use UDP because dropping packets is prefer-
able to waiting for delayed packets, which may not be an
option in a real-time system.
[1]
If error correction facil-
ities are needed at the network interface level, an appli-
cation may use the Transmission Control Protocol (TCP)
or Stream Control Transmission Protocol (SCTP) which
are designed for this purpose.
17.1 Attributes
A number of UDPs attributes make it especially suited
for certain applications.
It is transaction-oriented, suitable for simple query-
response protocols such as the Domain Name Sys-
tem or the Network Time Protocol.
It provides datagrams, suitable for modeling other
protocols such as in IP tunneling or Remote Proce-
dure Call and the Network File System.
It is simple, suitable for bootstrapping or other pur-
poses without a full protocol stack, such as the
DHCP and Trivial File Transfer Protocol.
It is stateless, suitable for very large numbers of
clients, such as in streaming media applications for
example IPTV
The lack of retransmission delays makes it suitable
for real-time applications such as Voice over IP,
online games, and many protocols built on top of
the Real Time Streaming Protocol.
Works well in unidirectional communication, suit-
able for broadcast information such as in many kinds
of service discovery and shared information such as
broadcast time or Routing Information Protocol
17.2 Service ports
Main article: TCP and UDP port
Applications use datagram sockets to establish host-to-
host communications. An application binds a socket to
its endpoint of data transmission, which is a combination
of an IP address and a service port. A port is a software
structure that is identied by the port number, a 16 bit
integer value, allowing for port numbers between 0 and
65535. Port 0 is reserved, but is a permissible source port
value if the sending process does not expect messages in
response.
The Internet Assigned Numbers Authority (IANA) has
divided port numbers into three ranges.
[2]
Port numbers
0 through 1023 are used for common, well-known ser-
vices. On Unix-like operating systems, using one of these
ports requires superuser operating permission. Port num-
bers 1024 through 49151 are the registered ports used for
IANA-registered services. Ports 49152 through 65535
are dynamic ports that are not ocially designated for
any specic service, and may be used for any purpose.
They also are used as ephemeral ports, from which soft-
ware running on the host may randomly choose a port in
order to dene itself.
[2]
In eect, they are used as tempo-
rary ports primarily by clients when communicating with
servers.
92
17.4. CHECKSUM COMPUTATION 93
17.3 Packet structure
UDP is a minimal message-oriented Transport Layer pro-
tocol that is documented in IETF RFC 768.
UDP provides no guarantees to the upper layer protocol
for message delivery and the UDP protocol layer retains
no state of UDP messages once sent. For this reason,
UDP sometimes is referred to as Unreliable Datagram
Protocol.
[3]
UDP provides application multiplexing (via port num-
bers) and integrity verication (via checksum) of the
header and payload.
[4]
If transmission reliability is de-
sired, it must be implemented in the users application.
The UDP header consists of 4 elds, each of which is 2
bytes (16 bits).
[1]
The use of the elds Checksum and
Source port is optional in IPv4 (pink background in ta-
ble). In IPv6 only the source port is optional (see below).
Source port number This eld identies the senders
port when meaningful and should be assumed to be
the port to reply to if needed. If not used, then it
should be zero. If the source host is the client, the
port number is likely to be an ephemeral port num-
ber. If the source host is the server, the port number
is likely to be a well-known port number.
[2]
Destination port number This eld identies the re-
ceivers port and is required. Similar to source port
number, if the client is the destination host then the
port number will likely be an ephemeral port num-
ber and if the destination host is the server then
the port number will likely be a well-known port
number.
[2]
Length A eld that species the length in bytes of the
UDP header and UDP data. The minimum length
is 8 bytes since thats the length of the header. The
eld size sets a theoretical limit of 65,535 bytes (8
byte header + 65,527 bytes of data) for a UDP data-
gram. The practical limit for the data length which is
imposed by the underlying IPv4 protocol is 65,507
bytes (65,535 8 byte UDP header 20 byte IP
header).
[2]
In IPv6 Jumbograms it is possible to have UDP packets
of size greater than 65,535 bytes.
[5]
RFC2675 spec-
ies that the length eld is set to zero if the length
of the UDP header plus UDP data is greater than
65,535.
Checksum The checksum eld is used for error-
checking of the header and data. If no checksum is
generated by the transmitter, the eld uses the value
all-zeros.
[6]
This eld is not optional for IPv6.
[7]
17.4 Checksum computation
The method used to compute the checksum is dened in
RFC 768:
Checksum is the 16-bit ones complement of the
ones complement sumof a pseudo header of in-
formation from the IP header, the UDP header,
and the data, padded with zero octets at the
end (if necessary) to make a multiple of two
octets.
[6]
In other words, all 16-bit words are summed using ones
complement arithmetic. The sum is then ones comple-
mented to yield the value of the UDP checksum eld.
If the checksum calculation results in the value zero (all
16 bits 0) it should be sent as the ones complement (all
1s).
The dierence between IPv4 and IPv6 is in the data used
to compute the checksum.
17.4.1 IPv4 Pseudo Header
When UDP runs over IPv4, the checksum is computed
using a pseudo header
[8]
that contains some of the
same information from the real IPv4 header. The pseudo
header is not the real IPv4 header used to send an IP
packet, it is used only for the checksum calculation.
The source and destination addresses are those in the IPv4
header. The protocol is that for UDP (see List of IP pro-
tocol numbers): 17 (0x11). The UDP length eld is the
length of the UDP header and data.
UDP checksum computation is optional for IPv4. If a
checksum is not used it should be set to the value zero.
17.4.2 IPv6 Pseudo Header
When UDP runs over IPv6, the checksum is mandatory.
The method used to compute it is changed as documented
in RFC 2460:
Any transport or other upper-layer protocol that
includes the addresses from the IP header in
its checksum computation must be modied for
use over IPv6 to include the 128-bit IPv6 ad-
dresses.
[7]
When computing the checksum, again a pseudo header is
used that mimics the real IPv6 header:
The source address is the one in the IPv6 header. The des-
tination address is the nal destination; if the IPv6 packet
does not contain a Routing header, that will be the desti-
nation address in the IPv6 header; otherwise, at the orig-
inating node, it will be the address in the last element of
94 CHAPTER 17. USER DATAGRAM PROTOCOL
the Routing header, and, at the receiving node, it will be
the destination address in the IPv6 header. The value of
the Next Header eld is the protocol value for UDP: 17.
The UDP length eld is the length of the UDP header and
data.
17.5 Reliability and congestion
control solutions
Lacking reliability, UDP applications must generally be
willing to accept some loss, errors or duplication. Some
applications, such as TFTP, may add rudimentary relia-
bility mechanisms into the application layer as needed.
[2]
Most often, UDP applications do not employ reliabil-
ity mechanisms and may even be hindered by them.
Streaming media, real-time multiplayer games and voice
over IP (VoIP) are examples of applications that often
use UDP. In these particular applications, loss of pack-
ets is not usually a fatal problem. If an application re-
quires a high degree of reliability, a protocol such as the
Transmission Control Protocol may be used instead.
17.6 Applications
Numerous key Internet applications use UDP, including:
the Domain Name System (DNS), where queries must be
fast and only consist of a single request followed by a sin-
gle reply packet, the Simple Network Management Pro-
tocol (SNMP), the Routing Information Protocol (RIP)
[1]
and the Dynamic Host Conguration Protocol (DHCP).
Voice and video trac is generally transmitted using
UDP. Real-time video and audio streaming protocols are
designed to handle occasional lost packets, so only slight
degradation in quality occurs, rather than large delays if
lost packets were retransmitted. Because both TCP and
UDP run over the same network, many businesses are
nding that a recent increase in UDP trac from these
real-time applications is hindering the performance of ap-
plications using TCP, such as point of sale, accounting,
and database systems. When TCP detects packet loss, it
will throttle back its data rate usage. Since both real-time
and business applications are important to businesses, de-
veloping quality of service solutions is seen as crucial by
some.
[9]
17.7 Comparison of UDP and TCP
Main article: Transport Layer
Transmission Control Protocol is a connection-oriented
protocol, which means that it requires handshaking to set
up end-to-end communications. Once a connection is set
up, user data may be sent bi-directionally over the con-
nection.
Reliable TCP manages message acknowledgment,
retransmission and timeout. Multiple attempts to
deliver the message are made. If it gets lost along
the way, the server will re-request the lost part. In
TCP, theres either no missing data, or, in case of
multiple timeouts, the connection is dropped.
Ordered If two messages are sent over a connec-
tion in sequence, the rst message will reach the re-
ceiving application rst. When data segments arrive
in the wrong order, TCP buers delay the out-of-
order data until all data can be properly re-ordered
and delivered to the application.
Heavyweight TCP requires three packets to set up
a socket connection, before any user data can be
sent. TCP handles reliability and congestion con-
trol.
Streaming Data is read as a byte stream, no distin-
guishing indications are transmitted to signal mes-
sage (segment) boundaries.
UDP is a simpler message-based connectionless protocol.
Connectionless protocols do not set up a dedicated end-
to-end connection. Communication is achieved by trans-
mitting information in one direction from source to des-
tination without verifying the readiness or state of the re-
ceiver. However, one primary benet of UDP over TCP
is the application to VoIP where latency and jitter are the
primary concerns. It is assumed in VoIP UDP that the
end users provide any necessary real time conrmation
that the message has been received.
Unreliable When a message is sent, it cannot be
known if it will reach its destination; it could get lost
along the way. There is no concept of acknowledg-
ment, retransmission, or timeout.
Not ordered If two messages are sent to the same
recipient, the order in which they arrive cannot be
predicted.
Lightweight There is no ordering of messages, no
tracking connections, etc. It is a small transport layer
designed on top of IP.
Datagrams Packets are sent individually and are
checked for integrity only if they arrive. Packets
have denite boundaries which are honored upon
receipt, meaning a read operation at the receiver
socket will yield an entire message as it was origi-
nally sent.
No congestion control UDP itself does not avoid
congestion, unless they implement congestion con-
trol measures at the application level.
17.10. EXTERNAL LINKS 95
17.8 See also
List of TCP and UDP port numbers
Reliable User Datagram Protocol (RUDP)
SCTP
Comparison of transport layer protocols
UDP ood attack
UDP Data Transport
UDP Lite, a variant that will deliver packets even if
they are malformed
UDP Helper Address
TP (Micro Transport Protocol)
17.9 Notes and references
17.9.1 Notes
[1] Kurose, J. F.; Ross, K. W. (2010). Computer Networking:
A Top-Down Approach (5th ed.). Boston, MA: Pearson
Education. ISBN 978-0-13-136548-3.
[2] Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed.
New Delhi, India: Tata McGraw-Hill Publishing Com-
pany Limited.
[3] [email protected]. UDP Protocol Overview.
Ipv6.com. Retrieved 17 August 2011.
[4] Clark, M.P. (2003). Data Networks IP and the Internet,
1st ed. West Sussex, England: John Wiley & Sons Ltd.
[5] RFC 2675
[6] Postel, J. (August 1980). RFC 768: User Datagram Pro-
tocol. Internet Engineering Task Force".
[7] Deering S. & Hinden R. (December 1998). RFC 2460:
Internet Protocol, Version 6 (IPv6) Specication. Internet
Engineering Task Force..
[8] RFC 768, p2
[9] The impact of UDP on Data Applications. Networkper-
formancedaily.com. Retrieved 17 August 2011.
17.9.2 RFC references
RFC 768 User Datagram Protocol
RFC 2460 Internet Protocol, Version 6 (IPv6)
Specication
RFC 2675 IPv6 Jumbograms
RFC 4113 Management Information Base for the
UDP
RFC5405 Unicast UDP Usage Guidelines for Ap-
plication Designers
17.10 External links
IANA Port Assignments
The Trouble with UDP Scanning (PDF)
Breakdown of UDP frame
UDP on MSDN Magazine Sockets and WCF
UDP connections
Chapter 18
Internet Control Message Protocol
The Internet Control Message Protocol (ICMP) is one
of the main protocols of the Internet Protocol Suite. It is
used by network devices, like routers, to send error mes-
sages indicating, for example, that a requested service is
not available or that a host or router could not be reached.
ICMP can also be used to relay query messages.
[1]
It is as-
signed protocol number 1.
[2]
ICMP
[3]
diers from trans-
port protocols such as TCP and UDP in that it is not
typically used to exchange data between systems, nor is
it regularly employed by end-user network applications
(with the exception of some diagnostic tools like ping and
traceroute).
ICMPfor Internet Protocol version 4 (IPv4) is also known
as ICMPv4. IPv6 has a similar protocol, ICMPv6.
18.1 Technical details
The Internet Control Message Protocol is part of the
Internet Protocol Suite, as dened in RFC 792. ICMP
messages are typically used for diagnostic or control pur-
poses or generated in response to errors in IP operations
(as specied in RFC 1122). ICMP errors are directed to
the source IP address of the originating packet.
[1]
For example, every device (such as an intermediate
router) forwarding an IP datagram rst decrements the
time to live (TTL) eld in the IP header by one. If the
resulting TTL is 0, the packet is discarded and an ICMP
Time To Live exceeded in transit message is sent to the
datagrams source address.
Although ICMP messages are contained within standard
IP packets, ICMP messages are usually processed as a
special case, distinguished from normal IP processing,
rather than processed as a normal sub-protocol of IP. In
many cases, it is necessary to inspect the contents of the
ICMP message and deliver the appropriate error message
to the application that generated the original IP packet,
the one that sent the packet that prompted the sending of
the ICMP message.
Many commonly used network utilities are based on
ICMP messages. The traceroute command can be imple-
mented by transmitting IP datagrams with specially set IP
TTL header elds, and looking for ICMP Time to live ex-
ceeded in transit (above) and Destination unreachable
messages generated in response. The related ping util-
ity is implemented using the ICMP Echo request and
Echo reply messages.
18.2 ICMP segment structure
18.2.1 Header
The ICMP header starts after the IPv4 header and is iden-
tied by IP protocol number '1'. All ICMP packets have
an 8-byte header and variable-sized data section. The rst
4 bytes of the header have xed format, while the last 4
bytes depend on the type/code of that ICMP packet.
[1]
Type ICMP type, see Control messages.
Code ICMP subtype, see Control messages.
Checksum Error checking data, calculated from the
ICMP header and data, with value 0 substituted for
this eld. The Internet Checksum is used, specied
in RFC 1071.
Rest of Header Four-bytes eld, contents vary based
on the ICMP type and code.
ICMP error messages contain a data section that includes
the entire IPv4 header, plus the rst eight bytes of data
from the IPv4 packet that caused the error message. The
ICMPpacket is then encapsulated in a newIPv4 packet.
[1]
18.2.2 Data
The variable size of the ICMP packet data section has
been exploited. In the well-known "Ping of death, large
or fragmented ping packets are used for denial-of-service
attacks. ICMP can also be used to create covert channels
for communication, as with the LOKI exploit.
[4]
96
18.3. CONTROL MESSAGES 97
18.3 Control messages
18.3.1 Source quench
Source Quench requests that the sender decrease the rate
of messages sent to a router or host. This message may
be generated if a router or host does not have sucient
buer space to process the request, or may occur if the
router or host buer is approaching its limit.
Data is sent at a very high speed from a host or from
several hosts at the same time to a particular router on
a network. Although a router has buering capabilities,
the buering is limited to within a specied range. The
router cannot queue any more data than the capacity of
the limited buering space. Thus if the queue gets lled
up, incoming data is discarded until the queue is no longer
full. But as no acknowledgement mechanism is present
in the network layer, the client does not know whether
the data has reached the destination successfully. Hence
some remedial measures should be taken by the network
layer to avoid these kind of situations. These measures are
referred to as source quench. In a source quench mecha-
nism, the router sees that the incoming data rate is much
faster than the outgoing data rate, and sends an ICMP
message to the clients, informing them that they should
slow down their data transfer speeds or wait for a cer-
tain amount of time before attempting to send more data.
When a client receives this message, it will automatically
slow down the outgoing data rate or wait for a sucient
amount of time, which enables the router to empty the
queue. Thus the source quench ICMP message acts as
ow control in the network layer.
Since research suggested that ICMP Source Quench
was an ineective (and unfair) antidote for congestion,
routers creation of source quench messages was dep-
recated in 1995 by RFC 1812. Furthermore, forward-
ing of and any kind of reaction to (ow control actions)
source quench messages was deprecated from 2012 by
RFC 6633.
Where:
Type must be set to 4
Code must be set to 0
IP header and additional data is used by the
sender to match the reply with the associated
request
18.3.2 Redirect
Redirect requests data packets be sent on an alternative
route. ICMP Redirect is a mechanism for routers to con-
vey routing information to hosts. The message informs a
host to update its routing information (to send packets on
an alternative route). If a host tries to send data through a
router (R1) and R1 sends the data on another router (R2)
and a direct path from the host to R2 is available (that is,
the host and R2 are on the same Ethernet segment), then
R1 will send a redirect message to informthe host that the
best route for the destination is via R2. The host should
then send packets for the destination directly to R2. The
router will still send the original datagram to the intended
destination.
[7]
However, if the datagram contains routing
information, this message will not be sent even if a better
route is available. RFC 1122 states that redirects should
only be sent by gateways and should not be sent by Inter-
net hosts.
Where:
Type must be set to 5.
Code species the reason for the redirection,
may be one of the following:
IP address is the 32-bit address of the gateway
to which the redirection should be sent.
IP header and additional data is included to al-
low the host to match the reply with the request
that caused the redirection reply.
18.3.3 Time exceeded
Time Exceeded is generated by a gateway to inform the
source of a discarded datagram due to the time to live
eld reaching zero. A time exceeded message may also
be sent by a host if it fails to reassemble a fragmented
datagram within its time limit.
Time exceeded messages are used by the traceroute utility
to identify gateways on the path between two hosts.
Where:
Type must be set to 11
Code species the reason for the time ex-
ceeded message, include the following:
IP header and rst 64 bits of the original
payload are used by the source host to match
the time exceeded message to the discarded
datagram. For higher level protocols such as
UDP and TCP the 64 bit payload will include
the source and destination ports of the dis-
carded packet.
18.3.4 Timestamp
Timestamp is used for time synchronization. The origi-
nating timestamp is set to the time (in milliseconds since
midnight) the sender last touched the packet. The receive
and transmit timestamps are not used.
98 CHAPTER 18. INTERNET CONTROL MESSAGE PROTOCOL
Where:
Type must be set to 13
Code must be set to 0
Identier and Sequence Number can be used
by the client to match the timestamp reply with
the timestamp request.
Originate timestamp is the number of mil-
liseconds since midnight Universal Time (UT).
If a UT reference is not available the most-
signicant bit can be set to indicate a non-
standard time value.
18.3.5 Timestamp reply
Timestamp Reply replies to a Timestamp message. It con-
sists of the originating timestamp sent by the sender of
the Timestamp as well as a receive timestamp indicating
when the Timestamp was received and a transmit times-
tamp indicating when the Timestamp reply was sent.
Where:
Type must be set to 14
Code must be set to 0
Identier and Sequence number can be used
by the client to match the reply with the request
that caused the reply.
Originate timestamp is the time the sender
last touched the message before sending it.
Receive timestamp is the time the echoer rst
touched it on receipt.
Transmit timestamp is the time the echoer
last touched the message on sending it.
All timestamps are in units of milliseconds
since midnight UT. If the time is not available
in milliseconds or cannot be provided with re-
spect to midnight UT then any time can be in-
serted in a timestamp provided the high order
bit of the timestamp is also set to indicate this
non-standard value.
18.3.6 Address mask request
Address mask request is normally sent by a host to a router
in order to obtain an appropriate subnet mask.
Recipients should reply to this message with an Address
mask reply message.
Where:
Type must be set to 17
Code must be set to 0
Address mask can be set to 0
ICMP Address Mask Request may be used as a part of
reconnaissance attack to gather information on the target
network, therefore ICMPAddress Mask Reply is disabled
by default on Cisco IOS.
[8]
18.3.7 Address mask reply
Address mask reply is used to reply to an address mask
request message with an appropriate subnet mask.
Where:
Type must be set to 18
Code must be set to 0
Address mask should be set to the subnet
mask
18.3.8 Destination unreachable
Destination unreachable is generated by the host or its in-
bound gateway
[3]
to inform the client that the destination
is unreachable for some reason. A Destination Unreach-
able message may be generated as a result of a TCP, UDP
or another ICMP transmission. Unreachable TCP ports
notably respond with TCP RST rather than a Destination
Unreachable type 3 as might be expected.
The error will not be generated if the original datagram
has a multicast destination address. Reasons for this mes-
sage may include: the physical connection to the host
does not exist (distance is innite); the indicated protocol
or port is not active; the data must be fragmented but the
'don't fragment' ag is on.
Where:
Type eld (bits 0-7) must be set to 3
Code eld (bits 8-15) is used to specify the
type of error, and can be any of the following:
Next-hop MTU eld (bits 48-63) contains the
MTU of the next-hop network if a code 4 error
occurs.
IP header and additional data is included to
allow the client to match the reply with the re-
quest that caused the destination unreachable
reply.
18.4 See also
ICMP tunnel
ICMP hole punching
ICMPv6
18.6. EXTERNAL LINKS 99
IRDP
PMTU blackhole
Pathping
Path MTU Discovery
Ping
Smurf attack
TCP
18.5 References
[1] Forouzan, Behrouz A. (2007). Data Communications And
Networking (Fourth ed.). Boston: McGraw-Hill. pp.
621630. ISBN 0-07-296775-7.
[2] Protocol Numbers. Internet Assigned Numbers Au-
thority. Retrieved 2011-06-23.
[3] Postel, J. (September 1981). Internet Control Message
Protocol. IETF. RFC 792. https://tools.ietf.org/html/
rfc792.
[4] ICMP Protocol Exploit Loki. Retrieved 2014-09-19.
[5] IANA ICMP Parameters. Iana.org. 2012-09-21. Re-
trieved 2013-01-07.
[6] Computer Networking ATop-Down Approach by Kurose
and Ross
[7] When Are ICMP Redirects Sent?". Cisco Systems.
2008-06-28. Retrieved 2013-08-15.
[8] Cisco IOS IP Command Reference, Volume 1 of 4:
Addressing and Services, Release 12.3 - IP Addressing
and Services Commands: ip mask-reply through ip web-
cache. Cisco Systems. Retrieved 2013-01-07.
18.6 External links
RFCs
RFC 792, Internet Control Message Protocol
RFC 950
RFC 1016 - Something a Host Could Do with
Source Quench: The Source Quench Intro-
duced Delay (SQuID)
RFC 1122, Requirements for Internet Hosts
Communication Layers
RFC 1716, Towards Requirements for IP
Router
RFC 1812, Requirements for IP Version 4
Routers
IANA ICMP parameters
IANA protocol numbers
Explanation of ICMP Redirect Behavior
Chapter 19
Internet Group Management Protocol
The Internet Group Management Protocol (IGMP)
is a communications protocol used by hosts and adjacent
routers on IP networks to establish multicast group mem-
berships. IGMP is an integral part of IP multicast.
IGMP can be used for one-to-many networking appli-
cations such as online streaming video and gaming, and
allows more ecient use of resources when supporting
these types of applications.
IGMP is used on IPv4 networks. Multicast management
on IPv6 networks is handled by Multicast Listener Dis-
covery (MLD) which uses ICMPv6 messaging in contrast
to IGMPs bare IP encapsulation.
19.1 Architecture
A network designed to deliver a multicast service using
IGMP might use this basic architecture:
IGMP operates between the client computer and a local
multicast router. Switches featuring IGMP snooping de-
rive useful information by observing these IGMP trans-
actions. Protocol Independent Multicast (PIM) is then
used between the local and remote multicast routers, to
direct multicast trac from the multicast server to many
multicast clients.
IGMP operates on the network layer, just the same as
other network management protocols like ICMP.
[1]
The IGMP protocol is implemented on a particular host
and within a router. A host requests membership to a
group through its local router while a router listens for
these requests and periodically sends out subscription
queries.
IGMP is vulnerable to some attacks,
[2][3][4][5]
and re-
walls commonly allow the user to disable it if not needed.
19.2 Standards
There are three versions of IGMP, as dened by Request
for Comments (RFC) documents of the Internet Engi-
neering Task Force (IETF). IGMPv1 is dened by RFC
1112, IGMPv2 is dened by RFC 2236 and IGMPv3
was initially dened by RFC 3376 and has been updated
by RFC 4604 which denes both IGMPv3 and MLDv2.
IGMPv2 improves over IGMPv1 by adding the ability
for a host to signal desire to leave a multicast group.
IGMPv3 improves over IGMPv2 mainly by supporting
source-specic multicast.
[6]
19.3 Packet structure
IGMP messages are carried in bare IP packets with IP
protocol number 2.
[7]
There is no transport layer used
with IGMP messaging, similar to the Internet Control
Message Protocol.
There are several types of IGMP messages: Member-
ship Queries (general and group-specic), Membership
Reports, and Leave Group messages.
Membership Queries are sent by multicast routers to de-
termine which multicast addresses are of interest to sys-
tems attached to its network. Routers periodically send
General Queries to refresh the group membership state
for all systems on its network. Group-Specic Queries are
used for determining the reception state for a particular
multicast address. Group-and-Source-Specic Queries
allow the router to determine if any systems desire recep-
tion of messages sent to a multicast group from a source
address specied in a list of unicast addresses.
100
19.4. IMPLEMENTATIONS 101
19.3.1 IGMPv2 messages
Where:
Type Indicates the message type as follows: Member-
ship Query (0x11), Membership Report (IGMPv1:
0x12, IGMPv2: 0x16, IGMPv3: 0x22), Leave
Group (0x17)
Max Resp Time Species the time limit for the corre-
sponding report. The eld has a resolution of 100
milliseconds, the value is taken directly. This eld
is meaningful only in Membership Query (0x11); in
other messages it is set to 0 and ignored by the re-
ceiver.
Group Address This is the multicast address being
queried when sending a Group-Specic or Group-
and-Source-Specic Query. The eld is zeroed
when sending a General Query.
The message is sent to following IP addresses:
19.3.2 IGMPv3 membership query
Where:
Max Resp Code This eld species the maximumtime
(in 1/10 second) allowed before sending a respond-
ing report. If the number is below 128, the value
is used directly. If the value is 128 or more, it is
interpreted as an exponent and mantissa.
Checksum This is the 16-bit ones complement of the
ones complement sumof the entire IGMP message.
Group Address This is the multicast address being
queried when sending a Group-Specic or Group-
and-Source-Specic Query. The eld is zeroed
when sending a General Query.
Resv This eld is reserved. It should be zeroed when
sent and ignored when received.
S (Suppress Router-side Processing) Flag When
this ag is set, it indicates to receiving routers that
they are to suppress the normal timer updates.
QRV (Queriers Robustness Variable) If this is non-
zero, it contains the Robustness Variable value used
by the sender of the Query. Routers should update
their Robustness Variable to match the most recently
received Query unless the value is zero.
QQIC (Queriers Query Interval Code) This code is
used to specify the Query Interval value (in seconds)
used by the querier. If the number is below 128, the
value is used directly. If the value is 128 or more, it
is interpreted as an exponent and mantissa.
Number of Sources (N) This eld species the num-
ber of source addresses present in the Query. For
General and Group-Specic Queries, this value is
zero. For Group-and-Source-Specic Queries, this
value is non-zero, but limited by the networks
MTU.
Source Address [i] The Source Address [i] elds are a
vector of n IP unicast addresses, where n is the value
in the Number of Sources (N) eld.
19.4 Implementations
The FreeBSD,
[note 1]
Linux
[note 2]
and Windows operating
systems support IGMP at the host side.
19.5 Notes
[1] IGMPv3 was added to FreeBSD in version 8.0.
[2] IGMPv3 was added in the Linux 2.5 kernel series.
19.6 See also
Internet Group Management Protocol with Access
Control
19.7 References
[1] Forouzan, Behrouz A. (2012). Data Communications and
Networking (5th ed.). New York, NY: McGraw-Hill. p.
658. ISBN 0073376221.
[2] Spoofed IGMP report denial of service vulnerability.
[3] Fragmented IGMP packet may promote Denial of Ser-
vice attack.
[4] IGMP Security Problem Statement and Requirements.
[5] Microsoft Security Bulletin MS06-007: Vulnerability in
TCP/IP Could Allow Denial of Service (913446).
[6] Internet Group Management Protocol Overview.
Javvin. Retrieved 2010-11-18.
[7] RFC 3376 Section 4
[8] RFC 2236 Section 2
[9] RFC 2236 Section 9
[10] RFC 3376 Section 4.1
19.8 External links
IPv4 Multicasting Tools and Settings on Microsoft
TechNet
Chapter 20
Industrial Ethernet
Industrial Ethernet switch
Industrial Ethernet (IE) refers to the use of standard
Ethernet protocols with rugged connectors and extended
temperature switches in an industrial environment, for
automation or process control. Components used in plant
process areas must be designed to work in harsh environ-
ments of temperature extremes, humidity, and vibration
that exceed the ranges for information technology equip-
ment intended for installation in controlled environments.
The use of ber Ethernet reduces the problems of elec-
trical noise and provides electrical isolation to prevent
equipment damage. Some industrial networks empha-
sized deterministic delivery of transmitted data, whereas
Ethernet used collision detection which made transport
time for individual data packets dicult to estimate with
increasing network trac. Typically, industrial use of
Ethernet use full-duplex standards and other methods so
that collisions do not unacceptably inuence transmission
times.
20.1 Application environment
While industrial Ethernet systems use the same proto-
cols as Ethernet applied to oce automation, industrial
plant use requires consideration of the environment in
which the equipment must operate. Plant-oor equip-
ment must tolerate a wider range of temperature, vibra-
tion, and electrical noise than equipment installed in ded-
icated information-technology areas. Since closed-loop
process control may rely on an Ethernet link, economic
cost of interruptions may be high and availability is there-
fore an essential criterion. Industrial Ethernet networks
must interoperate with both current and legacy systems,
and must provide predictable performance and maintain-
ability. In addition to physical compatibility and low-
level transport protocols, a practical industrial Ethernet
system must also provide interoperability of higher levels
of the OSI model. An industrial network must provide
security both from intrusions from outside the plant, and
from inadvertent or unauthorized use within the plant.
[1]
Industrial networks often use network switches to seg-
ment a large system into logical sub-networks, divided by
address, protocol, or application. Using network switches
allows the network to be broken up into many small
collision domains. This reduces the risk of a faulty or
mis-congured device generating excess network trac.
When an industrial network must connect to an oce net-
work or external networks, a rewall system can be in-
serted to control exchange of data between the networks.
To preserve the performance and reliability of the indus-
trial network, general oce automation systems are sep-
arated from the network used for control or I/O devices.
20.2 Advantages and diculties
PLC (Programmable logic controller) communicate us-
ing one of several possible open or proprietary proto-
cols, such as Modbus, Sinec H1, Probus, CANopen,
DeviceNet or FOUNDATION Fieldbus. The idea to
use standard Ethernet makes these systems more inter-
operable.
Some of the advantages over other types of industrial net-
work are:
Increased speed, up from9.6 kbit/s with RS-232 to 1
Gbit/s with Gigabit Ethernet over Cat5e/Cat6 cables
or optical ber
Increased distance
Ability to use standard access points, routers,
switches, hubs, cables and optical ber
102
20.5. EXTERNAL LINKS 103
Ability to have more than two nodes on link, which
was possible with RS-485 but not with RS-232
Peer-to-peer architectures may replace master-slave
ones
Better interoperability
Diculties of using Industrial Ethernet include:
Migrating existing systems to a new protocol
Real-time uses may suer for protocols using TCP
Managing a whole TCP/IP stack is more complex
than just receiving serial data
The minimumEthernet frame size is 64 bytes, while
typical industrial communication data sizes can be
closer to 18 bytes. This protocol overhead aects
data transmission eciency.
20.3 See also
Computer network
Distributed control system
Fieldbus
Human-machine interface
Modbus
Process control
Programmable logic controller
SCADA
Parallel Redundancy Protocol
Media Redundancy Protocol
20.4 References
[1] Perry S. Marshall, John S. Rinaldi How to Plan, In-
stall and Maintain TCP/IPEthernet Networks, ISA, 2004
ISBN 1-55617-869-7 pp. 14
20.5 External links
Industrial Ethernet Advisory Group
Lammermann.eu: Ethernet as a Real-Time Tech-
nology
Chapter 21
PROFINET
PROFINETis a standard for industrial automation using
a computer network. PROFINET uses standards such as
TCP/IP and Ethernet. PROFINETs modular structure
allows users to select only needed functions for dierent
requirements.
For example, a simple component model is dened, and
another mechanism was developed for real time (RT) and
isochronous real time (IRT) communication.
21.1 Technology
Three protocol levels are dened:
TCP/IP for PROFINET CBA and the commission-
ing of a plant
[1]
with reaction times in the range of
100 ms
RT (real-time) protocol for PROFINET CBA and
PROFINET IO applications
[1]
up to 10 ms cycle
times
IRT (Isochronous Real-Time) for PROFINET IO
applications in drive systems
[1]
with cycles times of
less than 1 ms
The protocols can be recorded and displayed using an
Ethernet analysis tool such as Wireshark.
[1]
The topology
can be shown using analysis tools such as TH Scope.
21.2 Component model
A PROFINET Component Based Automation (CBA)
system consists of various automation components. One
component covers all mechanical, electrical and IT vari-
ables. The component can be generated using the stan-
dard programming tools. A component is described us-
ing a PROFINET component description (PCD) le in
XML. A planning tool loads these descriptions and en-
ables the logical interconnections between the individual
components to be generated for implementing a plant.
This model was largely inspired by the IEC 61499 stan-
dard.
The basic idea of CBAis that an entire automation system
can be divided into autonomously operating subsystems.
The design and the functions can end up in identical or
slightly modied form in several systems. Each compo-
nent is usually controlled by manageable number of input
signals. Within the component, a control program exe-
cutes the function and passes the corresponding output
signals to another controller. The engineering that is as-
sociated with it is manufacturer-neutral. The communi-
cation of a component-based system is only congured,
instead of being programmed. The communication with
PROFINET CBA (without real time) is suitable for bus
cycle times of approx. 50 to 100 ms. The parallel running
RT channel allows for data cycles similar to PROFINET
IO (a few ms).
21.3 Peripherals
Interfacing to peripherals is implemented by PROFINET
IO.
[1][2]
It denes the communication with eld con-
nected peripheral devices. Its basis is a cascading real-
time concept. PROFINET IO denes the entire data ex-
change between controllers (devices with master func-
tionality) and the devices (devices with slave func-
tionality), as well as parameter setting and diagno-
sis. PROFINET IO is designed for the fast data ex-
change between Ethernet-based eld devices and fol-
lows the provider-consumer model.
[1]
Field devices in
a subordinate PROFIBUS line can be integrated in the
PROFINET IO system without any eort and seamlessly
via an IO-Proxy (representative of a subordinate bus sys-
tem). A device developer can implement PROFINET IO
with any commercially available Ethernet controller.
[1]
It
is well-suited for the data exchange with bus cycle times
of a few ms. The conguration of an IO-System has been
kept similar to PROFIBUS. PROFINET IO always con-
tains the real-time concept.
A PROFINET IO system consists of the following de-
vices:
The IO Controller, which controls the automation
task.
The IO Device, which is a eld device, monitored
104
21.6. ISOCHRONOUS COMMUNICATION 105
and controlled by an IO Controller. An IO Device
may consist of several modules and sub-modules.
The IO Supervisor is software typically based on a
PC for setting parameters and diagnosing individual
IO Devices.
[2]
An Application Relation (AR) is established between an
IO Controller and an IO Device. These ARs are used
to dene Communication Relations (CR) with dier-
ent characteristics for the transfer of parameters, cyclic
exchange of data and handling of alarms.
[1]
Refer to
PROFNET IO connection life-cycle for a more detailed
description.
The characteristics of an IO Device are described by
the device manufacturer in a General Station Descrip-
tion (GSD) le. The language used for this purpose is
the GSDML (GSD Markup Language) - an XML based
language. The GSD le provides the supervision soft-
ware with a basis for planning the conguration of a
PROFINET IO system.
[1][2]
21.4 IO addressing
Every module within a PROFINET network has three ad-
dresses:
MAC address
IP address
Device name, a logical name for the module within
the total conguration
Because PROFINET uses TCP/IP a MAC and IP ad-
dress are used. A MAC address changes if the device
is replaced. An IP address is a form of dynamic address-
ing. Because there was a need for a xed address a device
name is used.
For allocation of the IP address, subnet mask and default
gateway two methods are dened:
DCP: Discovery and Conguration Protocol
DHCP: Dynamic Host Conguration Protocol
21.5 Real time
Within PROFINET IO, process data and alarms are
always transmitted in real time (RT). Real time in
PROFINET is based on denitions of IEEE and IEC,
which allow for only a limited time for execution of real-
time services within a bus cycle. The RT communication
represents the basis for the data exchange for PROFINET
IO. Real-time data are treated with a higher priority than
TCP(UDP)/IP data. RT provides the basis for the real-
time communication in the area of distributed periphery
and for the PROFINET component model. This type of
data exchange allows bus cycle times in the range of a few
hundred microseconds.
21.6 Isochronous communication
Isochronous data exchange with PROFINET is dened in
the isochronous real-time (IRT) concept. Devices with
IRT functionality have switch ports integrated in the eld
device. They can be based e.g. on the Ethernet con-
trollers ERTEC 400/200. The data exchange cycles are
usually in the range of a few hundred microseconds up
to a few milliseconds. The dierence to real-time com-
munication is essentially the high degree of determinism,
so that the start of a bus cycle is maintained with high
precision. The start of a bus cycle can deviate up to 1 s
(jitter). IRT is required, for example, for motion control
applications (positioning control processes).
21.7 Proles
Proles are pre-dened congurations of the functions
and features available from PROFINET for use in spe-
cic devices or applications. They are specied by PI
working groups and published by PI. Proles are impor-
tant for openness, interoperability and interchangeability,
so that the end user can be sure that similar equipments
from dierent vendors perform in a standardised way.
There are PROFINET proles for encoders, for exam-
ple. Other proles have been specied for motion con-
trol (PROFIdrive) and Functional Safety (PROFIsafe). A
special prole for trains also exists.
Another prole is PROFIenergy which includes services
for real time monitoring of energy demand. This was
requested in 2009 by the AIDA group of German au-
tomotive Manufacturers (Audi, BMW, Mercedes-Benz,
Porsche and VW) who wished to have a standardised way
of actively managing energy usage in their plants. High
energy devices and sub-systems such as robots, lasers and
even paint lines are the target for this prole, which will
help reduce a plants energy costs by intelligently switch-
ing the devices into 'sleep' modes to take account of pro-
duction breaks, both foreseen (e.g. weekends and shut-
downs) and unforeseen (e.g. breakdowns).
21.8 Organization
PROFINET is dened by PROFIBUS and PROFINET
International (PI) and backed by the INTERBUS Club
and, since 2003, is part of the IEC 61158 and IEC 61784
standards.
106 CHAPTER 21. PROFINET
21.9 References
[1] Application Layer protocol for decentralized periph-
ery and distributed automation, Specication for
PROFINET, Version 2.3, October 2010, Order No.:
2.722, PROFIBUS Nutzerorganisation e.V. (PNO)
[2] Industrial communication with PROFINET, Manfred
Popp, Order no.: 4.182, PROFIBUS Nutzerorganisation
e.V. (PNO)
21.10 Further reading
Raimond Pigan, Mark Metter: Automating with
PROFINET, 2nd rev. and enl. edition. 2008, ISBN
978-3-89578-294-7
21.11 External links
PROFIBUS & PROFINET International (PI)
All Things PROFINET
21.12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES 107
21.12 Text and image sources, contributors, and licenses
21.12.1 Text
List of network buses Source: http://en.wikipedia.org/wiki/List_of_network_buses?oldid=590964845 Contributors: DougEngland,
TastyPoutine, Nhumfrey, Electron9, Widefox, Beefstu, R'n'B, Dmillimono, Andy Dingley, Lightmouse, Arizavi, TonyBallioni, Avoided,
Addbot, Lightbot, Crispmuncher, Anna Frodesiak, FrescoBot, Betsytimmer and Anonymous: 10
RS-232 Source: http://en.wikipedia.org/wiki/RS-232?oldid=627661675 Contributors: AxelBoldt, Bryan Derksen, Malcolm Farmer, Just-
fred, Aldie, Ortolan88, Maury Markowitz, Heron, Topory, RTC, Tim Starling, Nixdorf, Pnm, Liftarn, SGBailey, Breakpoint, Delir-
ium, Paddu, Egil, WeiNix, Baylink, Theresa knott, Glenn, Hpa, Ed Brey, Crissov, Dmsar, Reddi, Zoicon5, Sweety Rose, Itai, Ed g2s,
Bevo, Robbot, Scott McNay, SchmuckyTheCat, Captain Segfault, Giftlite, Brouhaha, Lunkwill, Christopher Parham, Inter, Ferkelpa-
rade, TomViza, AJim, Alexander.stohr, Rchandra, Uzume, Bobblewik, Mobius, Wmahan, Utcursch, Sam Hocevar, Gazpacho, Imroy, Rich
Farmbrough, Bert490, Jcmaco, IlyaHaykinson, Alistair1978, Closeapple, Plugwash, Evice, Femto, West London Dweller, Underdog, Wipe,
Dcxf, Yonkie, Hawklord, Towel401, ClementSeveillac, Jason One, Gcbirzan, Alansohn, Atlant, Hopp, Water Bottle, RoySmith, Wtmitchell,
Wtshymanski, Rick Sidwell, Danhash, Jheald, Yurivict, Thryduulf, Poppafuze, Miketwo, Weevil, Snaekid, Ketiltrout, Rjwilmsi, Koavf,
SummitWulf, Allen Moore, FlaBot, Flydpnkrtn, Chobot, Adoniscik, Roboto de Ajvol, YurikBot, Jengelh, DanMS, Shaddack, Bovineone,
Anomalocaris, Mipadi, Tkbwik, Tokachu, Fixedd, Mikeblas, Neil.steiner, SixSix, Jeh, Jeremy Visser, Caerwine, Ato basehore, The imp,
Petri Krohn, Lio, CWenger, Madlobster, Jroddi, Linkminer, Krtki, SmackBot, Thunderboltz, Chris the speller, Thumperward, Miquon-
ranger03, Sampi, Colonies Chris, Frap, An-chan, S Roper, Tony esopi patra, Efalk, Charivari, Nmnogueira, Maarten1980, Lambiam,
Petr Kopa, Fingew, Dave Yost, Gang65, Bollinger, Manifestation, Kvng, Andrew Hampe, Paul Foxworthy, IanOfNorwich, Robinhw,
CmdrObot, Chrike, Hatched3, Jesse Viviano, CuriousEric, Requestion, Spoxox, Gogo Dodo, Wa2ise, SreekumarC, Tawkerbot4, Quibik,
JLD, Gimmetrow, WillFarrell, Nekkensj, Hcberkowitz, DmitTrix, Electron9, Reswobslc, Druiloor, SparhawkWiki, J Clear, Luna Santin,
Seaphoto, Jj137, Markthemac, JAnDbot, CombatWombat42, MER-C, Arch dude, IanOsgood, Austinmurphy, Jahoe, Nicolaasuni, Bong-
warrior, VoABot II, SEREGA784, Jatkins, Jonsg, JaGa, I B Wright, Captainspizzo, Ksero, Sigmundg, Exostor, Mange01, ISC PB, Wa3frp,
Extransit, Davandron, Bigdumbdinosaur, Inwind, Useight, Funandtrvl, Xenonice, Buddhikaeport, Deor, VolkovBot, Vihljun, KyferEz,
Philip Trueman, TXiKiBoT, Ngorham, Wireless router, Someguy1221, CanOfWorms, Mezzaluna, Mcculley, Andy Dingley, NHRHS2010,
Biscuittin, Ronaldesmith, Keilana, Happysailor, Fahidka, Rowine719, Lightmouse, Engineerism, OKBot, Anchor Link Bot, Pplshero54,
Dlrohrer2003, Bajsejohannes, ClueBot, Mild Bill Hiccup, Uncle Milty, Pointillist, Rgraham nz, Dekisugi, The Yowser, Kthbn, Jonverve,
Aronzak, DumZiBoT, Theo177, XLinkBot, Spitre, Jonbowen234, Rror, Oparidae, Addbot, Mortense, PaterMcFly, Tothwolf, Abisys,
Luckas-bot, Yobot, Crispmuncher, Mmxx, Wonder, AnomieBOT, RandomAct, Citation bot, Isheden, Nasa-verve, Bon21, Shadowjams,
Haji akhundov, Tongtang, Vertago1, SpaceFlight89, Signal7, Toolnut, Pthurmes, Vrenator, Limited Atonement, RjwilmsiBot, EmausBot,
Acather96, Hit.kansagra, Ponydepression, ZroBot, Mastergreg82, Makecat, Demiurge1000, Sbmeirow, Overdoer949, Electron18, Dml-
max, L Kensington, Tsaavik, DJeo, Sven Manguard, ClueBot NG, MKA667, Matthiaspaul, Wosch21149, DieSwartzPunkt, Antiqueight,
Oddbodz, Helpful Pixie Bot, Wbm1058, Komalnirala, Hallows AG, Robert the Devil, Dhanashreevaidya, Sdimteam, Jegor57, Pjb304,
Webclient101, Sriharsh1234, Nishitpatira, FrigidNinja, Richpike, Mmpozulp, Monkbot, Gandhi.ktn2 and Anonymous: 433
Serial port Source: http://en.wikipedia.org/wiki/Serial_port?oldid=625542501 Contributors: Lee Daniel Crocker, Tarquin, Rmhermen,
Ray Van De Walker, Volker, Edward, Modster, Mahjongg, Pekkapihlajasaari, SGBailey, CesarB, Egil, Hpa, Reddi, Pedant17, Spikey,
EpiVictor, Robbot, Kadin2048, Puckly, Giftlite, Brouhaha, Everyking, Alexander.stohr, Khalid hassani, Uzume, Bobblewik, Vina, Bk0,
ZZyXx, Eric B. and Rakim, Henriquevicente, Imroy, ElTyrant, Rhobite, Bert490, Clawed, Adam850, Plugwash, CanisRufus, West London
Dweller, Polluks, Towel401, MatthewWilcox, Guy Harris, Interiot, CyberSkull, Yamla, Benefros, Trylks, Wtshymanski, ComCat, Cdric,
Camw, Haikupoet, Brolin Empey, Ttwaring, Moreati, Crazycomputers, DuLithgow, Chobot, Roboto de Ajvol, Wavelength, Hairy Dude,
Torinir, Kilowattradio, Xgoat, Jengelh, JayCarlson, Yyy, Shaddack, Wiki alf, Rei-artur, Scott Stirling, Assjack, SixSix, Jeh, Kewp, Slicing,
Whitejay251, Zzuuzz, Ninly, Closedmouth, Haymaker, Ianb1469, Cabe6403, Thumperward, Maxsonbd, Decemberster, Snowmanradio,
DMacks, Luigi.a.cruz, Feraudyh, 16@r, My Wikipedia, KurtRaschke, Kvng, Hu12, Hetar, Radiant chains, Robinhw, CmdrObot, 3rik,
Jesse Viviano, HenkeB, Johnlogic, MrFish, Rhe br, Thijs!bot, DSLeB, Saruwine, Wiki fanatic, Electron9, TheJosh, Andrew sh, Wik-
ijimmy, Druiloor, Fabulatech, AntiVandalBot, Adrzip, Myanw, VoABot II, Dulciana, Wderousse, Hdt83, Axlq, APT, Jim.henderson,
J.delanoy, V8Cougar, Guyzero, Nikhilgupta2020, JayC, Clarince63, Dkgdkg, Andy Dingley, SieBot, Coee, Chimin 07, Lightmouse,
ClueBot, Binksternet, Aaa3-other, Gavron, Ridge Runner, Thejoshwolfe, Sv1xv, Pklala, Orangebodhi, Walkingstick3, Thingg, Mac128,
Theo177, XLinkBot, Sandeepgupta26, Dsimic, Addbot, Mortense, Ghettoblaster, Tothwolf, Scientus, MrOllie, MrVanBot, CarsracBot,
RWDutton, Lightbot, Sergioledesma, Luckas Blade, Sergiej87, Wonder, Thaiio, Tempodivalse, Koman90, 1exec1, IRP, brahimbarbaros,
Photographerguy, Mywifeandkids, ArthurBot, Kajaco2, Capricorn42, Bellerophon, Shadowjams, Motsjo, Tongtang, Glider87, Mfwitten,
VipX1, Zeptozoid, Andrew kir, DASHBot, John of Reading, Akhilan, Mayur, Peter Karlsen, Rmashhadi, ClueBot NG, Jaanus.kalde,
Giobe2000, Wbm1058, Gauravsangwan, Vanangamudiyan, Abracus, Kokkkikumar, Insidiae, ChrisGualtieri, P-Worm, Spinlock55, Blue-
turtle79, RationalBlasphemist and Anonymous: 242
RS-485 Source: http://en.wikipedia.org/wiki/RS-485?oldid=630523398 Contributors: Smack, Arteitle, Royce, Radiojon, UtherSRG,
Giftlite, DavidCary, Fleminra, Funvill, MementoVivere, Mjuarez, CanisRufus, Femto, Frodet, M7, Lectonar, Wdfarmer, Marianoce-
cowski, Velella, Wtshymanski, Gene Nygaard, Isnow, LinkTiger, FlaBot, Homo stannous, Chobot, Bgwhite, Roboto de Ajvol, Wavelength,
DMahalko, Armistej, Chris Capoccia, Shaddack, RussNelson, Voidxor, Zwobot, Jeh, Deville, Jzap, Back ache, Kevin, Nelson50, Viper-
Snake151, SmackBot, Commander Keane bot, Elronxenu, Charlierichmond, Sfxtd, Chris the speller, Bluebot, EncMstr, MaxSem, Frap,
AlexBadea, Adamarthurryan, Littleman TAMU, SlayerK, Dicklyon, Petr Matas, Ronaldvd, CmdrObot, Wsmarz, Gogo Dodo, Alaibot,
Mtpaley, Electron9, Andrew sh, Tom dl, JAnDbot, The Tarnz, SEREGA784, Rhdv, MagicBobert, Dbrunner, J.delanoy, Molly-in-md,
STBotD, Deor, VolkovBot, Intchanter, Gri6507, Jhawkinson, Biscuittin, Ronaldesmith, Fahidka, OsamaBinLogin, Lightmouse, Fratrep,
Frappucino, CiudadanoGlobal, Foxj, Jacques.boudreau, Arjayay, Dekisugi, Jonverve, Joel Saks, XLinkBot, Addbot, Mortense, Cst17,
Download, Lightbot, Vanuan, Yobot, Nallimbot, Birdy1982, AnomieBOT, 4k05, Kristen Eriksen, Pyrrhus16, JoshuaJohnston, LilHelpa,
Helothm, Lionblue, Bon21, GrouchoBot, Kyng, I2so4, Thaas00, Teuxe, Trappist the monk, Thrownshadows, ZroBot, Wagner, Free-
toseetheworld, Electron18, Dmlmax, RonWessels, Stndle, ClueBot NG, Cybercluster, Nagilum15, Hmpeople, , EE JRW, 331dot and
Anonymous: 149
RS-422 Source: http://en.wikipedia.org/wiki/RS-422?oldid=627677400 Contributors: SimonP, CesarB, Hpa, Dysprosia, David Gerard,
Giftlite, Markus Kuhn, Mboverload, Bobblewik, Skarg, Xezbeth, CanisRufus, Femto, M7, Denniss, Wtshymanski, Garzo, Bsadowski1,
Isnow, Mandarax, Yuriybrisk, Haikupoet, Brolin Empey, Rjwilmsi, FlaBot, BjKa, Chobot, YurikBot, Shaddack, Tony1, Nelson50,
Linkminer, SmackBot, Unyoyega, Bluebot, Jerome Charles Potts, Hongooi, Ged UK, J Crow, Iridescent, Robinhw, CmdrObot, Anthony
108 CHAPTER 21. PROFINET
Bradbury, Joeyhagedorn, Reportingsjr, Andrew sh, DirkHelgemo, J Clear, Sciams, Robijn, Dorftrottel, VolkovBot, Triesault, Kbrose,
SieBot, Ronaldesmith, This, that and the other, Crm123, Fahidka, Jonverve, Addbot, Lightbot, Yobot, Fightin' Phillie, GrouchoBot, Fp-
sasm, Thehelpfulbot, Thaas00, WikitanvirBot, MaGa, Ksliech, DieSwartzPunkt, Martyhascak, JordoCo, Paulino 2 and Anonymous: 53
Probus Source: http://en.wikipedia.org/wiki/Profibus?oldid=626457071 Contributors: AxelBoldt, Kku, Zanimum, Texture, Auric,
Giftlite, Micru, Harriv, Smalljim, Giraedata, Wtshymanski, Versageek, FlaBot, PlatypeanArchcow, YurikBot, Gaius Cornelius, Ra-
zorICE, Rwwww, SmackBot, Eskimbot, Zeruski, Bluebot, JonHarder, Alca Isilon, Plcsys, Morten, Dicklyon, Plutix, Amalas, Cyde-
bot, Alaibot, Kozuch, Ebyabe, Thijs!bot, Electron9, Dougher, Claudia1220, EdBever, Lordeaswar, ABF, Langerwolfgang, Krushia,
SieBot, Abriwrite, Fahidka, ClueBot, Christian1969, Wolfch, Carpacho, Estirabot, SoxBot III, DumZiBoT, PNOAvE, Addbot, Laaknor-
Bot, Luckas-bot, Fizzbann1234, TheAMmollusc, Xetheriel, Creativesoul8, Nasa-verve, FrescoBot, Jkeck-wiki, EmausBot, Tarbarrels,
MereNonsense, Northamerica1000, Naarbarry, Nukerebel, ChrisGualtieri, GoShow, Faizan, Tc.guho and Anonymous: 86
Fieldbus Source: http://en.wikipedia.org/wiki/Fieldbus?oldid=628890233 Contributors: Heron, Rl, Robbot, Texture, DavidCary, Jason
Quinn, Mboverload, Alexf, Beland, Spalding, Makomk, Giraedata, Kundor, Geschichte, Grutness, Suruena, Notan Frag, Tabletop,
Grika, BD2412, Rjwilmsi, Vegaswikian, Ground Zero, BjKa, YurikBot, Mikeblas, Youngkalam, Rwwww, Attilios, SmackBot, Dickcaro,
Royalguard11, Zeruski, HeavyD14, JonHarder, Zvar, Fuhghettaboutit, Finejon, Euchiasmus, Thiagoeh, TastyPoutine, Kvng, ChrisCork,
Cydebot, Pais, Jono4174, Mattisse, Thijs!bot, Electron9, JustAGal, Crackerjackal, Eng101, Arch dude, DickCaro, Billywhack, Magiola-
ditis, Ishi Gustaedr, Paulpw, User A1, MartinBot, Rpclod, J.delanoy, Lee Vonce, Zakholdsworth, Acalamari, Oliverkywu, Joaoborges, S,
Mlewis000, Langerwolfgang, Gri6507, Kramer-Wolf, Brolin, Fieldbus, Regregex, SCH56, Aussiecontrols, Euryalus, BotMultichill, Pe-
dro.haruo, Cialo, Foggy Morning, ClueBot, Christian1969, Lorenzbe, Wolfch, SuperHamster, Michbeie, Mojtaba Cazi, ResidueOfDesign,
Lobrien29, IamNotU, BOTarate, El bot de la dieta, Wdustbuster, Adacore, Addbot, Mortense, Ronhjones, MrOllie, Luckas-bot, Yobot,
CBMalloch, Mrazmara, Phd0, ArthurBot, Xqbot, Nasa-verve, Chemical Processing, Homagrani, FrescoBot, PigFlu Oink, Diego Grez
Bot, Fieldbus man, DASHBotAV, ClueBot NG, AlfredoMQuintero, BG19bot, Martinzou, RAPIEnet, Meatsgains, Elky7, ChrisGualtieri,
Dexbot, Tc.guho, Monkbot, Dkkarthi, Deepakrichrad and Anonymous: 105
CAN bus Source: http://en.wikipedia.org/wiki/CAN_bus?oldid=631596587 Contributors: Heron, PhilipMW, Michael Hardy, Nixdorf,
SGBailey, Ee79, Egil, Ahoerstemeier, Ronz, , CAkira, Colin Marquardt, Sertrel, Selket, Natevw, Finlay McWalter, Jni, Robbot,
Pingveno, Akadruid, Zigger, Fleminra, Niteowlneils, Aechols, Bobblewik, Chrisbolt, Vsmith, Gejigeji, Agl, Harriv, CanisRufus, Meesta-
plu, Mpeg4codec, Enric Naval, Nsaa, Tpikonen, Guy Harris, Hopp, Corwin8, Wdfarmer, Cburnett, Suruena, Amorymeltzer, Versageek,
Kinema, Woohookitty, Robert K S, Slgrandson, MC MasterChef, Pentawing, Vegaswikian, Allen Moore, FlaBot, Jidan, Benlisquare,
YurikBot, Deeptrivia, RussBot, Armistej, Shaddack, Grafen, Joel7687, Tony1, Vanished user 34958, StealthFox, Dpotop, Attilios, Smack-
Bot, Sagie, Marco Guardigli, KnowledgeOfSelf, Sam8, SethML, Bluebot, EncMstr, MaxSem, Bsilverthorn, Eliyahu S, JonHarder, Idonra,
BIL, Kingdon, Drunken Pirate, Khazar, IronGargoyle, Dicklyon, Ft1, TastyPoutine, Russella, Kris iyer, Kvng, MisterTS, Wleizero, Dmorr,
JohnCD, Quibik, Optimist on the run, Thijs!bot, JacobBramley, Electron9, Mdem, Iviney, Philippe, MStock, Stannered, AntiVandalBot,
Hidayat ullah, Ramtam, Skomorokh, IanOsgood, Wikipedia tang, Phosphoricx, Xoneca, Jredders, Benburleson, Nyq, TheAllSeeingEye,
Albramallo, Gabriel Kielland, DerHexer, Calltech, MartinBot, STBot, Axlq, AGlossop, Stobor827, Katharineamy, Plupp01, Patpou77,
JuergenKlueser, Inwind, Trailprice, TFolsom, AlnoktaBOT, Langerwolfgang, Rocketmagnet, Nono le petit robot, Fxhomie, Qxz, Inv-
ernizzi.l, Andy Dingley, Kramer-Wolf, Thunderbird2, SieBot, Accounting4Taste, Fahidka, Mc cappy, Radartooth, Alex.muller, OKBot,
Pikamander2, Treekids, Denisarona, Asher196, Zer0431, SlackerMom, ClueBot, Wolfch, TinyMark, SuperHamster, Simon04, Laksh-
mank85, Alexbot, Tyler, Arjayay, Vendeka, IamNotU, Ajn1, Rvoorhees, Johnny.cespedes, Automotive joe, Andre maier, Ponchobonjo,
Addbot, Meise, Mortense, Yoenit, Thomas888b, GyroMagician, Scientus, MrOllie, Lightbot, Xylome, Luckas-bot, Yobot, D rock naut,
Thaiio, AnomieBOT, Hondrej, Xqbot, Notyetinspace, Marcelosr, Nasa-verve, Ondrejandrej, RibotBOT, Reply123, Alexandreag, Ana-
paulasag, SD5, Depictionimage, FrescoBot, Miceduan, Hobsonlane, Plindemann, D'ohBot, Biker Biker, Triplestop, Jschnur, Betsytimmer,
RedBot, Plasticspork, Kdub432, RolfBly, Deagle AP, DASHBot, Thebigandroid, EmausBot, John of Reading, GoingBatty, Gregmelson,
ZroBot, Wikfr, Sbmeirow, Nyarcel, MarkO555, Leeraphael, Rocketrod1960, Rotmat, ClueBot NG, Rcpinto, Millermk, Widr, 2001:db8,
BG19bot, Erniotti, Piguy101, Juggers2k, Hmpeople, BattyBot, Tayaq, Aaron Nitro Danielson, John fromIdegon, AbuJazar, EE JRW, Mar-
ius siuram, Waheed446, Passengerpigeon, Epicgenius, DAALIYA, Catverine, Tc.guho, Liptakokgabora, Nyashinski, Lagoset, Shanpali8,
Levai.peter, Ncooper.csm and Anonymous: 375
Ethernet Source: http://en.wikipedia.org/wiki/Ethernet?oldid=631450983 Contributors: Damian Yerrick, Mav, The Anome, Amillar,
Dachshund, JeLuF, Aldie, PierreAbbat, Paul, Maury Markowitz, Heron, B4hand, Branko, Roybadami, Tedernst, JohnOwens, Michael
Hardy, Norm, Mahjongg, Nixdorf, Minesweeper, CamTarn, CesarB, Egil, Ahoerstemeier, Haakon, Angela, Setu, Salsa Shark, Glenn,
Cstanners, Harvester, Schneelocke, Ehn, Crissov, Wikiborg, Oakad, Colin Marquardt, The quark, Wik, Zoicon5, Judzillah, Tpbradbury,
Mrand, Furrykef, Itai, Khalad, Thue, Indefatigable, Cluth, Lumos3, Phil Boswell, TimBovee, Robbot, Chealer, Sander123, TomPhil, Ton-
sofpcs, Jakohn, Fredrik, Boy b, Scott McNay, RedWolf, Modulatum, Rholton, Steeev, Hadal, Chaosgate, ElBenevolente, Blutrot, Alan
Liefting, Giftlite, DocWatson42, Laudaka, Fudoreaper, Karn, Peruvianllama, Everyking, Carlo.Ierna, Jason Quinn, AlistairMcMillan,
Alvestrand, Bobblewik, Wmahan, Chowbok, Pgan002, Mendel, Ebear422, CryptoDerk, OverlordQ, WhiteDragon, Quarl, MacGyver-
Magic, Bumm13, Mozzerati, Sam Hocevar, Rlcantwell, Biot, Tooki, Creidieki, Joyous!, Ukexpat, Vijaykumar, Now3d, Chmod007, Ab-
dull, Adashiel, Moxfyre, EagleOne, Generica, Corti, Mike Rosoft, Frankchn, Urvabara, Econrad, Discospinster, Rich Farmbrough, Rhobite,
Pmsyyz, Wk muriithi, ArnoldReinhold, Wefa, Irq, Nvj, Kbh3rd, Goplat, Limbo socrates, Plugwash, Sharkford, Oneocean, Kwamikagami,
Mwanner, Pilatus, Tverbeek, Shanes, Sietse Snel, Dennis Brown, Bookofjude, Rufus210, Femto, Vdm, Flxmghvgvk, Cmdrjameson, Ricsi,
Kjkolb, Digitalsushi, HCelik, Wrs1864, Helix84, Xenium, Nsaa, Wayfarer, ClementSeveillac, Knucmo2, Jumbuck, Alansohn, Nroets,
Guy Harris, Corwin8, RoySmith, Sligocki, Wtshymanski, Rick Sidwell, Cburnett, Stephan Leeds, Suruena, Dtcdthingy, NJM, CloudNine,
Boscobiscotti, Matt.farina, Algocu, Kinema, Adrian.benko, Dennis Bratland, Kbolino, Tunnie, Firsfron, Vashti, OwenX, Woohookitty,
Mindmatrix, RHaworth, Tyz, Percy Snoodle, Steven Luo, Armando, Ruud Koot, WadeSimMiser, Jhartmann, Alecv, Drak2, Andybryant,
Marudubshinki, Graham87, Bilbo1507, BD2412, Jemichel, Casey Abell, Rjwilmsi, Tizio, Isaac Rabinovitch, Johnblade, Bruce1ee, Hap-
pyCamper, Ligulem, Mbutts, ScottJ, Mikm, Hungrymouse, Fred Bradstadt, Aapo Laitinen, Utuado, Lotu, JamesEG, Silenceisfoo, FlaBot,
Ewlyahoocom, Intgr, Fresheneesz, TheMoog, King of Hearts, Guanxi, Chobot, Tas50, DVdm, 121a0012, WriterHound, Vmenkov, Yurik-
Bot, Wavelength, Sceptre, Charles Gaudette, Michael Slone, Jtkiefer, RadioFan, Stephenb, Yyy, Lavenderbunny, Rsrikanth05, Ibc111,
Bovineone, Markjx, Wimt, NawlinWiki, Vanished user kjdioejh329io3rksdkj, Gosub, DavidH, Dogcow, Leotohill, Bota47, Yudiweb,
Bdmcmahon, Closedmouth, Iambk, KGasso, LordJumper, Back ache, QmunkE, Nelson50, Davehard, David Biddulph, Rwwww, Grin-
Bot, Selmo, Veinor, SmackBot, FocalPoint, Zhangyue, Unschool, Brian Patrie, Reedy, KnowledgeOfSelf, McGeddon, Unyoyega, Praetor
alpha, Betbest1, WillAndrews, Bomac, KocjoBot, Fulldecent, Pkirlin, Monz, KelleyCook, BiT, Mhare, Eloil, Gilliam, Ohnoitsjamie, Be-
tacommand, Skizzik, K45671, El Cubano, Fetofs, Stuart P. Bentley, Amatulic, Lovecz, KaragouniS, DHN-bot, Can't sleep, clown will eat
me, Frap, Vidmes, JonHarder, SundarBot, UU, Cybercobra, Martijn Hoekstra, Akriasas, Drphilharmonic, Bidabadi, Zac67, Ohconfucius,
Evert Mouw, Pjbrockmann, ThurnerRupert, The undertow, Spiritia, SashatoBot, Anss123, Nishkid64, Zero10one, Kuru, Rait, Evil genius,
21.12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES 109
DavidBailey, Gobonobo, Ksn, Minna Sora no Shita, JohnWittle, N TRoPY, Eivind F yangen, Jec, Hvn0413, Aeluwas, Dicklyon, Arkr-
ishna, Lped999, Peyre, Kvng, Lee Carre, Iridescent, Paul Koning, Kate.woodcroft, Igoldste, Finest1, Tawkerbot2, Ghaly, MightyWarrior,
Hobophobe, CRGreathouse, CmdrObot, Ale jrb, Causantin, Makeemlighter, Requestion, MrFish, Danrok, Mblumber, UncleBubba, Gogo
Dodo, Wa2ise, BlueAg09, Corpx, Chasingsol, Tawkerbot4, Juansempere, SpamBilly, Ameliorate!, Branclem, Viridae, Trev M, Epbr123,
Daa89563, RichardBennett, Electron9, Fenrisulfr, Wmasterj, Wikifranz, Solveforce, Eleuther, Yuvalnod, Luna Santin, Quintote, Prolog,
Bbachrac, Azaghal of Belegost, Peck123, Dcorzine, Spencer, Myanw, Golgofrinchian, Bigjimr, JAnDbot, Deective, Harryzilber, MER-C,
Nthep, Wootery, Arch dude, John a s, TAnthony, Kerotan, Greylion, LittleOldMe, Nicolaasuni, Enjoi4586, Andreas Toth, Magioladitis,
Ramurf, JamesBWatson, SHCarter, Kakomu, Willy on Wheels over Ethernet, Nyttend, Nikevich, Recurring dreams, CS46, Catgut, Elin-
ruby, Cpl Syx, Dharmadhyaksha, Kgeischmann, Calltech, 0612, Lockg, Hdt83, MartinBot, BetBot, ARC Gritt, Jim.henderson, Rettetast,
Keith D, Pekaje, Gah4, Artaxiad, J.delanoy, Trusilver, MoussePad, Grandsonofmaaden, Andareed, Plasticup, GTAKIllerEric, NewEng-
landYankee, Juliancolton, Useight, Alyssapvr, Melvinvon, VolkovBot, Mrh30, Leebo, VasilievVV, Philip Trueman, TXiKiBoT, Wingnu-
tamj, Rednectar.chris, Jackfork, BotKung, Milan Kerlger, Iamzemasterraf, Andy Dingley, Lamro, Altermike, Turgan, LittleBenW, Nigh-
traider0, Hughey, Kbrose, The Random Editor, SieBot, Nubiatech, Caltas, Yintan, Angusmca, 4a6f656c, Flyer22, Herberthuber, Cjdaniel,
Oxymoron83, Gopher23, Lightmouse, Fratrep, Engineerism, Gyanlakhwani, Svick, Rapaporta, Xnatedawgx, Tiny plastic Grey Knight,
C0nanPayne, Martarius, ClueBot, Bootleggingly mcbootleg, The Thing That Should Not Be, H0serdude, EoGuy, Nnemo, Mightyms, Ex-
cirial, Eeekster, Thingg, 7, Versus22, Sobelbob, Johnuniq, SoxBot III, SF007, Diskdoc, Stickee, Rror, Pgallert, Kevmcs, Facts707, Zodon,
1stJahman, Dsimic, Kbdankbot, Bookbrad, Addbot, Applemacintosh10, Mortense, DOI bot, Gnalk, Tothwolf, EjsBot, Amore proprio,
Fieldday-sunday, CanadianLinuxUser, Cst17, MrOllie, Download, SoSaysChappy, Swapdisk, LinkFA-Bot, Manish soni, Tide rolls, Atom-
Edge, Lightbot, Avono, Mmiszka, Legobot, Publicly Visible, Luckas-bot, Yobot, Crispmuncher, Peter Flass, Tempodivalse, AnomieBOT,
Bctwriter, EEgirl18, Efa, Jim1138, NeaNita, Royote, Gascreed, Piano non troppo, Shieldforyoureyes, AdjustShift, Tom87020, Wasisnt,
Ulric1313, Flewis, Citation bot, Aneah, Packetslinger, LilHelpa, Idkyididthis, Capricorn42, J04n, Stratocracy, Jangirke, Shadowjams,
WaysToEscape, Gnuish, FrescoBot, Transmission 1000, Lukith, W Nowicki, Thaas00, Itusg15q4user, Geek2003, Typo47, ZenerV, Kwiki,
SeaChanger, Citation bot 1, Gekkoblaster, Lallolu, Biker Biker, Jschnur, Btilm, TobeBot, Rarmy, Sincoskie, WikiJaZon, Carminowe of
Hendra, Grgan, RjwilmsiBot, Rw4nd4, Andyhodapp, Becritical, DASHBot, Ajraddatz, Joseph507357, RA0808, Michael Thomas Sul-
livan, Wbenton, Palmer1973, Solarra, Swarnabhra, Wikipelli, 1lovegal, ZroBot, Hussein 95, Elektrik Shoos, Davidch12, G4wsz, Mes-
siFCB, DASHBotAV, 28bot, Petrb, ClueBot NG, Nimiew, Donnieleefarrow, Manubot, Satellizer, Buy P%E%P%S%I, Bigboymcgee, Will-
Lord, Pluma, Helpful Pixie Bot, Johnnyboyshoots, HMSSolent, Wbm1058, DarkSlayer516, Northamerica1000, Metaprinter, Test35965,
PinkMonkeys, Glacialfox, Lolpack, Mavieira, BattyBot, Wattlesmorse, Tmontalv, DarafshBot, ChrisGualtieri, Jags707, Dexbot, Kasabax,
Frosty, Graphium, Faizan, DBhavsar709, Oztuck, Bakerdaft, Tankman98, Someones Moving Castle, Semsi Paco Virchow, Pcpded, Im-
ran771, Jmars180, Monkbot, Thetrollface5, MoLtO95, YOOOOOOOOLO, Unician, The Last Arietta and Anonymous: 739
Ethernet physical layer Source: http://en.wikipedia.org/wiki/Ethernet_physical_layer?oldid=628574601 Contributors: Leandrod, Conti,
Mrand, Giftlite, Antandrus, Guy Harris, Rd232, Stephan Leeds, RJFJR, Boscobiscotti, Woohookitty, Armando, MarcoTolo, Rjwilmsi,
DougBurbidge, Mancini, Intgr, Lmatt, Celebere, Rosenbluh, Petri Krohn, SmackBot, Sam8, KelleyCook, Thumperward, Adamantios,
Radagast83, Zac67, Gobonobo, Bezenek, The emm, Kvng, Lee Carre, Electron9, Alphachimpbot, Slidersv, SolarWind, Arch dude, VoABot
II, Think outside the box, JaGa, GermanX, Bobby the Lordd, Mange01, Peter Chastain, Peppergrower, Philip Trueman, Gareth8118,
Mikachu42, Neophyrigian, Nitrooreo, Fahidka, Masgatotkaca, Editore99, Engineerism, ImageRemovalBot, Martarius, ClueBot, Iandiver,
PolarYukon, Sun Creator, Rswarbrick, Addbot, Tothwolf, Sawao, Jekader, Yobot, Jordsan, Crispmuncher, AnomieBOT, HistPhd, Grou-
choBot, FaTony, W Nowicki, StandardsNettle, Btilm, Conachlmrs09, Miracle Pen, RjwilmsiBot, Alph Bot, Dewritech, Wbenton, Mikhail
Ryazanov, ClueBot NG, 336, Like Budda, BattyBot, Aeroid and Anonymous: 48
Ethernet frame Source: http://en.wikipedia.org/wiki/Ethernet_frame?oldid=631435880 Contributors: Glenn, Buchs, M1ss1ontomars2k4,
Xezbeth, Guy Harris, DeadlyAssassin, Salix alba, FlaBot, Intgr, Jijithecat, Hawaiian717, Pburka, Myjkccd, SmackBot, Grawity,
Torzsmokus, Zac67, Kvng, Alexh19740110, Christian75, Kubanczyk, Electron9, K7aay, Magioladitis, Bostonvaulter, Mange01, Jack-
fork, Tomaxer, Behind The Wall Of Sleep, Bananastalktome, EoGuy, Kendo70133, Tchai, Dsimic, Addbot, Gyro Copter, AnomieBOT,
QueBurro, Quinn d, W Nowicki, Systemparadox, Renepick, Staaki, Dewritech, Mayur, ClueBot NG, Jiemingwei, Helpful Pixie Bot,
BG19bot, Ocdex, Shashiskills, Writ Keeper, Yemisilin, Wjwatson67, ChrisGualtieri, SFK2, I340793, Faizan, Dancysoft, MortenZdk,
Nogupry, Nchangfong, Isaacchua, ValliusDax and Anonymous: 87
Autonegotiation Source: http://en.wikipedia.org/wiki/Autonegotiation?oldid=618203274 Contributors: Indefatigable, Andrewjrallan, Al-
istair1978, Plugwash, Boscobiscotti, Ceyockey, Graham87, Rjwilmsi, Tizio, Ctempleton3, FlaBot, DarkPhoenix, Retired username, Alpha
4615, JLaTondre, SmackBot, Arny, KelleyCook, Humble226, Bluebot, Oli Filth, Zac67, Soumyasch, Arkrishna, Kvng, Bmcdonou, Cm-
drObot, UncleBubba, Electron9, EdwinGroothuis, MER-C, Appraiser, Dweingart, Perfgeek, Editore99, Vdcappel, Complicated1, Addbot,
Amore proprio, Favonian, Ettrig, Ptbotgourou, TaBOT-zerem, Scallop7, DSisyphBot, W Nowicki, 4essdee, Yacz, BG19bot, 0x41726c6f
and Anonymous: 45
Internet protocol suite Source: http://en.wikipedia.org/wiki/Internet_protocol_suite?oldid=631633348 Contributors: Damian Yerrick,
AxelBoldt, Tobias Hoevekamp, Matthew Woodcraft, Brion VIBBER, Mav, Zundark, The Anome, Tarquin, Koyaanis Qatsi, Etu, Gsl,
XJaM, Aldie, Matusz, Paul, William Avery, Shii, Imran, B4hand, Mintguy, Branko, Nknight, Edward, Nealmcb, Michael Hardy, Nixdorf,
Ixfd64, Paul A, Ellywa, Ahoerstemeier, Haakon, Ronz, Typhoon, Theresa knott, Glenn, IMSoP, Palfrey, Arteitle, Edmilne, Timwi, Do-
radus, Zoicon5, Kaare, Saltine, Itai, Nv8200p, Jnc, Ed g2s, Shizhao, Topbanana, Betterworld, Bloodshedder, Olathe, Robbot, TomPhil,
Yas, RedWolf, Sunray, Hadal, Pps, Miles, Carnildo, Smjg, Kim Bruning, Wolfkeeper, Ferkelparade, Zigger, Marcika, Rick Block, Nite-
owlneils, AlistairMcMillan, SWAdair, Tagishsimon, Golbez, Mendel, Beland, Dnas, Zfr, Biot, Daniel Staal, Chadernook, Ukexpat, Abdull,
Zondor, EagleOne, RevRagnarok, Mike Rosoft, Ta bu shi da yu, DanielCD, JTN, Rich Farmbrough, JesterXXV, DerekLaw, Dmeranda,
Jackqu7, Bender235, Tr606, Plugwash, Violetriga, STHayden, Joanjoc, Jantangring, Sietse Snel, Coolcaesar, John Vandenberg, Xojo,
Obradovic Goran, Wrs1864, Helix84, Krellis, Martyman, PioM, Mrzaius, Alansohn, Sully, Arcenciel, Duman, Guy Harris, Nealcardwell,
Darkhalfactf, Hoary, Kocio, Snowolf, Here, Rick Sidwell, Cburnett, Stephan Leeds, Suruena, Evil Monkey, Fixman88, RaNo, Kusma,
Freyr, Mattbrundage, Ericl234, MilesMi, Ramnath R Iyer, GaelicWizard, Woohookitty, Camw, Ilario, ^demon, Wikiklrsc, Eyreland,
Mckoss, Pfalstad, Leapfrog314, Mandarax, Runis57, Graham87, Magister Mathematicae, Casey Abell, Jorunn, Sjakkalle, Rjwilmsi, KY-
Park, Johnblade, Weregeek, Xos, Vegaswikian, Aapo Laitinen, Yamamoto Ichiro, Sheldrake, RobertG, Nivix, Aliasptr, Cheesycow5,
Otets, Intgr, Bmicomp, Chobot, DVdm, Bgwhite, SuperWiki, Albanaco, Wavelength, Hairy Dude, Jimp, Mukkakukaku, Hyad, Bhavin,
Stephenb, Manop, Cate, Rsrikanth05, Wimt, NawlinWiki, Barberio, Expensivehat, Dogcow, CecilWard, Layer, Nick C, Tony1, Zwobot,
Falcon9x5, Yudiweb, Tim Watson, Robost, Phgao, Maltest, Kevin, Katieh5584, Snaxe920, Eptin, Finell, That Guy, From That Show!,
Luk, Yakudza, Erik Sandberg, SmackBot, Paulkramer, KnowledgeOfSelf, Rayward, Unyoyega, MeiStone, Thunderboltz, Elwood j blues,
Ruthherrin, Canthusus, Bernard Franois, Gilliam, Locketine, Bluebot, Geneb1955, Jprg1966, Thumperward, EncMstr, Kungming2, Sp-
mion, Rrelf, Vanis314, JonHarder, Gringo.ch, Wonderstruck, Radagast83, Cybercobra, Richardwhiuk, Kasperd, HarisM, Drphilharmonic,
110 CHAPTER 21. PROFINET
James Mohr, Victor Liu, Reliablesources, Rodeosmurf, T, Nasz, Tmchk, Ana Couto, Doug Bell, Nhorton, Disavian, Breno, Hpnguyen83,
Bezenek, CaptainVindaloo, Ckatz, Dicklyon, Kim Rubin, Waggers, Avant Guard, Rserpool, Kvng, Lee Carre, Paul Koning, Fr34k, Matt
Dunn, Tawkerbot2, Brian.fsm, CmdrObot, Imcdnzl, Oheckmann, NE Ent, RobEby, Whereizben, Nmacu, Equendil, Cydebot, Peripi-
tus, Krauss, Acceptus, Swhitehead, Indeterminate, Roberta F., DumbBOT, NMChico24, Thijs!bot, Epbr123, Wikid77, Hcberkowitz,
Headbomb, Electron9, JustAGal, Ekashp, Perfectpasta, Xeesh, Mentisto, AntiVandalBot, Konman72, Luna Santin, Widefox, Seaphoto,
Smartse, Labongo, Storkk, JAnDbot, Harryzilber, Mwarren us, Holylampposts, Acroterion, Enjoi4586, Magioladitis, Parsecboy, VoABot
II, AuburnPilot, JamesBWatson, Swpb, Tedickey, AliMaghrebi, Jatkins, Rich257, Jrogern, Avicennasis, Edwardando, Logictheo, Tech-
pro30, Papadopa, Inhumandecency, Falcor84, Techmonk, GordonMcKinney, MartinBot, Flexdream, BetBot, R'n'B, TinaSDCE, J.delanoy,
Pharaoh of the Wizards, Mange01, Public Menace, Skullketon, AntiSpamBot, NewEnglandYankee, SJP, Shiraun, Inomyabcs, Ross Fraser,
Ale2006, Funandtrvl, Meiskam, VolkovBot, TheOtherJesse, Metaclassing, Philip Trueman, TXiKiBoT, Walor, Leekil, Donjrude, Anna
Lincoln, Abdullais4u, Navedahmed123, Lova Falk, Larree, Alireza.usa, EmxBot, Kbrose, CrinklyCrunk, Thw1309, SieBot, Ethanthej,
Nubiatech, Yintan, Mothmolevna, Bentogoa, Martyvis, EnOreg, Oxymoron83, Ydalal, Tmaufer, DavidDW, BenoniBot, Ngrieth, Svick,
Denisarona, Sitush, Elassint, ClueBot, Zeerak88, Axcess, The Thing That Should Not Be, Rjd0060, Quinxorin, Alek Baka, CounterVandal-
ismBot, Patilravi1985, Mzje, DragonBot, Jusdafax, Anon lynx, Wiki104, Eeekster, Zac439, Tyler, Shiro jdn, Cynthia Rhoads, Dorgan65,
Thingg, Johnuniq, Punjabi101, Dgtsyb, Thatguyint, Addbot, Atethnekos, Jncraton, Coasting, Jmdavid1789, Glane23, Amungale, Favo-
nian, West.andrew.g, Tassedethe, Tide rolls, Lightbot, Avono, Globemasterthree, SasiSasi, Legobot, Luckas-bot, Yobot, TaBOT-zerem,
Fmrauch, ArchonMagnus, Wadamja, AnomieBOT, Rubinbot, Jim1138, Piano non troppo, Law, Materialscientist, OttoTheFish, Citation
bot, Aneah, Merlissimo, Xqbot, TinucherianBot II, Oxwil, Karlos77, RibotBOT, SassoBot, Kyng, , JediMaster362, Ctm314,
Master Conjurer, FrescoBot, Weyesr1, ZNott, Kkj11210, Jonathansuh, Barnacle157, Citation bot 1, Pokeywiz, I dream of horses, HRoest-
Bot, A8UDI, Weylinp, Yunshui, Renepick, Reaper Eternal, ArticCynda, Suusion of Yellow, SnoFox, Sideways713, DARTH SIDIOUS
2, EmausBot, Clark42, Solarra, P. S. F. Freitas, Hasty001, StanQuayle, Anororn, The Nut, Samjoopin, A930913, Aeonx, Cf. Hay, Staszek
Lem, W163, GeorgeBarnick, Stefan Milosevski, Putdust, Jsoon eu, DASHBotAV, 28bot, ClueBot NG, Mechanical digger, GlobalEdge
2010, Stahla92, Widr, HMSSolent, Northamerica1000, AvocatoBot, Zvezda1111, Winston Chuen-Shih Yang, Tutelary, Rbhagat0, APer-
son, Indinkgo, Lugia2453, Dave Braunschweig, DBhavsar709, Epicgenius, Red-eyed demon, Rickh1219rh, PenlroINFS315, Hawkins88,
No3mann, Dingdong44, Abhijith anil, B Rowanz, Haosjaboeces, Akin DSA, MattQuarneri, Zaraman, Mehnames and Anonymous: 674
IPv4 Source: http://en.wikipedia.org/wiki/IPv4?oldid=631370290 Contributors: General Wesc, The Anome, Arcade, Paul, Formulax,
Nealmcb, Karada, CesarB, Angela, Magnus.de, Kaal, Jnc, Ed g2s, Shizhao, Garo, Robbot, Noldoaran, Fredrik, Faco, Mushroom, Pengo,
SmilingBoy, Giftlite, DocWatson42, Brouhaha, DavidCary, Presto8, Rchandra, AlistairMcMillan, Nathan Hamblen, Kasperl, Dnas, Robert
Brockway, CaribDigita, Dmaftei, Zfr, Daniel Staal, Cynical, Ojw, Abdull, RevRagnarok, Corti, Mike Rosoft, Imroy, JTN, Shane kerr,
Alexkon, Plugwash, Johnh, Theinfo, El C, Kwamikagami, Spearhead, Mochi, Johnteslade, Cwolfsheep, SpeedyGonsales, Barro, Zetawoof,
Wrs1864, Krellis, Pratikarun, HasharBot, PaulHanson, Duman, RoySmith, DreamGuy, Themonstergila, Markrod, Carlo.arenas, Cbur-
nett, Stephan Leeds, Suruena, Adrian.benko, Woohookitty, Mindmatrix, Armando, Ilario, Scjessey, ^demon, Dotshuai, Liface, Graham87,
Taestell, Rpwoodbu, RxS, Pmj, Rjwilmsi, Ekspiulo, Fred Bradstadt, Bmpercy, Undeference, RexNL, Fresheneesz, Kickboy, Chobot, Wave-
length, Borgx, Hairy Dude, Tyler.szabo, AlanR, Phorque, Yyy, Rsrikanth05, Sarafankit, CecilWard, Ranto, Graciella, Calcwatch, Thnidu,
Chrishmt0423, Smurrayinchester, Katieh5584, SmackBot, Wolfsbane2k, Muks, Zanetu, Nil Einne, Gilliam, Parkamark, StrangerInPar-
adise, Omniplex, DHN-bot, Onceler, Christan80, Parent5446, UU, Xibe, A.R., Phoenix314, ILike2BeAnonymous, Daniel.Cardenas, Lph,
ArglebargleIV, Miss Sa, Molerat, Swellesley, Breno, Coredesat, Rblhjm, Peterhoneyman, Ruwolf, Morten, JeroenMassar, EdC, Kvng,
Teemuk, Joseph Solis in Australia, Ariel Pontes, EvilSS, Chris55, Barryd815, Zarex, Neelix, Dsearls, CCFreak2K, Cydebot, Thijs!bot, Ul-
timus, Hcberkowitz, Electron9, Widefox, Seaphoto, Opelio, Indrek, MECU, Leuqarte, AndreasWittenstein, JAnDbot, Joshua, Raanoo, En-
joi4586, Magioladitis, Rantsroamer, AlephGamma, Graven69, Kgeischmann, MichaelGoldshteyn, Floydpink, Khr0n0s, Kmwiki, Kiore,
Jpyeron, Glrx, Gthm159, Mange01, Brest, Jesant13, Qwidjib0, Gehlers, NewEnglandYankee, Cmichael, DH85868993, Mokgen, CWii,
DeftTechie, Sirmelle, Philip Trueman, Milan Kerlger, ErikWarmelink, Phantomdj, AlleborgoBot, Kbrose, Kevin66, Dunganb, Mmtre-
buchet, Nubiatech, Althena, Lightmouse, DavidDelaune, Khvalamde, Lukeritchie, Axelriv, Chris D Heath, ClueBot, The Thing That
Should Not Be, Dungkal, Marcoscm, Vivio Testarossa, Gallando, Arjayay, Ericbarch, M.O.X, Versus22, Johnuniq, Joelby, C. A. Rus-
sell, RobbertS, Maimai009, Addbot, Wyksztalcioch, Jgeer, Ironholds, Glane23, Favonian, Jasper Deng, Tide rolls, HerculeBot, LuK3,
Legobot, Luckas-bot, Yobot, AnomieBOT, AmritasyaPutra, Piano non troppo, MattTait, TheGreyArea, Materialscientist, Andrewmc123,
Xqbot, DataWraith, Jbohac, Ptmc2112, Cybjit, Kyng, Andypar, Crashdoom, Mbdxecw2, Visiting1, Dan6hell66, DenisKrivosheev, Nageh,
Thayts, Mfwitten, Tschfer, Outback the koala, Credomane, SpacemanSpi, HRoestBot, 10metreh, Kaeso, RedBot, Toolnut, Renepick,
Clarkcj12, Begoon, Danielbarnabas, Melnakeeb, DARTH SIDIOUS 2, Guerillero, John of Reading, Acather96, WikitanvirBot, Yann Leje-
une, Dewritech, XavierHager, Mmeijeri, Bro1960, SpectatorRah, ZroBot, John Cline, Jbergste, ClueBot NG, MelbourneStar, Satellizer,
Mewashere1, Cm115, , Widr, Exallium, Jk2q3jrklse, Johnnyboyshoots, HMSSolent, DBigXray, BG19bot, TheGeneralUser, Al-
tar, Tenretnieht, Winston Chuen-Shih Yang, IRedRat, Vkartiik, JYBot, Jwdonal, Mogism, John F. Lewis, Calinou1, MiNeEstasVortaristo,
Corn cheese, Dave Braunschweig, Faizan, Techbymak, Ruby Murray, Vaibhav69, ArmbrustBot, Comp.arch, Kgavhane702, Monkbot,
Alexmft, Sumit.taraphdar, Jonstout, Aidinabedi, Sonic8Forum, Gray0784 and Anonymous: 429
IP address Source: http://en.wikipedia.org/wiki/IP_address?oldid=631422784 Contributors: Magnus Manske, Vicki Rosenzweig, The
Anome, Taw, Tao, Malcolm Farmer, Rjstott, Ted Longstae, Danny, PierreAbbat, William Avery, SimonP, Dzof, Edward, Zhackwyatt,
Patrick, Infrogmation, Michael Hardy, W, Zocky, Pnm, SGBailey, Tannin, Ixfd64, Dcljr, Karada, Paddu, Georey, CesarB, Ahoerste-
meier, Haakon, Mac, Nanshu, Jpatokal, Ahkitj, Darrell Greenwood, Jebba, Kingturtle, Andres, Evercat, Iseeaboar, Idcmp, Hashar, Jid-
Gom, Mulad, Paul Stansifer, Fuzheado, DJ Clayworth, Vancouverguy, Jake Nelson, Dragons ight, Furrykef, Jnc, ZeWrestler, SEWilco,
Thue, Gamera2, Fvw, Jusjih, Frazzydee, JorgeGG, Denelson83, Chuunen Baka, Robbot, MrJones, RedWolf, Yelyos, Nurg, Merovingian,
Rfc1394, PedroPVZ, Litefantastic, Hadal, JesseW, Fuelbottle, Mushroom, Superm401, Scyrma, Dina, SmilingBoy, Giftlite, Gwalla, Andy,
Geeoharee, Tom harrison, Lupin, Dharris, Braaropolis, Peruvianllama, Everyking, No Guru, Curps, Alison, Gamaliel, Niteowlneils, Beta
m, Gracefool, Rchandra, AlistairMcMillan, VampWillow, Alvestrand, Jackol, Bobblewik, Golbez, SonicAD, Wmahan, Gadum, Ura-
nographer, Zeimusu, Antandrus, OverlordQ, Jossi, Alex Cohn, Rdsmith4, Kesac, Dmaftei, Kevin B12, Karl-Henner, Rlcantwell, Joyous!,
Ukexpat, Jh51681, Abdull, Zondor, Grunt, EagleOne, Shotwell, Corti, Mike Rosoft, Mormegil, Imroy, DanielCD, JTN, Andy Smith, Py-
rop, Discospinster, CannedLizard, Rich Farmbrough, Simonwheatley, Oliver Lineham, Pmsyyz, Kjd, Naive cynic, Spundun, Ceo, Xezbeth,
Mani1, Pavel Vozenilek, ESkog, ZeroOne, Kaisershatner, Brian0918, *drew, El C, Kwamikagami, Tverbeek, Shanes, Diomidis Spinel-
lis, Sietse Snel, RoyBoy, Bobo192, Johnteslade, Cwolfsheep, Dungodung, SpeedyGonsales, Sasquatch, Kjkolb, Alphax, Thewayforward,
Towel401, Sebastian Goll, Wrs1864, Krellis, Hagerman, Nsaa, Jumbuck, Zachlipton, Danski14, Alansohn, PaulHanson, Denis.arnaud,
Eric Kvaalen, Atlant, Mmmready, Riana, AzaToth, Yamla, Goldom, SlimVirgin, Echuck215, Lightdarkness, Fritzpoll, InShaneee, Cdc,
Judik, Malo, SidP, Cburnett, Stephan Leeds, Suruena, RainbowOfLight, Henry W. Schmitt, Versageek, TheCoee, Bullzila, Fleizach,
Agurzil, Feezo, Hojimachong, Weyes, Kelly Martin, Simetrical, UFu, Mrio, Mindmatrix, TigerShark, WadeSimMiser, JeremyA, CiT-
rusD, Howabout1, Schzmo, Pachydermballet, Gengiskanhg, Damicatz, Paul Carpenter, Dionyziz, Sega381, Hughcharlesparker, Wayward,
21.12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES 111
VirtuousCircle, Prashanthns, Wilson Tam, Simsong, Kryptops, Dysepsion, SqueakBox, Graham87, Magister Mathematicae, Dark Moo-
Goo, Ilya, David Levy, Kbdank71, FreplySpang, Josh Parris, Sj, Sjakkalle, Nightscream, Kinu, Wikibofh, Vary, Bill37212, PinchasC,
JHMM13, Tangotango, Pabix, Nneonneo, ElKevbo, Bubba73, Yug, Maurog, Sango123, Yamamoto Ichiro, Titoxd, Latka, Margosbot,
Crazycomputers, Bfolkens, Nivix, Thecosmos, RexNL, Gurch, Smileyrepublic, Quuxplusone, KFP, Krun, Alphachimp, Malhonen, Syn-
chrite, King of Hearts, Ttlkr, Chobot, Sherool, Nastajus, Hall Monitor, Digitalme, Gwernol, Metaeducation, Roboto de Ajvol, Wavelength,
SingingDragon, Crazytales, DMahalko, [email protected], Anonymous editor, Piet Delport, SluggoOne, SpuriousQ, Lucinos, Kirill
Lokshin, Edward301, Hydrargyrum, Stephenb, Eric4, Lord Voldemort, Manop, Gaius Cornelius, Pseudomonas, Bovineone, Wimt, Ugur
Basak, Shanel, NawlinWiki, 0waldo, MSSEVER, Wiki alf, RattleMan, Chick Bowen, NickBush24, Jaxl, D-Katana, Rjensen, RazorICE,
Valhallia, Joelr31, Cleared as led, JDoorjam, Irishguy, Johndarrington, Cholmes75, CecilWard, Raven4x4x, Iancarter, My Cat inn,
Emersoni, Alex43223, Bucketsofg, DeadEyeArrow, Psy guy, Sebleblanc, AnthonyR, Alpha 4615, Poochy, Nlu, User27091, Rwxrwxrwx,
Graciella, Paul Magnussen, 21655, Phgao, Zzuuzz, Cynicism addict, Ageekgal, Chase me ladies, I'm the Cavalry, Theda, Closedmouth,
Jwissick, Dspradau, GraemeL, Adammw, JoanneB, Peter, JLaTondre, Andrewski, Archer7, Ajuk, RunOrDie, Katieh5584, Kungfuadam,
Moomoomoo, GPugh, AtomSmazher, JoanThaBone, Kookykman, Airconswitch, DVDRW, Crystallina, Iorek85, SmackBot, Avogadro94,
Mmernex, Ashenai, Arizona1983, NSLE, Haza-w, KnowledgeOfSelf, David.Mestel, Obakeneko, Betbest1, Brick Thrower, Matthuxtable,
Pandion auk, Jab843, Veesicle, Hbackman, HalfShadow, Gilliam, Ohnoitsjamie, JoeKearney, Chris the speller, Master Jay, Organize-
FISH, Bluebot, Kurykh, LinguistAtLarge, Tjwagner, Persian Poet Gal, Lordkazan, Rmt2m, Master of Puppets, Tree Biting Conspiracy,
OrangeDog, Robocoder, The Rogue Penguin, Not Sure, Octahedron80, Kungming2, DHN-bot, Darth Panda, Brianporter, Yanksox, Emur-
phy42, Zsinj, Famspear, Rcmarotz, Can't sleep, clown will eat me, Frap, Chainz, JonHarder, Yidisheryid, TheKMan, Rrburke, Rsm99833,
Kcordina, RedHillian, Mr.Z-man, SundarBot, Threeafterthree, Flyguy649, Ddas, Khukri, Melonite, Melter, Comex, Nakon, Jackohare, Ve-
gaDark, Funky Monkey, J450NH3, Imveryveryveryverybored, Dreadstar, Richard001, Thegraham, Xagent86, Pg2114, Fuzzypeg, Wisco,
BryanG, Mwtoews, Jklin, Kthsujal, Salamurai, Daniel.Cardenas, Er Komandante, Sayden, Mion, Pilotguy, Drunken Pirate, Zchenyu,
Nishkid64, ArglebargleIV, Rory096, Kuru, Ksn, Soumyasch, Sir Nicholas de Mimsy-Porpington, Agentscott00, Shadowlynk, Accurizer,
Minna Sora no Shita, Jmunchovie, CaptainVindaloo, Goodnightmush, ManiF, Bjankuloski06en, JohnWittle, Ocatecir, Mr. Lefty, Iron-
Gargoyle, Misteror, Timpailthorpe, 16@r, MarkSutton, Thekittenofterra, George The Dragon, PRRfan, Mets501, Whomp, Sims2789,
Gary99129, Peyre, LaMenta3, Kvng, Nathanrdotcom, TJ Spyke, Possum, Iridescent, Agent007bond, RaiderTarheel, Doc Daneeka, Shoe-
ofdeath, 76df457hjkozdfg, OlivierMehani, V0rt3x, Courcelles, Radiant chains, Tawkerbot2, Daniel5127, Ryt, Orangutan, StabiloBoss,
Fvasconcellos, Bayberrylane, JForget, Dragonball1986, Oshra schwartz, Friendly Neighbour, Ahy1, Tanthalas39, The Return Of Squad,
Makeemlighter, Chopeen, Benwildeboer, Dgw, Kaplin, Tim1988, Cepopaladin, Phatom87, Emo Elli, Ryan, Controloye, Ramitmaha-
jan, UncleBubba, Gogo Dodo, Ohmy, FellowWikipedian, Indeterminate, Corpx, A Softer Answer, Chasingsol, SymlynX, Viscious81,
Tawkerbot4, Shirulashem, DumbBOT, Frozenpandaman, FastLizard4, Biblbroks, SpK, Gonzo fan2007, Aqberr, JoshSkidmore, Omicron-
persei8, Daniel Olsen, FrancoGG, SummonerMarc, JamesAM, Dante20XX, Thijs!bot, Epbr123, Junckerg, Jacnoc, Qwyrxian, HappyIn-
General, Teh tennisman, Hcberkowitz, Mojo Hand, RevolverOcelotX, Marek69, Klepas, John254, Woody, GICodeWarrior, Davidhor-
man, FreeKresge, SusanLesch, Natalie Erin, Spazit, CTZMSC3, Escarbot, Mentisto, Hmrox, AntiVandalBot, Davido, Luna Santin,
Widefox, Wengero, Chacor, Opelio, Quintote, Prolog, Jj137, Mrsudip, LibLord, Vendettax, LegitimateAndEvenCompelling, Gerardkco-
hen, Labongo, Huttarl, Golgofrinchian, Bigjimr, JAnDbot, Barek, MER-C, Hut 8.5, J-stan, East718, PhilKnight, LittleOldMe, Acrote-
rion, Yahel Guhan, VzjrZ, Connormah, Bongwarrior, VoABot II, Farquaadhnchmn, Rantsroamer, Bubba hotep, Alanbrowne, Arthuran,
Robotman1974, Ferrija1, Martynas Patasius, Vclortho, Chaoserver, DerHexer, JaGa, Kgeischmann, Patstuart, SquidSK, G.A.S, Hdt83,
MartinBot, Junnel, Swalot, Tvoz, Rianvisser, Rettetast, Burnedthru, Mschel, Amnuay, Brothejr, Mastershake phd, PrestonH, Lilac Soul,
RockMFR, J.delanoy, Pharaoh of the Wizards, Abecedare, Trusilver, Bogey97, Uncle Dick, VAcharon, Jesant13, Ginsengbomb, Again-
Erick, Twinkiesarethesourceofallknowledge, Acalamari, Katalaveno, Bubzyz, McSly, Myransree, Jeepday, Skier Dude, Gurchzilla, Py-
rospirit, Deman 24, Chriswiki, AntiSpamBot, Floateruss, NewEnglandYankee, Doria, Aervanath, Cobi, Kraftlos, El Monster, Julian-
colton, Cometstyles, Guardians611, WJBscribe, SmallPotatoes, DorganBot, Ja 62, Useight, Cardonnell, Idioma-bot, Funandtrvl, Spellcast,
Montchav, James ONeal, VolkovBot, ABF, Murderbike, CSumit, Je G., Imperator3733, Forkazoo, VasilievVV, Soliloquial, Fagiolonero,
Ryan032, Jsalims80, Philip Trueman, Fran Rogers, Wikifan07, TXiKiBoT, BuickCenturyDriver, Maximillion Pegasus, Alan Rockefeller,
BlueCanary9999, Rei-bot, GcSwRhIc, Sean D Martin, Qxz, Artibaton, Anna Lincoln, Corvus cornix, Mattv2006, Leafyplant, PaulTane-
nbaum, Canaima, Jackfork, LeaveSleaves, Lam4o, Cremepu222, Guest9999, Blutred, Madhero88, Greswik, Andy Dingley, Francis22,
Damore1405, Nrlight, Synthebot, Falcon8765, Enviroboy, Kingjalis3, 1a2b3c4e5d, Spinningspark, Lanasa, Why Not A Duck, Monty845,
HiDrNick, Bobo The Ninja, AlleborgoBot, Nagy, Fredtheyingfrog, Radioactive akomen, Demmy, Berro9, Kbrose, Hansmohrid, Fdgsd-
fgg rgfsfdg fdsgsrf, SieBot, Kevin66, Shiva 29, Anthonymetal, Nubiatech, Tresiden, Tiddly Tom, Moonriddengirl, Wiigocrazii, Jauerback,
Jsc83, Neeples, Rockstone35, Dawn Bard, Caltas, RiK harhar, Ponies123456789, Purbo T, Blake3522, Maddiekate, Chromaticity, San-
tamage98, Jaredbelch, Arbor to SJ, Oxymoron83, Faradayplank, AngelOfSadness, Avnjay, AnonGuy, Seanx820, La Parka Your Car,
Dillard421, Lilserif, Fox816, Maelgwnbot, Sean.hoyland, Mygerardromance, JR JakeRs, 48states, WikiLaurent, Nn123645, Escape Or-
bit, Michael Pheddyn, Kanonkas, Troy 07, MaverickSolutions, WikipedianMarlith, Twinsday, Loren.wilton, Martarius, Elassint, ClueBot,
The Thing That Should Not Be, Kafka Liz, Lawrence Cohen, MacroDaemon, Wysprgr2005, Arakunem, Drmies, Robby.is.on, Coun-
terVandalismBot, Blanchardb, LizardJr8, Dylan620, Abdul muqeet, Nicklous20, Willysmilk, DragonBot, Excirial, Jusdafax, Wiki104,
SpikeToronto, Polaed, RDaneel2, Trysudhakar, JamieS93, Mikaey, Ottawa4ever, ChrisHodgesUK, La Pianista, Inspector 34, Thingg,
Gatlingunlevel27, Aitias, Asoiaf fanatic, Versus22, Johnuniq, Egmontaz, Tgotchi, Vanished User 1004, 20percent, Skunkboy74, Bar-
retB, Badmachine, XLinkBot, Gnowor, Wertuose, Rror, Ricgal, DaL33T, Little Mountain 5, Avoided, Badgernet, Noctibus, Airplane-
man, Hacii, Addbot, Willking1979, AVand, Jojhutton, Tcncv, Apoyon, Tothwolf, Ronhjones, Fieldday-sunday, UnknownzD, Home-
4f8918a9a7.\mshome, CanadianLinuxUser, Zemadmat, Cst17, SoSaysChappy, Morning277, Chamal N, BepBot, Glane23, Chzz, Favo-
nian, Doniago, Jasper Deng, 5 albert square, Tyw7, Tide rolls, Lightbot, Avono, Romanskolduns, Teles, Gail, Applesqsx, Dr.queso, Ar-
gentium, Maxweb, Klose99, Yobot, Sportsfan 555, Les boys, Kipoc, II MusLiM HyBRiD II, Rameshbabu.itian, AnomieBOT, Rubinbot,
1exec1, IRP, Galoubet, 9258fahskh917fas, Piano non troppo, Ipatrol, AdjustShift, Kingpin13, Law, Ulric1313, Crecy99, Bluerasberry,
Materialscientist, The High Fin Sperm Whale, OllieFury, Maxis ftw, JohnnyB256, Vandalismterminator, Nifky?, Vrraybadboy78, Cher-
ron1994, Freshmaniac, Ralphwiggam75, Intelati, Cureden, Myhihihi, Capricorn42, Bihco, 4twenty42o, Jerey Mall, Myiptest, Ryamigo,
Grim23, Onecountry, Pmlineditor, Wizardist, Zarcillo, Frankie0607, Shirik, H8erade, Cybjit, Kwoksir, , Lokimang, Doulos
Christos, Creative0o, Shadowjams, WaysToEscape, E0steven, Dougofborg, Who then was a gentleman?, Dan6hell66, Spazturtle, GT5162,
George2001hi, FrescoBot, Wikedit-34, Pepper, Lothar von Richthofen, Mark Renier, AltecLansing12, Rafasseb, Perilwalruz, BenzolBot,
1.mallesh, Rmustar 10, T3h 1337 b0y, Simple Bob, Pinethicket, Elockid, ScienceGolfFanatic, Tanweer Morshed, Newwhist, Supreme
Deliciousness, Razakausar, Reconsider the static, Mmeerman, FoxBot, Soundcomm, TobeBot, Retired user 0001, Pantjz, Renepick, Lotje,
BlackAce48, Dinamik-bot, Vrenator, KevinTjan, Dandorid, TheGrimReaper NS, Weedwhacker128, Nascar1996, Tbhotch, Mld zero,
DARTH SIDIOUS 2, Regancy42, Slon02, Deagle AP, EmausBot, John of Reading, Acather96, Imisslife, Patpink, Immunize, Heracles31,
Huskihuskihuski, Ninny777, LyonJE, RenamedUser01302013, Sgarcia05, Tommy2010, Scgtrp, Koolkat2448, Wikipelli, K12345wiki,
112 CHAPTER 21. PROFINET
Hughesey, 7qr41r, Wayne Slam, OnePt618, Arman Cagle, Sillicongal, Coasterlover1994, MonoAV, Pun, Orange Suede Sofa, Luke
wyatt, BioPupil, Shiftoften66, Nofallah, Matthewrbowker, L'ecrivant, TYelliot, Samilamethmal, Nula666, Drkmaster, ClueBot NG, Patch-
esTheCaveman, Deannyc, Nimiew, Sahansuraweera, Rachtchi, RenRochefort, 09ialsharrai, Hon-3s-T, Movses-bot, ConconJondor, Cntras,
Cj005257-public, MerlIwBot, Odistery, Idts, , PoopyPantsMcPooperson, Abmitgkp2011, Superuserit, IraChestereld, Mins-
bot, Unconventional2, HueSatLum, Rezonansowy, Jemappelleungarcon, Redalert2fan, Abhishekdepro, Monkbot, ElectronicKing888 and
Anonymous: 2014
Transmission Control Protocol Source: http://en.wikipedia.org/wiki/Transmission_Control_Protocol?oldid=630388727 Contributors:
WojPob, Brion VIBBER, Zundark, The Anome, Alex, Andre Engels, Aldie, Fubar Obfusco, Jtk, Mjb, B4hand, PeterB, Edward, Michael
Hardy, Nixdorf, Kku, Meekohi, Karada, Dori, Pde, Mac, William M. Connolley, Ojs, BAxelrod, Harvester, Eirik (usurped), Samuel,
Nikola Smolenski, Idcmp, Hashar, Timwi, Dcoetzee, Sepper, Andrewman327, Wkcheang, Jnc, Gamera2, Shizhao, Betterworld, Raul654,
Rogper, Robbot, Chealer, Fredrik, Tomchiukc, RedWolf, Nurg, PedroPVZ, PxT, Jondel, Bkell, Lupo, Dina, Giftlite, Graeme Bartlett, Sim,
Kim Bruning, Inter, Wolfkeeper, Fleminra, Frencheigh, Saaga, Mboverload, Nayuki, Jaan513, Jackol, SWAdair, Jsavage, Kasperl, Fishal,
Haggis, Mendel, LiDaobing, Beland, Dnas, Cheshire, Mozzerati, Biot, Daniel Staal, SamSim, Jewbacca, Thorwald, RevRagnarok, Scrool,
N328KF, Imroy, Pmadrid, JTN, Pak21, Hydrox, Qutezuce, Wrp103, Smyth, Bender235, Dewet, ZeroOne, Goplat, Plugwash, Glenn
Willen, Evice, Syp, CanisRufus, Purplefeltangel, Kwamikagami, Spearhead, Sietse Snel, RoyBoy, Spoon!, GalaxiaGuy, John Vandenberg,
Arnhemcr, Foobaz, Makomk, SpeedyGonsales, Toh, Nk, Mhandley, Ryan Stone, Wrs1864, Helix84, MtB, Krellis, Klhuillier, Zachlip-
ton, Guy Harris, DariuszT, Nealcardwell, Yamla, SHIMONSHA, Lightdarkness, Fawcett5, Snowolf, Markrod, Vedantm, Velella, Rick
Sidwell, Mark Bergsma, Cburnett, Suruena, Evil Monkey, Egg, Sleigh, Boscobiscotti, Kinema, Kenyon, Tariqabjotu, GilHamilton, Lime,
Gmaxwell, Boothy443, Woohookitty, Beccus, StradivariusTV, Bkkbrad, Alexescalona, Palica, Pfalstad, Graham87, Bilbo1507, Rjwilmsi,
Plainsong, CraSH, Ryk, Fredrikh, Brighterorange, Fred Bradstadt, FlaBot, Jowagner, Shultzc, Ysangkok, Otets, Pg8p, Intgr, Fresheneesz,
Alvin-cs, Synchrite, Butros, Daev, Chobot, Moocha, P0per, YurikBot, Hairy Dude, Phantomsteve, Akamad, Stephenb, Manop, Gaius Cor-
nelius, Yyy, Shaddack, Rsrikanth05, Wimt, NawlinWiki, Zwobot, Maerk, Phandel, DeadEyeArrow, Fabiob, Harput, Bstrand, J. Nguyen,
Arthur Rubin, Jogers, JoanneB, Elfalem, Fsiler, Garion96, GrinBot, TuukkaH, Kf4bdy, Marty Pauley, Luk, Amalthea, Erik Sandberg,
SmackBot, PaulWay, Ymiaji, DaveSymonds, The Monster, StephenHemminger, Doc Strange, Canthusus, Timotheus Canens, Agi896,
BillMcGonigle, Andy M. Wang, Anwar saadat, Stevenwagner, Djdawso, Coinchon, Oli Filth, EncMstr, Colonies Chris, LeiZhu, Can't
sleep, clown will eat me, Neo139, OrphanBot, JonHarder, Logicwax, Zvar, Addshore, Ortzinator, Dharmabum420, NeilGoneWiki, Duck-
bill, Alca Isilon, Martijn Hoekstra, Mini-Geek, DylanW, Jwh, Acdx, A5b, Daniel.Cardenas, LeoNomis, T, DKEdwards, Masterpjz9,
Qwerty0, Via strass, SashatoBot, Miss Sa, Trou, Breno, A-moll9, Bezenek, Prasannaxd, Stonesand, Jec, Tasc, Peytons, Aarktica, Matta-
bat, Jgrahn, Prunk, MTSbot, Kvng, Akill, Pegasus1138, Bill Malloy, Alexh19740110, Phuyal, Svinodh, MrBoo, Cheburashka, Unixguy,
CmdrObot, Imcdnzl, Agent Koopa, Nviladkar, Mr Echo, Splint9, Lark ascending, Pgr94, MeekMark, Equendil, Phatom87, Revolus,
Sbnoble, UncleBubba, Gogo Dodo, Tawkerbot4, Quibik, JCO312, Asenine, Christopher P, CobbSalad, Omicronpersei8, M.S.K., Hilger-
denaar, Thijs!bot, Epbr123, Kubanczyk, El pak, Oldiowl, Marek69, TangentCube, Uruiamme, LachlanA, I already forgot, AntiVandalBot,
Majorly, Yonatan, Luna Santin, Widefox, DarkAudit, NKarstens, D235, Alphachimpbot, Sdomin3, Esmond.pitt, Lanilsson, JAnDbot,
Harryzilber, MER-C, Okiefromokla (old), Leolaursen, PhilKnight, Enjoi4586, CrizCraig, Ideoplex, Magioladitis, Fisherisland14, VoABot
II, TheVoid, Kevinmon, Bubba hotep, PureRumble, Papadopa, Kgeischmann, WLU, I-baLL, Gwern, HiB2Bornot2B, Blacksqr, Perfgeek,
MartinBot, Poeloq, Rettetast, Jonathan Hall, FDD, Leyo, Lilac Soul, Gthm159, Mange01, Blendmaster, Jesant13, Jayden54, AntiSpamBot,
Squidish, Kraftlos, Bigdumbdinosaur, Juliancolton, Cometstyles, Manlyjacques, OsirisV, Wlgrin, Inwind, Izno, Ale2006, Tjhiker, Lights,
Maksym.Yehorov, VolkovBot, Scorpiondiain, Umar420e, MenasimBot, Loor39, Lunadesign, Philip Trueman, JuneGloom07, TXiKiBoT,
ALexL33, Sh manu, Drake Redcrest, Gwinnadain, Rodowen, Cbrettin, Vinu Padmanabhan, Oxfordwang, Anna Lincoln, David.bar, Zioun-
clesi, Katimawan2005, Neshom, Nave.notnilc, Enviroboy, Michael Frind, Jehorn, Jxw13, Kbrose, Nubiatech, Nestea Zen, ToePeu.bot,
PanagosTheOther, Brech, Smsarmad, TediousFellow, Danielgrad, Flyer22, Cjdaniel, Oxymoron83, Jjinno, Rdone, Alt-sysrq, Ngrieth,
OKBot, Aprice457, StaticGull, WikiLaurent, Savagejumpin, Sasha Callahan, Explicit, Youpilot, ClueBot, The Thing That Should Not
Be, Mild Bill Hiccup, DnetSvg, Blanchardb, Lucasbfr2, Alexbot, Jusdafax, Ciprian Dorin Craciun, PixelBot, Dregin1, Technobadger,
Pluknet, Kumarat9pm, Charles.partellow, Nedim.sh, Frederico1234, The-tenth-zdog, Cincaipatrin, Akshaymathur156, Johnuniq, Ordoon,
DumZiBoT, Darkicebot, Astronomerren, Nneuman, BodhisattvaBot, WikHead, StubbyT, Alexius08, TravisAF, Dsimic, Oxyacanthous,
Maimai009, Addbot, Mortense, Ghettoblaster, Jgeer, Psyced, Mootros, Anichandran.mca, Scientus, CanadianLinuxUser, Leszek Jaczuk,
Graham.Fountain, MrOllie, Glane23, Torla42, Loukris, 5 albert square, IOLJe, AgadaUrbanit, Numbo3-bot, Tide rolls, Arsenal9boi,
Avono, Teles, Jarble, Quantumobserver, Luckas-bot, Yobot, Kartano, THEN WHO WAS PHONE?, AnotherNitPicker, SwisterTwister,
Eric-Wester, Centrew, AnomieBOT, Jim1138, IRP, Piano non troppo, Shadowjain, Materialscientist, Ursushoribilis, Citation bot, Mithras-
Priest, Mbruck, DirlBot, Nifky?, LilHelpa, Xqbot, Sergiodc, TechBot, Prashant.khodade, RodrigoCruzatti, RibotBOT, ,
Shadowjams, Gmaran23, FrescoBot, Lokacit443, BenzolBot, Kwiki, Citation bot 1, Awy997, AstaBOTh15, 10metreh, Hamtechperson,
Encognito, RedBot, MastiBot, PBSurf, HarrisonLi, Fraxtil, Banej, Mohitjoshi999, Cwats124, Lam Kin Keung, Longuniongirl, Rtclaw-
son, Vrenator, PS3ninja, MoreNet, Danielbarnabas, Some Wiki Editor, Ashwinsbhat, Jfmantis, RjwilmsiBot, Xaphnir, Scil100, WildBot,
EmausBot, Zeroboo, Ouimetch, John of Reading, Acather96, Velowiki, GoingBatty, RA0808, Urmajest, Smappy, Tommy2010, Wikipelli,
Ahson7, Ru.in.au, Kirelagin, Ancientphoenixians, Access Denied, DrHannibal216, Henriktudborg, Ocaasi, Thine Antique Pen, Nateshwar
kamlesh, L Kensington, Putdust, Ego White Tray, Cpaasch, MacStep, ClueBot NG, Nimiew, Jack Greenmaven, Satellizer, GarryAnderson,
Karthick.s5, FGont, Ltsampros2, JeClarkis, Clark-gr, Helpful Pixie Bot, HMSSolent, Silverwindx, Calabe1992, Mtsz, Arnavchaudhary,
Iitywybmad, Northamerica1000, Mrzehak, Prakash mit, Compfreak7, Altar, Fcp999, Jcarlos-causa, A1vast, Nikhil raskar, Maclion, Talel
Atias, BattyBot, C10191, Padmini Gaur, Ych06391, Vshebordaev, Codename Lisa, Hainesr2000, Lone boatman, Sethwm, Frosty, Kapil-
sharma15, Sfgiants1995, Wywin, Dave Braunschweig, DBhavsar709, Camyoung54, Koszik, Srigaurav1986, Soham, Scornay, Moris560,
AlexanderRedd, St170e, Kieranmcgr, Valeritn, WaterSnail, Jterminator and Anonymous: 888
User Datagram Protocol Source: http://en.wikipedia.org/wiki/User_Datagram_Protocol?oldid=631335839 Contributors: Damian Yer-
rick, Bryan Derksen, The Anome, Fubar Obfusco, Jtk, Mahjongg, Nixdorf, Alo, Ronz, , BAxelrod, Samuel, Vanished user
5zariu3jisj0j4irj, Tpbradbury, Wkcheang, Itai, Gamera2, Shizhao, Tjdw, Robbot, Fredrik, RedWolf, Romanm, Modulatum, PedroPVZ,
Robbe, Tobias Bergemann, Giftlite, Fennec, Beefman, Reub2000, Gracefool, SWAdair, Matt Darby, Neilc, Gordoni, Thray, Erik Garrison,
Daniel Staal, Joachim Wuttke, RevRagnarok, JTN, Twinxor, Ardonik, Xezbeth, Alistair1978, Michael Zimmermann, Mani1, Bender235,
Djordjes, Plugwash, Joanjoc, Kwamikagami, Mpeg4codec, Towel401, Krellis, Frodet, Terrycojones, Nroets, Guy Harris, Ayeroxor, Rick
Sidwell, Cburnett, Suruena, Cvalda, Kinema, DSatz, Mindmatrix, ^demon, Hdante, Ashmoo, Graham87, E090, BD2412, CraSH, Quid-
dity, Wiarthurhu, Fredrikh, Aapo Laitinen, Alvin-cs, YurikBot, Borgx, Phantomsteve, RussBot, Jengelh, Rsrikanth05, Voidxor, Zwobot,
Falcon9x5, DeadEyeArrow, Eclipsed, Bota47, Bobstopper, E Wing, Tdangkhoa, Petri Krohn, Rwwww, SmackBot, InverseHypercube,
The Monster, Od Mishehu, Golwengaud, Smeggysmeg, BenAveling, CrookedAsterisk, Cassan, MLeb, DavidSol, Misterdom, A5b, Jna
runn, Paulish, SashatoBot, Breno, Ben Moore, Clalansingh, Kvng, Johnny 0, Ginkgo100, Teemuk, Conrad.Irwin, Burisch, Phatom87,
Reywas92, Sammydee, UncleBubba, Thijs!bot, JNighthawk, DesTroy, AntiVandalBot, Widefox, Opelio, Esmond.pitt, JAnDbot, Dicen-
21.12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES 113
tra, CombatWombat42, Enjoi4586, Ideoplex, Recurring dreams, 28421u2232nfenfcenc, Kgeischmann, Mike6271, Anaxial, Gthm159,
Mange01, Public Menace, Gzkn, Sci13960, Aram33, 83d40m, STBotD, Zara1709, Mike V, Gnipahellir, AlnoktaBOT, Vinu Padman-
abhan, DennyColt, Kovianyo, Spearsall, Teh romaoer, Chenzw, Andrew Kember, Kbrose, S-n-ushakov, SieBot, Nubiatech, Eagleal,
R2richar, Mam711, Bentogoa, Oxymoron83, Jjinno, Jdaloner, FrisoB, Bane1998, ClueBot, Uncle Milty, Hitherebrian, WestwoodMatt,
Pelesl, Dfurbeck, Razorame, The-tenth-zdog, Cincaipatrin, Chiefmanzzz, Upadhyaykc, Johnuniq, Mwholt, BodhisattvaBot, Silvonen-
Bot, Dsimic, Samersarhan83, Jncraton, MagnusA.Bot, Jasper Deng, , Lightbot, Legobot, Eduardopinheiro, KamikazeBot,
AnomieBOT, Rubinbot, 1exec1, Fromageestciel, Flewis, Materialscientist, ArthurBot, Gsmgm, Xqbot, Locos epraix, Fightin' Phillie,
Omnipaedista, RibotBOT, Kyng, Locobot, Ll1324, Frozenevolution, Uncopy, Plindemann, I dream of horses, RedBot, Lissajous, Cn-
williams, FoxBot, Headbangerkenny, Fox Wilson, The Utahraptor, WildBot, Alison22, EmausBot, Ouimetch, WikitanvirBot, Bongo-
ramsey, Bobby Caudwell, Wingman4l7, Tolly4bolly, Irrypride, Gorryf, ChuispastonBot, Teapeat, Rememberway, ClueBot NG, Fudgefr,
Dkogh, Theopolisme, Ssd293, Benqmonitor, Helpful Pixie Bot, Beacon11, Timothyjaden, Dhruvv7, Achowat, IRedRat, PatheticCopyEd-
itor, Popescucalin, Pratyya Ghosh, Yelojakit, Areh adeola, TechyOne, Rotlink, Dave Braunschweig, Jsztabzyb, ArmbrustBot, MortenZdk,
Psycoconnetic, Jackmcbarn, Rubenprot, Pall123ban and Anonymous: 318
Internet Control Message Protocol Source: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol?oldid=627001620 Con-
tributors: The Anome, Drj, Wayne Hardman, Matusz, Fubar Obfusco, William Avery, PeterB, SarahEmm, Nixdorf, Shellreef, Kku, Jnc,
Robbot, Chealer, Fredrik, Romanm, Tobias Bergemann, Alerante, Mintleaf, Niteowlneils, Beowulf king, Bgraabek, Huwr, Anggarda,
Canterbury Tail, Monkeyman, JTN, Pmsyyz, CanisRufus, Sietse Snel, Robotje, Polluks, Wrs1864, Jumbuck, Poweroid, Caesura, Suru-
ena, Grenavitar, Kinema, Kenyon, S.emmerson, Nuno Tavares, Woohookitty, RHaworth, DrThompson, Fbriere, Graham87, Qwertyus,
Tlroche, FlaBot, Fresheneesz, Sioux.cz, Alvin-cs, Chobot, YurikBot, Hawaiian717, Me and, Jengelh, Voidxor, SixSix, DeadEyeArrow,
Antiduh, ArielGold, TuukkaH, Mr link, KocjoBot, Tjpayne, Hardyplants, Jasminek, Joseanes, Plustgarten, Vina-iwbot, Ugur Basak Bot,
Oskilian, Mahboud, Manifestation, Celtkin, Kvng, Courcelles, Unixguy, WeggeBot, Phatom87, Cydebot, UncleBubba, Quibik, Thijs!bot,
Dark knight, AntiVandalBot, Bradycardia, JAnDbot, Enjoi4586, Kgeischmann, Gwern, Ageekymonk, Verdatum, J.delanoy, Mange01,
Athaenara, Andareed, Dnevil, VolkovBot, TXiKiBoT, Naveenpf, Goreatic, Piper8, Whbstare, Rjgodoy, YordanGeorgiev, AlleborgoBot,
Logan, Pointy haired fellow, Kbrose, BobHackett, SieBot, VVVBot, Tstojano, Ajk91, Martarius, ClueBot, LAX, Hari36533, VsBot,
Adamianash, Alexbot, Jadhav.m, Monkeymaker, Promethean, Mremail1964, SilvonenBot, Dsimic, Addbot, Favonian, ChenzwBot, Her-
culeBot, Luckas-bot, Yobot, Massimobeltramo, Fraggle81, Amirobot, Nallimbot, Eliellou, Ranjithts, Jim1138, Xqbot, Forton, RibotBOT,
Philleb, Electrocut, Omar35880, FrescoBot, Wikisierracharlie, FoxBot, RjwilmsiBot, B20180, Xmm0, Mayonaise15, K6ka, ZroBot,
John Cline, Kalin.KOZHUHAROV, Jay-Sebastos, VictorianMutant, Voomoo, ClueBot NG, Nimiew, CocuBot, MatthewIreland, Khazar2,
Lythamlatic, Jasubbey1, Bennettaur, Dave Braunschweig, Faizan, ArmbrustBot, Joshuaje1, Sangeshitou and Anonymous: 199
Internet Group Management Protocol Source: http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol?oldid=630095260
Contributors: DWay, B4hand, Karada, Nichtich, Pmolinero, Nikai, Charles Matthews, David Newton, Zoicon5, Evan, Kaal, Ed g2s,
RedWolf, Gwalla, Msiebuhr, JTN, Robotje, Robhu, R. S. Shaw, Suruena, Antichrist, Kinema, Kenyon, Woohookitty, Pchov, Sega381,
Sango123, FlaBot, Chobot, YurikBot, Hairy Dude, Hede2000, Nothing1212, Psu256, Rcronk, SmackBot, Patrickdepinguin, Thumper-
ward, DRahier, Apexprim8, Vina-iwbot, Abolen, Kvng, Grasshoppa, CmdrObot, WeggeBot, Cydebot, Thijs!bot, Salgueiro, Leolaursen,
Raanoo, Enjoi4586, AlephGamma, Mateo2, Kgeischmann, Mange01, VolkovBot, Trasz, Metaclassing, TXiKiBoT, Kvangend, Fal-
con8765, Kbrose, SieBot, AS, Cgcastor, Ruwanindika, Alexbot, Eeekster, Technobadger, MystBot, Addbot, Grunzh, ,
PlankBot, Ptbotgourou, Nallimbot, AnomieBOT, Harpreet82, SvartMan, R.srinivaas, ArthurBot, Xqbot, TheAMmollusc, Termininja, Ri-
botBOT, MathsPoetry, Hoo man, Jandalhandler, Runkalicious, DARTH SIDIOUS 2, EmausBot, Wikihelp1, Bktero, Accumulator one,
ChuispastonBot, ClueBot NG, ArmbrustBot, MSheshera, LukasMatt, Houston-IT12 and Anonymous: 101
Industrial Ethernet Source: http://en.wikipedia.org/wiki/Industrial_Ethernet?oldid=617319349 Contributors: Greenrd, Texture, Mush-
room, Bobblewik, EagleOne, Sietse Snel, Femto, Laug, Wtshymanski, Notan Frag, Woohookitty, Waldir, Mandarax, Cherubino, Srlef-
er, Yoasif, Seb1982, Back ache, Ehrhardtl, Bluebot, Oli Filth, Frap, JonHarder, UU, Kvng, Requestion, Pgr94, Chungyu, Tim1988,
Satori Son, Redcs37, Fieldbusguy, Dougher, Magioladitis, Prozac1980, XandroZ, Glrx, Grandsonofmaaden, MSchu, Cmathas, Sol87, Fu-
nandtrvl, Drake Redcrest, Brolin, SieBot, SCH56, Advantecheautomation, Qi78, Cuvette, Glauco.b, Cialo, SkeletorUK, Mild Bill Hiccup,
EBY3221, Arjayay, Addbot, Some jerk on the Internet, MrOllie, Luckas-bot, Themfromspace, TommySp, Oldcommguy, AnomieBOT,
Surv1v4l1st, QueBurro, W Nowicki, Ex Puexto, DrilBot, LittleWink, Btilm, Sunny2who, Dinamik-bot, EmausBot, Dnator, Santosd, Jw-
CLPA org, Martinzou, RAPIEnet, Elky7, Jdvmanen and Anonymous: 55
PROFINET Source: http://en.wikipedia.org/wiki/PROFINET?oldid=615360363 Contributors: Techtonik, LucasVB, D6, Richwales,
MarkusHagenlocher, Marudubshinki, Benjaminmyklebust, Gaius Cornelius, SmackBot, Bluebot, JonHarder, Dicklyon, Iridescent, Play-
time, Nick Number, DrRSP, Nyttend, VolkovBot, Langerwolfgang, SieBot, Aussiecontrols, Fahidka, Christian1969, Mild Bill Hiccup,
Estirabot, Dipl.-Ing, PNOAvE, Addbot, Splodgeness, Biezl, DSisyphBot, GrouchoBot, W Nowicki, EmausBot, WikitanvirBot, Tarbarrels,
ZroBot, CarlHenning, BG19bot, Northamerica1000, Ssugathapala, Smipi01, AStove and Anonymous: 24
21.12.2 Images
File:0x-pb-stecker-verschieden.jpg Source: http://upload.wikimedia.org/wikipedia/commons/8/8a/0x-pb-stecker-verschieden.jpg Li-
cense: CC-BY-SA-2.0-de Contributors: Transferred from de.wikipedia Original artist: Original uploader was Oxensepp at de.wikipedia
File:10Base5transcievers.jpg Source: http://upload.wikimedia.org/wikipedia/commons/4/40/10Base5transcievers.jpg License: CC-BY-
SA-2.5 Contributors: Transferred from en.wikipedia Original artist: Original uploader was Robert.Harker at en.wikipedia
File:An_Intel_82574L_Gigabit_Ethernet_NIC,_PCI_Express_x1_card.jpg Source: http://upload.wikimedia.org/wikipedia/
commons/2/24/An_Intel_82574L_Gigabit_Ethernet_NIC%2C_PCI_Express_x1_card.jpg License: CC-BY-SA-3.0 Contributors: Took a
picture Original artist: Dsimic
File:Bus_icon.svg Source: http://upload.wikimedia.org/wikipedia/commons/c/ca/Bus_icon.svg License: Public domain Contributors: ?
Original artist: ?
File:CAN-Bus-frame_in_base_format_without_stuffbits.svg Source: http://upload.wikimedia.org/wikipedia/commons/5/5e/
CAN-Bus-frame_in_base_format_without_stuffbits.svg License: CC-BY-SA-3.0 Contributors: ? Original artist: ?
File:CAN-Bus_Elektrische_Zweidrahtleitung.svg Source: http://upload.wikimedia.org/wikipedia/commons/9/9e/CAN-Bus_
Elektrische_Zweidrahtleitung.svg License: CC-BY-SA-3.0 Contributors: Own work Original artist: Stefan-Xp
114 CHAPTER 21. PROFINET
File:CAN_Bit_Timing2.svg Source: http://upload.wikimedia.org/wikipedia/commons/8/8a/CAN_Bit_Timing2.svg License: Public do-
main Contributors: en:Image:CAN Bit Timing2.png Original artist: en:User:Rocketmagnet, traced by User:Stannered
File:CAN_Node.png Source: http://upload.wikimedia.org/wikipedia/commons/c/c0/CAN_Node.png License: CC-BY-SA-4.0 Contribu-
tors: Own work Original artist: EE JRW
File:Commons-logo.svg Source: http://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: ? Contributors: ? Original
artist: ?
File:Computer-aj_aj_ashton_01.svg Source: http://upload.wikimedia.org/wikipedia/commons/c/c1/Computer-aj_aj_ashton_01.svg
License: ? Contributors: ? Original artist: ?
File:Coreswitch_(2634205113).jpg Source: http://upload.wikimedia.org/wikipedia/commons/9/9b/Coreswitch_%282634205113%29.
jpg License: CC-BY-SA-2.0 Contributors: New toy at work Original artist: Dave Fischer
File:DB25_Diagram.svg Source: http://upload.wikimedia.org/wikipedia/commons/b/b8/DB25_Diagram.svg License: Public domain
Contributors: ? Original artist: ?
File:Edit-clear.svg Source: http://upload.wikimedia.org/wikipedia/en/f/f2/Edit-clear.svg License: ? Contributors: The Tango! Desktop
Project. Original artist:
The people from the Tango! project. And according to the meta-data in the le, specically: Andreas Nilsson, and Jakub Steiner (although
minimally).
File:Ethernet_Connection.jpg Source: http://upload.wikimedia.org/wikipedia/commons/1/11/Ethernet_Connection.jpg License: CC-
BY-SA-3.0 Contributors: Template:Revathi Original artist: Someones Moving Castle
File:Ethernet_RJ45_connector_p1160054.jpg Source: http://upload.wikimedia.org/wikipedia/commons/d/d7/Ethernet_RJ45_
connector_p1160054.jpg License: CC-BY-SA-3.0 Contributors: ? Original artist: ?
File:Ethernet_Type_II_Frame_format.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/13/Ethernet_Type_II_Frame_
format.svg License: Public domain Contributors: ? Original artist: ?
File:Ethernet_frame.svg Source: http://upload.wikimedia.org/wikipedia/commons/4/42/Ethernet_frame.svg License: Public domain
Contributors: Own work Original artist: Self-made
File:FTDI_USB_SERIAL.jpg Source: http://upload.wikimedia.org/wikipedia/commons/7/78/FTDI_USB_SERIAL.jpg License: Public
domain Contributors: Own work (enwiki) Original artist: Kilowattradio
File:Fast-link-pulses.svg Source: http://upload.wikimedia.org/wikipedia/commons/5/5a/Fast-link-pulses.svg License: Public domain
Contributors: Own work Original artist: Paolo Liberatore
File:Folder_Hexagonal_Icon.svg Source: http://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: ? Con-
tributors: ? Original artist: ?
File:IGMP_basic_architecture.png Source: http://upload.wikimedia.org/wikipedia/commons/c/c9/IGMP_basic_architecture.png Li-
cense: Public domain Contributors: Transferred from en.wikipedia to Commons by User:Insanity using CommonsHelper. Original artist:
Harpreet Eighty-Two (Harpreet82 at en.wikipedia)
File:IP_stack_connections.svg Source: http://upload.wikimedia.org/wikipedia/commons/c/c4/IP_stack_connections.svg License: CC-
BY-SA-3.0 Contributors: Prior Wikipedia artwork by en:User:Cburnett Original artist: en:User:Kbrose
File:Internet_map_1024.jpg Source: http://upload.wikimedia.org/wikipedia/commons/d/d2/Internet_map_1024.jpg License: CC-BY-
2.5 Contributors: Originally from the English Wikipedia; description page is/was here. Original artist: The Opte Project
File:Ipv4_address.svg Source: http://upload.wikimedia.org/wikipedia/commons/7/74/Ipv4_address.svg License: Public domain Contrib-
utors: Own work Original artist: Indeterminate
File:Ipv6_address.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/15/Ipv6_address.svg License: Public domain Contrib-
utors: Own work Original artist: Indeterminate
File:Link-code-word.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/15/Link-code-word.svg License: Public domain
Contributors: Own work Original artist: Paolo Liberatore
File:Mac_lc_printer_modem_ports.jpg Source: http://upload.wikimedia.org/wikipedia/commons/d/de/Mac_lc_printer_modem_ports.
jpg License: CC-BY-SA-3.0 Contributors: Own work Original artist: Caroline Ford
File:Mergefrom.svg Source: http://upload.wikimedia.org/wikipedia/commons/0/0f/Mergefrom.svg License: Public domain Contributors:
? Original artist: ?
File:Network_card.jpg Source: http://upload.wikimedia.org/wikipedia/commons/9/9e/Network_card.jpg License: CC-BY-SA-3.0 Con-
tributors: ? Original artist: ?
File:Network_switches.jpg Source: http://upload.wikimedia.org/wikipedia/commons/e/e5/Network_switches.jpg License: CC-BY-SA-
3.0 Contributors: Own work Original artist: ShakataGaNai
File:Normal-link-pulses.svg Source: http://upload.wikimedia.org/wikipedia/commons/5/59/Normal-link-pulses.svg License: Public do-
main Contributors: Own work Original artist: Paolo Liberatore
File:Padlock-silver.svg Source: http://upload.wikimedia.org/wikipedia/commons/f/fc/Padlock-silver.svg License: ? Contributors: http:
//openclipart.org/people/Anonymous/padlock_aj_ashton_01.svg Original artist: This image le was created by AJ Ashton. Uploaded from
English WP by User:Eleassar. Converted by User:AzaToth to a silver color.
File:Question_book-new.svg Source: http://upload.wikimedia.org/wikipedia/en/9/99/Question_book-new.svg License: ? Contributors:
Created from scratch in Adobe Illustrator. Based on Image:Question book.png created by User:Equazcion Original artist:
Tkgd2007
File:RS-485_3_wire_connection.png Source: http://upload.wikimedia.org/wikipedia/en/b/b9/RS-485_3_wire_connection.png License:
? Contributors: ? Original artist: ?
21.12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES 115
File:RS-485_waveform.svg Source: http://upload.wikimedia.org/wikipedia/commons/f/f2/RS-485_waveform.svg License: CC-BY-SA-
3.0 Contributors: Transferred from en.wikipedia Original artist: Roy Vegard Ovesen (Royvegard at en.wikipedia)
File:RS232-UART_Oscilloscope_Screenshot.png Source: http://upload.wikimedia.org/wikipedia/commons/e/e1/RS232-UART_
Oscilloscope_Screenshot.png License: CC-BY-SA-3.0 Contributors: Own work Original artist: Haji akhundov
File:RS232_PCI-E.jpg Source: http://upload.wikimedia.org/wikipedia/commons/5/56/RS232_PCI-E.jpg License: Public domain Con-
tributors: Transferred from en.wikipedia, transfer was stated to be made by GreyCat. Original artist: Original version: Towel401. Later
version: Kbh3rd.
File:Rs232_oscilloscope_trace.svg Source: http://upload.wikimedia.org/wikipedia/commons/b/b0/Rs232_oscilloscope_trace.svg Li-
cense: ? Contributors:
Rs232_oscilloscope_trace.jpg Original artist: Rs232_oscilloscope_trace.jpg: Ktnbn
File:Rs485-bias-termination.svg Source: http://upload.wikimedia.org/wikipedia/commons/9/96/Rs485-bias-termination.svg License:
CC0 Contributors: Own work Original artist: Stndle
File:SMSC_LAN91C110_ethernet_chip.jpg Source: http://upload.wikimedia.org/wikipedia/commons/8/82/SMSC_LAN91C110_
ethernet_chip.jpg License: CC-BY-SA-3.0 Contributors: Own work Original artist: Nixdorf
File:SRI_First_Internetworked_Connection_diagram.jpg Source: http://upload.wikimedia.org/wikipedia/commons/d/d5/SRI_First_
Internetworked_Connection_diagram.jpg License: CC-BY-SA-3.0 Contributors: SRI International Original artist: SRI International
File:SRI_Packet_Radio_Van.jpg Source: http://upload.wikimedia.org/wikipedia/commons/0/0d/SRI_Packet_Radio_Van.jpg License:
CC-BY-SA-3.0 Contributors: SRI International Original artist: SRI International
File:Serial_port.jpg Source: http://upload.wikimedia.org/wikipedia/commons/e/ea/Serial_port.jpg License: Public domain Contributors:
Own work Original artist: Duncan Lithgow
File:Siemens_ESM_TP80.JPGSource: http://upload.wikimedia.org/wikipedia/commons/c/c4/Siemens_ESM_TP80.JPGLicense: Pub-
lic domain Contributors: Own work Original artist: Mixabest
File:TCP_CLOSE.svg Source: http://upload.wikimedia.org/wikipedia/commons/5/55/TCP_CLOSE.svg License: CC-BY-SA-3.0 Con-
tributors: https://secure.wikimedia.org/wikipedia/commons/wiki/File:Fin_de_conexi%C3%B3n_TCP.svg Original artist: Clemente
File:Tcp.svg Source: http://upload.wikimedia.org/wikipedia/commons/d/db/Tcp.svg License: CC-BY-SA-3.0 Contributors: Own work
Original artist: Mike de
File:Tcp_state_diagram_fixed_new.svg Source: http://upload.wikimedia.org/wikipedia/commons/f/f6/Tcp_state_diagram_fixed_
new.svg License: CC-BY-SA-3.0-2.5-2.0-1.0 Contributors: Based on File:Tcp state diagram xed.svg Original artist: Sergiodc2, Marty
Pauley, Scil100
File:UDP_encapsulation.svg Source: http://upload.wikimedia.org/wikipedia/commons/3/3b/UDP_encapsulation.svg License: CC-BY-
SA-3.0 Contributors: Original artwork by en:User:Cburnett Original artist: en:User:Cburnett original work, colorization by en:User:Kbrose
File:Wiki_letter_w_cropped.svg Source: http://upload.wikimedia.org/wikipedia/commons/1/1c/Wiki_letter_w_cropped.svg License:
CC-BY-SA-3.0 Contributors:
Wiki_letter_w.svg Original artist: Wiki_letter_w.svg: Jarkko Piiroinen
File:Wikibooks-logo-en-noslogan.svg Source: http://upload.wikimedia.org/wikipedia/commons/d/df/Wikibooks-logo-en-noslogan.
svg License: CC-BY-SA-3.0 Contributors: Own work Original artist: User:Bastique, User:Ramac et al.
File:Wikiversity-logo.svg Source: http://upload.wikimedia.org/wikipedia/commons/9/91/Wikiversity-logo.svg License: ? Contributors:
Snorky (optimized and cleaned up by verdy_p) Original artist: Snorky (optimized and cleaned up by verdy_p)
File:Wire_blue.svg Source: http://upload.wikimedia.org/wikipedia/commons/d/de/Wire_blue.svg License: GPL Contributors: ? Original
artist: ?
File:Wire_brown.svg Source: http://upload.wikimedia.org/wikipedia/commons/d/d0/Wire_brown.svg License: GPL Contributors: ?
Original artist: ?
File:Wire_green.svg Source: http://upload.wikimedia.org/wikipedia/commons/d/d9/Wire_green.svg License: GPL Contributors: ? Orig-
inal artist: ?
File:Wire_orange.svg Source: http://upload.wikimedia.org/wikipedia/commons/c/c7/Wire_orange.svg License: GPL Contributors: ?
Original artist: ?
File:Wire_white_blue_stripe.svg Source: http://upload.wikimedia.org/wikipedia/commons/2/29/Wire_white_blue_stripe.svg License:
GPL Contributors: ? Original artist: ?
File:Wire_white_brown_stripe.svg Source: http://upload.wikimedia.org/wikipedia/commons/3/3b/Wire_white_brown_stripe.svg Li-
cense: GPL Contributors: ? Original artist: ?
File:Wire_white_green_stripe.svg Source: http://upload.wikimedia.org/wikipedia/commons/c/c4/Wire_white_green_stripe.svg Li-
cense: GPL Contributors: ? Original artist: ?
File:Wire_white_orange_stripe.svg Source: http://upload.wikimedia.org/wikipedia/commons/d/dd/Wire_white_orange_stripe.svg Li-
cense: GPL Contributors: ? Original artist: ?
File:_Ipv4_address.svg Source: http://upload.wikimedia.org/wikipedia/commons/7/74/Ipv4_address.svg License: Public domain Con-
tributors: Own work Original artist: Indeterminate
21.12.3 Content license
Creative Commons Attribution-Share Alike 3.0