Tcpip Tutorial And Technical Overview 7th Edition Ibm Redbooks

Tcpip Tutorial And Technical Overview 7th
Edition Ibm Redbooks download
https://ebookbell.com/product/tcpip-tutorial-and-technical-
overview-7th-edition-ibm-redbooks-929444
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Tcp Ip Tutorial And Technical Overview 8th Edition Lydia Parziale
https://ebookbell.com/product/tcp-ip-tutorial-and-technical-
overview-8th-edition-lydia-parziale-2168648
Tcpip Illustrated Vol 1 2nd Ed Kevin R Fall W Richard Stevens
https://ebookbell.com/product/tcpip-illustrated-vol-1-2nd-ed-kevin-r-
fall-w-richard-stevens-47033106
Tcp Ip For Dummies Candace Leiden Marshall Wilensky
https://ebookbell.com/product/tcp-ip-for-dummies-candace-leiden-
marshall-wilensky-47608262
Tcp Ip Essentials A Labbased Approach Shivendra S Panwar Shiwen Mao
https://ebookbell.com/product/tcp-ip-essentials-a-labbased-approach-
shivendra-s-panwar-shiwen-mao-2011448

Tcpip Network Administration 3rd Edition 3rd Edition Craig Hunt
https://ebookbell.com/product/tcpip-network-administration-3rd-
edition-3rd-edition-craig-hunt-2112678
Tcpip Sockets In Java Second Edition Practical Guide For Programmers
Kenneth L Calvert
https://ebookbell.com/product/tcpip-sockets-in-java-second-edition-
practical-guide-for-programmers-kenneth-l-calvert-2310140
Tcp Ip Protocol For Beginners The Ultimate Beginners Guide To Learn
Tcp Ip Protocol Step By Step Claudia Alves
https://ebookbell.com/product/tcp-ip-protocol-for-beginners-the-
ultimate-beginners-guide-to-learn-tcp-ip-protocol-step-by-step-
claudia-alves-23904024
Tcp Ip Protocol Suite 4th Edition Behrouz A Forouzan
https://ebookbell.com/product/tcp-ip-protocol-suite-4th-edition-
behrouz-a-forouzan-2426314
Tcp Ip Analysis And Troubleshooting Toolkit 1st Edition Kevin Burns
https://ebookbell.com/product/tcp-ip-analysis-and-troubleshooting-
toolkit-1st-edition-kevin-burns-2526046

ibm.com/redbooks
TCP/IP Tutorial and
Technical Overview
Adolfo Rodriguez
John Gatrell
John Karas
Roland Peschke
Understand networking fundamentals
of the TCP/IP protocol suite
Contains advanced concepts
such as QoS and security
Includes the latest
TCP/IP protocols

TCP/IP Tutorial and Technical Overview
August 2001
GG24-3376-06
International Technical Support Organization

© Copyright International Business Machines Corporation 1989-2001. All rights reserved.
Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject to
restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Seventh Edition (August 2001)
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. HZ8 Building 678
P.O. Box 12195
Research Triangle Park, NC 27709-2195
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
Before using this information and the product it supports, be sure to read the general information in
Appendix B, “Special notices” on page 913.
Take Note!

© Copyright IBM Corp. 2001 iii
Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xix
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Part 1. Core TCP/IP protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Architecture, history, standards, and trends . . . . . . . . . . . . 3
1.1 TCP/IP architectural model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Internetworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 The TCP/IP protocol layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 TCP/IP applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.4 Bridges, routers, and gateways . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 The roots of the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 ARPANET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 NSFNET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.3 Commercial use of the Internet. . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.4 Internet2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.5 The Open Systems Interconnection (OSI) Reference Model . . . . 19
1.3 TCP/IP standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1 Request For Comments (RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.2 Internet standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4 Future of the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.1 Multimedia applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.2 Commercial use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.3 The wireless Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 2. Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1 Ethernet and IEEE 802.x Local Area Networks (LANs) . . . . . . . . . . . . 29
2.2 Fiber Distributed Data Interface (FDDI) . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Serial Line IP (SLIP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Point-to-Point Protocol (PPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Point-to-Point encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Integrated Services Digital Network (ISDN) . . . . . . . . . . . . . . . . . . . . 36
2.6 X.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7 Frame relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.1 Frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7.2 Interconnect issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7.3 Data link layer parameter negotiation . . . . . . . . . . . . . . . . . . . . . 41
2.7.4 IP over frame relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8 PPP over SONET and SDH circuits . . . . . . . . . . . . . . . . . . . . . . . . . . 43

iv TCP/IP Tutorial and Technical Overview
2.8.1 Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.9 Multi-Path Channel+ (MPC+) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.10 Asynchronous Transfer Mode (ATM) . . . . . . . . . . . . . . . . . . . . . . . . 44
2.10.1 Address resolution (ATMARP and InATMARP). . . . . . . . . . . . . 45
2.10.2 Classical IP over ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.10.3 ATM LAN emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.10.4 Classical IP over ATM versus LAN emulation . . . . . . . . . . . . . . 57
2.11 Multiprotocol over ATM (MPOA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.11.1 Benefits of MPOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.11.2 MPOA logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.11.3 MPOA functional components. . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.11.4 MPOA operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.12 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 3. Internetworking protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1 Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.1 IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.2 IP subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.3 IP routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.1.4 Methods of delivery - unicast, broadcast, multicast, and anycast 80
3.1.5 The IP address exhaustion problem . . . . . . . . . . . . . . . . . . . . . . 83
3.1.6 Intranets - private IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.1.7 Classless Inter-Domain Routing (CIDR) . . . . . . . . . . . . . . . . . . . 86
3.1.8 IP datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2 Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . . . . . . . . 102
3.2.1 ICMP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.2.2 ICMP applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.3 Internet Group Management Protocol (IGMP). . . . . . . . . . . . . . . . . . 113
3.4 Address Resolution Protocol (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.4.1 ARP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.4.2 ARP detailed concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.4.3 ARP and subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.4.4 Proxy-ARP or transparent subnetting . . . . . . . . . . . . . . . . . . . . 118
3.5 Reverse Address Resolution Protocol (RARP) . . . . . . . . . . . . . . . . . 120
3.5.1 RARP concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.6 Bootstrap protocol (BOOTP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.6.1 BOOTP forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.6.2 BOOTP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.7 Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . 126
3.7.1 The DHCP message format . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.7.2 DHCP message types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.7.3 Allocating a new network address. . . . . . . . . . . . . . . . . . . . . . . 130
3.7.4 DHCP lease renewal process . . . . . . . . . . . . . . . . . . . . . . . . . . 133

v
3.7.5 Reusing a previously allocated network address. . . . . . . . . . . . 134
3.7.6 Configuration parameters repository. . . . . . . . . . . . . . . . . . . . . 135
3.7.7 DHCP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
3.7.8 BOOTP and DHCP interoperability . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 4. Routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.1 Autonomous systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.2 Types of IP routing and IP routing algorithms . . . . . . . . . . . . . . . . . . 140
4.2.1 Static routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.2.2 Distance vector routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.2.3 Link state routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.2.4 Hybrid routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.3 Routing Information Protocol (RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.3.1 RIP packet types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.3.2 RIP packet format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.3.3 RIP modes of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.3.4 Calculating distance vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.3.5 Convergence and counting to infinity . . . . . . . . . . . . . . . . . . . . 148
4.3.6 RIP limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.4 Routing Information Protocol Version 2 (RIP-2) . . . . . . . . . . . . . . . . 152
4.4.1 RIP-2 packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
4.4.2 RIP-2 limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
4.5 RIPng for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
4.5.1 Differences between RIPng and RIP-2 . . . . . . . . . . . . . . . . . . . 155
4.5.2 RIPng packet format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
4.6 Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
4.6.1 OSPF terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.6.2 OSPF packet types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.6.3 Neighbor communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.6.4 OSPF neighbor state machine . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.6.5 OSPF virtual links and transit areas . . . . . . . . . . . . . . . . . . . . . 169
4.6.6 OSPF route redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.6.7 OSPF stub areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.6.8 OSPF route summarization. . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.7 Enhanced Interior Gateway Routing Protocol (EIGRP) . . . . . . . . . . . 174
4.7.1 Features of EIGRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.7.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.7.3 Neighbor discovery and recovery . . . . . . . . . . . . . . . . . . . . . . . 177
4.7.4 The DUAL algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
4.7.5 EIGRP packet types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.8 Exterior Gateway Protocol (EGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
4.9 Border Gateway Protocol (BGP). . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
4.9.1 BGP concepts and terminology. . . . . . . . . . . . . . . . . . . . . . . . . 181

vi TCP/IP Tutorial and Technical Overview
4.9.2 IBGP and EBGP communication. . . . . . . . . . . . . . . . . . . . . . . . 183
4.9.3 Protocol description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4.9.4 Path selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
4.9.5 BGP synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
4.9.6 BGP aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.9.7 BGP confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.9.8 BGP route reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
4.10 Routing protocol selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.11 Additional functions performed by the router . . . . . . . . . . . . . . . . . 198
4.12 Routing processes in UNIX-based systems . . . . . . . . . . . . . . . . . . 199
Chapter 5. Transport layer protocols . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.1 Ports and sockets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.1.1 Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.1.2 Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
5.2.1 UDP datagram format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.2.2 UDP application programming interface . . . . . . . . . . . . . . . . . . 206
5.3 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . . . . . . . . . . 206
5.3.1 TCP concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
5.3.2 TCP application programming interface . . . . . . . . . . . . . . . . . . 220
5.3.3 TCP congestion control algorithms . . . . . . . . . . . . . . . . . . . . . . 221
Chapter 6. IP multicast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.1 Multicast addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.1.1 Multicasting on a single physical network . . . . . . . . . . . . . . . . . 230
6.1.2 Multicasting between network segments. . . . . . . . . . . . . . . . . . 231
6.2 Internet Group Management Protocol (IGMP). . . . . . . . . . . . . . . . . . 232
6.2.1 IGMP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.2.2 IGMP operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.3 Multicast delivery tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
6.4 Multicast forwarding algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.4.1 Reverse path forwarding algorithm . . . . . . . . . . . . . . . . . . . . . . 236
6.4.2 Center-based tree algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.4.3 Multicast routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.5 Distance Vector Multicast Routing Protocol (DVMRP) . . . . . . . . . . . 238
6.5.1 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.5.2 Building and maintaining multicast delivery trees . . . . . . . . . . . 240
6.5.3 DVMRP tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
6.6 Multicast OSPF (MOSPF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
6.6.1 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
6.6.2 MOSPF and multiple OSPF areas . . . . . . . . . . . . . . . . . . . . . . 244
6.6.3 MOSPF and multiple autonomous systems. . . . . . . . . . . . . . . . 245

vii
6.6.4 MOSPF interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.7 Protocol Independent Multicast (PIM). . . . . . . . . . . . . . . . . . . . . . . . 245
6.7.1 PIM dense mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.7.2 PIM sparse mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
6.8 Interconnecting multicast domains . . . . . . . . . . . . . . . . . . . . . . . . . . 251
6.8.1 Multicast Source Discovery Protocol (MSDP) . . . . . . . . . . . . . . 251
6.8.2 Border Gateway Multicast Protocol. . . . . . . . . . . . . . . . . . . . . . 253
6.9 The multicast backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.9.1 MBONE routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.9.2 Multicast applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Part 2. TCP/IP application protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Chapter 7. Application structure and programming interfaces . . . . . 261
7.1 Characteristics of applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
7.1.1 Client/server model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
7.2 Application programming interfaces (APIs) . . . . . . . . . . . . . . . . . . . . 262
7.2.1 The socket API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
7.2.2 Remote Procedure Call (RPC) . . . . . . . . . . . . . . . . . . . . . . . . . 266
7.2.3 Windows Sockets Version 2 (Winsock V2.0). . . . . . . . . . . . . . . 271
7.2.4 SNMP Distributed Programming Interface (SNMP DPI) . . . . . . 273
7.2.5 FTP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
7.2.6 CICS socket interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7.2.7 IMS socket interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7.2.8 Sockets Extended. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7.2.9 REXX sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Chapter 8. Directory and naming protocols . . . . . . . . . . . . . . . . . . . . 279
8.1 Domain Name System (DNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
8.1.1 The hierarchical namespace. . . . . . . . . . . . . . . . . . . . . . . . . . . 280
8.1.2 Fully Qualified Domain Names (FQDNs). . . . . . . . . . . . . . . . . . 281
8.1.3 Generic domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
8.1.4 Country domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
8.1.5 Mapping domain names to IP addresses . . . . . . . . . . . . . . . . . 282
8.1.6 Mapping IP addresses to domain names – pointer queries . . . . 282
8.1.7 The distributed name space . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
8.1.8 Domain name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
8.1.9 Domain Name System resource records. . . . . . . . . . . . . . . . . . 288
8.1.10 Domain Name System messages . . . . . . . . . . . . . . . . . . . . . . 290
8.1.11 A simple scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
8.1.12 Extended scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
8.1.13 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
8.1.14 DNS applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

viii TCP/IP Tutorial and Technical Overview
8.1.15 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
8.2 Dynamic Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
8.2.1 The UPDATE DNS message format . . . . . . . . . . . . . . . . . . . . . 301
8.2.2 The IBM implementation of DDNS . . . . . . . . . . . . . . . . . . . . . . 304
8.2.3 Proxy A Record update (ProxyArec) . . . . . . . . . . . . . . . . . . . . . 313
8.3 Network Information System (NIS) . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.4 Lightweight Directory Access Protocol (LDAP) . . . . . . . . . . . . . . . . . 316
8.4.1 LDAP - iightweight access to X.500 . . . . . . . . . . . . . . . . . . . . . 317
8.4.2 The LDAP directory server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
8.4.3 Overview of LDAP architecture . . . . . . . . . . . . . . . . . . . . . . . . . 320
8.4.4 LDAP models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
8.4.5 LDAP security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
8.4.6 LDAP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
8.4.7 LDAP and DCE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
8.4.8 The directory-enabled networks initiative (DEN) . . . . . . . . . . . . 334
8.4.9 Web-Based Enterprise Management (WBEM) . . . . . . . . . . . . . 335
8.4.10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Chapter 9. Remote execution and distributed computing . . . . . . . . . 337
9.1 TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
9.1.1 TELNET operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
9.1.2 Terminal emulation (Telnet 3270) . . . . . . . . . . . . . . . . . . . . . . . 344
9.1.3 TN3270 enhancements (TN3270E). . . . . . . . . . . . . . . . . . . . . . 345
9.1.4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
9.2 Remote Execution Command protocol (REXEC and RSH) . . . . . . . . 347
9.2.1 Principle of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
9.3 Introduction to the Distributed Computing Environment (DCE) . . . . . 348
9.3.1 DCE directory service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
9.3.2 DCE security service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
9.3.3 DCE threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
9.3.4 DCE remote procedure call. . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
9.3.5 Distributed time service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
9.3.6 Distributed file service (DFS) . . . . . . . . . . . . . . . . . . . . . . . . . . 361
9.3.7 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Chapter 10. File related protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
10.1 File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
10.1.1 Overview of FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
10.1.2 FTP operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
10.1.3 Reply codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
10.1.4 FTP scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
10.1.5 A sample FTP session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
10.1.6 Anonymous FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

ix
10.1.7 Remote job entry using FTP . . . . . . . . . . . . . . . . . . . . . . . . . . 371
10.2 Trivial File Transfer Protocol (TFTP). . . . . . . . . . . . . . . . . . . . . . . . 371
10.2.1 TFTP usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
10.2.2 Protocol description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
10.2.3 TFTP multicast option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
10.2.4 Security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
10.3 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
10.3.1 NFS concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
10.3.2 NFS Version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
10.3.3 WebNFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
10.3.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
10.4 The Andrew File System (AFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Chapter 11. Mail applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
11.1 Simple Mail Transfer Protocol (SMTP) . . . . . . . . . . . . . . . . . . . . . . 387
11.1.1 How SMTP works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
11.1.2 SMTP and the Domain Name System. . . . . . . . . . . . . . . . . . . 396
11.1.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
11.2 Multipurpose Internet Mail Extensions (MIME) . . . . . . . . . . . . . . . . 399
11.2.1 How MIME works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
11.2.2 The Content-Type field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
11.2.3 The Content-Transfer-Encoding field . . . . . . . . . . . . . . . . . . . 410
11.2.4 Using non-ASCII characters in message headers . . . . . . . . . . 416
11.2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
11.3 Post Office Protocol (POP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
11.3.1 POP3 commands and responses . . . . . . . . . . . . . . . . . . . . . . 419
11.3.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
11.4 Internet Message Access Protocol Version 4 (IMAP4) . . . . . . . . . . 420
11.4.1 IMAP4 underlying electronic mail models . . . . . . . . . . . . . . . . 421
11.4.2 IMAP4 commands and responses. . . . . . . . . . . . . . . . . . . . . . 421
11.4.3 Message numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
11.4.4 IMAP4 states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
11.4.5 Client commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
11.4.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Chapter 12. The World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
12.1 Web browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
12.2 Web servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
12.3 Hypertext Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . . . . . . 429
12.3.1 Overview of HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
12.3.2 HTTP operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
12.4 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
12.4.1 Static content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

x TCP/IP Tutorial and Technical Overview
12.4.2 Client-side dynamic content . . . . . . . . . . . . . . . . . . . . . . . . . . 441
12.4.3 Server-side dynamic content . . . . . . . . . . . . . . . . . . . . . . . . . 442
12.4.4 Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
12.4.5 Developing content with IBM Web Application Servers . . . . . . 446
12.5 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Chapter 13. Multimedia protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
13.1 Real-Time Protocols: RTP and RTCP. . . . . . . . . . . . . . . . . . . . . . . 449
13.1.1 The Real-Time Transport Protocol (RTP) . . . . . . . . . . . . . . . . 450
13.1.2 The Real-Time Control Protocol . . . . . . . . . . . . . . . . . . . . . . . 455
13.1.3 RTCP packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
13.1.4 RTP translators and mixers . . . . . . . . . . . . . . . . . . . . . . . . . . 459
13.1.5 Real-time applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
13.2 IP telephony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
13.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
13.2.2 The IP telephony protocol stack . . . . . . . . . . . . . . . . . . . . . . . 464
13.2.3 ITU-T recommendation H.323. . . . . . . . . . . . . . . . . . . . . . . . . 465
13.2.4 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . . . 470
13.2.5 Media Gateway Control Protocol (MGCP). . . . . . . . . . . . . . . . 472
13.2.6 Media Gateway Controller (Megaco). . . . . . . . . . . . . . . . . . . . 473
13.2.7 Signaling protocol functional comparison . . . . . . . . . . . . . . . . 474
13.2.8 Voice encoding and compression . . . . . . . . . . . . . . . . . . . . . . 476
Chapter 14. Wireless Application Protocol (WAP) . . . . . . . . . . . . . . . 479
14.1 The WAP environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
14.2 Key elements of the WAP specifications. . . . . . . . . . . . . . . . . . . . . 480
14.2.1 Overview of the WAP programming model . . . . . . . . . . . . . . . 480
14.2.2 WAP network configurations . . . . . . . . . . . . . . . . . . . . . . . . . . 483
14.3 Wireless Markup Language (WML) and WMLScript . . . . . . . . . . . . 486
14.3.1 WML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
14.3.2 WMLScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
14.4 Push architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
14.4.1 Push framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
14.4.2 Push proxy gateway (PPG). . . . . . . . . . . . . . . . . . . . . . . . . . . 491
14.4.3 Push access control protocol (PAP) . . . . . . . . . . . . . . . . . . . . 492
14.4.4 Service indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
14.4.5 Push over-the-air protocol (OTA) . . . . . . . . . . . . . . . . . . . . . . 494
14.4.6 Client-side infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
14.4.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
14.5 Overview of the WAP protocol stack. . . . . . . . . . . . . . . . . . . . . . . . 495
14.5.1 Wireless application environment (WAE) . . . . . . . . . . . . . . . . 496
14.5.2 Wireless Telephony Application (WTA) . . . . . . . . . . . . . . . . . . 498
14.5.3 Wireless Session Protocol (WSP) . . . . . . . . . . . . . . . . . . . . . . 498

xi
14.5.4 Wireless Transaction Protocol (WTP) . . . . . . . . . . . . . . . . . . . 511
14.5.5 Wireless Transport Layer Security (WTLS) . . . . . . . . . . . . . . . 514
14.5.6 Wireless Datagram Protocol (WDP) . . . . . . . . . . . . . . . . . . . . 519
14.6 Protocol summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Chapter 15. Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
15.1 Simple Network Management Protocol and MIB overview . . . . . . . 525
15.2 Structure and identification of management information (SMI) . . . . 526
15.3 Management Information Base (MIB) . . . . . . . . . . . . . . . . . . . . . . . 528
15.3.1 IBM-specific MIB part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
15.4 Simple Network Management Protocol (SNMP) . . . . . . . . . . . . . . . 532
15.5 Simple Network Management Protocol Version 2 (SNMPv2) . . . . . 535
15.5.1 SNMPv2 entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
15.5.2 SNMPv2 party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
15.5.3 GetBulkRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
15.5.4 InformRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
15.6 MIB for SNMPv2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
15.7 The new administrative model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
15.8 Simple Network Management Protocol Version 3 (SNMPv3) . . . . . 542
15.8.1 Single authentication and privacy protocol . . . . . . . . . . . . . . . 543
15.9 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Chapter 16. Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
16.1 Remote printing (LPR and LPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
16.2 X Window system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
16.2.1 Functional concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
16.2.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
16.3 Network News Transfer Protocol (NNTP) . . . . . . . . . . . . . . . . . . . . 553
16.4 Finger protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
16.5 Netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Part 3. Advanced concepts and new technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Chapter 17. IP Version 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
17.1 IPv6 overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
17.2 The IPv6 header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
17.2.1 Packet sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
17.2.2 Extension headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
17.2.3 IPv6 addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
17.2.4 Traffic class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
17.2.5 Flow labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
17.3 Internet Control Message Protocol Version 6 (ICMPv6) . . . . . . . . . 579
17.3.1 Neighbor discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

xii TCP/IP Tutorial and Technical Overview
17.3.2 Stateless address autoconfiguration . . . . . . . . . . . . . . . . . . . . 590
17.3.3 Multicast Listener Discovery (MLD) . . . . . . . . . . . . . . . . . . . . 592
17.4 DNS in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
17.4.1 Format of IPv6 resource records. . . . . . . . . . . . . . . . . . . . . . . 595
17.5 DHCP in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
17.5.1 Differences between DHCPv6 and DHCPv4 . . . . . . . . . . . . . . 599
17.5.2 DHCPv6 messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
17.6 Mobility support in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
17.7 Internet transition - Migrating from IPv4 to IPv6 . . . . . . . . . . . . . . . 601
17.7.1 Dual IP stack implementation - the IPv6/IPv4 node. . . . . . . . . 601
17.7.2 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
17.7.3 Header translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
17.7.4 Interoperability summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
17.8 The drive towards IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
17.9 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Chapter 18. Multiprotocol Label Switching (MPLS) . . . . . . . . . . . . . . 613
18.1 MPLS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
18.1.1 Conventional routing model . . . . . . . . . . . . . . . . . . . . . . . . . . 613
18.1.2 MPLS forwarding model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
18.1.3 Additional benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
18.2 Components of an MPLS network . . . . . . . . . . . . . . . . . . . . . . . . . 615
18.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
18.2.2 Label swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
18.2.3 Label switched path (LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
18.2.4 Label stack and label hierarchies . . . . . . . . . . . . . . . . . . . . . . 620
18.2.5 MPLS stacks in a BGP environment . . . . . . . . . . . . . . . . . . . . 622
18.3 Label distribution protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
18.3.1 Types of label distribution protocols . . . . . . . . . . . . . . . . . . . . 624
18.3.2 Label distribution methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
18.4 Stream merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
18.4.1 Merging in a frame-based environment. . . . . . . . . . . . . . . . . . 625
18.4.2 Merging in an ATM environment . . . . . . . . . . . . . . . . . . . . . . . 626
18.5 Multiprotocol Lambda Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Chapter 19. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
19.1 Mobile IP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
19.2 Mobile IP operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
19.3 Mobility agent advertisement extensions . . . . . . . . . . . . . . . . . . . . 632
19.4 Mobile IP registration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
19.5 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
19.6 Broadcast datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
19.7 Move detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

xiii
19.7.1 Returning home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
19.8 ARP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
19.9 Mobile IP security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Chapter 20. Integrating other protocols with TCP/IP . . . . . . . . . . . . . 641
20.1 Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
20.1.1 Performance and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
20.2 Data Link Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
20.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
20.2.2 Functional description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
20.3 Multiprotocol Transport Network (MPTN) . . . . . . . . . . . . . . . . . . . . 645
20.3.1 Requirements for mixed-protocol networking . . . . . . . . . . . . . 645
20.3.2 MPTN architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
20.3.3 MPTN methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
20.3.4 MPTN major components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
20.4 NetBIOS over TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
20.4.1 NetBIOS Name Server (NBNS) implementations . . . . . . . . . . 652
Chapter 21. TCP/IP security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
21.1 Security exposures and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 655
21.1.1 Common attacks against security . . . . . . . . . . . . . . . . . . . . . . 655
21.1.2 Solutions to network security problems. . . . . . . . . . . . . . . . . . 656
21.1.3 Implementations of security solutions . . . . . . . . . . . . . . . . . . . 657
21.1.4 Network security policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
21.2 A short introduction to cryptography . . . . . . . . . . . . . . . . . . . . . . . . 660
21.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
21.2.2 Symmetric or secret-key algorithms . . . . . . . . . . . . . . . . . . . . 663
21.2.3 Asymmetric or public-key algorithms. . . . . . . . . . . . . . . . . . . . 664
21.2.4 Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
21.2.5 Digital certificates and certification authorities . . . . . . . . . . . . 675
21.2.6 Random-number generators . . . . . . . . . . . . . . . . . . . . . . . . . . 676
21.2.7 Export/import restrictions on cryptography . . . . . . . . . . . . . . . 677
21.3 Firewalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
21.3.1 Firewall concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
21.3.2 Components of a firewall system . . . . . . . . . . . . . . . . . . . . . . 680
21.3.3 Packet-filtering router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
21.3.4 Application level gateway (proxy) . . . . . . . . . . . . . . . . . . . . . . 682
21.3.5 Circuit level gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
21.3.6 Types of firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
21.4 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . 694
21.4.1 NAT concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
21.4.2 Translation mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
21.4.3 NAT limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

xiv TCP/IP Tutorial and Technical Overview
21.5 The IP security architecture (IPsec) . . . . . . . . . . . . . . . . . . . . . . . . 698
21.5.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
21.5.2 Authentication Header (AH) . . . . . . . . . . . . . . . . . . . . . . . . . . 702
21.5.3 Encapsulating Security Payload (ESP) . . . . . . . . . . . . . . . . . . 708
21.5.4 Combining IPsec protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
21.5.5 The Internet Key Exchange protocol (IKE) . . . . . . . . . . . . . . . 721
21.6 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
21.6.1 SOCKS Version 5 (SOCKSv5) . . . . . . . . . . . . . . . . . . . . . . . . 741
21.7 Secure Shell (l). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
21.7.1 SSH overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
21.8 Secure Sockets Layer (SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
21.8.1 SSL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
21.8.2 SSL protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
21.9 Transport Layer Security (TLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
21.10 Secure Multipurpose Internet Mail Extension (S-MIME) . . . . . . . . 755
21.11 Virtual private networks (VPN) overview . . . . . . . . . . . . . . . . . . . . 755
21.11.1 VPN Introduction and benefits . . . . . . . . . . . . . . . . . . . . . . . 755
21.12 Kerberos authentication and authorization system . . . . . . . . . . . . 757
21.12.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
21.12.2 Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
21.12.3 Kerberos authentication process. . . . . . . . . . . . . . . . . . . . . . 759
21.12.4 Kerberos database management . . . . . . . . . . . . . . . . . . . . . 763
21.12.5 Kerberos Authorization Model. . . . . . . . . . . . . . . . . . . . . . . . 764
21.12.6 Kerberos Version 5 enhancements . . . . . . . . . . . . . . . . . . . . 764
21.13 Remote access authentication protocols. . . . . . . . . . . . . . . . . . . . 765
21.14 Layer 2 Tunneling Protocol (L2TP) . . . . . . . . . . . . . . . . . . . . . . . . 768
21.14.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
21.14.2 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
21.14.3 L2TP security issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
21.15 Secure electronic transactions (SET) . . . . . . . . . . . . . . . . . . . . . . 773
21.15.1 SET roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
21.15.2 SET transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
21.15.3 The SET certificate scheme . . . . . . . . . . . . . . . . . . . . . . . . . 777
21.16 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Chapter 22. Quality of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
22.1 Why QoS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
22.2 Integrated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
22.2.1 Service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
22.2.2 The Resource Reservation Protocol (RSVP). . . . . . . . . . . . . . 790
22.2.3 Integrated Services outlook . . . . . . . . . . . . . . . . . . . . . . . . . . 803
22.3 Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
22.3.1 Differentiated Services architecture . . . . . . . . . . . . . . . . . . . . 806

xv
22.3.2 Integrated Services (Intserv) over Diffserv networks . . . . . . . . 815
22.3.3 Configuration and administration of DS with LDAP . . . . . . . . . 818
22.3.4 Using Differentiated Services with IPSec . . . . . . . . . . . . . . . . 819
22.4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Chapter 23. Availability, scalability, and load balancing . . . . . . . . . . 823
23.1 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
23.2 Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
23.3 Load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
23.4 Terms used in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
23.4.1 Sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
23.4.2 Workload Manager (WLM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
23.4.3 Virtual IP-address (VIPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
23.4.4 Dynamic XCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
23.4.5 Dynamic IP addressing in a sysplex . . . . . . . . . . . . . . . . . . . . 828
23.4.6 Takeover/takeback of DVIPA addresses. . . . . . . . . . . . . . . . . 830
23.5 Introduction of available solutions. . . . . . . . . . . . . . . . . . . . . . . . . . 832
23.6 Network Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
23.6.1 Network Dispatcher components . . . . . . . . . . . . . . . . . . . . . . 833
23.6.2 Load balancing with weights . . . . . . . . . . . . . . . . . . . . . . . . . . 837
23.6.3 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
23.6.4 Server affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
23.6.5 Rules-based balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
23.6.6 Wide Area Network Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . 840
23.6.7 Combining ISS and Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . 841
23.6.8 Advisors and custom advisors . . . . . . . . . . . . . . . . . . . . . . . . 842
23.6.9 SNMP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
23.6.10 Co-location option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
23.6.11 ISP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
23.6.12 OS/390 Parallel Sysplex support . . . . . . . . . . . . . . . . . . . . . 845
23.7 Cisco LocalDirector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
23.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
23.7.2 Connection and datagram flow . . . . . . . . . . . . . . . . . . . . . . . . 848
23.8 IBM Sysplex Distributor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
23.8.1 Sysplex Distributor elements . . . . . . . . . . . . . . . . . . . . . . . . . 849
23.8.2 Sysplex Distributor initialization and takeover/takeback . . . . . 850
23.8.3 Sysplex Distributor load balancing rules . . . . . . . . . . . . . . . . . 851
23.8.4 Handling connection requests. . . . . . . . . . . . . . . . . . . . . . . . . 851
23.8.5 Data path after connection establishment . . . . . . . . . . . . . . . . 851
23.8.6 Takeover/takeback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
23.8.7 Attaining availability, scalability, and load balancing . . . . . . . . 853
23.9 Cisco MultiNode Load Balancing (MNLB) . . . . . . . . . . . . . . . . . . . . 854
23.9.1 Overview of the MultiNode Load Balancing functions . . . . . . . 855

xvi TCP/IP Tutorial and Technical Overview
23.9.2 Connection establishment and subsequent data flow . . . . . . . 856
23.9.3 Client-server connection restart . . . . . . . . . . . . . . . . . . . . . . . 859
23.9.4 Attaining availability, scalability, and load balancing . . . . . . . . 859
23.10 IBM Sysplex Distributor and Cisco MNLB . . . . . . . . . . . . . . . . . . . 861
23.10.1 What does this mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
23.10.2 Overview of IBM Sysplex Distributor with Service Manager . 863
23.10.3 Cisco Forwarding Agent: overview and functions . . . . . . . . . 864
23.10.4 Cisco Workload Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
23.10.5 Connection establishment process . . . . . . . . . . . . . . . . . . . . 864
23.10.6 Stack, Server, or LPAR failure . . . . . . . . . . . . . . . . . . . . . . . 867
23.10.7 Failure of the Sysplex Distributor . . . . . . . . . . . . . . . . . . . . . 867
23.10.8 Routing packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
23.10.9 Additional tasks of the MNLB components . . . . . . . . . . . . . . 868
23.11 OS/390 DNS/WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
23.11.1 DNS in a sysplex environment . . . . . . . . . . . . . . . . . . . . . . . 870
23.11.2 DNS/WLM with remote name server . . . . . . . . . . . . . . . . . . . 874
23.12 Virtual Router Redundancy Protocol (VRRP) . . . . . . . . . . . . . . . . 875
23.12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
23.12.2 VRRP Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
23.12.3 VRRP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
23.12.4 Sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
23.12.5 VRRP packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
23.13 Round-robin DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
23.14 Alternative solutions to load balancing . . . . . . . . . . . . . . . . . . . . . 884
23.14.1 Network address translation . . . . . . . . . . . . . . . . . . . . . . . . . 884
23.14.2 Encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Appendix A. Platform implementations . . . . . . . . . . . . . . . . . . . . . . . . . 889
A.1 IBM Communications Server for OS/390 V2R10 . . . . . . . . . . . . . . . . . . 889
A.1.1 Supported connectivity protocols and devices . . . . . . . . . . . . . . . . 889
A.1.2 Supported routing applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
A.1.3 Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
A.1.4 Virtual IP Addressing (VIPA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
A.1.5 Sysplex Distributor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
A.1.6 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
A.2 IBM OS/400 V5R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
A.2.1 GUI configuration support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
A.2.2 TCP/IP Connectivity Utilities for IBM ^ iSeries . . . . . . . . . . 898
A.2.3 Dynamic IP routing (RIP and RIP2) . . . . . . . . . . . . . . . . . . . . . . . . 898
A.2.4 Advanced functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
A.2.5 Proxy Address Resolution Protocol (Proxy ARP) . . . . . . . . . . . . . . 900
A.2.6 Point-to-Point Protocol (PPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
A.2.7 Security features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901

xvii
A.2.8 Virtual IP Addressing (VIPA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
A.2.9 Application programming interfaces (APIs) . . . . . . . . . . . . . . . . . . 903
A.2.10 Supported applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
A.3 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
A.3.1 Linux firewall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
A.4 The network computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Appendix B. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Appendix C. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
C.1 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
C.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
C.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
C.4 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957

xviii TCP/IP Tutorial and Technical Overview

© Copyright IBM Corp. 2001 xix
Preface
The TCP/IP protocol suite has become the de facto standard for computer
communications in today’s networked world. The ubiquitous implementation
of a specific networking standard has led to an incredible dependence on the
applications enabled by it. Today, we use the TCP/IP protocols and the
Internet not only for entertainment and information, but to conduct our
business by performing transactions, buying and selling products, and
delivering services to customers. We are continually extending the set of
applications that leverage TCP/IP, thereby driving the need for further
infrastructural support.
In TCP/IP Tutorial and Technical Overview, we take an in-depth look into the
TCP/IP protocol suite. In Part I, we introduce TCP/IP, providing a basic
understanding of the underlying concepts essential to the protocols. We
continue our discussion in Part II with a survey of today’s most popular
TCP/IP application protocols, including emerging wireless and multimedia
applications.
Finally, in Part III, we cover advanced concepts and the latest infrastructural
trends in networking, including IPv6, security, Quality of Service, IP mobility,
and MPLS. We address the challenges that TCP/IP is currently facing and the
technology being developed to overcome them.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization Raleigh Center.
Adolfo Rodriguez is an Advisory I/T Specialist at the International Technical
Support Organization, Raleigh Center. He writes extensively and teaches IBM
classes worldwide on all areas of TCP/IP. Before joining the ITSO, Adolfo
worked in the design and development of Communications Server for
OS/390, in RTP, NC. He holds a B.A. degree in Mathematics and B.S. and
M.S. degrees in Computer Science from Duke University, Durham, NC. He is
currently pursuing a Ph.D. degree in Computer Science at Duke University,
with a concentration on Networking Systems.
John Gatrell works for IBM in the UK. He has 15 years experience in
communications customer support, and a further seven years in programming.
He holds a B.A. Honours degree in Physics from Oxford University. His
specialized areas include UNIX and communications.

xx TCP/IP Tutorial and Technical Overview
John Karas is a network architect in IBM Global Services in the United States.
He has 14 years of experience in the data networking field. He holds a Masters of
Science degree in Telecommunications from Pace University. His areas of
expertise include IP routing algorithms, complex network design, capacity
planning, and application performance testing. He has written extensively on
supporting OSPF and BGP networks, as well as performance monitoring in SAP
environments.
Roland Peschke is a Senior IT Networking Specialist working for IBM
customers requesting consulting and education services for the OS/390
TCP/IP and SNA environment. His comprehensive experiences in these
areas come from working at IBM Germany and ITSO Raleigh for more than
three decades. He worked intensively on several SNA- and TCP/IP Redbooks.
Thanks to the following people for their invaluable contributions to this project:
International Technical Support Organization, Raleigh Center
Gail Christensen, Margaret Ticknor, Jeanne Tucker, David Watts, Juan
Rodriguez, Byron Braswell, Thomas Barlen, Linda Robinson
International Technical Support Organization, Austin Center
Wade Wallace and Matthew Parente
IBM Communication Server for OS/390 Development
Jeff Haggar, Bebe Isrel, Dinakaran Joseph
Cisco Systems, Inc.
Rick Williams and Edward Mazurek
BOPS, Inc.
Ricardo Rodriguez
North Carolina State University
Karina Rodriguez
FIrst Edition authors
Peter Frick, Gerard Bourbigot, Frank Vandewiele
Second Edition authors
Peter Frick, Lesia Cox, Ricardo Haragutchi
Third Edition authors
Philippe Beaupied and Frederic Debulois

xxi
Fourth Edition authors
Philippe Beaupied and Francis Li
Fifth Edition authors
Eamon Murphy, Matthias Enders, Steve Hayes
Sixth Edition authors
Martin Murhammer, Orcun Atakan, Stefan Bretz, Larry Pugh, Kazunari
Suzuki, David Wood
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Please send us your
comments about this or other Redbooks in one of the following ways:
• Fax the evaluation form found in “IBM Redbooks review” on page 957 to
the fax number shown on the form.
• Use the online evaluation form found at ibm.com/redbooks
• Send your comments in an Internet note to redbook@us.ibm.com

xxii TCP/IP Tutorial and Technical Overview

© Copyright IBM Corp. 2001 1
Part 1. Core TCP/IP protocols

2 TCP/IP Tutorial and Technical Overview

© Copyright IBM Corp. 2001 3
Chapter 1. Architecture, history, standards, and trends
Today, the Internet and World Wide Web (WWW) are familiar terms to
millions of people all over the world. Many people depend on applications
enabled by the Internet, such as electronic mail and Web access. In addition,
the increase in popularity of business applications places additional emphasis
on the Internet. The Transmission Control Protocol/Internet Protocol (TCP/IP)
protocol suite is the engine for the Internet and networks worldwide. Its
simplicity and power has lead to its becoming the single network protocol of
choice in the world today. In this chapter, we give an overview of the TCP/IP
protocol suite. We discuss how the Internet was formed, how it developed
and how it is likely to develop in the future.
1.1 TCP/IP architectural model
The TCP/IP protocol suite is so named for two of its most important protocols:
Transmission Control Protocol (TCP) and Internet Protocol (IP). A less used
name for it is the Internet Protocol Suite, which is the phrase used in official
Internet standards documents. We use the more common, shorter term,
TCP/IP, to refer to the entire protocol suite in this book.
1.1.1 Internetworking
The main design goal of TCP/IP was to build an interconnection of networks,
referred to as an internetwork, or internet, that provided universal
communication services over heterogeneous physical networks. The clear
benefit of such an internetwork is the enabling of communication between
hosts on different networks, perhaps separated by a large geographical area.
The words internetwork and internet is simply a contraction of the phrase
interconnected network. However, when written with a capital "I", the Internet
refers to the worldwide set of interconnected networks. Hence, the Internet is
an internet, but the reverse does not apply. The Internet is sometimes called
the connected Internet.
The Internet consists of the following groups of networks:
• Backbones: Large networks that exist primarily to interconnect other
networks. Currently the backbones are NSFNET in the US, EBONE in
Europe, and large commercial backbones.
• Regional networks connecting, for example, universities and colleges.

• Commercial networks providing access to the backbones to subscribers,
and networks owned by commercial organizations for internal use that
also have connections to the Internet.
• Local networks, such as campus-wide university networks.
In most cases, networks are limited in size by the number of users that can
belong to the network, by the maximum geographical distance that the
network can span, or by the applicability of the network to certain
environments. For example, an Ethernet network is inherently limited in terms
of geographical size. Hence, the ability to interconnect a large number of
networks in some hierarchical and organized fashion enables the
communication of any two hosts belonging to this internetwork. Figure 1
shows two examples of internets. Each is comprised of two or more physical
networks.
Figure 1. Internet examples - Two interconnected sets of networks, each seen as one logical
network
Another important aspect of TCP/IP internetworking is the creation of a
standardized abstraction of the communication mechanisms provided by
each type of network. Each physical network has its own
technology-dependent communication interface, in the form of a
Two networks interconnected by a router equals Internet A
Router
R
One
Virtual
Network
Network 1 Network 2
Router
R Network 3
Network 1 Network 2
Router
R
Multiple networks interconnected by routers
(also seen as 1 virtual network, an Internet)
3376a3376F1D1

Chapter 1. Architecture, history, standards, and trends 5
programming interface that provides basic communication functions
(primitives). TCP/IP provides communication services that run between the
programming interface of a physical network and user applications. It enables
a common interface for these applications, independent of the underlying
physical network. The architecture of the physical network is therefore hidden
from the user and from the developer of the application. The application need
only code to the standardized communication abstraction to be able to
function under any type of physical network and operating platform.
As is evident in Figure 1, to be able to interconnect two networks, we need a
computer that is attached to both networks and can forward data packets
from one network to the other; such a machine is called a router. The term IP
router is also used because the routing function is part of the Internet
Protocol portion of the TCP/IP protocol suite (see 1.1.2, “The TCP/IP protocol
layers” on page 5).
To be able to identify a host within the internetwork, each host is assigned an
address, called the IP address. When a host has multiple network adapters
(interfaces), such as with a router, each interface has a unique IP address.
The IP address consists of two parts:
IP address = <network number><host number>
The network number part of the IP address identifies the network within the
internet and is assigned by a central authority and is unique throughout the
internet. The authority for assigning the host number part of the IP address
resides with the organization that controls the network identified by the
network number. The addressing scheme is described in detail in 3.1.1, “IP
addressing” on page 65.
1.1.2 The TCP/IP protocol layers
Like most networking software, TCP/IP is modeled in layers. This layered
representation leads to the term protocol stack, which refers to the stack of
layers in the protocol suite. It can be used for positioning (but not for
functionally comparing) the TCP/IP protocol suite against others, such as
Systems Network Architecture (SNA) and the Open System Interconnection
(OSI) model. Functional comparisons cannot easily be extracted from this, as
there are basic differences in the layered models used by the different
protocol suites.
By dividing the communication software into layers, the protocol stack allows
for division of labor, ease of implementation and code testing, and the ability
to develop alternative layer implementations. Layers communicate with those
above and below via concise interfaces. In this regard, a layer provides a

service for the layer directly above it and makes use of services provided by
the layer directly below it. For example, the IP layer provides the ability to
transfer data from one host to another without any guarantee to reliable
delivery or duplicate suppression. Transport protocols such as TCP make use
of this service to provide applications with reliable, in-order, data stream
delivery. Figure 2 shows how the TCP/IP protocols are modeled in four layers.
Figure 2. The TCP/IP protocol stack - Each layer represents a package of functions
These layers include:
Application layer The application layer is provided by the program
that uses TCP/IP for communication. An
application is a user process cooperating with
another process usually on a different host (there
is also a benefit to application communication
within a single host). Examples of applications
include Telnet and the File Transfer Protocol
(FTP). The interface between the application and
transport layers is defined by port numbers and
sockets, which is described in more detail in 5.1,
“Ports and sockets” on page 201.
Transport layer The transport layer provides the end-to-end data
transfer by delivering data from an application to
its remote peer. Multiple applications can be
supported simultaneously. The most-used
transport layer protocol is the Transmission
Control Protocol (TCP), which provides
connection-oriented reliable data delivery,
duplicate data suppression, congestion control,
and flow control. It is discussed in more detail in
5.3, “Transmission Control Protocol (TCP)” on
Applications
Transport
Internetwork
Network Interface
and
Hardware
Applications
TCP/UDP
ICMP
IP
ARP/RARP
Network Interface
and Hardware
.......
.......
.......
.......

page 206.
Another transport layer protocol is the User
Datagram Protocol (UDP, discussed in 5.2, “User
Datagram Protocol (UDP)” on page 204). It
provides connectionless, unreliable, best-effort
service. As a result, applications using UDP as the
transport protocol have to provide their own
end-to-end integrity, flow control, and congestion
control, if it is so desired. Usually, UDP is used by
applications that need a fast transport mechanism
and can tolerate the loss of some data.
Internetwork layer The internetwork layer, also called the internet
layer or the network layer, provides the "virtual
network" image of an internet (this layer shields
the higher levels from the physical network
architecture below it). Internet Protocol (IP) is the
most important protocol in this layer. It is a
connectionless protocol that doesn't assume
reliability from lower layers. IP does not provide
reliability, flow control, or error recovery. These
functions must be provided at a higher level.
IP provides a routing function that attempts to
deliver transmitted messages to their destination.
IP is discussed in detail in 3.1, “Internet Protocol
(IP)” on page 65. A message unit in an IP network
is called an IP datagram. This is the basic unit of
information transmitted across TCP/IP networks.
Other internetwork layer protocols are IP, ICMP,
IGMP, ARP and RARP.
Network interface layer The network interface layer, also called the link
layer or the data-link layer, is the interface to the
actual network hardware. This interface may or
may not provide reliable delivery, and may be
packet or stream oriented. In fact, TCP/IP does
not specify any protocol here, but can use almost
any network interface available, which illustrates
the flexibility of the IP layer. Examples are IEEE
802.2, X.25 (which is reliable in itself), ATM, FDDI,
and even SNA. Some physical networks and
interfaces are discussed in Chapter 2, “Network

interfaces” on page 29.
TCP/IP specifications do not describe or
standardize any network layer protocols per se;
they only standardize ways of accessing those
protocols from the internetwork layer.
A more detailed layering model is included in Figure 3.
Figure 3. Detailed architectural model
1.1.3 TCP/IP applications
The highest-level protocols within the TCP/IP protocol stack are application
protocols. They communicate with applications on other internet hosts and
are the user-visible interface to the TCP/IP protocol suite.
All application protocols have some characteristics in common:
• They can be user-written applications or applications standardized and
shipped with the TCP/IP product. Indeed, the TCP/IP protocol suite
includes application protocols such as:
- TELNET for interactive terminal access to remote internet hosts.
- FTP (file transfer protocol) for high-speed disk-to-disk file transfers.
- SMTP (simple mail transfer protocol) as an internet mailing system.
These are some of the most widely implemented application protocols, but
many others exist. Each particular TCP/IP implementation will include a
lesser or greater set of application protocols.
• They use either UDP or TCP as a transport mechanism. Remember that
UDP is unreliable and offers no flow-control, so in this case, the
application has to provide its own error recovery, flow control, and
congestion control functionality. It is often easier to build applications on
Applications
Transport
Internetwork
Network Interface
and Hardware
SMTP, Telnet, FTP, Gopher...
TCP UDP
IP
ICMP
ARP RARP
Ethernet, Token-Ring, FDDI, X.25, Wireless, Async, ATM,
SNA...

top of TCP because it is a reliable stream, connection-oriented,
congestion-friendly, flow control enabled protocol. As a result, most
application protocols will use TCP, but there are applications built on UDP
to achieve better performance through reduced protocol overhead.
• Most applications use the client/server model of interaction.
1.1.3.1 The client/server model
TCP is a peer-to-peer, connection-oriented protocol. There are no
master/slave relationships. The applications, however, typically use a
client/server model for communications.
A server is an application that offers a service to internet users; a client is a
requester of a service. An application consists of both a server and a client
part, which can run on the same or on different systems. Users usually invoke
the client part of the application, which builds a request for a particular
service and sends it to the server part of the application using TCP/IP as a
transport vehicle.
The server is a program that receives a request, performs the required
service and sends back the results in a reply. A server can usually deal with
multiple requests and multiple requesting clients at the same time.
Figure 4. The client/server model of applications
Client
A
TCP/IP
Client
B
TCP/IP
Server
TCP/IP
.....
Internet Network

Most servers wait for requests at a well-known port so that their clients know
which port (and in turn, which application) they must direct their requests.
The client typically uses an arbitrary port called an ephemeral port for its
communication. Clients that wish to communicate with a server that does not
use a well-known port must have another mechanism for learning to which
port they must address their requests. This mechanism might employ a
registration service such as portmap, which does use a well-known port.
For detailed information on TCP/IP application protocols, please refer to
Part 2, “TCP/IP application protocols” on page 259.
1.1.4 Bridges, routers, and gateways
There are many ways to provide access to other networks. In an internetwork,
this done with routers. In this section, we distinguish between a router, a
bridge and a gateway for allowing remote network access.
Bridge Interconnects LAN segments at the network interface layer level
and forwards frames between them. A bridge performs the
function of a MAC relay, and is independent of any higher layer
protocol (including the logical link protocol). It provides MAC layer
protocol conversion, if required.
A bridge is said to be transparent to IP. That is, when an IP host
sends an IP datagram to another host on a network connected by
a bridge, it sends the datagram directly to the host and the
datagram "crosses" the bridge without the sending IP host being
aware of it.
Router Interconnects networks at the internetwork layer level and routes
packets between them. The router must understand the
addressing structure associated with the networking protocols it
supports and take decisions on whether, or how, to forward
packets. Routers are able to select the best transmission paths
and optimal packet sizes. The basic routing function is
implemented in the IP layer of the TCP/IP protocol stack, so any
host or workstation running TCP/IP over more than one interface
could, in theory and also with most of today's TCP/IP
implementations, forward IP datagrams. However, dedicated
routers provide much more sophisticated routing than the
minimum functions implemented by IP.
Because IP provides this basic routing function, the term "IP
router," is often used. Other, older terms for router are "IP
gateway," "Internet gateway," and "gateway." The term gateway is

now normally used for connections at a higher layer than the
internetwork layer.
A router is said to be visible to IP. That is, when a host sends an IP
datagram to another host on a network connected by a router, it
sends the datagram to the router so that it can forward it to the
target host.
Gateway Interconnects networks at higher layers than bridges and routers.
A gateway usually supports address mapping from one network to
another, and may also provide transformation of the data between
the environments to support end-to-end application connectivity.
Gateways typically limit the interconnectivity of two networks to a
subset of the application protocols supported on either one. For
example, a VM host running TCP/IP may be used as an
SMTP/RSCS mail gateway.
A gateway is said to be opaque to IP. That is, a host cannot send
an IP datagram through a gateway; it can only send it to a
gateway. The higher-level protocol information carried by the
datagrams is then passed on by the gateway using whatever
networking architecture is used on the other side of the gateway.
Closely related to routers and gateways is the concept of a firewall, or firewall
gateway, which is used to restrict access from the Internet or some untrusted
network to a network or group of networks controlled by an organization for
security reasons. See 21.3, “Firewalls” on page 678 for more information on
firewalls.
1.2 The roots of the Internet
Networks have become a fundamental, if not the most important, part of
today's information systems. They form the backbone for information sharing
in enterprises, governmental and scientific groups. That information can take
several forms. It can be notes and documents, data to be processed by
another computer, files sent to colleagues, and multimedia data streams.
A number of networks were installed in the late 60s and 70s, when network
design was the "state of the art" topic of computer research and sophisticated
The term "gateway," when used in this sense, is not
synonymous with "IP gateway."
Note

implementers. It resulted in multiple networking models such as
packet-switching technology, collision-detection local area networks,
hierarchical networks, and many other excellent communications
technologies.
The result of all this great know-how was that any group of users could find a
physical network and an architectural model suitable for their specific needs.
This ranges from inexpensive asynchronous lines with no other error
recovery than a bit-per-bit parity function, through full-function wide area
networks (public or private) with reliable protocols such as public
packet-switching networks or private SNA networks, to high-speed but
limited-distance local area networks.
The down side of the development of such heterogeneous protocol suites is
the rather painful situation where one group of users wishes to extend its
information system to another group of users who have implemented a
different network technology and different networking protocols. As a result,
even if they could agree on some network technology to physically
interconnect the two environments, their applications (such as mailing
systems) would still not be able to communicate with each other because of
different application protocols and interfaces.
This situation was recognized in the early 70s by a group of U.S. researchers
funded by the Defense Advanced Research Projects Agency (DARPA). Their
work addressed internetworking, or the interconnection of networks. Other
official organizations became involved in this area, such as ITU-T (formerly
CCITT) and ISO. The main goal was to define a set of protocols, detailed in a
well-defined suite, so that applications would be able to communicate with
other applications, regardless of the underlying network technology or the
operating systems where those applications run.
The official organization of these researchers was the ARPANET Network
Working Group, which had its last general meeting in October 1971. DARPA
continued its research for an internetworking protocol suite, from the early
Network Control Program (NCP) host-to-host protocol to the TCP/IP protocol
suite, which took its current form around 1978. At that time, DARPA was well
known for its pioneering of packet-switching over radio networks and satellite
channels. The first real implementations of the Internet were found around
1980 when DARPA started converting the machines of its research network
(ARPANET) to use the new TCP/IP protocols. In 1983, the transition was
completed and DARPA demanded that all computers willing to connect to its
ARPANET use TCP/IP.

DARPA also contracted Bolt, Beranek, and Newman (BBN) to develop an
implementation of the TCP/IP protocols for Berkeley UNIX on the VAX and
funded the University of California at Berkeley to distribute the code free of
charge with their UNIX operating system. The first release of the Berkeley
Software Distribution (BSD) to include the TCP/IP protocol set was made
available in 1983 (4.2BSD). From that point on, TCP/IP spread rapidly among
universities and research centers and has become the standard
communications subsystem for all UNIX connectivity. The second release
(4.3BSD) was distributed in 1986, with updates in 1988 (4.3BSD Tahoe) and
1990 (4.3BSD Reno). 4.4BSD was released in 1993. Due to funding
constraints, 4.4BSD was the last release of the BSD by the Computer
Systems Research Group of the University of California at Berkeley.
As TCP/IP internetworking spread rapidly, new wide area networks were
created in the U.S. and connected to ARPANET. In turn, other networks in
the rest of the world, not necessarily based on the TCP/IP protocols, were
added to the set of interconnected networks. The result is what is described
as The Internet. Some examples of the different networks that have played
key roles in this development are described in the next sections.
1.2.1 ARPANET
Sometimes referred to as the "grand-daddy of packet networks," the
ARPANET was built by DARPA (which was called ARPA at that time) in the
late 60s to accommodate research equipment on packet-switching
technology and to allow resource sharing for the Department of Defense's
contractors. The network interconnected research centers, some military
bases and government locations. It soon became popular with researchers
for collaboration through electronic mail and other services. It was developed
into a research utility run by the Defense Communications Agency (DCA) by
the end of 1975 and split in 1983 into MILNET for interconnection of military
sites and ARPANET for interconnection of research sites. This formed the
beginning of the "capital I" Internet.
In 1974, the ARPANET was based on 56 Kbps leased lines that
interconnected packet-switching nodes (PSN) scattered across the
continental U.S. and western Europe. These were minicomputers running a
protocol known as 1822 (after the number of a report describing it) and
dedicated to the packet-switching task. Each PSN had at least two
connections to other PSNs (to allow alternate routing in case of circuit failure)
and up to 22 ports for user computer (host) connections. These 1822 systems
offered reliable, flow-controlled delivery of a packet to a destination node.
This is the reason why the original NCP protocol was a rather simple protocol.
It was replaced by the TCP/IP protocols, which do not assume reliability of

the underlying network hardware and can be used on other-than-1822
networks. This 1822 protocol did not become an industry standard, so
DARPA decided later to replace the 1822 packet switching technology with
the CCITT X.25 standard.
Data traffic rapidly exceeded the capacity of the 56 Kbps lines that made up
the network, which were no longer able to support the necessary throughput.
Today the ARPANET has been replaced by new technologies in its role of
backbone on the research side of the connected Internet (see NSFNET later
in this chapter), whereas MILNET continues to form the backbone of the
military side.
1.2.2 NSFNET
NSFNET, the National Science Foundation (NSF) Network, is a three-level
internetwork in the United States consisting of:
• The backbone: A network that connects separately administered and
operated mid-level networks and NSF-funded supercomputer centers. The
backbone also has transcontinental links to other networks such as
EBONE, the European IP backbone network.
• Mid-level networks: Three kinds (regional, discipline-based, and
supercomputer consortium networks).
• Campus networks: Whether academic or commercial, connected to the
mid-level networks.
Over the years, the NSF upgraded its backbone to meet the increasing
demands of its clients:
First backbone Originally established by the NSF as a
communications network for researchers and
scientists to access the NSF supercomputers, the first
NSFNET backbone used six DEC LSI/11
microcomputers as packet switches, interconnected
by 56 Kbps leased lines. A primary interconnection
between the NSFNET backbone and the ARPANET
existed at Carnegie Mellon, which allowed routing of
datagrams between users connected to each of those
networks.
Second backbone The need for a new backbone appeared in 1987, when
the first one became overloaded within a few months
(estimated growth at that time was 100 percent per
year). The NSF and MERIT, Inc., a computer network
consortium of eight state-supported universities in
Michigan, agreed to develop and manage a new,

higher-speed backbone with greater transmission and
switching capacities. To manage it, they defined the
Information Services (IS), which is comprised of an
Information Center and a Technical Support Group.
The Information Center is responsible for information
dissemination, information resource management,
and electronic communication. The Technical Support
Group provides support directly to the field. The
purpose of this is to provide an integrated information
system with easy-to-use-and-manage interfaces
accessible from any point in the network supported by
a full set of training services.
Merit and NSF conducted this project in partnership
with IBM and MCI. IBM provided the software,
packet-switching and network-management
equipment, while MCI provided the long-distance
transport facilities. Installed in 1988, the new network
initially used 448 Kbps leased circuits to interconnect
13 nodal switching systems (NSS), supplied by IBM.
Each NSS was composed of nine IBM RISC systems
(running an IBM version of 4.3BSD UNIX) loosely
coupled via two IBM Token-Ring Networks (for
redundancy). One Integrated Digital Network
Exchange (IDNX) supplied by IBM was installed at
each of the 13 locations, to provide:
• Dynamic alternate routing
• Dynamic bandwidth allocation
Third backbone In 1989, the NSFNET backbone circuits topology was
reconfigured after traffic measurements and the speed
of the leased lines increased to T1 (1.544 Mbps) using
primarily fiber optics.
Due to the constantly increasing need for improved
packet switching and transmission capacities, three
NSSs were added to the backbone and the link speed
was upgraded. The migration of the NSFNET
backbone from T1 to T3 (45Mbps) was completed in
late 1992. The subsequent migration to gigabit levels
has already started and is continuing today.

In April 1995, the US government discontinued its funding of NSFNET. This
was, in part, a reaction to growing commercial use of the network. About the
same time, NSFNET gradually migrated the main backbone traffic in the U.S.
to commercial network service providers, and NSFNET reverted to being a
network for the research community. The main backbone network is now run
in cooperation with MCI and is known as the vBNS (very high speed
Backbone Network Service).
NSFNET has played a key role in the development of the Internet. However,
many other networks have also played their part and/or also make up a part
of the Internet today.
1.2.3 Commercial use of the Internet
In recent years the Internet has grown in size and range at a greater rate than
anyone could have predicted. A number of key factors have influenced this
growth. Some of the most significant milestones have been the free
distribution of Gopher in 1991, the first posting, also in 1991, of the
specification for hypertext and, in 1993, the release of Mosaic, the first
graphics-based browser. Today the vast majority of the hosts now connected
to the Internet are of a commercial nature. This is an area of potential and
actual conflict with the initial aims of the Internet, which were to foster open
communications between academic and research institutions. However, the
continued growth in commercial use of the Internet is inevitable, so it will be
helpful to explain how this evolution is taking place.
One important initiative to consider is that of the Acceptable Use Policy
(AUP). The first of these policies was introduced in 1992 and applies to the
use of NSFNET. At the heart of this AUP is a commitment "to support open
research and education." Under "Unacceptable Uses" is a prohibition of "use
for for-profit activities," unless covered by the General Principle or as a
specifically acceptable use. However, in spite of this apparently restrictive
stance, the NSFNET was increasingly used for a broad range of activities,
including many of a commercial nature, before reverting to its original
objectives in 1995.
The provision of an AUP is now commonplace among Internet service
providers, although the AUP has generally evolved to be more suitable for
commercial use. Some networks still provide services free of any AUP.
Let us now focus on the Internet service providers who have been most
active in introducing commercial uses to the Internet. Two worth mentioning
are PSINet and UUNET, which began in the late 80s to offer Internet access
to both businesses and individuals. The California-based CERFnet provided

services free of any AUP. An organization to interconnect PSINet, UUNET
and CERFnet was formed soon after, called the Commercial Internet
Exchange (CIX), based on the understanding that the traffic of any member of
one network may flow without restriction over the networks of the other
members. As of July 1997, CIX had grown to more than 146 members from
all over the world, connecting member internets. At about the same time that
CIX was formed, a non-profit company, Advance Network and Services
(ANS), was formed by IBM, MCI and Merit, Inc. to operate T1 (subsequently
T3) backbone connections for NSFNET. This group was active in increasing
the commercial presence on the Internet.
ANS formed a commercially oriented subsidiary called ANS CO+RE to
provide linkage between commercial customers and the research and
education domains. ANS CO+RE provides access to NSFNET as well as
being linked to CIX. In 1995 ANS was acquired by America Online.
In 1995, as the NSFNET was reverting to its previous academic role, the
architecture of the Internet changed from having a single dominant backbone
in the U.S. to having a number of commercially operated backbones. In order
for the different backbones to be able to exchange data, the NSF set up four
Network Access Points (NAPs) to serve as data interchange points between
the backbone service providers.
Another type of interchange is the Metropolitan Area Ethernet (MAE). Several
MAEs have been set up by Metropolitan Fiber Systems (MFS), who also have
their own backbone network. NAPs and MAEs are also referred to as public
exchange points (IXPs). Internet service providers (ISPs) typically will have
connections to a number of IXPs for performance and backup. For a current
listing of IXPs, consult the Exchange Point at:
http://www.ep.net
Similar to CIX in the United States, European Internet providers formed the
RIPE (Réseaux IP Européens) organization to ensure technical and
administrative coordination. RIPE was formed in 1989 to provide a uniform IP
service to users throughout Europe. Today, the largest Internet backbones
run at OC48 (2.4 Gbps) or OC192 (96 Gbps).
1.2.4 Internet2
The success of the Internet and the subsequent frequent congestion of the
NSFNET and its commercial replacement led to some frustration among the
research community who had previously enjoyed exclusive use of the
Internet. The university community, therefore, together with government and

industry partners, and encouraged by the funding component of the Next
Generation Internet (NGI) initiative, have formed the Internet2 project.
The NGI initiative is a federal research program that is developing advanced
networking technologies, introducing revolutionary applications that require
advanced networking technologies and demonstrating these technological
capabilities on high-speed testbeds.
1.2.4.1 Mission
The Internet2 mission is to facilitate and coordinate the development,
operation, and technology transfer of advanced, network-based applications
and network services to further U.S. leadership in research and higher
education and accelerate the availability of new services and applications on
the Internet.
The goals of Internet2 are the following:
• Demonstrate new applications that can dramatically enhance researchers'
ability to collaborate and conduct experiments.
• Demonstrate enhanced delivery of education and other services (for
instance, health care, environmental monitoring, etc.) by taking advantage
of virtual proximity created by an advanced communications infrastructure.
• Support development and adoption of advanced applications by providing
middleware and development tools.
• Facilitate development, deployment, and operation of an affordable
communications infrastructure, capable of supporting differentiated
Quality of Service (QoS) based on applications requirements of the
research and education community.
• Promote experimentation with the next generation of communications
technologies.
• Coordinate adoption of agreed working standards and common practices
among participating institutions to ensure end-to-end quality of service
and interoperability.
• Catalyze partnerships with governmental and private sector organizations.
• Encourage transfer of technology from Internet2 to the rest of the Internet.
• Study the impact of new infrastructure, services, and applications on
higher education and the Internet community in general.
1.2.4.2 Internet2 participants
Internet2 has 180 participating universities across the United States. Affiliate
organizations provide the project with valuable input. All participants in the

Internet2 project are members of the University Corporation for Advanced
Internet Development (UCAID).
In most respects, the partnership and funding arrangements for Internet2 will
parallel those of previous joint networking efforts of academia and
government, of which the NSFnet project is a very successful example. The
United States government will participate in Internet2 through the NGI
initiative and related programs.
Internet2 also joins with corporate leaders to create the advanced network
services necessary to meet the requirements of broadband, networked
applications. Industry partners work primarily with campus-based and
regional university teams to provide the services and products needed to
implement the applications developed by the project. Major corporations
currently participating in Internet2 include Alcatel, Cisco Systems, IBM, Nortel
Networks, Sprint and Sun Microsystems. Additional support for Internet2
comes from collaboration with non-profit organizations working in research
and educational networking. Affiliate organizations committed to the project
include MCNC, Merit, National Institutes of Health (NIH), and the State
University System of Florida.
For more information on Internet2, see their Web page at:
http://www.internet2.edu
1.2.5 The Open Systems Interconnection (OSI) Reference Model
The OSI (Open Systems Interconnect) Reference Model (ISO 7498) defines a
seven-layer model of data communication with physical transport at the lower
layer and application protocols at the upper layers. This model, shown in
Figure 5, is widely accepted as a basis for the understanding of how a
network protocol stack should operate and as a reference tool for comparing
network stack implementation.

.
Figure 5. The OSI Reference Model
Each layer provides a set of functions to the layer above and, in turn, relies
on the functions provided by the layer below. Although messages can only
pass vertically through the stack from layer to layer, from a logical point of
view, each layer communicates directly with its peer layer on other nodes.
The seven layers are:
Application Network applications such as terminal emulation and file
transfer
Presentation Formatting of data and encryption
Session Establishment and maintenance of sessions
Transport Provision of reliable and unreliable end-to-end delivery
Network Packet delivery, including routing
Data Link Framing of units of information and error checking
Physical Transmission of bits on the physical hardware
In contrast to TCP/IP, the OSI approach started from a clean slate and
defined standards, adhering tightly to their own model, using a formal
committee process without requiring implementations. Internet protocols use
a less formal engineering approach, where anybody can propose and
comment on RFCs, and implementations are required to verify feasibility. The
OSI protocols developed slowly, and because running the full protocol stack
is resource intensive, they have not been widely deployed, especially in the
desktop and small computer market. In the meantime, TCP/IP and the
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application
Presentation
Session
Transport
Network
Data Link
Physical

Internet were developing rapidly, with deployment occurring at a very high
rate.
1.3 TCP/IP standards
TCP/IP has been popular with developers and users alike because of its
inherent openness and perpetual renewal. The same holds true for the
Internet as an open communications network. On the other hand, this
openness could easily turn into a sword with two edges if it were not
controlled in some way. Although there is no overall governing body to issue
directives and regulations for the Internet – control is mostly based on mutual
cooperation – the Internet Society (ISOC) serves as the standardizing body
for the Internet community. It is organized and managed by the Internet
Architecture Board (IAB).
The IAB itself relies on the Internet Engineering Task Force (IETF) for issuing
new standards, and on the Internet Assigned Numbers Authority (IANA) for
coordinating values shared among multiple protocols. The RFC Editor is
responsible for reviewing and publishing new standards documents.
The IETF itself is governed by the Internet Engineering Steering Group
(IESG) and is further organized in the form of Areas and Working Groups
where new specifications are discussed and new standards are propsoed.
The Internet Standards Process, described in RFC 2026 – The Internet
Standards Process - Revision 3, is concerned with all protocols, procedures,
and conventions that are used in or by the Internet, whether or not they are
part of the TCP/IP protocol suite.
The overall goals of the Internet Standards Process are:
• Technical excellence
• Prior implementation and testing
• Clear, concise, and easily understood documentation
• Openness and fairness
• Timeliness
The process of standardization is summarized below:
• In order to have a new specification approved as a standard, applicants
have to submit that specification to the IESG where it will be discussed
and reviewed for technical merit and feasibility and also published as an

Internet draft document. This should take no shorter than two weeks and
no longer than six months.
• Once the IESG reaches a positive conclusion, it issues a last-call
notification to allow the specification to be reviewed by the whole Internet
community.
• After the final approval by the IESG, an Internet draft is recommended to
the Internet Engineering Taskforce (IETF), another subsidiary of the IAB,
for inclusion into the standards track and for publication as a Request for
Comment (see 1.3.1, “Request For Comments (RFC)” on page 22).
• Once published as an RFC, a contribution may advance in status as
described in 1.3.2, “Internet standards” on page 24. It may also be revised
over time or phased out when better solutions are found.
• If the IESG does not approve of a new specification after, of if a document
has remained unchanged within, six months of submission, it will be
removed from the Internet drafts directory.
1.3.1 Request For Comments (RFC)
The Internet protocol suite is still evolving through the mechanism of Request
For Comments (RFC). New protocols (mostly application protocols) are being
designed and implemented by researchers, and are brought to the attention
of the Internet community in the form of an Internet draft (ID).1
The largest
source of IDs is the Internet Engineering Task Force (IETF) which is a
subsidiary of the IAB. However, anyone may submit a memo proposed as an
ID to the RFC Editor. There are a set of rules which RFC/ID authors must
follow in order for an RFC to be accepted. These rules are themselves
described in an RFC (RFC 2223) which also indicates how to submit a
proposal for an RFC.
Once an RFC has been published, all revisions and replacements are
published as new RFCs. A new RFC which revises or replaces an existing
RFC is said to "update" or to "obsolete" that RFC. The existing RFC is said to
be "updated by" or "obsoleted by" the new one. For example RFC 1542,
which describes the BOOTP protocol, is a "second edition," being a revision
of RFC 1532 and an amendment to RFC 951. RFC 1542 is therefore labelled
like this: "Obsoletes RFC 1532; Updates RFC 951." Consequently, there is
never any confusion over whether two people are referring to different
versions of an RFC, since there is never more than one current version.
1
Some of these protocols, particularly those dated April 1, can be described as impractical at best. For instance, RFC
1149 (dated 1990 April 1) describes the transmission of IP datagrams by carrier pigeon and RFC 1437 (dated 1993 April
1) describes the transmission of people by electronic mail.

Some RFCs are described as information documents while others describe
Internet protocols. The Internet Architecture Board (IAB) maintains a list of
the RFCs that describe the protocol suite. Each of these is assigned a state
and a status.
An Internet protocol can have one of the following states:
Standard The IAB has established this as an official protocol for
the Internet. These are separated into two groups:
1. IP protocol and above, protocols that apply to the
whole Internet.
2. Network-specific protocols, generally
specifications of how to do IP on particular types
of networks.
Draft standard The IAB is actively considering this protocol as a
possible standard protocol. Substantial and
widespread testing and comments are desired.
Comments and test results should be submitted to the
IAB. There is a possibility that changes will be made in
a draft protocol before it becomes a standard.
Proposed standard These are protocol proposals that may be considered
by the IAB for standardization in the future.
Implementations and testing by several groups are
desirable. Revision of the protocol is likely.
Experimental A system should not implement an experimental
protocol unless it is participating in the experiment and
has coordinated its use of the protocol with the
developer of the protocol.
Informational Protocols developed by other standard organizations,
or vendors, or that are for other reasons outside the
purview of the IAB may be published as RFCs for the
convenience of the Internet community as
informational protocols. Such protocols may, in some
cases, also be recommended for use on the Internet
by the IAB.
Historic These are protocols that are unlikely to ever become
standards in the Internet either because they have
been superseded by later developments or due to lack
of interest.

Protocol status can be any of the following:
Required A system must implement the required protocols.
Recommended A system should implement the recommended
protocol.
Elective A system may or may not implement an elective
protocol. The general notion is that if you are going to
do something like this, you must do exactly this.
Limited use These protocols are for use in limited circumstances.
This may be because of their experimental state,
specialized nature, limited functionality, or historic
state.
Not recommended These protocols are not recommended for general
use. This may be because of their limited functionality,
specialized nature, or experimental or historic state.
1.3.2 Internet standards
Proposed standard, draft standard, and standard protocols are described as
being on the Internet Standards Track. When a protocol reaches the standard
state, it is assigned a standard number (STD). The purpose of STD numbers
is to clearly indicate which RFCs describe Internet standards. STD numbers
reference multiple RFCs when the specification of a standard is spread
across multiple documents. Unlike RFCs, where the number refers to a
specific document, STD numbers do not change when a standard is updated.
STD numbers do not, however, have version numbers since all updates are
made via RFCs and the RFC numbers are unique. Thus to clearly specify
which version of a standard one is referring to, the standard number and all of
the RFCs which it includes should be stated. For instance, the Domain Name
System (DNS) is STD 13 and is described in RFCs 1034 and 1035. To
reference the standard, a form like "STD-13/RFC1034/RFC1035" should be
used.
For some standards track RFCs, the status category does not always contain
enough information to be useful. It is therefore supplemented, notably for
routing protocols, by an applicability statement which is given either in STD 1
or in a separate RFC.
References to the RFCs and to STD numbers will be made throughout this
book, since they form the basis of all TCP/IP protocol implementations.

The following Internet standards are of particular importance:
• STD 1 - Internet Official Protocol Standards
This standard gives the state and status of each Internet protocol or
standard and defines the meanings attributed to each state or status. It is
issued by the IAB approximately quarterly. At the time of writing this
standard is in RFC 2800.
• STD 2 – Assigned Internet Numbers
This standard lists currently assigned numbers and other protocol
parameters in the Internet protocol suite. It is issued by the Internet
Assigned Numbers Authority (IANA). The current edition at the time of
writing is RFC1700.
• STD 3 – Host Requirements
This standard defines the requirements for Internet host software (often by
reference to the relevant RFCs). The standard comes in three parts:
RFC1122 – Requirements for Internet hosts – communications layer,
RFC1123 – Requirements for Internet hosts – application and support, and
RFC 2181 – Clarifications to the DNS Specification.
• STD 4 – Router Requirements
This standard defines the requirements for IPv4 Internet gateway (router)
software. It is defined in RFC 1812 – Requirements for IPv4 Routers.
1.3.2.1 For Your Information (FYI)
A number of RFCs that are intended to be of wide interest to Internet users
are classified as For Your Information (FYI) documents. They frequently
contain introductory or other helpful information. Like STD numbers, an FYI
number is not changed when a revised RFC is issued. Unlike STDs, FYIs
correspond to a single RFC document. For example, FYI 4 - FYI on
Questions and Answers - Answers to Commonly asked "New Internet User"
Questions, is currently in its fifth edition. The RFC numbers are 1177, 1206,
1325 and 1594, and 2664.
1.3.2.2 Obtaining RFCs
RFC and ID documents are available publicly and online and may be best
obtained from the IETF Web site:
http://www.ietf.org
A complete list of current Internet Standards can be found in RFC 2800 –
Internet Official Protocol Standards.

1.4 Future of the Internet
Trying to predict the future of the Internet is not an easy task. Few would
have imagined, even five years ago, the extent to which the Internet has now
become a part of everyday life in business, homes and schools. There are a
number of things, however, about which we can be fairly certain.
1.4.1 Multimedia applications
Bandwidth requirements will continue to increase at massive rates; not only is
the number of Internet users growing rapidly, but the applications being used
are becoming more advanced and therefore consume more bandwidth. New
technologies such as Dense Wave Division Multiplexing (DWDM) are
emerging to meet these high bandwidth demands being placed on the
Internet.
Much of this increasing demand is attributable to the increased use of
multimedia applications. One example is that of Voice over IP technology. As
this technology matures, we are almost certain to see a sharing of bandwidth
between voice and data across the Internet. This raises some interesting
questions for phone companies. The cost to a user of an Internet connection
between Raleigh, NC and Lima, Peru is the same as a connection within
Raleigh - not so for a traditional phone connection. Inevitably, voice
conversations will become video conversations as phone calls become video
conferences.
Today, it is possible to hear radio stations from almost any part of the globe
via the Internet with FM quality. We can watch television channels from all
around the world leading to the clear potential of using the Internet as the
vehicle for delivering movies and all sorts of video signals to consumers
everywhere. It all comes at a price, however, as the infrastructure of the
Internet must adapt to such high bandwidth demands.
1.4.2 Commercial use
The Internet has been through an explosion in terms of commercial use.
Today, almost all large business depend on the Internet, whether for
marketing, sales, customer service, or employee access. These trends are
expected to continue. Electronic stores will continue to flourish by providing
convenience to customers that do not have time to make their way to
traditional stores.
Businesses will rely more and more on the Internet as a means for
communicating branches across the globe. With the popularity of Virtual

Exploring the Variety of Random
Documents with Different Content

SHAGBARK HICKORY
Shagbark Hickory

T
SHAGBARK HICKORY
(Hicoria Ovata)
welve species of hickory grow in the United States, all east of
the Rocky Mountains. None grow anywhere else in the world,
as far as known. They were widely dispersed over the
northern hemisphere in prehistoric times. The records of
geology, written by leaf prints in the rocks, tell of forests of
hickory in Europe, and even in Greenland, probably a hundred
thousand or more years ago, and certainly not in times that can be
called recent. No records there later than the ice age have been
found. This leads to the presumption that the sheet of ice which
pushed down from the North and covered the larger portions of
Europe and North America, overwhelmed the hickory forests, and all
others, as far as the southern limit of the ice’s advance.
In Europe the hickory was utterly destroyed, and it never returned
after the close of the reign of ice; but America was more fortunate.
The ice sheet pushed little farther in its southward course than the
Ohio and Missouri rivers, and forests south of there held their
ground, and they slowly worked their way back north as the ice
withdrew. Hickory recovered part but not all of its lost ground in
America, for it is now found no farther north than southern Canada,
which is more than a thousand miles from its old range in
Greenland.
The early settlers in New England and in the South at once came
into contact with hickory. It was one of the first woods named in this
country, and the name is of Indian origin, and is spelled in no fewer
than seventeen ways in early literature relating to the settlements. It
is probable that John Smith, a prominent man in early Virginia and
New England, was the first man who ever wrote the name. He

spelled it as the Indians pronounced it, “powcohiscora,” and it has
been trimmed down to our word hickory. The Indian word was the
name of a salad or soup made of pounded hickory nuts and water,
and was only indirectly applied to the tree itself.
The first settlers along the Atlantic coast nearly always called this
tree a walnut, and the name white walnut was common. They were
unacquainted with any similar nut-bearing tree in Europe, except the
walnut, and most people preferred applying a name with which they
were already familiar. Hickories and walnuts belong to the same
family, and have many points in common.
Although there are twelve hickories in the United States, and in
many respects they are similar, all are not of equal value. Some are
very scarce, and the wood of others is not up to standard. From a
commercial standpoint, four surpass the others. These are shagbark
(Hicoria ovata), shellbark (Hicoria laciniosa), pignut (Hicoria glabra),
and mockernut (Hicoria alba). The wood of some of the others is as
good, but is scarce; and still others, particularly the pecans, are
abundant enough, but the wood is inferior. It is impossible in
business to separate the hickories. Lumbermen do not do it;
manufacturers cannot do it. In some regions one is more abundant
than the others, and consequently is used in larger quantities, but in
some other region a different species may predominate in the forest
and in the factory. It cannot be truthfully asserted that one hickory is
always as good as another, or even that a certain species in one
region is as good as the same species in another region. All parts of
the same tree do not produce wood of equal value.
Along certain general lines, hickories have many properties in
common. The wood is ring-porous, that is, the inner edge of the
yearly growth ring has a row of large pores. Others are scattered
toward the outer part of the ring, generally decreasing in number
and size outward. There is no distinct division between spring and
summerwood. The medullary rays are thin and obscure. The unaided
eye seldom notices them. The sapwood is white in all species of
hickory, and is usually very thick. The heartwood is reddish.

Common opinion has long held that sapwood is tougher and more
elastic than heartwood, and therefore to be preferred for most
purposes. Tests made a few years ago by the United States Forest
Service ran counter to the long-established opinion of users, by
showing that in most respects the redwood of the heart was as good
as the white sapwood. However, where resiliency is the chief
requisite, as in slender handles, many manufacturers still prefer
sapwood.
Hickory is very strong, probably the strongest wood in common use
in this country. The statement that one wood is stronger than all
others is hardly justified because averages of strength should be
taken, and not isolated instances. Satisfactory averages have not yet
been worked out for a large number of our woods; but, as far as
existing figures may be accepted, hickory is at the head of the list
for strength, toughness, and resiliency. Choice samples of certain
woods may exceed the average of hickory in some of these
particulars. Sugar maple, hornbeam, and locust occasionally show
greater strength than hickory, but they lack in toughness and
resiliency—the very properties which give hickory its chief value for
many purposes.
Considerable misunderstanding exists as to second growth hickory.
Some suppose it consists of trees of commercial size developed from
sprouts where old trees have been cut. That is not generally correct.
When small hickory trees are cut, the stumps often sprout, but hoop
poles are about the only commodity made from that kind of hickory.
If sprouts are left to grow large, the trees produced are generally
defective. Good hickory grows from the nut. The term “second
growth” means little, unless it is explained in each instance just what
conditions are included. In one sense, all young, vigorous trees are
second growth, and that is often the idea in the mind of the speaker.
Some would restrict it to trees which have come up in old fields or
partial clearings, where they have plenty of light, and have grown
rapidly. Their trunks are short, the wood is tough, and there is little
red heartwood. The larger a pine, oak, or poplar, provided it is

sound, the better the wood; but not so with hickory. Great age and
large size add no desirable qualities to this wood.
Shagbark is largest of the true hickories. The pecans are not usually
regarded as true hickories from the wood-user’s viewpoint. Some
shagbarks are 120 feet high and four feet in diameter, but the
average size is about seventy-five tall, two in diameter. There is
confusion of names among all the hickories, and shagbark is
misnamed and over-named as often as any of the others. Many
persons do not know shagbark and shellbark apart, though the
ranges of the two species lie only partly in the same territory.
Shagbark is known as shellbark hickory, shagbark hickory, shellbark,
upland hickory, hickory, scaly bark hickory, white walnut, walnut,
white hickory, and red heart hickory. Most of the names refer to the
bark, which separates into thin strips, often a foot or more long, and
six inches or more wide; and this remains more or less closely
attached to the trunk by the middle, giving the shaggy appearance
to which the tree owes its common name.
The leaf-buds are large and ovate, with yellowish-green and brown
scales. The leaves are compound and alternate; they have rough
stalks containing five or seven leaflets; they are sessile, tapering to a
point and having a rounded base. The lower pair of leaflets is
markedly different from the rest in shape; sharply serrate and thin;
dark green and glabrous above; lighter below. The flowers do not
appear until the leaves have fully matured. They grow in catkins; the
staminate ones are light green, slender, and grow in groups of three
on long peduncles; the pistillate ones grow in spikes of from two to
five flowers. The fruit grows within a dense, green husk, shiny and
smooth on the outside, opening in four parts. The nut is nearly
white, four-angled, and flattened at the sides. The kernel is sweet
and of a strong flavor.
This tree’s range is not much short of 1,000,000 square miles, but it
is not equally abundant in all parts. It grows from southern Maine to
western Florida; is found in Minnesota and Nebraska, and southward
beyond the Mississippi. It is most common and of largest size on the

western slopes of the southern Appalachian mountains and in the
basin of the lower Ohio river. Its favorite habitat is on low hills, or
near streams and swamps, in rich and moderately well drained soil.
The hickories have long tap roots, and they do best in soils which
the tap roots can penetrate, going down like a radish. The root
system makes most hickories difficult trees to transplant. Early in life
they do a large part of their growing under ground, and when that
growth is interrupted, as it must be in transplanting, the young tree
seldom recovers. Those who would grow hickories for timber, nuts,
or as ornaments, should plant the seed where the tree is expected
to remain. Most of the planting of hickory in the forest is done by
squirrels which bury nuts, with the apparent expectation of digging
them up later. Occasionally one is missed, and a young tree starts.
The uses of this wood are typical of all the other hickories. Handles
and light vehicles consume most of it. The markets are in all parts of
this country, and in manufacturing centers in many foreign lands.

BITTERNUT HICKORY
Bitternut Hickory

T
BITTERNUT HICKORY
(Hicoria Minima)
he tannin in the thin shelled nuts which grow abundantly on
this tree gives the name bitternut. The name is truly
descriptive. Gall itself scarcely exceeds the intense bitterness
of the kernel, when crushed between the teeth. The sense of
taste does not immediately detect the bitterness in its full
intensity. A little time seems to be necessary to dissolve the
astringent principal and distribute it to the nerves of taste. When this
has been accomplished, the bitterness remains a long time, seeming
to persist after the last vestige of the cause has been removed. In
that respect it may be likened to the resin of the incense cedar of
California which is among tastes what musk is among odors, nearly
everlasting. The bitterness of this hickory nut has much to do with
the perpetuation of the species. No wild or tame animal will eat the
fruit unless forced by famine. Consequently, the nuts are left to
grow, provided they can get themselves planted. That is not always
easy, for small quadrupeds which bury edible nuts for food, and then
occasionally forget them, show no interest whatever in the
unpalatable bitternut. It is left where it falls, unless running water, or
some other method of locomotion, transports it to another locality.
This happens with sufficient frequency to plant the nuts as widely as
those of any other hickory. It is believed that this is the most
abundant of the hickories.
The tree bears names other than bitternut. It is called swamp
hickory, though that name is more applicable to a different species,
the water hickory. Pig hickory or pignut are names used in several
states, but without good reason. Hogs may sometimes eat the nuts,
but never when anything better can be found. Besides, pignut is the

accepted name of another species (Hicoria glabra). In Louisiana they
call it the bitter pecan tree. Bitter hickory is a common name in
many localities. In New Hampshire it is known as pig walnut, in
Vermont as bitter walnut, and in Texas as white hickory. The names
are so many, and so often apply as well to other hickories as to this,
that the name alone is seldom a safe guide to identification. It has
two or three characters which will help to pick it out from among
others. Its leaves and bark bear considerable resemblance to ash.
The leaves are the smallest among the hickories, and the bark is
never shaggy. The small branches always carry yellow buds, no
matter what the season of the year. The compound leaves are from
six to ten inches long, and consist of from five to nine leaflets,
always an odd number.
Bitternut hickory’s range covers pretty generally the eastern part of
the United States. It is one of the largest and commonest hickories
of New England, and is likewise the common hickory of Kansas,
Nebraska, and Iowa. It grows from Maine through southern Canada
to Minnesota, follows down the western side of the Mississippi valley
to Texas, and extends into western Florida.
Hickory is often lumbered in ways not common with other
hardwoods. It is not generally found in ordinary lumber yards, and is
not cut into lumber as most other woods are. It is in a class by itself.
The person who would consult statistics of lumber cut in the United
States to ascertain the quantity of hickory going to market, would
utterly fail to obtain the desired information. The statistics of lumber
cut in the United States for the year 1910 listed the total for hickory
at 272,252,000 feet, distributed among 33 states, and cut by 6,349
mills. Reports by users of this wood in a number of states show that
probably twice as much goes to factories to be manufactured into
finished commodities, as all the sawmills cut. This means that much
hickory goes to factories without having passed through sawmills to
be first converted into lumber. It goes as bolts and billets, and as
logs of various lengths. Some sawmills in the hickory region cut
dimension stock and sell it to factories to be further worked up; but

that is a comparatively small part of the hickory that finds its way to
factories of various kinds. Many sawmills refuse to cut hickory,
claiming that it does not pay them to specialize on a scarce wood.
Scattered trees occur among other timber, but these are left when
the other logging is done. Special operators go after the hickory, and
distribute it among various industries which are in the market for it.
That method often results in much waste, because the man who is
specializing in one commodity, such as wagon poles, ax handles,
sucker-rods, wheel stock, or the like, is apt to cut out only what
meets his requirements, and abandon the rest. Some of the hickory
camps where such stock is roughed out are spectacles of
carelessness and waste, with heaps of rejected hickory which,
though not meeting requirements for the special articles in view, are
valuable for many other things. Few woods contribute to the trash
heap more in proportion to the total cut than hickory; but the waste
nearly all occurs before the factories which finally work up the
products are reached. These factories are often hundreds of miles
from the forests where the hickory grows.
Hickory was not a useful farm timber in early times, as oak and
chestnut were. It decayed quickly when exposed to weather, and
was not suitable for fence rails, posts, house logs, or general lumber.
It was sometimes used for barn floors, but when seasoned it was so
hard to nail that it was not well liked. The pioneers were not able to
use this wood to advantage, because it is a manufacturer’s material,
not a farmer’s or a villager’s standby. It can be said to the credit of
the pioneers, however, that they knew its value for certain purposes,
and employed as much of it as they needed.
Fuel was the most important place for hickory on the farm. All things
considered, it is probably the best firewood of the American forest.
The yawning fireplaces called for cords of wood every month of
winter in the northern states. Enough to make a modern buggy
would go up the chimney in a rich red blaze in an hour, and no one
thought that it was waste; and it was not waste then, because farms
had to be cleared, and firewood was the best use possible for the

hickory at that time. Every cord burned in the chimney was that
much less to be rolled into logheaps and consumed in the clearing
for the new cornfield.
Hickory has always been considered the best material for smoking
meat. More than 30,000 cords a year are now used that way. It was
so used in early times, when every farmer smoked and packed his
own meat. Hickory smoke was supposed to give bacon a flavor
equalled by no other wood; and in addition to that it was believed to
keep the skippers out.
The nuts were made into oil which was thought to be efficacious as
a liniment employed as a remedy against rheumatism to which
pioneers were susceptible because their moccasins were porous and
their feet were often wet. The oil was used also for illuminating
purposes. It fed the flame of a crude lamp.
No other wood equalled hickory for “split brooms,” the kind that
swept the cabins before broom corn was known or carpet sweepers
and vacuum cleaners were invented. The toughness, smoothness,
and strength of hickory made it the best oxbow wood, and the same
property fitted it for barrel hoops. Thousands of fish casks in New
England and tobacco hogsheads in Maryland and Virginia were
hooped with hickory before George Washington was born. The
wood’s value for ax handles was learned early. The Indians used it
for the long, slender handles of their stone hammers with which
they barked trees in their clearings, and broke the skulls of enemies
in war.
Bitternut hickory has about ninety-two per cent of the strength of
shagbark, and seventy-three per cent of its stiffness. It yields
considerably more ash when burned, and is rated a little lower in
fuel value.
Mocker Nut Hickory (Hicoria alba) has many names. It is called mocker nut in
Massachusetts, Rhode Island, New York, New Jersey, Delaware, Alabama,
Mississippi, Louisiana, Texas, Arkansas, Illinois, Iowa, and Kansas; white heart
hickory, Rhode Island, New York, Pennsylvania, Delaware, North Carolina, Texas,

Illinois, Ontario, Iowa, Kansas, Minnesota, and Nebraska; black hickory, Texas,
Mississippi, Louisiana, Missouri; big bud and red hickory, Florida; hardback hickory,
Illinois; white hickory, Pennsylvania, South Carolina; big hickory nut, West Virginia;
hognut, Delaware. The name mocker nut is supposed to refer to the thick shell
and disappointingly small kernel within. The range is not as extensive as some of
the other hickories. Beginning in southern Ontario, it extends westward and
southward to eastern Kansas and the eastern half of Texas. The region of its most
abundant growth is in the basin of the lower Ohio and in Arkansas, the best
specimens appearing in fertile uplands. This is said to be the only hickory that
invades the southern maritime pinebelt, growing on the low country along the
Atlantic and Gulf coasts in abundance. The leaves are fragrant with a powerful,
resinous odor; they have five or seven leaflets with hairy petioles or stems. The
bark resembles that of bitternut, and is not scaly like that of shagbark. The wood
weighs 51.21 pounds per cubic foot. It is hard, strong, tough, flexible. It has about
ninety-four per cent of the strength of shagbark, and eighty per cent of its
stiffness. Certain selected specimens of this species are probably as strong as any
hickory; but, as is the case with all woods, there is great difference between
specimens, and general averages only are to be relied upon. G. W. Letterman, who
collected woods for Sargent’s tests, procured a sample of this hickory near
Allenton, Missouri, which showed strength sufficient to sustain 20,000 pounds per
square inch, and its measure of stiffness was the enormous figure of 2,208,000
pounds per square inch.
The uses of mocker nut hickory do not differ from those of other hickories. The
tree is frequently nearly all sapwood, to which the name white hickory is due.
Some persons suppose that the heartwood is white, but that misconception is due
to the fact that some pretty large trees have no heartwood, but are sap clear
through.
The term “black hickory” is sometimes applied to three species with dark-colored
bark which bears some resemblance to the bark of ash. They are bitternut (Hicoria
minima), pignut (Hicoria glabra), and mocker nut (Hicoria alba). When the word
black is thus used, it refers to the bark and the general outward appearance of the
tree, and not to the wood, which is as white as that of any other hickory.

T
PIGNUT HICKORY
(Hicoria Glabra)
he name of this tree is unfortunate, although so far as the
nuts are concerned, no injustice is done. It is one of the best
hickories in the quality of its wood, and also as an ornamental
tree. It is likewise abundant in many parts of its range, which
extends from Maine to Kansas, Texas, Florida, and throughout
most of the territory enclosed by the boundary lines thus delimited.
The name pignut is common in New England, New York, New Jersey,
Pennsylvania, Delaware, West Virginia, North Carolina, South
Carolina, Florida, Alabama, Mississippi, Louisiana, Texas, Arkansas,
Kentucky, Missouri, Illinois, Indiana, Ohio, Iowa, Kansas, Nebraska,
and Minnesota; bitternut in Arkansas, Illinois, Iowa, and Wisconsin;
black hickory in Mississippi, Louisiana, Arkansas, Missouri, Iowa, and
Indiana; broom hickory in Missouri; brown hickory in Mississippi,
Delaware, Texas, Tennessee, Minnesota; hardshell in West Virginia;
red hickory in Delaware; switch bud hickory in Alabama; and white
hickory in New Hampshire and Iowa.
The nuts are generally bitter, but some trees bear fruit which is not
very offensive to the taste. The avidity with which swine feed upon it
gives the common name. This tree is doubtless confused many times
with bitternut, though their differences are enough to distinguish
them readily if they grow side by side. As far as the woods of the
two species are concerned, there is little occasion to keep them
separate. The pignut is a forked tree more frequently than any other
species of hickory; and the nuts vary in shape and size more than
those of any other. The tree is more remarkable for its variations
than for its regularity. In one thing, however, it is pretty constant:
the limbs and branches are smooth and clean, hence the botanical

name glabra. As a name for this tree, smooth hickory would be
preferable to pignut. Trunks attain a height of eighty or ninety feet
and a diameter of three or four, but the extreme sizes are rare. The
largest specimens are found in the lower Ohio valley, and the species
is most common in Missouri and Arkansas. It grows farther south
and farther west than any other hickory except pecan. Its southern
limit is in Florida and its western in Texas.
The uses of hickory fall into general classes. More is manufactured
into vehicles than into any other single class of commodities, but not
more than into all other articles combined. The second largest users
of hickory are the manufacturers of handles. The third largest
demand comes from makers of agricultural implements and farm
tools. Large amounts are required for athletic goods, meat smoking,
and various miscellaneous purposes. The total amount used yearly in
this country, and exported to foreign countries, is not accurately
known, but it probably exceeds 500,000,000 feet, board measure.
About half of this passes through sawmills in the usual manner, and
the other half goes directly from the forest to the factory or to the
consumer.
The superiority of American buggies, sulkies, and other light vehicles
is due to the hickory in their construction. No other wood equals this
in combination of desirable physical properties. Though heavy, it is
so strong, tough, and resilient that small amounts suffice, and the
weight of the vehicle can be reduced to a lower point, without
sacrificing efficiency, than when any other wood is employed. It is
preëminently a wood for light vehicles. Oak, ash, maple, and elm
answer well enough for heavy wagons where strength is more
essential than toughness and elasticity. Hickory is suitable for
practically all wooden parts of light vehicles except the body. The
slender spokes look like frail dowels, and seem unable to maintain
the load, but appearances are deceptive. The bent rims are likewise
very slender, but they last better than steel. The shafts and poles
with which carriages and carts are equipped will stand severe strains
and twists without starting a splinter. The manufacturing of the stock

is little less than a fine art. In scarcely any other wood-using
industry—probably excepting the making of handles—is the grain so
closely watched. Hickory users generally speak of the annual growth
rings as the grain. The grain must run straight in spokes, rims,
shafts, and poles. If the grain crosses the stick, a break may occur
by the simple process of splitting, and the hickory in that case is no
more dependable than many other woods.
Handle makers observe the same rule, and must have straight grain.
The more slender the handle, the more strictly the rule must be
followed. A cross grained golf club handle would fail at the first
stroke. An ax handle, if it has cross grain, will last a little longer, but
it will speedily split. Many of the best slender handles are of split
hickory. The line of cleavage follows the grain, but a saw does not
always do so. Heavy handles, like those for picks and sledges, are
not so strictly straight grained, because they are made strong
enough to stand much more strain than is ever likely to be put on
them. Red heartwood is frequently used in handles of that kind.
Peavey and canthook handles are generally split from billets,
because the grain must be straight. Though they are among the
largest and heaviest of handles, breakage must be guarded against
with extra care, for the snap of a peavey handle at a critical moment
might cost the operator his life by precipitating a skidway of logs
upon him.
The hickory which goes into agricultural implements fills many
places, among the most important being connecting rods. It is often
made into springs to take up or check oscillation. It is used for that
purpose as picker sticks in textile mills.
Furniture makers could get along without hickory, and they do not
need much. It is oftenest seen in dowels, slender spindles, and the
rungs of chairs. The makers of sporting and athletic goods bend it
for rackets, hoops, and rims, or make vaulting poles, bats, or
trapezes.

Shellbark Hickory (Hicoria laciniosa) is often mistaken for shagbark.
The ranges of the two species coincide in part only. Shagbark grows
farther east, north and south than shellbark. The latter occupies an
island, as it were, inside the shagbark’s range. Shellbark is found
from central New York and eastern Pennsylvania, westward to
Kansas, and southward to North Carolina and middle Tennessee. The
species is at its best in the lower Ohio valley and in Missouri. The
largest trees are 120 feet high and three in diameter, and are often
free from branches half or two-thirds of the length. The species
prefers rich, deep bottom lands, and does not suffer from occasional
inundation from overflowing rivers. The average tree is not quite as
large as shagbark. The leaves are larger than those of any other
hickory, ranging in length from fifteen to twenty-two inches. There
are from five to nine leaflets, usually seven. The upper ones are
largest, and may be eight or nine inches long and four or five wide.
In the autumn the leaflets drop from the petioles which adhere to
the branches and furnish means of identifying the tree in winter. The
nuts including the hulls are as large as small apples. When ripe, the
hulls open and the nuts fall out; but the hulls fall also. The nuts are
as large as shagbark nuts, but the two are seldom distinguished in
market, though the shagbark’s are a little richer in flavor. The bark’s
roughness gives the tree its name. Strips three or four feet long and
five or six inches wide curl up at the lower ends—sometimes at both
ends—and adhere to the trunk several years. The species has other
names. It is known as big shellbark in Rhode Island, Pennsylvania,
West Virginia, Kentucky, Missouri, Illinois, and Kansas; bottom
shellbark in Illinois; western shellbark or simply shellbark in Rhode
Island and Kentucky; thick shellbark in South Carolina, Indiana, and
Tennessee; kingnut in Tennessee.
The wood weighs 50.53 pounds per cubic foot, and is very hard,
strong, tough, and flexible. The heartwood is dark brown, the
sapwood nearly white. This hickory usually has less sapwood in
proportion to heart than other members of the species; but the
wood is not kept separate from the others when it goes to market,
and its uses are as extensive as the other hickories’. It is believed by

some foresters that shellbark hickory is worth cultivating for its nuts,
as it is a vigorous bearer; but little planting has been done. East of
the Alleghanies, particularly in Virginia, some planting has been
carried out on old plantations for ornamental purposes. On account
of its long taproot, the tree is difficult to transplant, and the nuts
should be planted where the trees are expected to remain.

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Tcpip Tutorial And Technical Overview 7th Edition Ibm Redbooks

More Related Content

Similar to Tcpip Tutorial And Technical Overview 7th Edition Ibm Redbooks (20)

Recently uploaded (20)

Tcpip Tutorial And Technical Overview 7th Edition Ibm Redbooks