CP09

CHAPTER 1 DATA COMMUNICATION
CHAPTER 2 INTERNET PROTOCOL
CHAPTER 3 ROUTING PROTOCOLS
CHAPTER 4 TRANSPORT PROTOCOLS
CHAPTER 5 APPLICATION PROTOCOLS
CHAPTER 6 DOMAIN NAME SERVICE
CHAPTER 7 IP VERSION 6
CHAPTER 8 AUTOMATIC CONFIGURATION
TCP/IP
CP09
Issue 1 Revision 4 Training Manual
FOR TRAINING PURPOSES ONLY
TCP/IP
Course
Issue 1 Revision 4 FOR TRAINING PURPOSES ONLY
Positin mark for TED spine
Training Manual Issue 1 Revision 4 Course Training Manual
CP09
TCP/IP
Issue 1 Revision 4
CP09 TCP/IP
E Motorola 1993, 1994, 1995, 1996, 1997, 1998, 1999 All Rights Reserved Printed in the U.K.
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Copyrights, notices and trademarks

Copyrights
The Motorola products described in this document may include copyrighted Motorola computer programs stored in semiconductor memories or other media. Laws in the United States and other countries preserve for Motorola certain exclusive rights for copyright computer programs, including the exclusive right to copy or reproduce in any form the copyright computer program. Accordingly, any copyright Motorola computer programs contained in the Motorola products described in this document may not be copied or reproduced in any manner without the express written permission of Motorola. Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by implication, estoppel or otherwise, any license under the copyrights, patents or patent applications of Motorola, except for the rights that arise by operation of law in the sale of a product.
Restrictions
The software described in this document is the property of Motorola. It is furnished under a license agreement and may be used and/or disclosed only in accordance with the terms of the agreement. Software and documentation are copyright materials. Making unauthorized copies is prohibited by law. No part of the software or documentation may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language, in any form or by any means, without prior written permission of Motorola.
Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola assumes no liability resulting from any inaccuracies or omissions in this document, or from the use of the information obtained herein. Motorola reserves the right to make changes to any products described herein to improve reliability, function, or design, and reserves the right to revise this document and to make changes from time to time in content hereof with no obligation to notify any person of revisions or changes. Motorola does not assume any liability arising out of the application or use of any product or circuit described herein; neither does it convey license under its patent rights of others.
Trademarks
and MOTOROLA are trademarks of Motorola Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. Tandem, Integrity, Integrity S2, and Non-Stop-UX are trademarks of Tandem Computers Incorporated. X Window System, X and X11 are trademarks of the Massachusetts Institute of Technology. Looking Glass is a registered trademark of Visix Software Ltd. OSF/Motif is a trademark of the Open Software Foundation. Ethernet is a trademark of the Xerox Corporation. Wingz is a trademark and INFORMIX is a registered trademark of Informix Software Ltd. SUN, SPARC, and SPARCStation are trademarks of Sun Microsystems Computer Corporation. IBM is a registered trademark of International Business Machines Corporation. HP is a registered trademark of Hewlett Packard Inc.
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Important notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . First aid in case of electric shock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artificial respiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Burns treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reporting safety issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warnings and cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warning labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specific warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RF radiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laser radiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lifting equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Do not ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Battery supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toxic material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Human exposure to radio frequency energy (PCS1900 only) . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum permitted exposures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum permitted exposure ceilings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power density measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beryllium health and safety precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Health issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inhalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Skin contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eye contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disposal methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product life cycle implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caution labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specific cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fibre optics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static discharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 1 2 2 3 3 3 3 4 4 4 5 5 5 5 6 6 6 6 6 6 6 7 7 7 7 8 8 8 8 9 10 10 10 11 11 11 11 12 12 12 12 12 13 13 13 13 13 13
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
Devices sensitive to static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special handling techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Motorola GSM manual set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tandem OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scaleable OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Category number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Catalogue number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ordering manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14 14 14 15 15 15 15 16 16 16 17 17 17
Chapter 1 Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Communication and Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming and Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seven Layer Model for Open System Interconnection (OSI) . . . . . . . . . . . . . . . . . Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request for Comment (RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP (DoD) Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
11 11 12 14 14 14 14 14 14 14 16 16 18 18 110 112 114 116 116 116 116 116 116
Chapter 2 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class A, B, C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class D, E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CP09: TCP/IP
iv
i
21 21 22 24 24 26 26 26
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Example Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reserved Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reserved Address Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Mask: Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Mask: Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Mask Table: Class A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Length Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type of Service Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Length Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flags [D, M] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time-to-Live Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Header Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Option Field Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options Type Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Record Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loose Source Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strict Source Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reverse Address Resolution Protocol (RARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ICMP Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Echo Request/Echo Reply (0 and 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Unreachable (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Quench (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redirect (5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28 210 212 214 216 218 220 222 224 226 232 234 234 234 236 238 238 238 240 240 242 242 244 244 244 244 246 246 246 246 246 246 248 250 250 250 250 250 250 252 252 256 258 258 258 258 258
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Time Exceeded (11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Problem (12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TimeStamp Request/Reply (13, 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Request/Reply (15, 16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Mask Request/Reply (17,18) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
260 260 260 260 260 268
Chapter 3 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing and Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distance Vector Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link-State Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Distance Vector Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Gateway to Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exterior Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Distance Vector Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Gateway Routing Protocol (IGRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link State Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
31 31 32 34 36 36 36 38 38 310 310 312 312 312 314 314 314
Chapter 4 Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source and Destination Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgement number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CP09: TCP/IP
vi
i
41 41 42 42 42 42 44 44 44 44 46 48 48 410 412 414 414 414 414
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Urgent Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
416 418 418 418 418 418 420 422 424 426 428 430 432 434
Chapter 5 Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trivial File Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Mail Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mail Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
51 51 52 52 54 56 56 58 510 512
Chapter 6 Domain Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Domain Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Structure and Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Server Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
61 61 62 62 64 66 68
Chapter 7 IP Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPV4/IPV6 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
71 71 72 72 74 76 76 76 78 710
CP09: TCP/IP
EMOTOROLA LTD. 2001
vii
Issue 1 Revision 4
Multicast Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extension Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jumbo Payload Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Options Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing of Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulating Security Payload Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication and Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Parameters Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neighbour Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
712 712 714 716 718 718 720 722 724 724 726 728 730 732 732 734
Chapter 8 Automatic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Automatic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reverse Address Resolution Protocol (RARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DHCP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of RARP, BOOTP/TFTP and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
81 81 82 84 86 88 88 810 812
Chapter 9 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP09: TCP/IP
viii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
General information
General information
Important notice
If this manual was obtained when you attended a Motorola training course, it will not be updated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If it was supplied under normal operational circumstances, to support a major software release, then corrections will be supplied automatically by Motorola in the form of General Manual Revisions (GMRs).
Purpose
Motorola Global System for Mobile Communications (GSM) Technical Education manuals are intended to support the delivery of Technical Education only and are not intended to replace the use of Customer Product Documentation. WARNING Failure to comply with Motorolas operation, installation and maintenance instructions may, in exceptional circumstances, lead to serious injury or death. These manuals are not intended to replace the system and equipment training offered by Motorola, although they can be used to supplement and enhance the knowledge gained through such training.
About this manual
CP09: TCP/IP
EMOTOROLA LTD. 2001
General information
Issue 1 Revision 4
Cross references
Throughout this manual, cross references are made to the chapter numbers and section names. The section name cross references are printed bold in text. This manual is divided into uniquely identified and numbered chapters that, in turn, are divided into sections. Sections are not numbered, but are individually named at the top of each page, and are listed in the table of contents.
Text conventions
The following conventions are used in the Motorola GSM manuals to represent keyboard input text, screen output text and special key sequences.
Input
Characters typed in at the keyboard are shown like this.
Output
Messages, prompts, file listings, directories, utilities, and environmental variables that appear on the screen are shown like this.
Special key sequences

Special key sequences are represented as follows: CTRL-c ALT-f | CR or RETURN Press the Control and c keys at the same time. Press the Alt and f keys at the same time. Press the pipe symbol key. Press the Return (Enter) key. The Return key is identified with the symbol on both the X terminal and the SPARCstation keyboards. The SPARCstation keyboard Return key is also identified with the word Return.
CP09: TCP/IP
2
EMOTOROLA LTD. 2001
Issue 1 Revision 4
First aid in case of electric shock
First aid in case of electric shock

Warning
WARNING Do not touch the victim with your bare hands until the electric circuit is broken. Switch off. If this is not possible, protect yourself with dry insulating material and pull or push the victim clear of the conductor.
Artificial respiration
In the event of an electric shock it may be necessary to carry out artificial respiration. Send for medical assistance immediately.
Burns treatment
If the patient is also suffering from burns, then, without hindrance to artificial respiration, carry out the following: 1. 2. 3. Do not attempt to remove clothing adhering to the burn. If help is available, or as soon as artificial respiration is no longer required, cover the wound with a dry dressing. Do not apply oil or grease in any form.
CP09: TCP/IP
EMOTOROLA LTD. 2001
Reporting safety issues
Issue 1 Revision 4
Reporting safety issues

Introduction
Whenever a safety issue arises, carry out the following procedure in all instances. Ensure that all site personnel are familiar with this procedure.
Procedure
Whenever a safety issue arises: 1. 2. 3. 4. Make the equipment concerned safe, for example, by removing power. Make no further attempt to tamper with the equipment. Report the problem directly to GSM MCSC +44 (0)1793 430040 (telephone) and follow up with a written report by fax +44 (0)1793 430987 (fax). Collect evidence from the equipment under the guidance of the MCSC.
CP09: TCP/IP
4
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Warnings and cautions
Warnings and cautions

Introduction
The following describes how warnings and cautions are used in this manual and in all manuals of the Motorola GSM manual set.
Warnings
Definition
A warning is used to alert the reader to possible hazards that could cause loss of life, physical injury, or ill health. This includes hazards introduced during maintenance, for example, the use of adhesives and solvents, as well as those inherent in the equipment.
Example and format

WARNING Do not look directly into fibre optic cables or optical data in/out connectors. Laser radiation can come from either the data in/out connectors or unterminated fibre optic cables connected to data in/out connectors.
Cautions
Definition
A caution means that there is a possibility of damage to systems, or individual items of equipment within a system. However, this presents no danger to personnel.
Example and format

CAUTION Do not use test equipment that is beyond its calibration due date when testing Motorola base stations.
CP09: TCP/IP
EMOTOROLA LTD. 2001
General warnings
Issue 1 Revision 4
General warnings
Introduction
Observe the following warnings during all phases of operation, installation and maintenance of the equipment described in the Motorola GSM manuals. Failure to comply with these warnings, or with specific warnings elsewhere in the Motorola GSM manuals, violates safety standards of design, manufacture and intended use of the equipment. Motorola assumes no liability for the customers failure to comply with these requirements.
Warning labels
Personnel working with or operating Motorola equipment must comply with any warning labels fitted to the equipment. Warning labels must not be removed, painted over or obscured in any way.
Specific warnings
Warnings particularly applicable to the equipment are positioned on the equipment and within the text of this manual. These must be observed by all personnel at all times when working with the equipment, as must any other warnings given in text, on the illustrations and on the equipment.
High voltage
Certain Motorola equipment operates from a dangerous high voltage of 230 V ac single phase or 415 V ac three phase mains which is potentially lethal. Therefore, the areas where the ac mains power is present must not be approached until the warnings and cautions in the text and on the equipment have been complied with. To achieve isolation of the equipment from the ac supply, the mains input isolator must be set to off and locked. Within the United Kingdom (UK) regard must be paid to the requirements of the Electricity at Work Regulations 1989. There may also be specific country legislation which need to be complied with, depending on where the equipment is used.
RF radiation
High RF potentials and electromagnetic fields are present in the base station equipment when in operation. Ensure that all transmitters are switched off when any antenna connections have to be changed. Do not key transmitters connected to unterminated cavities or feeders. Refer to the following standards: S S ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to Human Exposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz. CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields High Frequency (10kHz to 300GHz).
Laser radiation
Do not look directly into fibre optic cables or optical data in/out connectors. Laser radiation can come from either the data in/out connectors or unterminated fibre optic cables connected to data in/out connectors. CP09: TCP/IP
6
EMOTOROLA LTD. 2001
Issue 1 Revision 4
General warnings
Lifting equipment
When dismantling heavy assemblies, or removing or replacing equipment, the competent responsible person must ensure that adequate lifting facilities are available. Where provided, lifting frames must be used for these operations. When equipments have to be manhandled, reference must be made to the Manual Handling of Loads Regulations 1992 (UK) or to the relevant manual handling of loads legislation for the country in which the equipment is used.
Do not ...
... substitute parts or modify equipment. Because of the danger of introducing additional hazards, do not install substitute parts or perform any unauthorized modification of equipment. Contact Motorola if in doubt to ensure that safety features are maintained.
Battery supplies
Do not wear earth straps when working with standby battery supplies.
Toxic material
Certain Motorola equipment incorporates components containing the highly toxic material Beryllium or its oxide Beryllia or both. These materials are especially hazardous if: S S S Beryllium materials are absorbed into the body tissues through the skin, mouth, or a wound. The dust created by breakage of Beryllia is inhaled. Toxic fumes are inhaled from Beryllium or Beryllia involved in a fire.
See the Beryllium health and safety precautions section for further information.
CP09: TCP/IP
EMOTOROLA LTD. 2001
Human exposure to radio frequency energy (PCS1900 only)
Issue 1 Revision 4

Introduction
This equipment is designed to generate and radiate radio frequency (RF) energy. It should be installed and maintained only by trained technicians. Licensees of the Federal Communications Commission (FCC) using this equipment are responsible for insuring that its installation and operation comply with FCC regulations designed to limit human exposure to RF radiation in accordance with the American National Standards Institute IEEE Standard C95.1-1991, IEEE Standard for Safety Levels with Respect to Human Exposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
Definitions
This standard establishes two sets of maximum permitted exposure limits, one for controlled environments and another, that allows less exposure, for uncontrolled environments. These terms are defined by the standard, as follows:
Uncontrolled environment
Uncontrolled environments are locations where there is the exposure of individuals who have no knowledge or control of their exposure. The exposures may occur in living quarters or workplaces where there are no expectations that the exposure levels may exceed those shown for uncontrolled environments in the table of maximum permitted exposure ceilings.
Controlled environment
Controlled environments are locations where there is exposure that may be incurred by persons who are aware of the potential for exposure as a concomitant of employment, by other cognizant persons, or as the incidental result of transient passage through areas where analysis shows the exposure levels may be above those shown for uncontrolled environments but do not exceed the values shown for controlled environments in the table of maximum permitted exposure ceilings.
Maximum permitted exposures

The maximum permitted exposures prescribed by the standard are set in terms of different parameters of effects, depending on the frequency generated by the equipment in question. At the frequency range of this Personal Communication System equipment, 1930-1970MHz, the maximum permitted exposure levels are set in terms of power density, whose definition and relationship to electric field and magnetic field strengths are described by the standard as follows:
Power density (S)

Power per unit area normal to the direction of propagation, usually expressed in units of watts per square metre (W/m2) or, for convenience, units such as milliwatts per square centimetre (mW/cm2). For plane waves, power density, electric field strength (E) and magnetic field strength (H) are related by the impedance of free space, 377 ohms. In particular,
2 S + E + 377 377
H2
where E and H are expressed in units of V/m and A/m, respectively, and S in units of W/m 2. Although many survey instruments indicate power density units, the actual quantities measured are E or E2 or H or H2. CP09: TCP/IP
8
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Maximum permitted exposure ceilings

Within the frequency range, the maximum permitted exposure ceiling for uncontrolled environments is a power density (mW/cm2) that equals f/1500, where f is the frequency expressed in MHz, and measurements are averaged over a period of 30 minutes. The maximum permitted exposure ceiling for controlled environments, also expressed in mW/cm 2, is f/300 where measurements are averaged over 6 minutes. Applying these principles to the minimum and maximum frequencies for which this equipment is intended to be used yields the following maximum permitted exposure levels: Uncontrolled Environment 1930MHz Ceiling 1970MHz Controlled Environment 1930MHz 1970MHz 6.567mW/cm 2
1.287mW/cm 2 1.313mW/cm 2 6.433mW/cm 2
If you plan to operate the equipment at more than one frequency, compliance should be assured at the frequency which produces the lowest exposure ceiling (among the frequencies at which operation will occur). Licensees must be able to certify to the FCC that their facilities meet the above ceilings. Some lower power PCS devices, 100 milliwatts or less, are excluded from demonstrating compliance, but this equipment operates at power levels orders of magnitude higher, and the exclusion is not applicable. Whether a given installation meets the maximum permitted exposure ceilings depends, in part, upon antenna type, antenna placement and the output power to which this equipment is adjusted. The following example sets forth the distances from the antenna to which access should be prevented in order to comply with the uncontrolled and controlled environment exposure limits as set forth in the ANSI IEEE standards and computed above.
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Example calculation
For a base station with the following characteristics, what is the minimum distance from the antenna necessary to meet the requirements of an uncontrolled environment? Transmit frequency Base station cabinet output power, P Antenna feeder cable loss, CL Antenna input power Pin Antenna gain, G Using the following relationship: G + 4pr W Pin
2
1930MHz +39.0dBm (8 watts) 2.0dB PCL = +39.02.0 = +37.0dB (5watts) 16.4dBi (43.65)
Where W is the maximum permissible power density in W/m2 and r is the safe distance from the antenna in metres, the desired distance can be calculated as follows: r+ GPin + 4pW 43.65 5 + 1.16m 4p 12.87
where W = 12.87 W/m2 was obtained from table listed above and converting from mW/cm 2 to W/m2. NOTE The above result applies only in the direction of maximum radiation of the antenna. Actual installations may employ antennas that have defined radiation patterns and gains that differ from the example set forth above. The distances calculated can vary depending on the actual antenna pattern and gain.
Power density measurements

While installation calculations such as the above are useful and essential in planning and design, validation that the operating facility using this equipment actually complies will require making power density measurements. For information on measuring RF fields for determining compliance with ANSI IEEE C95.1-1991, see IEEE Recommended Practice for the Measure of Potentially Hazardous Electromagnetic Fields - RF and Microwave, IEEE Std C95.3-1991. Copies of IEEE C95.1-1991 and IEEE C95.3-1991 may be purchased from the Institute of Electrical and Electronics Engineers, Inc., Attn: Publication Sales, 445 Hoes Lane, P.O. Box 1331, Piscattaway, NJ 08855-1331, (800) 678-IEEE or from ANSI, (212) 642-4900. Persons responsible for installation of this equipment are urged to consult these standards in determining whether a given installation complies with the applicable limits.
Other equipment
Whether a given installation meets ANSI standards for human exposure to radio frequency radiation may depend not only on this equipment but also on whether the environments being assessed are being affected by radio frequency fields from other equipment, the effects of which may add to the level of exposure. Accordingly, the overall exposure may be affected by radio frequency generating facilities that exist at the time the licensees equipment is being installed or even by equipment installed later. Therefore, the effects of any such facilities must be considered in site selection and in determining whether a particular installation meets the FCC requirements. CP09: TCP/IP
10
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Beryllium health and safety precautions

Introduction
Beryllium (Be), is a hard silver/white metal. It is stable in air, but burns brilliantly in Oxygen. With the exception of the naturally occurring Beryl ore (Beryllium Silicate), all Beryllium compounds and Beryllium metal are potentially highly toxic.
Health issues
Beryllium Oxide is used within some components as an electrical insulator. Captive within the component it presents no health risk whatsoever. However, if the component should be broken open and the Beryllium Oxide, which is in the form of dust, released, there exists the potential for harm.
Inhalation
Inhalation of Beryllium Oxide can lead to a condition known as Berylliosis, the symptoms of Berylliosis are similar to Pneumonia and may be identified by all or any of the following: Mild poisoning causes fever, shortness of breath, and a cough that produces yellow/green sputum, or occasionally bloodstained sputum. Inflammation of the mucous membranes of the nose, throat, and chest with discomfort, possibly pain, and difficulty with swallowing and breathing. Severe poisoning causes chest pain and wheezing which may progress to severe shortness of breath due to congestion of the lungs. Incubation period for lung symptoms is 220 days. Exposure to moderately high concentrations of Beryllium in air may produce a very serious condition of the lungs. The injured person may become blue, feverish with rapid breathing and raised pulse rate. Recovery is usual but may take several months. There have been deaths in the acute stage. Chronic response. This condition is more truly a general one although the lungs are mainly affected. There may be lesions in the kidneys and the skin. Certain features support the view that the condition is allergic. There is no relationship between the degree of exposure and the severity of response and there is usually a time lag of up to 10 years between exposure and the onset of the illness. Both sexes are equally susceptible. The onset of the illness is insidious but only a small number of exposed persons develop this reaction.
First aid
Seek immediate medical assistance. The casualty should be removed immediately from the exposure area and placed in a fresh air environment with breathing supported with Oxygen where required. Any contaminated clothing should be removed. The casualty should be kept warm and at rest until medical aid arrives.
CP09: TCP/IP
EMOTOROLA LTD. 2001
11
Issue 1 Revision 4
Skin contact
Possible irritation and redness at the contact area. Persistent itching and blister formations can occur which usually resolve on removal from exposure.
First aid
Wash area thoroughly with soap and water. If skin is broken seek immediate medical assistance.
Eye contact
May cause severe irritation, redness and swelling of eyelid(s) and inflammation of the mucous membranes of the eyes.
First aid
Flush eyes with running water for at least 15 minutes. Seek medical assistance as soon as possible.
Handling procedures
Removal of components from printed circuit boards (PCBs) is to take place only at Motorola approved repair centres. The removal station will be equipped with extraction equipment and all other protective equipment necessary for the safe removal of components containing Beryllium Oxide. If during removal a component is accidently opened, the Beryllium Oxide dust is to be wetted into a paste and put into a container with a spatula or similar tool. The spatula/tool used to collect the paste is also to be placed in the container. The container is then to be sealed and labelled. A suitable respirator is to be worn at all times during this operation. Components which are successfully removed are to be placed in a separate bag, sealed and labelled.
Disposal methods
Beryllium Oxide or components containing Beryllium Oxide are to be treated as hazardous waste. All components must be removed where possible from boards and put into sealed bags labelled Beryllium Oxide components. These bags must be given to the safety and environmental adviser for disposal. Under no circumstances are boards or components containing Beryllium Oxide to be put into the general waste skips or incinerated.
Product life cycle implications

Motorola GSM and analogue equipment includes components containing Beryllium Oxide (identified in text as appropriate and indicated by warning labels on the equipment). These components require specific disposal measures as indicated in the preceding (Disposal methods) paragraph. Motorola will arrange for the disposal of all such hazardous waste as part of its Total Customer Satisfaction philosophy and will arrange for the most environmentally friendly disposal available at that time. CP09: TCP/IP
12
EMOTOROLA LTD. 2001
Issue 1 Revision 4
General cautions
General cautions
Introduction
Observe the following cautions during operation, installation and maintenance of the equipment described in the Motorola GSM manuals. Failure to comply with these cautions or with specific cautions elsewhere in the Motorola GSM manuals may result in damage to the equipment. Motorola assumes no liability for the customers failure to comply with these requirements.
Caution labels
Personnel working with or operating Motorola equipment must comply with any caution labels fitted to the equipment. Caution labels must not be removed, painted over or obscured in any way.
Specific cautions
Cautions particularly applicable to the equipment are positioned within the text of this manual. These must be observed by all personnel at all times when working with the equipment, as must any other cautions given in text, on the illustrations and on the equipment.
Fibre optics
The bending radius of all fibre optic cables must not be less than 30 mm.
Static discharge
Motorola equipment contains CMOS devices that are vulnerable to static discharge. Although the damage caused by static discharge may not be immediately apparent, CMOS devices may be damaged in the long term due to static discharge caused by mishandling. Wear an approved earth strap when adjusting or handling digital boards. See Devices sensitive to static for further information.
CP09: TCP/IP
EMOTOROLA LTD. 2001
13
Devices sensitive to static
Issue 1 Revision 4
Devices sensitive to static

Introduction
Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer of insulation that is susceptible to damage from electrostatic charge. Such a charge applied to the leads of the device could cause irreparable damage. These charges can be built up on nylon overalls, by friction, by pushing the hands into high insulation packing material or by use of unearthed soldering irons. MOS devices are normally despatched from the manufacturers with the leads shorted together, for example, by metal foil eyelets, wire strapping, or by inserting the leads into conductive plastic foam. Provided the leads are shorted it is safe to handle the device.
Special handling techniques

In the event of one of these devices having to be replaced observe the following precautions when handling the replacement: S S S S S S Always wear an earth strap which must be connected to the electrostatic point (ESP) on the equipment. Leave the short circuit on the leads until the last moment. It may be necessary to replace the conductive foam by a piece of wire to enable the device to be fitted. Do not wear outer clothing made of nylon or similar man made material. A cotton overall is preferable. If possible work on an earthed metal surface. Wipe insulated plastic work surfaces with an anti-static cloth before starting the operation. All metal tools should be used and when not in use they should be placed on an earthed surface. Take care when removing components connected to electrostatic sensitive devices. These components may be providing protection to the device.
When mounted onto printed circuit boards (PCBs), MOS devices are normally less susceptible to electrostatic damage. However PCBs should be handled with care, preferably by their edges and not by their tracks and pins, they should be transferred directly from their packing to the equipment (or the other way around) and never left exposed on the workbench.
CP09: TCP/IP
14
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Motorola GSM manual set

Introduction
The following manuals provide the information needed to operate, install and maintain the Motorola GSM equipment.
Generic manuals
The following are the generic manuals in the GSM manual set, these manuals are release dependent:
Category number
GSM-100-101 GSM-100-201 GSM-100-311 GSM-100-313 GSM-100-320 GSM-100-321 GSM-100-403 GSM-100-423 GSM-100-501 GSM-100-521 GSM-100-523 GSM-100-503 GSM-100-721
Name
System Information: General Technical Description: OMC in a GSM System Technical Description: BSS Implementation Technical Description: BSS Command Reference Installation & Configuration: GSM System Configuration Installation & Configuration: BSS Optimization Maintenance Information: Alarm Handling at the OMC Maintenance Information: Device State Transitions Maintenance Information: BSS Field Troubleshooting Maintenance Information: GSM Statistics Application Software Release Notes: BSS/RXCDR
Catalogue number
68P02901W01 68P02901W31 68P02901W36 68P02901W23 68P02901W17 68P02901W43 68P02901W26 68P02901W57 68P02901W51 68P02901W56 68P02901W72
Operating Information: GSM System Operation 68P02901W14 Technical Description: OMC Database Schema 68P02901W34
Tandem OMC
The following Tandem OMC manuals are part of the GSM manual set for systems deploying Tandem S300 and 1475:
Category number
GSM-100-202 GSM-100-712
Name
Operating Information: OMC System Administration Software Release Notes: OMC System
Catalogue number
68P02901W13 68P02901W71
CP09: TCP/IP
EMOTOROLA LTD. 2001
15
Issue 1 Revision 4
Scaleable OMC
The following Scaleable OMC manuals replace the equivalent Tandem OMC manuals in the GSM manual set:
Category number
GSM-100-202 GSM-100-413 GSM-100-712
Name
Catalogue number
Operating Information: Scaleable OMC System 68P02901W19 Administration Installation & Configuration: Scaleable OMC Clean Install Software Release Notes: Scaleable OMC System 68P02901W47 68P02901W74
Related manuals
The following are related Motorola GSM manuals:
Category number
GSM-001-103 GSM-002-103 GSM-005-103 GSM-008-403
Name
System Information: BSS Equipment Planning System Information: DataGen System Information: Advance Operational Impact Installation & Configuration: Expert Adviser
Catalogue number
68P02900W21 68P02900W22 68P02900W25 68P02900W36
Service manuals
The following are the service manuals in the GSM manual set, these manuals are not release dependent. The internal organization and makeup of service manual sets may vary, they may consist of from one to four separate manuals, but they can all be ordered using the overall catalogue number shown below:
Category number
GSM-100-020 GSM-100-030 GSM-105-020 GSM-106-020 GSM-201-020 GSM-202-020 GSM-101-SERIES GSM-103-SERIES GSM-102-SERIES GSM-200-SERIES
Name
Service Manual: BTS Service Manual: BSC/RXCDR Service Manual: M-Cell2 Service Manual: M-Cell6 Service Manual: M-Cellcity Service Manual: M-Cellaccess ExCell4 Documentation Set ExCell6 Documentation Set TopCell Documentation Set M-Cellmicro Documentation Set
Catalogue number
68P02901W37 68P02901W38 68P02901W75 68P02901W85 68P02901W95 68P02901W65 68P02900W50 68P02900W70 68P02901W80 68P02901W90
CP09: TCP/IP
16
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Category number
The category number is used to identify the type and level of a manual. For example, manuals with the category number GSM-100-2xx contain operating information.
Catalogue number
The Motorola 68P catalogue number is used to order manuals.
Ordering manuals
All orders for Motorola manuals must be placed with your Motorola Local Office or Representative. Manuals are ordered using the catalogue number. Remember, specify the manual issue required by quoting the correct suffix letter.
CP09: TCP/IP
EMOTOROLA LTD. 2001
17
Issue 1 Revision 4
CP09: TCP/IP
18
EMOTOROLA LTD. 2001
Chapter 1
Data Communication
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 1 Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Communication and Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming and Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seven Layer Model for Open System Interconnection (OSI) . . . . . . . . . . . . . . . . . Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request for Comment (RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP (DoD) Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
11 11 12 14 14 14 14 14 14 14 16 16 18 18 110 112 114 116 116 116 116 116 116
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Data Communication
Data Communication
Objectives
On completion of this chapter the student will be able to: S S S Describe the basic objectives and functions of data communication networks. Describe the OSI Reference model. Describe basic addressing concepts.
CP09: TCP/IP
EMOTOROLA LTD. 2001
11
Data Communication and Distributed Processing
Issue 1 Revision 4

The factors driving distributed processing are: 1. 2. 3. Technological advances are changing the price-performance ratio in favour of multiple low-cost, high-performance systems. Interconnections and communication costs are falling dramatically. Users are demanding more economical, rapid, sophisticated and reliable facilities.
The proliferation of personal computers throughout organisations for a wide variety of business functions has resulted in an ever-increasing need for personal computers to communicate with each other. As well as intercommunication among personal computers, the communications network must facilitate communication with centralised data processing facilities and the sources of corporate data. Several networking technologies have been developed to support this intercommunication. Local Area Networks (LANs), such as Ethernet and Token Ring, are defined by the IEEE as data communication systems that allow a number of independent devices to communicate directly with each other over moderate distances on a shared transmission medium. LANs can be used for shared data, application and device access, electronic mail, process monitoring in a factory environment and even for alarm and security systems. The most interesting feature of the LAN is its capability to support co-operative applications in which an application runs partly on a LAN station and partly on a LAN server or possibly a mainframe. Although LANs generally operate at moderate speeds (10 Mbps), the increase in processing capability of the individual workstations has led to the development of more sophisticated multi-media applications which require higher speeds. 100Mbps Ethernet is becoming more common with 1 Gbps Ethernet available and Asynchronous Transfer Mode (ATM) multi-media LANs also being deployed. The range of LAN applications can be significantly extended by interconnecting several networks over Wide Area Network (WAN) connections. WANs allow interconnection over thousands of miles, thus removing the traditional distance limitations of the LAN. Most WANs are provided by the public telecommunications service providers, but de-regulation has seen many private operators competing in this market reducing costs significantly. Some WAN technologies, such as X.25 and Frame Relay have been designed specifically for the transport of data. However, the Public Switched Telephone Network (PSTN) allows users with modems to have access to data services through Internet Service Providers (ISPs) and is responsible for the huge growth in data communication services to the home. ISDN has improved the performance of dial-up connections and B-ISDN, based on Asynchronous Transfer Mode (ATM), will allow bandwidth-on-demand for the more sophisticated multi-media applications now being run on even the most basic of PCs. In between the LAN and the WAN is the Metropolitan Area Network (MAN). A typical MAN provides voice, data and video communications at speeds of 45-600 Mbps at distances ranging from 1 to 50 miles. Recent years have seen a large growth in internet working. Protocols have been developed that allow any device on one LAN to be connected to any device on another LAN if both LANs are connected to the Internet.
CP09: TCP/IP
12
EMOTOROLA LTD. 2001
Issue 1 Revision 4
X.25
PSTN
PSTN
ISP Frame Relay
ISP
CP09_1_1
CP09: TCP/IP
EMOTOROLA LTD. 2001
13
Communication System Functions
Issue 1 Revision 4

When networks are connected over many LAN-WAN-LAN links there must be an efficient and reliable method for ensuring that all data transmitted from one node reaches the required destination. The following are some of the most important functions of the communication system.
Naming and Addressing

A communication system manipulates names for objects. These objects can be such items as processes, ports, mailboxes, systems and sessions between users. Users typically supply names in symbolic form (such as Filename@DepartmentName.CompanyName) and then the communication system restates this form into a network address. The communication system must maintain translation tables (directories) to convert logical names into physical names.
Fragmenting
If a user message or file to be transmitted is larger than a network packet, the communication system must fragment a single message into multiple segments and reassemble it before delivery to the end user. For instance, the maximum frame size for Ethernet is 1518 bytes. The typical maximum frame size for Token Ring is 5000 bytes. A WAN might have a maximum transmission unit size of 128 bytes. Segmentation and re-assembly are processes that may have to be carried out on a link by link basis.
Flow Control
Many networks are designed to share limited resources among users on the assumption that not all users demand those services simultaneously. When the resulting traffic exceeds the network throughput capacity, network flow control is designed to optimise network performance by regulating the flow of information between a pair of communicating entities.
Synchronisation
Before devices can communicate, their interactions must be synchronised. Receivers must operate at the same rate as transmitters. When data resources are shared or distributed, it is necessary to co-ordinate the distributed resources to ensure they remain synchronised.
Priority
A communication system can differentiate between high and low priority traffic. High priority traffic suffers less delay, low priority traffic is not lost but may be buffered while high priority traffic is being processed. This is becoming a very important aspect of networking as bandwidth hungry multi-media applications, requiring delivery in real time, compete for resources with normal LAN data applications.
Error Control
Reliable and error-free communication is one of the prime objectives of communication systems. Error control functions include error detection, error correction and recovery. CP09: TCP/IP
14
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Naming and Addressing Fragmenting Flow Control Synchronization Priority Error Control
CP09_1_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
15
OSI Reference Model
Issue 1 Revision 4
OSI Reference Model

The International Standards Organisation has adopted a layered approach for the reference model for Open Systems Interconnection (OSI). The complete communication system is broken down into a number of layers, each of which performs a well-defined function. Each layer provides a well-defined function in the context of the overall communications subsystem. The layers operate according to a defined protocol (set of rules) by exchanging messages, both user data and control information, with a peer (similar) layer in a remote system. Each layer has a well-defined interface to the layers immediately above and below. A layer provides a service to the layer above and requests services from the layer below. The implementation of a particular layer is independent of all other layers.
Seven Layer Model for Open System Interconnection (OSI)

S S The application layer provides the user interface to a range of network services. The presentation layer converts the internal syntax of the application layer into suitable abstract data syntax and data transfer syntax, and can include encryption for data security. The session layer is responsible for setting up and clearing a communication channel between two presentation layers for the duration of the complete network transaction. The transport layer acts as the interface between the higher application-oriented layers and the underlying network-dependent layers. It provides a network independent reliable message delivery service to the session layer. The network layer performs such functions as addressing, routing and flow control across the user-to-network interface. The data link layer builds on the physical connection provided by a particular network to provide a reliable information transfer facility. It performs such functions as error detection and recovery. The data link layer may be able to correct errors or arrange for retransmission. The physical layer is concerned with the physical and electrical interfaces between equipment on the network.
S S
CP09: TCP/IP
16
EMOTOROLA LTD. 2001
Issue 1 Revision 4
OSI Reference Model
OSI Reference Model
Application Layer Presentation Layer Session Layer Transport Layer

Network Node
AL (7) PL (6) SL (5) TL (4) NL (3) DLL(2) PL (1)
Network Layer Data Link Layer Physical layer
CP09_ch01_03
CP09: TCP/IP
EMOTOROLA LTD. 2001
17
Background
Issue 1 Revision 4
Background
TCP/IP is the protocol suite that is used with the Internet. The origins of the Internet can be traced back to the 1960s and was initially developed by the Defence Advanced Research Projects Agency (DARPA) of the American Department of Defence (DoD). In the late 1960s DARPA set out to accomplish the inter-connectivity of networks with the resulting outcome of ARPANET, requiring the use of dedicated processors and leased point-to-point lines. The main development efforts centred on the design of a network that could withstand the loss of physical sections. Other design goals included the development of a flexible network that allowed the addition and removal of nodes with the minimum of impact. The network also had to be able to connect computers of different makes and allow them to communicate effectively. The ARPANET research led to the development of a new network protocol involving packet switching. In order to interconnect different networks using incompatible hardware and software to ARPANET, TCP/IP was developed. TCP and IP protocols were accepted as DoD standards in 1979. DoD mandating that all networks connected to the ARPANET use TCP/IP; thus the Internet was born. DARPA also funded TCP/IP implementation on UNIX operating systems in co-operation with the University of California, Berkeley and distributed the code free of charge with the operating system code itself. This spread TCP/IP throughout the universities and research centres.
Request for Comment (RFC)

The Internet is not a commercial product. It is still a large active research project. Reports of work, proposals for protocols standards all appear in a series of technical reports called Request For Comments, or RFCs. The Network Information Centre (NIC) distribute RFCs to the community electronically, using the Internet or by postal mail.
CP09: TCP/IP
18
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Background
Background
Research project funded by DARPA ARPA and ARPANET set up to link military CPUs DARPA funded Berkeley UNIX Standards published as RFCs
CP09_1_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
19
The Internet
Issue 1 Revision 4
The Internet
The goal of the DoD protocols was to build a unified, co-operative, interconnection of networks that supports a universal communication service. Within each network, computers would use the underlying dependent communications technology. New software inserted between this and the applications programs, would hide the low-level details, and make the collection of networks appear to be one large virtual network. This interconnection scheme is called an internetwork or internet. So there are two main goals:
S Universal Communication Services, that hides the physical network and provides a common, universal interface for all applications. It does not require the users to understand the details of hardware interconnections in order to use the internet. To interconnect these different physical networks to form one large network. Physically this attachment is provided by a computer which attaches to both networks. However, this in itself does not guarantee the interconnection we are seeking, since it does not ensure that the computer will cooperage with other machines which wish to communicate. To create a viable internet, we need computers that ALSO shuffle (and route) packets from one network to the other, these are called internet gateways.
S S
From the networks viewpoint, a gateway is just a normal host, to the user, gateways are transparent. The user only sees one large internet. The advantage of providing interconnection at the network permits application programs that communicate over the Internet, not to know the details of the underlying connections. They can run without change on any machine. Only the software which deals with the machines physical connection needs to change if a new/different physical connection is used. Also users, do not need to understand or remember how the networks connect or what traffic they carry. Networks which participate in the internet are like motorways throughout the UK, each network agrees to handle transit traffic in exchange for the right to send traffic through the internet. Typically users are unaffected and unaware of the extra traffic on their local network.
CP09: TCP/IP
110
EMOTOROLA LTD. 2001
Issue 1 Revision 4
The Internet
The Internet
IP Host
Virtual Network
Network Router
CP09_1_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
111
TCP/IP (DoD) Architecture
Issue 1 Revision 4

TCP/IP has been developed as a four-level architecture:
Process
Within TCP/IP, applications are referred to as processes. Used by people or programs, these user processes co-operate with other processes on the same or a different host. Examples are: S S TELNET - the protocol which allows for remote terminal connections. SMTP - Simple Mail Transfer Protocol, which is an electronic mail process that allows users to compose memos and send them to individuals or groups of individuals. FTP - File Transfer Protocol, that allows users to send or receive arbitrarily large files or programs or data. SNMP - Simple Network Management protocol, used to facilitate the exchange of management information between network devices.
S S
Transport
Provides for end-to-end transfer of the application data. The examples at this level are: S S TCP - Transmission Control Protocol. Provides the connection-oriented, reliable, end-to-end service. UDP - User Datagram Protocol. Provides the connectionless, unreliable, best-effort, end-to-end service.
Network
The function of this level is to deliver data from any host on the internetwork to any other host, regardless of the network or the destination. It is at this level that routing functions occur. There are several protocols that can be implemented at this level which assist the IP in delivering data. S IP - Internet Protocol, is the protocol used here. It does not provide reliability, flow control or error recovery.
Network Access
This is the interface to the actual network hardware. The TCP/IP protocols do not specify that a particular network must be used. Almost every network interface is available, illustrating the flexibility of the Internetwork (IP) layer. Examples of the networks used are: S S Ethernet, Token Ring, FDDI X.25, Frame Relay, ATM
CP09: TCP/IP
112
EMOTOROLA LTD. 2001
Issue 1 Revision 4
DoD Architecture
Process
Process or application
Host-to-Host
End-to-end exchange between processes
Internet
Data exchange between hosts regardless of network
Network Access
Data exchange between devices on the same network
CP09_1_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
113
Layering
Issue 1 Revision 4
Layering
To control the journey of user data from one host on the internet to another the user data has to pass through the underlying levels of protocol. Each level will append some of its own control information before passing the resultant message to the level below. The resultant unit at each level is called a Protocol Data Unit, or PDU. The name given to the PDU at each level is as follows: S S S S Process: Host: Internet: Network: Segments - as formed by Application Process Datagrams - as formed by UDP/TCP Datagrams - as formed by IP varies according to the technology (e.g. frame, packet, cell etc.)
CP09: TCP/IP
114
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Layering
Layering
Process Message or streams HosttoHost HosttoHost packets Internet IP Datagrams Network Interface
Encapsulation
User Data
TCPH User Data
TCP Segment
IPH TCPH User Data
IP Datagram
NIH IPH TCPH User Data
Network frame/packet Network Frames

CP09_1_7
NIH
IPH
TCPH User Data
CP09: TCP/IP
EMOTOROLA LTD. 2001
115
Addressing Concepts
Issue 1 Revision 4
Addressing Concepts
Port Numbers
Processes are identified with a 16-bit number. A process at a source host must know the port number at which its target process resides. The IAB (Internet Activities Board), has published a list of port numbers for all commonly used processes. These ports are known as Well Known Ports and are in the range of 1 -1023. An example is that SNMP is on port 161. However, in many cases, it is only the server process that has the well-known port number associated with it. The client process which makes the request uses a port number larger than 1024 that has been randomly allocated to it for a particular session.
Protocol Addressing
An 8-bit field in the IP header identifies the protocol which is encapsulated within the IP datagram. The following are typical protocol identifiers:TCP UDP ICMP 06 17 01
Host Addressing
Each host which resides on a particular network must uniquely identify itself with a network address. IP uses a 32-bit address, which is referred to as a dotted decimal number. IP uses this address in order to recognise the network and the host on that network. An example address is:122.45.2.5
Physical Address
Each device on a network has a unique physical address, which is sometimes known as the hardware address or MAC address. This is a 48-bit address written in hexadecimal format. Again, this must not be duplicated. The hardware address is normally encoded into a network interface card by either switches or more commonly, by software. An example address is:00:08:00:F2:C5:28
Interfaces
Each level of protocol in our architecture interacts with the immediately adjacent level. Any chosen process will make use of the services provided by the Host-to-Host level, and pass data to that level. The Host-to-Host level will in turn make use of the services of the Internet level and pass its PDU down to that level; which in turn passes its PDU to the network access level for transmission on the network. The use of any individual level in the architecture is not expressly required, since it is possible for applications to invoke the services of any one of the levels directly. However since the majority of applications require a reliable end-to-end service they make use of TCP. CP09: TCP/IP
116
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Addressing Concepts
Addressing Concepts
Telnet 23
SMTP 25 TCP 06 ARP 0806
FTP 21
TFTP 69
SNMP
161
DNS 53
UDP 17 IP 0800 122.45.2.5 Network Physical Medium 00:09:00:F2:C5:28 RARP 8035
CP09_1_9
CP09: TCP/IP
EMOTOROLA LTD. 2001
117
Addressing Concepts
Issue 1 Revision 4
CP09: TCP/IP
118
EMOTOROLA LTD. 2001
Chapter 2
Internet Protocol
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 2 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class A, B, C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class D, E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reserved Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reserved Address Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Mask: Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Mask: Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnet Mask Table: Class A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Length Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type of Service Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Length Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flags [D, M] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time-to-Live Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Header Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Header Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Option Field Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options Type Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Record Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loose Source Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strict Source Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
21 21 22 24 24 26 26 26 28 210 212 214 216 218 220 222 224 226 232 234 234 234 236 238 238 238 240 240 242 242 244 244 244 244 246 246 246 246 246 246 248 250 250 250 250 250 250
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
Address Resolution (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reverse Address Resolution Protocol (RARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ICMP Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Echo Request/Echo Reply (0 and 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Unreachable (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Quench (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redirect (5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Exceeded (11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Problem (12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TimeStamp Request/Reply (13, 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Request/Reply (15, 16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Mask Request/Reply (17,18) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
252 252 256 258 258 258 258 258 260 260 260 260 260 268
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Internet Protocol
Internet Protocol
Objectives
On completion of this chapter the student will be be able to: S S S Describe the IP address format. State the reason for using subnets and describe the structure of subnet masks. Describe the format of the IP datagram.
CP09: TCP/IP
EMOTOROLA LTD. 2001
21
Introduction
Issue 1 Revision 4
Introduction
TCP/IP is a family of protocols used for computer communications. The letters stand for Transmission Control Protocol / Internet Protocol, but the full name is rarely used. TCP and IP are both individual protocols that can be discussed separately, but they are not the only two protocols used in the family. Often, a TCP/IP user does not use the TCP protocol itself, but some other protocol from the family. To talk about using TCP/IP in this situation is still proper, however, because the name applies generically to the use of any protocol in the family. The TCP/IP suite includes protocols such as Internet protocol (IP), Address Resolution Protocol (ARP), Internet Control Message protocol (ICMP), User Datagram Protocol (UDP), Transmission Control Protocol (TCP), Routing Information Protocol (RIP), Telnet, Simple Mail Transfer protocol (SMTP), Domain Name Server (DNS) and numerous others. An understanding of all the protocols in the family is not a prerequisite to knowing how a network works. This section concentrates on the IP and ARP protocols. This focus, coupled with a minimal discussion of a particular link protocol (Ethernet), illustrates how a TCP/IP network causes data to flow smoothly across an internet. In TCP/IP, all protocols are transported across an IP internet, encapsulated in IP packets. IP is a routable protocol, which means that two nodes that communicate using IP do not have to be connected to the same wire (LAN). IP is a network protocol and provides addressing information to allow routers to forward datagrams to the final destination. IP provides for fragmentation if required to allow data to traverse networks having different maximum size packets. IP provides an unreliable service, meaning that it does not guarantee the delivery of datagrams. If a datagram gets lost or arrives out of sequence, it is up to higher layer protocols to detect and retransmit. To have a basic understanding of how information travels across a routed network, it is only necessary to understand the answers to the following six questions: 1. 2. 3. 4. 5. 6. What is the format of an address in this protocol? How do devices get an address? How is the address mapped onto a physical address? How does an end node find a router? How do routers learn the topology of the network? How do users find services on the network?
CP09: TCP/IP
22
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Introduction
Introduction
What is the format of an IP address? How do hosts obtain an IP address? How is the physical address mapped How does a host seek a router? How is the network topology ascertained? How do users find services on the network?
CP09_2_1
CP09: TCP/IP
EMOTOROLA LTD. 2001
23
Address Format
Issue 1 Revision 4
Address Format
Class A, B, C
To ensure that all hosts have a unique identifier, a 32-bit integer is used for each IP address. Three different address classes are defined to allow for the different sizes of networks to which a host might be attached. Each format is known by an address class; a single internet may use addresses from all classes. There are 5 classes of address. The three primary classes are A, B and C; each is intended for use with a different size network. The class to which an address belongs can be determined by looking at the first 4 bits of the first octet of the address. According to the class, the remaining three octets may specify a network identifier (netid) and/or a host identifier (hostid). Class A addresses are used by networks that have a large number of attached hosts and class C addresses provide lots of networks with a small number of hosts to be connected to the internet. To make it easier to work with IP addresses, the 32 bits are broken into 4 octets. These are converted into their equivalent decimal form with a dot between each. This is known as dotted decimal. e.g. 10000000 00000011 00000010 00000011 = 128.3.2.3 Note: Class A addresses will have the first octet in the range: Class B addresses will have the first octet in the range: Class C addresses will have the first octet in the range: 1 126 128 191 192 223
CP09: TCP/IP
24
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Address Format
Address Format (A, B, C)
OCTET 1 Class A 1-126 0 Net ID
OCTET 2
OCTET 3 Host ID
OCTET 4
OCTET 1 Class B 128-191 10 Net ID
OCTET 2
OCTET 3 Host ID
OCTET 4
OCTET 1 Class C 192-223 110
OCTET 2 Net ID
OCTET 3
OCTET 4 Host ID
CP09_2_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
25
Class D, E
Issue 1 Revision 4
Class D, E
Class D
Addresses are used for multicasting. In a LAN, a frame may be sent to an individual, broadcast or group address. The group address allows a group of hosts that are co-operating in some way, to arrange for network transmissions to be sent to all members of the group. This is often called computer-supported co-operative working (CSCW); class D addresses allow this mode of working to extend across the internet.
Class E
Addresses are reserved for future use, and therefore should not be encountered.
CP09: TCP/IP
26
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Class D, E
Address Format (D, E)
OCTET 1 ClassD 223239 1110
OCTET 2
OCTET 3
OCTET 4
Multicast Address
OCTET 1 ClassE 240254 1111
OCTET 2
OCTET 3
OCTET 4
Host Reserved for Future Use ID
CP09_2_3
CP09: TCP/IP
EMOTOROLA LTD. 2001
27
Example Addresses
Issue 1 Revision 4
Example Addresses
Class A addresses have 8 bits for the netid and 24 bits for the hostid. nnnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh Class B addresses have 16 bits for the netid and 16 bits for the hostid. nnnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh Class C addresses have 24 bits for the netid and 8 bits for the hostid. nnnnnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh Network or host IDs of all 1s or all 0s are reserved. Class A provides for up to 126 networks, each with up to 16,777,214 hosts. Class B provides for up to 16,384 networks, each with up to 65,534 hosts. Class C provides for up to 2,097,152 networks, each with up to 254 hosts.
CP09: TCP/IP
28
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Example Addresses
Example Addresses
Network
First A Last A First B Last B First C Last C 1.0.0.0 126.0.0.0 128.0.0.0
Net ID
First Host
1.0.0.1 126.0.0.1 128.0.0.1 191.255.0.1 192.0.0.1 223.255.255.1
Last Host
1.255.255.254 126.255.255.254 128.255.255.254 191.255.255.254 192.255.255.254 223.255.255.254
191.255.0.0 192.0.0.0 223.255.255.0
CP09: TCP/IP
EMOTOROLA LTD. 2001
29
Reserved Addresses
Issue 1 Revision 4
Reserved Addresses
Some addresses within the class parameters are reserved for particular functions, and should not be assigned to networks or hosts. Network or host IDs of all 1s or all 0s are reserved along with the network id of 127.0.0.0 or any network above 223. There are some special case addresses which the Internet is required to filter out and thus will not go into the Big Wide World. These are:Network Network Network 10.0.0.0 172.16.0.0 192.168.255.0
CP09: TCP/IP
210
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Reserved Addresses
Reserved Addresses
Net ID 127 0s 1s Valid
Host ID 0s 0s 1s 1s Internal Loopback This Host Broadcast Directed Broadcast
CP09_2_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
211
Reserved Address Examples
Issue 1 Revision 4

Network ID 127 is reserved for Internal loopback tests. This provides a confidence test of the protocol stack downwards to the IP network level. To test your own local host you should always be able to ping 127.0.0.1 All four octets with a value of all 0s means that the host does not know its host ID nor to which network it belongs. The host could also be in a situation where it knows its host ID but not its net ID. e.g. 0.0.0.32 I am host 32, but which network?
All four octets with a value of all 1s is a broadcast address to all hosts on my network. All host address bits with a value of all 1s is a broadcast address to all host in the advertised network.
CP09: TCP/IP
212
EMOTOROLA LTD. 2001
Issue 1 Revision 4
127
Local Loopback Test
What is my address?
255
255
255
255
Broadcast all Hosts on my Network
150
255
255
Broadcast all Hosts on Network 150.1.0.0
CP09_2_5b
CP09: TCP/IP
EMOTOROLA LTD. 2001
213
Subnets
Issue 1 Revision 4
Subnets
Although this basic structure is adequate for most addressing purposes, the introduction of multiple LANs at each site can mean unacceptably high overheads in terms of routing. With the basic addressing scheme, each LAN would have its own netid and all routers on the site would have to participate in the overall internet routing function. The efficiency of any routing scheme is strongly influenced by the number of routing nodes that make up the internet. The concept of subnets has been introduced to de-couple the routers associated with a single site from the overall internet routing function. Essentially, instead of each LAN associated with a site having its own netid, only the site is allocated an internet netid. The identity of each LAN then forms part of the hostid field. The same address classes and associated structure are still used, but the netid relates to a complete site rather than to a single network. Hence, since only a single gateway attached to a local site network performs internet-wide routing, the netid is considered as the internet part. For a single netid, with a number of associated subnetworks, the hostid part consists of two subfields: a subnetid part and a local hostid part. Because these have only local significance they are known as the local part. Normally, organisations building their own intranet also want to be connected to the Internet. The Internet Network Information Centre (InterNIC) assigns network numbers to applicants and ensures that each network number is globally unique. Sometimes, when an organisation connects to the Internet through an Internet Service Provider (ISP) the ISP provides the network number. In addition, many large organisations have internal network administrators in charge of assigning IP addresses to individual users within the company. Most IP devices require manual configuration. The person installing the device must obtain a unique and correct IP address and type it in, usually along with other information such as IP broadcast address, subnet mask and default gateway address.
CP09: TCP/IP
214
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Subnets
Subnets
128.3.2.1
128.3.2.2
All traffic to 128.3.0.0 Subnet 128.3.2.0
Internet IP Gateway Subnet 128.3.4.0 Subnet Gateway Subnet 128.3.3.0
128.3.4.1
128.3.4.2
128.3.3.1
128.3.3.2
CPO6_2_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
215
Default Subnet Masks
Issue 1 Revision 4

If it is not required that you use subnetting, then a default subnet mask must be configured in each network device for the type of address class being used. Remember that subnet masks have all 1s in the network portion of the address and 1s and 0s in the subnet and host portion. Then, if no subnet is required, the default subnet mask is simply all 1s in the net ID and all 0s in the host ID.
CP09: TCP/IP
216
EMOTOROLA LTD. 2001
Issue 1 Revision 4
255
Class A
255
255
Class B
255
255
255
Class C
CP09_2_7
CP09: TCP/IP
EMOTOROLA LTD. 2001
217
Subnet Masking
Issue 1 Revision 4
Subnet Masking
Because of the possibly wide range of subnets associated with different site networks, no attempt has been made to define rigid subaddress boundaries for the local part. Instead, an address mask is used to define subaddress boundaries. The address mask is kept by the internet gateway and routers at the site. The subnet mask is obtained by placing 1s into the network and subnet portions of the address, and 0s into the remaining host portion of the address.
Hence, an address mask of 11111111 11111111 11111111 00000000 means that the first 3 bytes contain a network/subnetwork identifier and the 4th octet contains the hostid part. The subnet mask is normally written in dotted decimal form, so the above would be written as 255.255.255.0. On a class B network, the above mask would be interpreted as meaning that the first 2 bytes are the internetid, the 3rd byte the subnetid and the 4th byte the hostid. Byte boundaries are normally used to simplify decoding but this is not essential. All hosts attached to the network have the same internet routing part but the presence of a possibly large number of subnets and associated routers is transparent to the internet gateways for routing purposes.
CP09: TCP/IP
218
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Subnet Masking
Subnet Masking
OCTET 1 Class B 128191 NET ID
OCTET 2
OCTET 3 HOST ID
OCTET 4
11111111
11111111
11111111
00000000
NET ID
SUBNET ID
HOST ID
CP09_2_8
CP09: TCP/IP
EMOTOROLA LTD. 2001
219
Logical AND
Issue 1 Revision 4
Logical AND
A subnet mask is used by IP to determine whether an IP datagram is destined for a local host or a host on another subnetwork. A process called logical anding is used to compare the binary value of an IP address with the binary value of a subnet mask. Every host on an IP network or internetwork requires a subnet mask to be associated with its IP address. Regardless whether an IP network is not connected to the Internet or another network, each host will still require a subnet mask.
CP09: TCP/IP
220
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Logical AND
Logical AND
128 10000000
240 11110000
193 11000001
101 01100101 Net 128.240 Host 193.101
255 11111111
255 11111111
255 11111111
0 Subnet Mask 00000000
128 10000000
240 11110000
193 11000001 Class B
0 00000000
Net 128.240 SN 193 (host 101)
CP09_2_9
CP09: TCP/IP
EMOTOROLA LTD. 2001
221
Subnet Mask: Example 1
Issue 1 Revision 4

The simplest way of defining subnet masks in your organisation is insert 1s in the highest bit positions of the host octet immediately adjacent to the net ID. It is recommended to keep the subnet bits contiguous. Subnetting will always reduce the number of possible hosts for a given network. In order to apply subnets, two key questions must be asked;S S How many total subnetworks do I need? How many hosts will I have on the largest of the subnets?
To calculate the number of subnets and/or the number of hosts, use the following formula:(2n 2) where n=number of subnet bits or host bits By multiplying the number of subnets with the number of hosts per subnet will give the total number of hosts available for that class and subnet mask. In the diagram, a 4-bit mask was used. This gives:(24 2) subnets therefore 16-2 = 14 subnets (212 2) hosts therefore 4096-2 = 4094 hosts 14 x 4094 = 57,316 hosts for this Class B address so subnetted rather than 65,534 hosts for a non-subnetted Class B address.
CP09: TCP/IP
222
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Octet 1 Net ID
Octet 2
Octet 3 Host ID
Octet 4
11111111
11111111
11110000
00000000
Net ID
SN Class B
Host ID
CP09_2_10
CP09: TCP/IP
EMOTOROLA LTD. 2001
223
Issue 1 Revision 4

A subnet mask needs to be configured into an IP host as well as its IP address. In IP networks, every router and host in the same network should share a common subnet mask. If there are disagreements on the subnet mask, datagrams will not be routed correctly. In the diagram, a host has a Class C address of 213.67.101.28 If you only had this information, this host would be identified as HOST 28 in NETWORK 213.67.101 However, with the applied subnet mask, it can be seen that the host is actually HOST 12 on SUBNET 16 in NETWORK 213.67.101
CP09: TCP/IP
224
EMOTOROLA LTD. 2001
Issue 1 Revision 4
213 255
67 255
101 255
28 240
Class C Address Applied Subnet Mask
Result with Mask applied
213
67
101
16 12
Net 213.67.101 Net Subnet 16 Host 12
CP09_2_11
CP09: TCP/IP
EMOTOROLA LTD. 2001
225
Subnet Mask Table: Class A
Issue 1 Revision 4

When planning an IP network, you may have to choose the number of subnet bits required that would suit your site. Using the tables on the following pages should help. The chunks field identifies ranges of IP addresses. For example, for four bits, chunks of 16 are given. Therefore, new subnets start at 16 and multiples thereof.
CP09: TCP/IP
226
EMOTOROLA LTD. 2001
Issue 1 Revision 4
No. bits 1 bit 2 bits 3 bits 4 bits 5 bits 6 bits 7 bits 8 bits 9 bits 10 bits 11 bits 12 bits 13 bits 14 bits 15 bits 16 bits 17 bits 18 bits 19 bits 20 bits 21 bits 22 bits
Subnet Mask 255.128.0.0 255.192.0.0 255.224.0.0 255.240.0.0 255.248.0.0 255.252.0.0 255.254.0.0 255.255.0.0 255.255.128.0 255.255.192.0 255.255.224.0 255.255.240.0 255.255.248.0 255.255.252.0 255.255.254.0 255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
No. of Networks 0 2 6 14 30 62 126 254 510 1,022 2,046 4,094 8,190 16,382 32,766 65,534 131,070 262,142 524,286 1,048,574 2,097,150 4,194,302
No. of Hosts 8,388,608 4,194,302 2,097,150 1,048,574 524,286 262,142 131,070 65,534 32,766 16,382 8,190 4,094 2,046 1,022 510 254 126 62 30 14 6 2
Chunks 128 64 32 16 8 4 2 1 128 64 32 16 8 4 2 1 128 64 32 16 8 4

CP09_2_12
CP09: TCP/IP
EMOTOROLA LTD. 2001
227
Issue 1 Revision 4
CP09: TCP/IP
228
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Subnet Mask Table: Class B and Class C
Class B
No. bits 1 bit 2 bits 3 bits 4 bits 5 bits 6 bits 7 bits 8 bits 9 bits 10 bits 11 bits 12 bits 13 bits 14 bits
Subnet Mask 255.128.0.0 255.192.0.0 255.224.0.0 255.240.0.0 255.248.0.0 255.252.0.0 255.254.0.0 255.255.0.0 255.255.128.0.0 255.255.192.0.0 255.255.224.0.0 255.255.240.0.0 255.255.248.0.0 255.255.252.0.0
No. of Networks 0 2 6 14 30 62 126 254 510 1,022 2,046 4,094 8,190 16,382
No. of Hosts 32,766 16,382 8,190 4,094 2,046 1,022 510 254 126 62 30 14 6 2
Chunks 128 64 32 16 8 4 2 1 128 64 32 16 8 4
Class C No. bits 1 bit 2 bits 3 bits 4 bits 5 bits 6 bits 7 bits Subnet Mask 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252 255.255.255.254 No. of Networks 0 2 6 14 30 62 126 No. of Hosts 126 62 30 14 6 2 0 Chunks 128 64 32 16 8 4 2
CP09_2_13
CP09: TCP/IP
EMOTOROLA LTD. 2001
229
Issue 1 Revision 4
IP Datagram
An IP Datagram contains the following components:
User Data
This is an amount of encapsulated data from higher layers.
TCP Header
As this course is dealing with TCP/IP we will assume that the layer above IP is TCP. Therefore there will be a TCP header attached to the user data.
IP Header
The IP header contains information concerning IP alone. Amongst other things, this header contains the source and destination IP addresses.
LAN Header
This header contains information for the underlying network. IP does not specify what type of underlying network is used, however, for this course we will assume an Ethernet LAN. Therefore, this header, amongst other things, will contain the MAC addresses of the immediate source and destination. IP provides a Datagram service. It is a connectionless service and delivery of datagrams is on a best-effort basis.
CP09: TCP/IP
230
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Datagram
MAC Addresses
LAN Header
IP Header
TCP Header
User Data
IP Addresses
CP09_2_14
CP09: TCP/IP
EMOTOROLA LTD. 2001
231
IP Header
Issue 1 Revision 4
IP Header
Before considering the various functions and protocols associated with IP, the format of the IP data unit or datagram must be considered. The format for the datagram is shown opposite. Its basic format is a header containing information for IP to use, and data that is only relevant to the higher layer protocols. The IP datagram header is a minimum of 20 octets long.
CP09: TCP/IP
232
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Header
IP Header
10
11
12
13
14
15
16
Version
Header Length Total length Identification
Type of Service
Fragment offset Protocol Header checksum Source IP address Destination IP address Options/Padding Data
TimetoLive
CP09_2_16
CP09: TCP/IP
EMOTOROLA LTD. 2001
233
IP Header Description
Issue 1 Revision 4
Version Field
4 bits
Specifies the version of IP so that all devices interpret the subsequent fields correctly. Currently, most devices use version 4 (IPv4) although some might also support version 6 (IPv6).
Length Field
4 bits
As the header can be of variable length, the header length specifies the actual length of the datagram header in multiples of 32-bit words. The minimum length is 5, which equates to 20 octets. If the datagram contains options, these must be in multiples of 32 bits. Any unused octets must be filled with padding.
10
11
12
13
14
15
16
Version
Type of Service
CP09_2_17
CP09: TCP/IP
234
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Internet Protocol Decode Status Version Type of Service 4 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved Total Length Identification Fragment Control 522 bytes 25598 0 x 4000 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes Time to Live Protocol Checksum Source Address Destination Address No IP Options
CP09_2_18
Header Length: 20
14 seconds/hops 6 (TCP) 0 x E60 137.28.1.2 (Checksum Good) 128.52.46.32
CP09: TCP/IP
EMOTOROLA LTD. 2001
235
Type of Service Field
Issue 1 Revision 4

8 bits
This field allows an application process to specify the preferred attributes associated with the route and is, therefore, used by each gateway during route selection, if a number of routes are available. The options being Precedence, Delay, Throughput, Reliability and Cost.
Precedence:
This provides a measure of the relative importance of the datagram. There are eight levels of precedence and IP will attempt to provide preferential treatment for higher value datagrams. The value ranges from normal precedence (000) to network control (111). Most routers ignore these flags.
Delay:
This is a measure for a route providing less probability of the datagram encountering delay.
Throughput:
This is a measure for a route providing a higher throughput rate.
Reliability:
This is a measure for a route providing less probability of the datagram being discarded.
Cost:
This is a measure for a route affording less cost. Cost being a value defined by the network administrator (money, hops etc).
4 D T
5 R
6 C
7 O
Precedence
Bits 123 000 001 010 011 100 101 110 111
Precedence Values Meaning Routine Priority Immediate Flash Flash Override Critical Internetwork Control Network Control
Bit 4 5 6 7 8
Meaning Delay Throughput Reliability Cost Not Used
0 value Normal Delay Normal Throughput Normal Reliability Normal Cost
1 value Low Delay High Througput High Reliability Low Cost
CP09_2_19
CP09: TCP/IP
236
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Internet Protocol Decode Status Version Type of Service 4 Header Length: 20 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved 522 bytes 25598 0 x 4000 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes 14 seconds/hops 6 (TCP) (Checksum Good) 0 x E60 128.52.46.32 137.28.1.2
Total Length Identification Fragment Control
Time to Live Protocol Checksum Source Address Destination Address No IP Options 1 2 3 4 5 6
10
11
12
13
14
15
16
Version
Header Length Total Length Identification
Type of Service
CP09_2_20
CP09: TCP/IP
EMOTOROLA LTD. 2001
237
Issue 1 Revision 4
Total Length Field
16 bits
This field defines the total length of the datagram including the header and the user data portion. This is specified in octets. As the field is 16 bits in length then the maximum length of a datagram is 65,535 octets.
Identification Field
16 bits
User messages may be transferred across the internet in multiple datagrams, with the identification field being used to allow a destination host to relate different datagrams to the same user message. Although this number is unique to a datagram, if a message has been fragmented into several datagrams, then each of the datagrams which are part of the whole message will contain the same identification number. This is not a sequence number, as IP is a connectionless service, there is no concept of a sequence of datagrams.
2 Version
10
11
12
13
14
15
16
Type of Service
CP09_2_21
CP09: TCP/IP
238
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09_2_22
Header Length: 20
CP09: TCP/IP
EMOTOROLA LTD. 2001
239
Issue 1 Revision 4
Fragmentation
Fragmenting the datagram means dividing it up into several smaller datagrams. The header of each of these smaller datagrams is a copy of the original datagram header, with obvious slight alterations, for example total length and fragmentation field entries. Please note that the Identification field is the same value for each fragment of the whole. Fragmentation occurs at Gateways (routers), the fragmented datagrams are only reassembled by the destination host. If, however, any one of the smaller datagrams that make up the complete message gets lost, then all of the received fragments belonging to the same will be discarded.
CP09: TCP/IP
240
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Header
IP Data
IP HDR
Fragment 1 O 2 D M 3 4
IP HDR
Fragment 16
Offset
Bit 1 2 3
Meaning Reserved D Flag M Flag
0 Value Must be zero May Fragment Last Fragment
1 Value
Dont fragment More fragments to come
10
11
12
13
14
15
16
Version
Header Length Total Length Identification
Type of Service
Fragment Offset
CP09_2_23
CP09: TCP/IP
EMOTOROLA LTD. 2001
241
Flags [D, M]
Issue 1 Revision 4
Flags [D, M]
3 bits
The next 3 bits are known as flag bits of which only 2 are currently used. These are used to control fragmentation. The highest bit is not used and is set to 0. The middle bit, known as the do not fragment or D bit, is intended for use by intermediate gateways. The D-bit is set to 1 indicates that the datagram should not be fragmented. The lowest bit, known as the more fragments or M bit, is used in the re-assembly procedure associated with user data transfer involving fragmented datagrams. The M-bit set to 0 means the last fragment of a datagram.
Fragment offset
13 bits
This field is used with fragmented datagrams to indicate the relative position where the data contained in this fragment was situated in the original whole datagram. This field is measured in units of 8 octets. The last fragment may have padding in this field if the remaining data does not complete an 8 octet boundary.
CP09: TCP/IP
242
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Flags [D, M]
IP Fragmentation
First Fragment IP Internet Protocol Total Length Identification Fragment Control 100 bytes 35087 0 x 4000 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 1 . . . . . . . . . . . . . = More Fragments . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes Second Fragment IP Internet Protocol Total Length Identification Fragment Control 100 bytes 35087 0 x 200A 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 1 . . . . . . . . . . . . . = More Fragments . . . 0 0000 0000 1010 = Fragment Offset = 80 bytes Third Fragment IP Internet Protocol Total Length Identification Fragment Control 100 bytes 35087 0 x 2014 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 1 . . . . . . . . . . . . . = More Fragments . . . 0 0000 0001 0100 = Fragment Offset = 160 bytes Last Fragment IP Internet Protocol Total Length Identification Fragment Control 88 bytes 35087 0 x 1E 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragments . . . 0 0000 0001 1110 = Fragment Offset = 240 bytes
CPO9_2_25a CP09_2_25
CP09: TCP/IP
EMOTOROLA LTD. 2001
243
Issue 1 Revision 4
Time-to-Live Field
8 bits
This field is set by the sender and defines the maximum time, for which a datagram can be in transit across the internet. More commonly, this defines the maximum number of hops through the network that a datagram can make. Each router, via which the datagram passes, will decrement by 1 the value. When the datagram encounters a router with its TTL at zero, then the datagram will be discarded.
Protocol Field
8 bits
More than one protocol is associated with the TCP/IP suite. This field indicates the Transport layer protocol being carried by this datagram, and thus to which layer 4 service IP is to pass the datagram. E.g. ICMP TCP UDP 0116 0616 1116 110 610 1710
Header Checksum
16 bits
This resultant value from a polynomial calculation performed on the IP header alone ensures the integrity of the header values. As the checksum calculation must be performed at each router and only the header values may change and not the data, then by only checking the header reduces any delay of the datagram as it passes through the router.
CP09: TCP/IP
244
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Internet Protocol Decode Status Version Type of Service 4 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved Total Length Identification Fragment Control 522 bytes 25598 0 x 00 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes Time to Live Protocol Checksum Source Address Destination Address No IP Options 14 seconds/hops 6 (TCP) 0 x E60 137.28.1.2
CP09_2_26
Header Length: 20
(Checksum Good)
128.52.46.32
CP09: TCP/IP
EMOTOROLA LTD. 2001
245
Issue 1 Revision 4
Source Address Field
32 bits
The 32-bit IP address of the host sending the datagram.
Destination Address Field

32 bits
The 32-bit IP address of the destination host.
Option Field Variable

This field is used in selected datagrams to carry additional information relating to one or more of, security, source routing, route recording, stream identification and timestamp. It is mainly used for network testing and de-bugging.
Padding Variable
This field represents 0s which are used to ensure that the header ends on a 32-bit boundary.
Data Variable
This is the data being carried in the datagram and is passed to a higher layer protocol as specified in the protocol options field. The total length of the data field plus the header is a maximum of 65,535 octets.
CP09: TCP/IP
246
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09_2_27
Header Length: 20
CP09: TCP/IP
EMOTOROLA LTD. 2001
247
Options Type Field
Issue 1 Revision 4
Options Type Field

The Options Field of the header is made up of the first octet describing the options type parameters, followed by a 1-octet length field followed by n-octets of options. The end of the option field is defined with the end of option list in the type field. Type Field (see diagram) Length Field Options Data Field 1 octet 1 octet n octets Defines the option field. Shows the length in octets of the option data, type and length fields. Contains the relevant data of the option.
The Options Type field is divided into three portions:
Copy Flag (Cf.)

Indicates whether the option field is to be copied into the header of each datagram if fragmentation has occurred.
Class
Class00 Datagram or network control Class 10 Debugging and measurement Class 01 Reserved for future use Class 11 Reserved for future use
Option Number
Identifies the specific option.
CP09: TCP/IP
248
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Options Type Field
Options
Cf 1
Class 2 3 4
Options Number 5 6 7 8
Options Length Field
n Octets of Options Data
Option Field Copy Flag 0 0 0 0 1 1 1 Options Class 00 00 00 10 00 00 00 Option Number 00000 00001 00111 00100 00010 00011 01001 Description End of Options List No Operation Record Route Internet Timestamp Security Loose Source Routing Strict Source Routing
CP09_2_28
CP09: TCP/IP
EMOTOROLA LTD. 2001
249
Options
Issue 1 Revision 4
Options
Record Route
This option causes each router to place its IP address into the option field as the datagram travels through the network. This list is used to ascertain the path which datagrams are using to reach their destination.
Internet Timestamp
This option allows a datagram to be sent through the network and gather timestamps from each router through which it passes. This can be used to assess delay.
Security
This option allows a router to detect datagrams that are carrying sensitive information and prevent them from leaving a secure environment.
Loose Source Routing

This is a management option that allows a datagram to be directed through a particular set of routers using a pre-defined list of IP addresses of routers that must be traversed in sequence. A loose source route allows other routers to be used between those defined.
Strict Source Routing

This is similar to Loose Source Routing except that only the routers defined can be used. If the datagram cannot be routed, an ICMP error message should result.
CP09: TCP/IP
250
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Options
Options
Cf
Class
Options Number
Options Length Field
n Octets of Options Data
Option Field Copy Flag 0 0 0 0 1 1 1 Options Class 00 00 00 10 00 00 00 Option Number 00000 00001 00111 00100 00010 00011 01001 Description End of Options List No Operation Record Route Internet Timestamp Security Loose Source Routing Strict Source Routing
CP09_2_28
CP09: TCP/IP
EMOTOROLA LTD. 2001
251
Address Resolution (ARP)
Issue 1 Revision 4

On a LAN, devices communicate with each other using a hardware or Medium Access Control (MAC) address. This is normally created at time of manufacture. It is a 6-byte address and is unique for every Network Interface Card (NIC). For instance, every device connected to an Ethernet LAN has a NIC, and each NIC has a unique 6-byte MAC address. Address Resolution Protocol (ARP) allows TCP/IP users to discover the MAC address to which an IP datagram should be sent. When an IP device wishes to initiate communications with another IP device, it first compares the destination network address with its own network address. The netmask allows it to determine how many bytes have been allocated for the network address. If the netids are the same, then the target device is on the same LAN. (Either on the same wire or separated by bridges.) The sending device sends an ARP request to all devices on the LAN using the hardware broadcast address of all 1s. The ARP request contains the senders IP address and MAC address as well as the IP address of the target device. All devices on the LAN receive and process the LAN frame but only the target device, with the matching IP address, responds. The response is sent to the originators MAC address directly, not broadcast. The response contains the required MAC address. Both devices store the IP to MAC address mappings that they now know in a list called the ARP cache. As long as the mapping is in the cache the devices can communicate without further ARP requests, thus reducing the amount of broadcast traffic. The timeout for the cache is normally configurable; anything from 30 seconds to hours. The shorter the timeout period, the more broadcast traffic that may be generated. However, if long timeouts are used and a device has its NIC changed, it cannot be contacted until the entry is updated.
Reverse Address Resolution Protocol (RARP)

The IP and MAC addresses of a host are normally held in permanent storage and are read by the operating system on start-up. With diskless hosts, this is not possible. Reverse Address Resolution Protocol (RARP), is used by a diskless host, in order to obtain its own IP address. On start-up, the host broadcasts a RARP request. The RARP request request is responded to by a server that holds all the IP to MAC addresses for the diskless hosts which it serves.
Finding a router
When the netid of a destination hos is different from the netid of the source host, then the IP datagam has to be sent to a router. A host is normally manually configured with the IP address of the default router. The sending host first discovers the MAC address of the router by sending an ARP request to the default routers IP address. On receiving a reply, the host can now send an IP packet using the destination nodes IP address and the MAC address of the default router. The router receives the packet and forwards it on the appropriate route towards the destination network.
CP09: TCP/IP
252
EMOTOROLA LTD. 2001
Issue 1 Revision 4
ARP Request
10
11
12
13
14
15
16
Hardware Type Protocol Type HLEN Operation Source Hardware Address Source IP Address Destination Hardware Address Destination IP Address PLEN
HLEN = MAC address length PLEN = IP address length Operation: 1. ARP Request 2. ARP response 3. RARP request 4. RARP response
CP09_2_28a
CP09: TCP/IP
EMOTOROLA LTD. 2001
253
Issue 1 Revision 4
ARP Request
IEEE 802.3/Ethernet DIX V2 Header Decode Status Frame Length 64 Destination Address FFFFFFFFFFFF (Group, Locally Administered Address) Source Address 0080C7495696 (OUI = XIRCOM, Universally Administered Address) Frame Format Ethernet DIX V2 Ethertype 0x806 (ARP) Frame Checksum Good. Frame Check Sequence 00 00 00 00 ARP Address Resolution Protocol Decode Status Hardware Type 0x01 (Ethernet) Protocol 0x800 (DoD Internet Protocol) Hardware Address Length 6 Protocol Address Length 4 Opcode 0x01 (REQUEST) Sender Hardware Address 0080C7495696 Sender Protocol Address 198.85.45.1 Target Hardware Address 000000000000 Target Protocol Address 198.85.45.252
CP09_2_29
CP09: TCP/IP
254
EMOTOROLA LTD. 2001
Issue 1 Revision 4
ARP Reply
IEEE 802.3/Ethernet DIX V2 Header Decode Status Frame Length Destination Address Source Address 64
0080C7495696 (OUI = ZIRCOM. Individual. Universally Administered Address) 0000C0FD5000 (OUI = WESTERN DIGITAL. Universally Administered Address) Ethernet 0x806 DIX V2 (ARP) Frame Check Sequence 00 00 00 00
Frame Format Ethertype
Frame Checksum Good. ARP Address Resolution Protocol Decode Status Hardware Type Protocol Hardware Address Length Protocol Address Length Opcode Sender Hardware Address Sender Protocol Address Target Hardware Address Target Protocol Address 0x01 0x800 6 4 0x02
(Ethernet) (DoD Internet Protocol)
(REPLY)
0000C0FD5060 198.85.45.252 0080C7495696 198.85.45.1
CP09_2_30
CP09: TCP/IP
EMOTOROLA LTD. 2001
255
Internet Control Message Protocol (ICMP)
Issue 1 Revision 4

Because IP is providing a connection-less system, then each gateway or host operates independently and IP itself does not assist the sender to test connectivity or learn about failures. ICMP forms an integral part of IP and must be implemented by every IP module. It is used by both hosts and gateways to report errors and to provide information about unexpected conditions. It is not used to make IP a reliable system, in fact, datagrams may still be undelivered without any reports as to why. ICMP can report errors on any IP datagram except for ICMP messages themselves.
The ICMP message is carried as the data portion of an IP datagram and the first part of that data field is in fact the ICMP header. ICMP has its own IP protocol number (1). Type 8 bits Specifies the type of ICMP message
Code Checksum Parameters Data
8 bits 16 bits 32 bits
Contains the error code for the datagram being reported zero if not used Checksum algorithm for the ICMP header and message Variable, depending on the option Variable contains more information. It will always include the IP header and first 64 data bits of the datagram causing the problem. The reason for returning more than the datagram header alone is to allow the receiver to determine more precisely which higher level protocol(s) were used, and thus which application program was responsible for the datagram.
10
11
12
13
14
15
16
IP Header Type Checksum Parameters/Data (Dependent on message type) Code
CP09_2_31
CP09: TCP/IP
256
EMOTOROLA LTD. 2001
Issue 1 Revision 4
ICMP Decode
IP Internet Protocol
... ... ...

Time to Live Protocol Checksum Source Address Destination Address No IP Options
... ... ...

32 seconds/hops 1 (ICMP) 0x7514 198.85.45.1 198.85.39.1 (Checksum Good)
ICMP Internet Control Message Protocol Decode Status Type Code ICMP Checksum Identifier Sequence Number Echo Data 8 (Echo) 0 x 495C 256 Checksum Good) 768 [32 byte(s) of data]
CP09_2_32
CP09: TCP/IP
EMOTOROLA LTD. 2001
257
ICMP Message Types
Issue 1 Revision 4
ICMP Message Types

There are different types of ICMP message, and some of them have code numbers to provide a more meaningful reason for the message.
Echo Request/Echo Reply (0 and 8)

This is a simple tool to determine reachability. When a node receives an Echo Request, the ICMP protocol requires that the node send the same ICMP data back to the originator as an Echo Reply. This routine is more commonly used as ping.
Destination Unreachable (3)

This message is returned if a router is unable to deliver a datagram. The values of the code field help to provide a reason why a datagram failed to arrive at its destination. Code Code Code Code Code Code Code Code Code Code Code Code Code Code 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Network Unreachable Host Unreachable Protocol Unreachable Port Unreachable Fragmentation Blocked Source Route Failed Target Network Unknown Target Host Unknown Source Host Isolated Target Network Prohibited Target Host Prohibited Network Type-of-Service Problem Host Type-of-Service Problem Communication Administratively Prohibited
Source Quench (4)

This message will be sent if a gateway or host if it does not have enough resources to process incoming datagrams and is therefore forced to discard any more incoming datagrams. This message provides an imperfect form of flow control. Whilst the standards do not specify by how much a device ought slow down when it has received a source quench message, it will receive another one until it does slow down enough.
Redirect (5)
This message is generated when a router receives a datagram and realises that there is a better route to reach the destination. The Redirect message includes the IP address of the router which the host should use for future datagrams. This information is added to the hosts routing table. CP09: TCP/IP
258
EMOTOROLA LTD. 2001
Issue 1 Revision 4
ICMP Message Types
ICMP Message Types
Type 0 3 4 5 8 11 12 13 14 15 16 17 18
Definition Echo Reply Destination Unreachable Source Quench Redirect Echo Request Time Exceeded Parameter Problem Timestamp Request Timestamp Reply Information Request Information Reply Address Mask Request Address Mask Reply
Code(s) 0 0 - 13 4 0-3 0 0-1 0 0 0 0 0 0 0
CP09_2_33
CP09: TCP/IP
EMOTOROLA LTD. 2001
259
Time Exceeded (11)
Issue 1 Revision 4
Time Exceeded (11)

This message is generated if either the Time to Live field has reached zero at a gateway or a host has not been able to reassemble a fragmented datagram within its time limit. Code Code 0 1 Time to Live Exceeded Time to Reassemble Exceeded
Parameter Problem (12)

This message is sent to indicate that there is a value in the IP header that could not be understood.
TimeStamp Request/Reply (13, 14)

This message is sent to obtain the time from the clock of a remote device. This could be used for performance statistics or clock synchronisation.
Information Request/Reply (15, 16)

This message is sent to obtain the network number that the requesting host is on if it is not known.
Address Mask Request/Reply (17,18)

This message is sent to allow a node to discover the subnet mask of the network to which it is connected. The node may direct the request to a known address, probably a router, or may broadcast the request to the network.
CP09: TCP/IP
260
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Time Exceeded (11)
ICMP Message Types
Type 0 3 4 5 8 11 12 13 14 15 16 17 18
Definition Echo Reply Destination Unreachable Source Quench Redirect Echo Request Time Exceeded Parameter Problem Timestamp Request Timestamp Reply Information Request Information Reply Address Mask Request Address Mask Reply
Code(s) 0 0 - 13 4 0-3 0 0-1 0 0 0 0 0 0 0

CP09_2_34
CP09: TCP/IP
EMOTOROLA LTD. 2001
261
Time Exceeded (11)
Issue 1 Revision 4
ICMP Echo Request (Ping)
IP Internet Protocol Source Address Destination Address No IP Options 198.85.45.1 198.85.39.1
ICMP Internet Control Message Protocol Decode Status Type Code ICMP Checksum Identifier Sequence Number Echo data 8 0 0x495C 256 768 [32 byte(s) of data] (Echo) (Checksum Good)
CP09_2_35
CP09: TCP/IP
262
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Time Exceeded (11)
ICMP Echo Reply (Ping)
IP Internet Protocol Source Address Destination Address No IP Options 198.85.39.1 198.85.45.1
ICMP Internet Control Message Protocol Decode Status Type Code ICMP Checksum Identifier Sequence Number Echo data 8 0 0x515C 256 768 [32 byte(s) of data] (Echo) (Checksum Good)
CP09_2_36
CP09: TCP/IP
EMOTOROLA LTD. 2001
263
Time Exceeded (11)
Issue 1 Revision 4
ICMP Destination Unreachable
IP Internet Protocol Source Address Destination Address No IP Options ICMP Internet Control Message Protocol Decode Status Type Code ICMP Checksum Original IP Header is following: Decode Status Version Type of Service
198.85.38.109 198.85.45.57
3 3 0 x AB9B
(Destination Unreachable) (Port Unreachable) (Checksum Good)
Time to Live Protocol Checksum Source Address Destination Address No IP Options 8 bytes of original datagram data
4 Header Length: 20 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved 522 bytes 25598 0 x 4000 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes 31 seconds/hops 17 (UDP) 0 x 9992 (Checksum Good) 198.85.45.57 198.85.38.109 00 8A 00 8A 00 DF 4F 6E
CP09_2_37
CP09: TCP/IP
264
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Time Exceeded (11)
ICMP Destination Unreachable
198.85.39.254 198.85.39.1
3 4 0 x 8E3A
(Destination Unreachable) (Fragmentation needed and DF bit set) (Checksum Good)
4 Header Length: 20 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved 1500 bytes 1561 0 x 4000 0 . . . . . . . . . . . . . . . = Reserved . 1 . . . . . . . . . . . . . . = Dont Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes 31 seconds/hops 6 (TCP) 0 x 6E5B (Checksum Good) 198.85.39.1 198.85.45.252 04 2C 00 14 04 82 64 19
CP09_2_38
CP09: TCP/IP
EMOTOROLA LTD. 2001
265
Time Exceeded (11)
Issue 1 Revision 4
ICMP Redirect
IP Internet Protocol Source Address Destination Address No IP Options ICMP Internet Control Message Protocol Decode Status Type Code ICMP Checksum Gateway Internet Address Original IP Header is following: Decode Status Version Type of Service
198.85.45.252 198.85.45.1
3 3 0 x B14F
(Redirect) (Redirect datagrams for the Host) (Checksum Good)
198.85.45.253 4 Header Length: 20 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved 60 bytes 17152 0 x 00 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes 32 seconds/hops 1 (ICMP) 0 x 7714 (Checksum Good) 198.85.45.1 198.85.39.1 08 00 4B 5C 01 00 01 00
CP09_2_39
CP09: TCP/IP
266
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Time Exceeded (11)
ICMP Time Exceed
198.85.45.252 198.85.45.1
11 0 0 x A0A3
(Time Exceeded) (Time to live exceeded in transit) (Checksum Good)
4 Header Length: 20 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved 60 bytes 18432 0 x 00 0 . . . . . . . . . . . . . . . = Reserved . 0 . . . . . . . . . . . . . . = May Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes 0 seconds/hops 1 (ICMP) 0 x 8D14 (Checksum Good) 198.85.45.1 198.85.43.1 08 00 3F 5C 01 00 0D 00
CP09_2_40
CP09: TCP/IP
EMOTOROLA LTD. 2001
267
IP Datagram
Issue 1 Revision 4
IP Datagram
IEEE 8 2.3/Ethernet DIX V2 Header Decode Status Frame Length 64 Destination Address 0000C0FD5000 (OUI = WESTERN DIGITAL. Individual, Universally Administered Address) Source Address 0080C7495696 (OUI = XIRCOM. Universally Administered Address) Frame Format Ethernet DIX V2 Ethertype 0 x 800 (IP) Frame Checksum Good Frame Check Sequence 00 00 00 00 IP Internet Protocol Decode Status Version 4 Header Length: 20 Type of Service 0 x 00 000 . . . . . = Routine Precedence . . . 0 . . . . = Normal Delay . . . . 0 . . . = Normal Throughput . . . . . 0 . . = Normal Reliability . . . . . . 00 = Reserved Total Length 44 bytes Identification 29184 Fragment Control 0 x 4000 0 . . . . . . . . . . . . . . . = Reserved . 1 . . . . . . . . . . . . . . = Dont Fragment . . 0 . . . . . . . . . . . . . = Last Fragment . . . 0 0000 0000 0000 = Fragment Offset = 0 bytes Time to Live 32 seconds/hops Protocol 6 (TCP) Checksum 0 x 124 (Checksum Good) Source Address 198.85.45.1 Destination Address 198.85.45.252 No IP Options TCP Transmission Control Protocol Decode Status (FTP) Source Port 21 (Unknown) Destination Port 1050 Sequence Number 1243040 Acknowledgement Number 3778555 Data Offset 0 x 60 0110 . . . . = Header Length = 24 Flags 0 x 12 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 1 . = Synchronize Sequence Numbers . . . . . . . 0 = No End of Data Flow from Sender Window 32768 Checksum 0 x 9257 (Checksum Good) Urgent Pointer 0 Kind 2 (Maximum Segment Size) Option Length 4 Maximum Segment Size 1460
CP09: TCP/IP
268
EMOTOROLA LTD. 2001
Chapter 3
Routing Protocols
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 3 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing and Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distance Vector Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link-State Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Distance Vector Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Gateway to Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exterior Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Distance Vector Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Gateway Routing Protocol (IGRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link State Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
31 31 32 34 36 36 36 38 38 310 310 312 312 312 314 314 314
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Routing Protocols
Routing Protocols
Objectives
On completion of this chapter the student will be able to: S Describe the purpose and use of routing protocols.
CP09: TCP/IP
EMOTOROLA LTD. 2001
31
Routing and Routing Tables
Issue 1 Revision 4

For routers to fulfil their role, they need to know which networks are reachable and how to get to them. To accomplish this routers store information about the topology of the network. This topology is usually stored as a routing table that lists each known network, tells how far away each network is (e.g. the number of hops) and to which router to send packets to reach a network which is not directly attached. When the distance is 0, the network is directly attached and the router can use the ARP protocol to find the MAC address of the destination node. When the cost is non-zero, the routing table indicates the IP address of the next hop router. The sending router makes an ARP request to the next hop router and encapsulates the datagram in a data link layer packet addressed to the MAC address of the next router. When this router receives the packet, it checks its routing table to determine if the packet can be delivered locally or has to be sent to another router. If the destination network (or default network) does not appear in the routing table, then the packet cannot be delivered and is dropped. This could happen for a variety of reasons, including the following: The sending node was mistaken or wrongly configured. The router was wrongly configured. All routes to that network are no longer operating. Usually, when a packet is dropped due to the lack of a route, the router sends an Internet Control Message Protocol (ICMP) destination unreachable message to the source, which should cause the node to log a message informing the user that data is not getting through. Routing tables can be set up manually or dynamically. Sometimes a combination of both methods is used. For manual configurations, the user has to enter the details in the fields of the routing table. This is the usual method of connecting over WAN links. Dynamic acquisition of routing tables is achieved by means of one or more routing protocols. In TCP/IP networks the most common protocol is Routing Information Protocol (RIP). RIP is a simple protocol that enables routers to tell each other what networks they know about and how far away they are. With this information, routers can assemble a table of every network on an internet, enabling packets to be sent from any network to any other network. However, this could entail excessively large tables, especially if connected to the Internet, greatly increasing the processing time and slowing data throughput. Provision is made to clump many networks together in a default route represented by the IP address 0.0.0.0. Routers advertising connectivity to 0.0.0.0 are essentially saying, if you do not have any other route for a packet then send it to me. RIP updates are broadcast by every router, on every network, every 30 seconds. Because this can impact on network performance on very large networks, more efficient protocols are being developed. Many networks are changing to Open Shortest Path First (OSPF) because there is less broadcast traffic and topology changes are more rapidly disseminated.
CP09: TCP/IP
32
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Router 1 Network Net 1 Net 2 Net 3 Net 4 Net 5 Net 6
Distance 0 0 1 1 2 0
Next Router 222.222.222.2 222.222.222.2 222.222.222.2 192.52.7.1
Router 3
Net 1 128.10.0.0
128.10.0.3 Router 1
Net 2 192.52.7.0
222.222.222.1
Network Net 1 Net 2 Net 3 Net 4 Net 5 Net 6
Distance 2 2 1 0 1 0
Next Router 200.15.22.1 200.15.22.1 200.15.22.1 200.15.22.1
Net 6 222.222.222.0
137.103.0.3 222.222.222.2 200.15.22.1 Router 2 Distance 1 1 0 0 1 0 Next Router 222.222.222.1 222.222.222.1 200.15.22.3 200.15.22.3
Net 5 130.200.0.0
Net 3 137.103.0.0
Router 2 Network Net 1 Net 2 Net 3 Net 4 Net 5 Net 6
CP09_3_1
Net 4 200.15.22.0
Router 3
CP09: TCP/IP
EMOTOROLA LTD. 2001
33
Internet Architecture
Issue 1 Revision 4
The basis for all TCP/IP routing decisions is a table of routing information maintained by each device. Entries in the table can be static, entered by the system administrator or dynamic, gathered from information exchanged between routing devices using a routing protocol. Each entry in the table contains a destination and router address pair. For a given destination address, the router address indicates the host to which an IP datagram should be forwarded to reach that destination. IP routing specifies that IP datagrams travel through the internetworks one hop at a time. The entire route is not known at the outset. Instead, at each stop, the next step is calculated by matching the destination address within the datagram with an entry in the current nodes routing table. Routing devices in the Internet have traditionally been called gateways but are informally called routers and are organised hierarchically. Some routers are used to move information through one particular group of networks under the same administrative authority and control (such an entity is called an autonomous system). Routers used within an autonomous system are called interior gateways. The combined Internet is considered as a core backbone network to which a number of autonomous systems are attached. Routers that move information between autonomous systems are called exterior gateways. If every gateway and host system contained a separate entry in its routing table for all other systems, the size of the routing tables and the amount of processing and transmission capacity needed to maintain the tables would be excessive and, for the Internet, unmanageable. Instead, the total routing information is organised hierarchically. S S S Hosts maintain sufficient routing information to forward datagrams to other hosts or an interior gateway(s) that is (are) attached to the same network. Interior gateways maintain sufficient routing information to forward datagrams to hosts or other interior gateways within the same autonomous system. Exterior gateways maintain sufficient routing information to forward datagrams either to an interior gateway, if the datagram is for the same autonomous system, or to another exterior gateway.
A number of routing protocols have been developed to implement this scheme. ARP is used by hosts to maintain their own tables, A number of interior gateway protocols are available, any one of which can be used within an autonomous system. An Exterior Gateway Protocol (EGP) is used between exterior gateways. In addition, a gateway may advertise that it is connected to network 0.0.0.0. This is a default gateway. If the destination address is not in the routing table of any other router, packets are sent to the default gateway for onward transmission. In an AS, this would normally be the gateway attached to the Internet.
CP09: TCP/IP
34
EMOTOROLA LTD. 2001
Issue 1 Revision 4
AS EGP Core Gateway Core Network Core Gateway EGP Exterior Gateway IGP Interior Gateway IGP Interior Gateway IGP Interior Gateway
AS EGP Core Gateway
Core Gateway EGP AS
AS
IGP
CP09_3_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
35
Routing Protocols
Issue 1 Revision 4
Routing Protocols
In order for routers to exchange routing information, they need to implement a common routing protocol. There are two general ways in which routing protocols can work; either by a router which advertises costs to all networks which it is aware or by advertising the costs to use the links from that router. These two methods are known as Distance-vector and Link-state protocols respectively.
Distance Vector Protocols

The way in which distance-vector protocols work is by all participating routers periodically broadcasting the state of their routing tables to all other routers. Each router receiving a routing table, compares the entries with its own routing table and decides whether it can reach the listed networks at a lower cost via this new route. If it can, then it over-writes the old entry with the new one. Protocols differ in the criteria used to broadcast a routing table, as some protocols broadcast after a set time interval (determined by an administrator), and others only broadcast after a routing table change.
Link-State Protocols
Most routing protocols of this type use the Shortest Path First (SPF) algorithm, developed in the late 1980s. Routers that implement an SPF protocol advertise information about each of their links to every other router that they are connected to. When a router receives such information, it keeps a copy and forwards the information on to each of the other routers that it is connected to. In this way, this link information from one original router is very quickly broadcast to every other router in the autonomous system. As each router learns the information about all other routers, it can build a map of the autonomous system, containing each network, each router and each link with its associated cost. Routers then use this map to decide on the best way to route datagrams towards their destination.
CP09: TCP/IP
36
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Routing Protocols
Routing Protocols
Router 1 S Distance Vector Network 3 at 5 hops Network 27 at 14 hops
Destination
Next Hop
Metric
Router Router
S Link State Link 1, to net12, costs 12 Link 2, to router5, costs 4
CP09_3_3
CP09: TCP/IP
EMOTOROLA LTD. 2001
37
Special Distance Vector Protocols
Issue 1 Revision 4

Due to the different amounts of information that gateways need to exchange, dependant on their type, there are three types of routing protocol. Core gateways exchange routing information using a special protocol which was originally one known as GGP; exterior gateways use a protocol known as EGP; and interior gateways can use any protocol they like.
The Gateway to Gateway Protocol

This was the original distance-vector protocol used solely by the core gateways to exchange routing information about all networks. The type of information exchanged using GGP is simply of the form (N,C) where N is a network reachable by the sending gateway, and C is the cost to reach the network, in hops. A directly connected network, is said to be at a distance of zero hops. Whenever a gateway becomes aware of a new network, or a network becomes unreachable, or a routing table entry changes due to receipt of new information from another GGP gateway, a gateway sends a GGP message to its GGP neighbours advertising this fact. By using this method, core gateways build routing tables that contain entries (routes to destination networks) that have the lowest hop count.
CP09: TCP/IP
38
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Gateway to Gateway Protocol (GGP)
Core Router GGP
GGP
Core Router GGP
Core Network
Core Router
GGP
Core Router
CP09_3_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
39
Issue 1 Revision 4
Exterior Gateway Protocol

EGP was the first interdomain reachability protocol to gain widespread acceptance in the Internet. However, because of its inherent weaknesses it is being replaced by the Border Gateway Protocol. Although EGP is a dynamic routing protocol, it uses a very simple design. It does not use metrics and therefore cannot make true intelligent routing decisions. EGP routing updates contain network reachability information. In other words, they specify that certain networks are reachable through certain nodes. EGP has three primary functions. First, routers running EGP establish a set of neighbours. These neighbours are simply routers with which an EGP router wishes to share reachability information; there is no implication of geographic proximity. Second, EGP routers poll their neighbours to check that they are still alive. Third, EGP routers send update messages containing information about the reachability of networks within their ASs. EGP does not interpret the distance metrics contained in routing update messages. EGP uses the field to indicate whether a path exists. The distance value can only be used to compare paths if those paths exist wholly within a particular AS. For this reason, EGP is more a reachability protocol than a true routing protocol. This restriction puts topology limitations on the structure of the Internet. The EGP portion of the Internet must be a tree structure in which a core gateway is the root and there must be no loops between other ASs in the tree. This is a primary limitation of EGP.
Border Gateway Protocol

BGP is an inter-AS routing protocol developed for use in the Internet. Unlike EGP, BGP can detect routing loops. Although designed as an inter-AS protocol, BGP can be used both within and between ASs. Two BGP neighbours communicating between ASs must reside on the same physical network. BGP routers within the same AS communicate with each other to ensure that they have a consistent view of the AS and to determine which BGP router within the AS will serve as the connection point to/from certain external ASs. BGP update messages consist of network number/AS path pairs. The AS path contains the string of ASs through which the specified network may be reached. These update messages are sent over the TCP transport mechanism to ensure reliable delivery. The initial data exchange between two routers is the entire BGP routing table. Incremental updates are sent out as the routing table changes. BGP does not require periodic refresh of the entire routing table. Instead, routers running BGP retain the latest version of each peer routing table. Although BGP maintains a routing table with all feasible paths to a particular network, it only advertises the primary path in its update messages. The BGP metric is an arbitrary unit number specifying the degree of preference of a particular path. These metrics are typically assigned by the network administrator through configuration files.
CP09: TCP/IP
310
EMOTOROLA LTD. 2001
Issue 1 Revision 4
EGP / BGP
Core Router EGP EGP EGP
Core Router EGP
AS
AS
AS
AS
CP09_3_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
311
Interior Distance Vector Protocols
Issue 1 Revision 4

Because interior gateways, by definition, are administered by one authority, then that authority can decide on the routing protocol to be used. The first standarised interior routing protocol for the Internet community was the Routing Information Protocol (RIP).
RIP
Each entry in a RIP routing table provides a variety of information, including the ultimate destination, the next hop on the way to that destination and a metric. The metric indicates the distance, in number of hops, to the destination. RIP maintains only the best route to the destination. When new information provides a better route, this information replaces the old route information. Network topology changes are reflected in routing update messages. For example, when a router detects a link failure, it recalculates its routes and sends routing update messages. Each router receiving a routing update message that includes a change, updates its tables and propagates the change. There are a number of problems associated with RIP which are not dealt with by the protocol. These include that the protocol does not detect loops; it uses a hop count number of 16 to mean infinity, and therefore unreachable; and routing updates propagate through the network slowly (known as slow convergence) and so inconsistencies can occur. These problems aside, a gateway that uses the hop-count metric to determine routes may not always pick the best route available. To overcome this last restriction, the much newer protocol, OSPF, looks at many properties of particular routes before deciding which is best. RIP ensures that each router sends a complete copy of its routing table to all its neighbouring routers every 30 seconds. If no update for a route is received, after 180 seconds the route is declared invalid. After 300 seconds, if no update is received, the route is removed from the table.
Interior Gateway Routing Protocol (IGRP)

IGRP is a routing protocol developed by Cisco to overcome the limitations of RIP. In particular, RIPs hop count limit restricted the size of internetworks and its single metric (hop count) did not allow for routing flexibility in complex environments. (A 64kbps link had the same metric as a 2Mbps link.) The popularity of Cisco and the robustness of IGRP have encouraged many organisations with large internetworks to replace RIP with IGRP. IGRP uses a combination of metrics. Internetwork delay, bandwidth, reliability and load are all factored into the routing decision. Network administrators can set the weighting factors for each of these metrics. IGRP uses either the administrator set or the default weightings to automatically calculate optional routes. IGRP sends updates every 90 seconds. A route is declared invalid if no update is received for 270 seconds and removed from the table after 630 seconds.
CP09: TCP/IP
312
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Router 2 EGP RT7
Destination N1 N2 N3 N4 Default
Next Step RT1 Direct RT3 RT3 RT1
Metric 2 0 1 3 3
N1 RT4
RT1
N2 RT2 RT3
N3 RT5 RT6
N4
CP09_3_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
313
Link State Protocols
Issue 1 Revision 4

A gateway running a link-state protocol works by advertising the states of all of its links/interfaces to those gateways to which it is connected. These other gateways, in turn pass on the information so that it is quickly flooded throughout the autonomous system. The messages that contain these link states, also contain a metric associated with each link and the address of the network or gateway at the remote end of each link. From this information gathered from all other gateways, a gateway now draws a conceptual map of the system. Of course, once the information from each gateway has reached every other gateway, they all have a similar map from which they can obtain the best route for any destination network.
Open Shortest Path First (OSPF)

OSPF was created for IP networks by the IGP working group of the Internet Engineering Task Force (IETF) because RIP was unable to serve large, complex internetworks. OSPF is a link state protocol. It calls for the sending of link state information to all other routers in the autonomous system. Information on attached interfaces, metrics used and other variables are included in OSPF Link State Advertisements (LSAs). As OSPF routers gather link state information, they use the SPF algorithm to calculate the shortest path to each node. As a link state algorithm, OSPF contrasts with RIP and IGRP, which are distance vector routing protocols.
Routing Hierarchy
OSPF can operate within a hierarchy. The largest entity within the hierarchy is the autonomous system (AS). OSPF is an interior gateway protocol although it is also capable of receiving routes from and sending routes to other ASs. An AS can be divided into a number of areas. An area is a group of contiguous networks and attached hosts. Routers with multiple interfaces can participate in multiple areas. These routers, which are called area border routers, maintain separate topological databases for each area. The topological database is essentially an overall picture of networks in relationship to routers. The topological database contains the collection of LSAs received from all routers in the same area. Because routers within the same area share the same information, they have identical topological databases. The term domain is sometimes used to describe a portion of the network in which all routers have identical topological databases. An areas topology is invisible to entities outside the area. By keeping area topologies separate, OSPF passes less routing traffic than if the AS were not partitioned. An OSPF backbone is responsible for distributing information between areas. It consists of all area border routers, networks not wholly contained in a single domain and their attached routers. The figure opposite shows an internetwork with several areas (the backbone is also an area). In this figure, Routers 4, 5, 6, 10, 11 and 12 make up the backbone. If host H3 in Area 3 wishes to send a packet to host H2 in Area 2, the packet is sent to Router 13, which forwards the packet to Router 12, which sends it to Router 11. Router 11 sends it along the backbone to area border Router 10. Which sends the packet through two intra-area routers (9 and 7) until it can be forwarded to host H2. The backbone topology is invisible to all intra-domain routers, as are individual domain topologies to the backbone. CP09: TCP/IP
314
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Routing Hierarchy
H2
RT7 RT9
RT8
RT2 RT1 RT3 Area 1
RT6
Area 2
RT10
RT4
RT11
RT5
RT12
Area 3
H3
RT13
CP09_3_7
CP09: TCP/IP
EMOTOROLA LTD. 2001
315
Issue 1 Revision 4
CP09: TCP/IP
316
EMOTOROLA LTD. 2001
Chapter 4
Transport Protocols
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 4 Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source and Destination Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgement number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Urgent Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing a TCP Session 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
41 41 42 42 42 42 44 44 44 44 46 48 48 410 412 414 414 414 414 416 418 418 418 418 418 420 422 424 426 428 430 432 434
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Transport Protocols
Transport Protocols
Objectives
On completion of this chapter the student will be able to: S S S Describe the purpose and use of Transport Protocols. Describe the concepts of UDP and the UDP format. Describe the concepts of TCP and the format of the TCP segment.
CP09: TCP/IP
EMOTOROLA LTD. 2001
41
TCP/IP Suite
Issue 1 Revision 4
TCP/IP Suite
The Host-to-host level (OSI Transport Layer) is the third of the four conceptual TCP/IP levels. Its primary duty is to provide communication from one application program to another. This is often called end-to-end communication. In the TCP/IP protocol suite there are two main protocols provided at this level. So far we have considered the frames of the datalink layer and the datagrams of the IP layer. The IP data is encapsulated by the IP datagram, which is in turn encapsulated by the frame. At this layer, there are two separate options, UDP or TCP, dependant on the type of service required by the users application. One of these protocols is carried in the data field of the IP datagram. Once information has been transferred to the correct machine by IP, then it has to be passed to the relevant application-level service. Multiplexing and de-multiplexing data from many applications to and from the IP layer and directing data to the correct application is one of the responsibilities of the transport layer.
User Datagram Protocol

The User Datagram Protocol provides a connectionless, unreliable service. It allows data to be transmitted to a machine or a group of machines without the need to establish a connection. Single datagrams are sent to a remote node without the requirement for responses to indicate that the datagram has arrived.
Transmission Control Protocol

The Transmission Control Protocol provides a connection-oriented service. TCP has all the features necessary to provide a reliable service between two devices. In achieving reliability, it adds a significant amount of overhead to manage acknowledgements, flow control, timers and connection management facilities. It has more overhead than UDP in terms of both the processing power required and the size of the network headers it uses.
Message Transfer
The position of the two protocols TCP and UDP in relation to the other protocols, associated with each level is shown opposite. The drawing also shows the complete message transfer unit (MTU) that is transmitted/received by a host. At the network interface it comprises the LAN/WAN frame header, the information (user data) field and an associated trailer (end-of-frame marker plus CRC). The IP address is used to route datagrams to a specific host. Also, the protocol field in the datagram header indicates the attached protocol within the host to which the user data part of the datagram should be sent. This may be a protocol associated with IP or one of the transport protocols, UDP or TCP. As can be seen, UDP and TCP can both support multiple applications. Hence for the transport level to relay the user data to the appropriate application protocol, there is an address field in the header of each transport level PDU. In the TCP/IP suite this is known as the (protocol) port address. With TCP/IP, the composite address of an application protocol is the internet-wide IP address of the host plus the additional protocol port address. CP09: TCP/IP
42
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP/IP Suite
Message Transfer
Protocol Stack Telnet SMTP FTP TFTP SNMP DNS
TCP
UDP
IP
Network Physical Medium Message Format

LAN/WAN Header
IP TCP/UDP Header number Header Diagram
User Data
LAN/WAN Trailer
CP09_4_1
CP09: TCP/IP
EMOTOROLA LTD. 2001
43
Addressing Concepts
Issue 1 Revision 4
Addressing Concepts
Communication protocols in a layered hierarchy use a technique called multiplexing and demultiplexing. We have already seen some of this when studying the IP layer. When sending a message, the source computer includes extra bits that encode the message type, originating process, and protocols used. Eventually, all messages are placed into network frames for transfer. The slide shows how software at the network interface layer uses the frame type field to decide how to handle the incoming frame. It is called demultiplexing the frame. In order that the choice can be made, software in the source machine must have set the frame type field before transmission. The process then continues through the layers. The demultiplexed frames that contain the IP datagrams are passed to the IP module; the IP software extracts the datagram and demultiplexes further based on the protocol address. This is then passed to the next module, for example TCP, which uses the process address to decide which application the data is destined. There are three types of addressing involved in this process:
Host addressing
In the IP layer. This is the 32-bit address, which has already been discussed.
Protocol Addressing
In the IP header, which indicates the transport protocol being used. The 8-bit field in the IP header addresses the protocol being used above IP. Each protocol has a well-known port number, which addresses it; for example TCP is port 6.
Process Addressing
In the transport protocol. Each process (application) that wants to communicate with another process identifies itself to the transport protocols (TCP and UDP) by one or more ports. A port is a 16-bit number, used by the transport protocols to identify which application protocol, or process, it must deliver incoming messages. Both UDP and TCP use well-known numbers in the destination port field to indicate the service required. These standardised port numbers are called well-known ports and the standard applications well-known services.
CP09: TCP/IP
44
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Addressing Concepts
Addressing Concepts
Telnet 23
SMTP 25
FTP 20 21
TFTP 69
SNMP 161
DNS 53
TCP 06
UDP 17
ARP 0806
IP 0800 122.45.2.5 Network Physical Medium 00:08:F2:C5:28
RARP 8035
CP09_4_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
45
UDP Concepts
Issue 1 Revision 4
UDP Concepts
In the TCP/IP protocol suite, the User Datagram Protocol (UDP) provides one of the mechanisms available for senders to identify the target process on the receiving host. UDP depends on the underlying IP layer to transport a UDP message from one machine to another. It provides: S S S S The same unreliable connectionless delivery service as IP. It does not use acknowledgements to make sure messages arrive. It does not sequence incoming messages. It does not provide any flow control mechanisms.
Because of this, UDP messages may be lost, duplicated or arrive out of order. Furthermore, as there is no flow control, packets may arrive faster than the recipient can process them. UDP is basically an application interface to IP. In addition to the user process, each UDP message contains both a destination port number and source port number, making it possible for the UDP software to deliver the message to the correct recipient and for the recipient to send a reply. UDP software accepts UDP datagrams from the IP software and demultiplexes them based on the UDP port address. Other port numbers may be assigned using dynamic binding. That is, where the target machine provides the correct port number for a calling application to use. Port numbers for well known processes are published in RFCs. UDP adds a header to the user data and passes it to IP. The IP layer then adds its own header to what it regards as user data from UDP. Finally the network interface layer embeds the datagram in a network frame before sending it from machine to machine. The format it uses depends on the network technology. On arrival, the packet is passed through successively higher layers. Each layer removes one header and performs any necessary processing before passing the message on. When the UDP datagram is passed from IP on the destination machine it is identical to the datagram that UDP passed to IP on the source machine. Also, the data that UDP delivers to a user process on the receiving machine will be exactly the data that a user process passed to UDP on the sending machine.
CP09: TCP/IP
46
EMOTOROLA LTD. 2001
Issue 1 Revision 4
UDP Concepts
UDP Concepts
TFTP 69
SNMP 161
DNS 53
UDP 17
IP 0800 122.45.2.5 Network Physical Medium 00:08:F2:C5:28

CP09_4_3
CP09: TCP/IP
EMOTOROLA LTD. 2001
47
UDP Format
Issue 1 Revision 4
UDP Format
Each UDP message is called a user datagram (or UDP datagram) and consists of two parts: S S UDP header. Data area, which is the user process data above UDP.
UDP Header
The header is divided into four 16-bit fields:
Source Port
16-bit UDP protocol port number. It indicates the port of the sending process. It is the port to which replies should be addressed. This field is optional, if not used it should be zero.
Destination Port
16-bit UDP protocol port number. Specifies the unique port number of the destination process.
Length
16-bits. Contains the count of octets in the UDP datagram, including the header and data. The minimum length is eight, the length of the header alone.
Checksum
16 bits. A value of zero in this field means that the checksum has not been computed by the sending entity. Remember that IP does not compute a checksum on the data portion of a datagram which means that the UDP checksum provides the only way to guarantee that data arrived intact and should be used. The checksum is performed on a pseudo header consisting of information obtained from the IP (source and destination IP addresses, protocol number and UDP length), as well as the UDP header and data itself. Standard applications are available using UDP, and these include: S S S S S Trivial File Transfer Protocol (TFTP) Host Name Server and Domain Name Server Remote Procedure Call (RPC), used by Network File System (NFS) The Simple Network Management protocol (SNMP) The Bootstrap Protocol (BootP)
CP09: TCP/IP
48
EMOTOROLA LTD. 2001
Issue 1 Revision 4
UDP Format
UDP Format
10
11
12
13
14
15
16
Source Port Destination Port Length Checksum Data
UDP = User Datagram Protocol Decode Status Source Port Destination Port UDP Length Checksum 520 520 92 0x00 (RIP) (RIP) (Checksum not sent)
CPO9_4_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
49
Issue 1 Revision 4

Here we introduce one of the most important and well known of the Internet services; reliable stream delivery, and the TCP protocol that defines it. Most of the user application protocols such as Telnet and FTP use TCP as the underlying protocol. TCP is a connection-orientated, end-to-end, reliable protocol providing logical connections between pairs of processes. A socket uniquely identifies each process: IP socket = (IP address, port number) The ports are used for demultiplexing incoming data to the relevant higher-level processes. This principle is applied to TCP as for UDP. Within TCP, a pair of sockets uniquely defines a connection. That is, by a pair of processes, on the same or different systems that are exchanging information. These two processes communicate with one another over the TCP connection. The need for a service such as TCP becomes more meaningful when we consider the needs of the application programs, which often need to send large volumes of data between computers. Using an unreliable, connectionless delivery system becomes tedious when transferring large volumes, since it requires that the programmers build error detection and recovery into each application program. Therefore, one goal of the network protocol research project was to find a general-purpose solution to the problem of providing a reliable stream delivery that all applications could use. Having such a protocol helps to isolate application programs from the details of networking, and makes it possible to define a uniform interface that dictates how application programs make use of the stream transfer service. TCP is presented here as part of the Internet protocol suite, but it is an independent, general-purpose protocol that can be used with other delivery systems. For example, because TCP makes very few assumptions about the underlying network, it is possible to use it over a single network like Ethernet, as well as over the complex Internet.
CP09: TCP/IP
410
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP Concepts
FTP 1025
FTP 21 Reliable TCP Connection
TCP 06
TCP 06
Unreliable IP Datagram IP IP
Network Physical Medium
CP09_4_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
411
TCP Segment
Issue 1 Revision 4
TCP Segment
The unit of transfer (or PDU) between the TCP modules on two machines is called a segment. Segments are exchanged: S S S S S To establish connections To transfer data To send acknowledgements To advertise window size To close connections
TCP usually acknowledges received segments promptly, although the protocol allows for acknowledgement piggybacking. In practice piggybacking only occurs when the recipient delays acknowledgements. Each segment is divided into two parts: S S A header, called the TCP header The data from the application process
CP09: TCP/IP
412
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP Segment
TCP Segment
10
11
12
13
14
15
16
Source Port Destination Port Sequence Number Sequence Number Acknowledgement Number Acknowledgement Number Data Offset 0 0 0 0 0 0 URG ACK PSH RST SYN FIN
Window Checksum Urgent Pointer Options/Padding
Data
CPO9_4_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
413
Source and Destination Port
Issue 1 Revision 4

(16 bits each) A port is a 16-bit number and is used by TCP to identify a connection to the application layer service. A port is unique within a host. Some port numbers are dynamically assigned whereas others are statically assigned. The static ports are the well-known port numbers. The source port identifies the application service from where the datagram came and the destination port identifies the application service that the datagram is intended for.
Sequence Number
(32-bits) In TCP, the sequence number is a count of octets within the data stream. The sequence number identifies the position in the overall data stream of the first octet of data in the segment. The initial sequence number is generated randomly, and is synchronised during connection establishment.
Acknowledgeme nt number
(32-bits) The acknowledgement number acknowledges correct receipt of all octets up to the acknowledgement number and shows the number of the next octet that is expected to be received from the host. TCP acknowledgements do not refer to received segments, instead they use the position of received octets in the data stream. Sequence numbers are counted octet-per-octet, and acknowledgements specify the sequence number of the next octet that the receiver expects to receive.
Data Offset
(4-bits) Contains an integer that specifies the number of 32-bit words in the TCP header. It indicates where the data begins. It is needed because the Options field varies in length, depending on the options that have been included. Thus, the size of the TCP header varies depending on the options selected.
CP09: TCP/IP
414
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP Header Decode
TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags 21 1050 1243040 3778555 0 x 60 0110 . . . . = Header Length = 24 0 x 12 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 1 . = Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender Window Checksum Urgent Pointer Kind Option Length Maximum Segment Size 32768 0 x 9257 0 2 4 1460
CP09_4_7
(FTP) (Unknown)
(Checksum Good) (Maximum Segment Size)
CP09: TCP/IP
EMOTOROLA LTD. 2001
415
Flags
Issue 1 Revision 4
Flags
(6 bits) Some segments carry only an acknowledgement, some carry data, while others carry requests to open and close connections. The flags (or pointers) are used to determine the contents and purpose of the segment. The flags are either on or off.
URG
Urgent pointer. Indicates that the Urgent pointer field is valid which points to an octet in the data field which is the end of urgent data. Urgent data is data, which should be processed before other data. It can be used to interrupt programs.
ACK
Acknowledgement Flag. This is used to acknowledge receipt of data.
PSH
Push Flag. This causes TCP to pass the segment immediately to the Application layer.
RST
Reset Flag. This shows that an error has occurred and that the connection is to be forcibly closed.
SYN
Synchronise Flag. This is used at the beginning of a connection set-up between two nodes. At this stage the sequence numbers to be used for the rest of the dialogue are being synchronised.
FIN
Finish Flag. This is used to terminate a TCP connection. When one device has no more data to transmit, it sends a segment with the FIN flag set. When both ends of a connection have sent the FIN flag, then the connection is closed.
CP09: TCP/IP
416
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Flags
TCP Decode
CP09_4_8
(FTP) (Unknown)
CP09: TCP/IP
EMOTOROLA LTD. 2001
417
Flags
Issue 1 Revision 4
Window
(16 bits) This is the number of octets that the source host will accept from the other end before requiring the other end to wait for an acknowledgement. The window is used for flow-control. The window size increases and decreases in response to network congestion and to host resource availability. Each acknowledgement advertises its current window size.
Checksum
(16 bits) Used to verify the integrity of the TCP segment header as well as the data. To compute the checksum, the TCP software on the sending machine prepends the same pseudo header (pseudo IP header) that was seen for UDP. The pseudo header allows the receiver to verify that the segment has reached its correct destination. This includes both a host Internet address as well as a protocol number.
Urgent Pointer
(16 bits) Points to the byte of urgent data and is only significant when the URG code bit is set. The protocol specifies that when urgent data is found, the receiving TCP should notify whatever application program is associated with the connection to go into the urgent mode. After all the urgent data has been received, TCP tells the application to return to normal. Note that the meaning of urgent is not defined!
Pointer
(Variable) If options are present then an additional 4 octets of data are present at the end of the TCP header. There is only one option normally used with TCP, which is the Maximum Segment Size and is used during the start of a TCP session, in order to advertise the maximum segment size which should be sent. The only currently used option is Kind. Kind 2 Maximum Segment Size
1 0
No Operation End of Option List
Padding
All zero bytes used to fill up the TCP header to a total length that is a multiple of 32 bits.
CP09: TCP/IP
418
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Flags
TCP Decode
CP09_4_9
(FTP) (Unknown)
CP09: TCP/IP
EMOTOROLA LTD. 2001
419
Establishing a TCP Session
Issue 1 Revision 4

Before any data can be transferred, a connection has to be established between the two processes. To establish a connection, TCP uses a three-way handshake. The first element has the SYN bit set in the code field. The second message has both the SYN bit and ACK bit set, indicating that it acknowledges the first SYN segment as well as continuing the handshake. The final message has the ACK bit set to acknowledgement that both sides agree that a connection has been established. The three-way handshake accomplishes two important tasks: S S It guarantees that both sides are ready to transfer data (and that they know the state of readiness of the other side). It allows both sides to advertise their initial sequence numbers.
Sequence numbers are sent and acknowledged during the handshake. Each machine chooses an initial sequence number that is used to identify octets in the stream it is sending.
CP09: TCP/IP
420
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Host A
Host B
SYN
SYN, ACK
ACK
CP09_4_10
CP09: TCP/IP
EMOTOROLA LTD. 2001
421
Establishing a TCP Session 1
Issue 1 Revision 4

At the beginning of every TCP session, the source and destination devices go through a 3-step handshake process to establish the session.
Step 1
1. 2. 3. The source device (Client) initiating the session generates a random sequence number and sets the Acknowledgement number to zero. The SYN flag is set to 1 which indicates that the Client is requesting that the destination (Server) is to synchronise onto this sequence number. The Client uses the Option field to advertise the Maximum Segment size, which the Client will be able to receive from the Server.
CP09: TCP/IP
422
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags 1025 21 5419543 0 0 x 60 0110 . . . . = Header Length = 24 0 x 02 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Not Acknowledged . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 1 . = Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender Window Checksum Urgent Pointer Kind Option Length Maximum Segment Size 8192 0 x D9FE 0 2 4 1460 (Maximum Segment Size) (Checksum Good) (Unknown) (FTP)
CP09_4_11
CP09: TCP/IP
EMOTOROLA LTD. 2001
423
Issue 1 Revision 4

Step 2
1. The Server generates a random sequence number and also acknowledges the Clients TCP segment by setting the acknowledgement number to a value of the Clients previous sequence number incremented by one. The SYN flag is set to 1 which indicates that the Server is requesting that the Client is to synchronise onto this sequence number. The ACK flag is set to 1 to indicate that the Server is returning a valid acknowledgement to the Client. 3. The Server uses the Option field to advertise the Maximum Segment size, which the Server will be able to receive from the Client.
2.
CP09: TCP/IP
424
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags 21 1025 21045782 5419544 0 x 60 0110 . . . . = Header Length = 24 0 x 12 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 1 . = Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender Window Checksum Urgent Pointer Kind Option Length Maximum Segment Size 32768 0 x 56DE 0 2 4 1442 (Maximum Segment Size) (Checksum Good) (FTP) (Unknown)
CP09_4_12
CP09: TCP/IP
EMOTOROLA LTD. 2001
425
Issue 1 Revision 4

Step 3
1. The Client acknowledges the Servers TCP segment by setting the acknowledgement number to a value of the Servers previous sequence number incremented by one. The ACK flag is set to 1 indicating that the Client is returning a valid acknowledgement number to the Server.
2.
CP09: TCP/IP
426
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags 1025 21 5419544 21045729 0 x 50 0101 . . . . = Header Length = 24 0 x 10 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 0 . = No Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender Window Checksum Urgent Pointer No TCP Options
CP09_4_13
(Unknown) (FTP)
8652 0 x CCBD 0 (Checksum Good)
CP09: TCP/IP
EMOTOROLA LTD. 2001
427
Terminating a TCP Session
Issue 1 Revision 4

Terminating the connection is done implicitly by sending a TCP segment with the FIN flag set. This means that there is no more data to be transmitted in that direction. As the connection is full duplex, with two independent data streams, the FIN segment only closes transfer in one direction, with TCP refusing to accept more data for that direction. The other process can continue to send its remaining data that it still has to transmit. When complete it also terminates the connection with a TCP FIN segment. The connection is deleted once the data stream is closed in both directions. This procedure ensures that both sides have received all outstanding data, and that both sides agree to closure termination before actual termination. One problem that could occur is that the FIN segment arrives at the other side before the last data segment. TCP would accept the FIN, close the connection, and lose the last segment of data. To avoid this a sequence number is associated with each FIN, and this number is designed such that it occurs after the last actual octet of transmitted data. This means that the receiving TCP, upon getting the FIN, will wait if necessary for late-arriving data before closing the connection. A more serious problem is the potential loss of segments and the potential presence of obsolete segments. To overcome this TCP requires that each side explicitly acknowledge the FIN segment from the other module, using an ACK, with the sequence number of the FIN to be acknowledged.
CP09: TCP/IP
428
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Host A FIN DATA
Host B
DATA
ACK FIN, ACK
ACK
CP09_4_14
CP09: TCP/IP
EMOTOROLA LTD. 2001
429
Issue 1 Revision 4

Step 1 When a Host at one end of the session no longer has data to transmit, the FIN flag is set to 1 (End of Data Flow from Sender). Note that TCP, in this example, is carrying 384 octets of FTP data from a Server to a Client. Step 2 The Client acknowledges the TCP segment by setting the acknowledgement number to a value of the Servers previous sequence number incremented by one. The Client acknowledges the 384 octets of FTP data and increments the acknowledgement number by one.
CP09: TCP/IP
430
EMOTOROLA LTD. 2001
Issue 1 Revision 4

SERVER TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags -20 (FTP Data) 1027 (Unknown) 21114611 543089 0 x 50 0101 . . . . = Header Length = 20 0 x 19 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 1 . . . = Push . . . . . 0 . . = No Reset . . . . . . 0 . = No Synchronize Sequence Numbers . . . . . . . 1 = End of data flow from sender 32768 0 x EDA0 0 (Checksum Good)
Window Checksum Urgent Pointer No TCP Options FTP Data File Transfer Protocol Data Decode Status Data CLIENT TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags
[384 bytes of data]
CP09_4_15
-1027 20 5453089 21114996 0 x 50 0101 . . . . = Header Length = 20 0 x 10 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 0 . = No Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender (Unknown) (FTP Data)
Window Checksum Urgent Pointer No TCP Options
8652 0 x 3BIF 0
CP09_4_16
(Checksum Good)
CP09: TCP/IP
EMOTOROLA LTD. 2001
431
Issue 1 Revision 4

Step 3 The Client then sends a TCP segment to the Server with the FIN flag is set to 1 (End of Data Flow from Sender). Step 4 The Server acknowledges the TCP segment by setting the acknowledgement number to a value of the Clients previous sequence number incremented by one.
CP09: TCP/IP
432
EMOTOROLA LTD. 2001
Issue 1 Revision 4

CLIENT TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags -1027 20 5453089 21114996 0 x 50 0101 . . . . = Header Length = 20 0 x 11 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 0 . = No Synchronize Sequence Numbers . . . . . . . 1 = End of data flow from sender Window Checksum Urgent Pointer No TCP Options
CP09_4_17
(Unknown) (FTP Data)
8652 0 x 3B1E 0 (Checksum Good)
SERVER
TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags -20 1027 21114996 5453090 0 x 50 0101 . . . . = Header Length = 20 0 x 10 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 0 . . = No Reset . . . . . . 0 . = No Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender Window Checksum Urgent Pointer No TCP Options
CP09_4_18
(FTP Data) (Unknown)
32767 0 x DCEA 0 (Checksum Good)
CP09: TCP/IP
EMOTOROLA LTD. 2001
433
Issue 1 Revision 4
Terminating a TCP Session Reset

Another method of terminating a TCP session is by sending a TCP segment with the Reset flag set to 1. This will terminate the session immediately. This method may be used when an application detects that the system is going down or when communications with the host at the other end of the session has been lost.
CP09: TCP/IP
434
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Terminating a TCP Session Reset
TCP Transmission Control Protocol Decode Status Source Port Destination Port Sequence Number Acknowledgement Number Data Offset Flags -21 1025 21046141 5419651 0 x 50 0101 . . . . = Header Length = 20 0 x 14 . . 0 . . . . . = No Urgent Pointer . . . 1 . . . . = Acknowledgement . . . . 0 . . . = No Push . . . . . 1 . . = Reset . . . . . . 0 . = No Synchronize Sequence Numbers . . . . . . . 0 = No End of data flow from sender Window Checksum Urgent Pointer No TCP Options
CP09_4_19
(FTP) (Unknown)
32661 0 x 6CE9 0 (Checksum Good)
CP09: TCP/IP
EMOTOROLA LTD. 2001
435
Issue 1 Revision 4
CP09: TCP/IP
436
EMOTOROLA LTD. 2001
Chapter 5
Application Protocols
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 5 Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trivial File Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Mail Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mail Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
51 51 52 52 54 56 56 58 510 512
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Objectives
On completion of this chapter the student will be able to describe the following application protocols: S S S S Telnet. File Transfer Protocol (FTP) Simple Mail Transfer Protocol (SMTP) Simple Network Management Protocol (SNMP)
CP09: TCP/IP
EMOTOROLA LTD. 2001
51
Process Layer
Issue 1 Revision 4
Process Layer
The highest-level protocols of the TCP/IP suite are called application protocols (APs). They communicate with applications on other Internet hosts and provide the interfaces and facilities to the user. The most widely used higher level applications, which are standardised and shipped with most TCP/IP implementations are: S S S S TELNET for interactive access to remote Internet hosts FTP (File Transfer Protocol) for high speed disk to disk file transfers SMTP (Simple Mail Transfer Protocol) provides an Internet mailing system Applications can either use TCP or UDP as a transport mechanism. Since UDP provides an unreliable service, it is often easier to build applications on top of TCP, as are the three application protocols given above.
Client-Server Model
TCP is a peer-to-peer, connection orientated protocol. The primary form of interaction between co-operating application programs is known as the client-server model. S S A Server is an application that offers a service to Internet users. A Client is an application program that is the requester of a service.
An application consists of both a server and client, either of which may run on the same or different systems. The server accepts requests that arrive over the network, perform their service, and return the result to the requester (client). Users usually invoke the client part of the application by building a request for a particular service which then sends it to the server part by using TCP/IP as the transport mechanism. The server is a program that starts its execution before an interaction begins with a client. It receives requests from the clients and sends responses. A server can usually deal with multiple requests (multiple clients) at the same time. It is usual for the server to wait for requests at a well-known port, so that their clients know to which IP socket they must direct their requests. The client, however, allocates an arbitrary, unused, non-reserved port for its communication. Those clients that wish to communicate with a server that does not have a well-known port number must have another mechanism for learning which port their requests must be directed. The mechanism is usually achieved by employing some registration service.
CP09: TCP/IP
52
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Process Layer
Client-Server Model
Request to a wellknown port FTP TELNET etc.

Client Server
Reponse to clients port
Client
Server
CP09_5_1
CP09: TCP/IP
EMOTOROLA LTD. 2001
53
Telnet
Issue 1 Revision 4
Telnet
The client Telnet protocol / process is accessed through the local operating system either by a user application or, more usually, by a user at a terminal. It provides services to enable a user to log on to the operating system of a remote machine, to initiate the running of a program on that machine and then to interact with it as if the user terminal were running on the same machine. All commands and data entered at the user terminal are passed by the local operating system to the client Telnet process which then passes them, using the reliable stream service provided by TCP, to the correspondent server Telnet. The latter issues the commands on behalf of the user, through the local operating system, to the interactive process. Any data output by the interactive process is returned in the same way for display on the client terminal. The two Telnet protocols communicate with each other using commands that are encoded in a standard format known as network virtual terminal (NVT). The character set used for the commands is ASCII. All input and output data relating to an interaction is also transferred as ASCII. If this is different from the local character set being used, the corresponding Telnet will carry out any necessary mapping functions. Although ASCII is normally a 7-bit code, an 8-bit code is used with Telnet. When the most significant bit is 0, all the characters have their normal meaning. An extra set of command characters is defined by setting the most significant bit to 1.
CP09: TCP/IP
54
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Telnet
Telnet
23
Network Virtual Terminal Telnet
Network Virtual Terminal Telnet
Operating System
Operating System
Client
Client
CP09_5_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
55
File Transfer Protocol (FTP)
Issue 1 Revision 4

Access to a remote file server is a fundamental requirement in many distributed systems. It is amongst the most frequently used operations, and since files can be large, this generates much network traffic, and requires a reliable end-to-end transport protocol like TCP. A client FTP can be accessed either by a user at a terminal or by a user application process. Normally, a single client can support multiple users concurrently. It provides each user with a similar set of services to those available with most file systems. Thus a user can list directories, create new files, read existing files, perform update operations on files, delete files and so on. Similarly, a server FTP can respond to requests from multiple clients concurrently. On receipt of each request, the server FTP interacts with its local file system to carry out the request as if it had been generated locally. Three file structures are supported; unstructured, structured and random access. Four data types are supported; 8-bit binary, variable length binary, ASCII and EBCDIC. The FTP server accesses each file from the local file system and transfers it to the client FTP in an appropriate way according to its defined structure. An unstructured file is sent as a transparent bit stream. Structured files consist of fixed size records of a defined type. The contents of such files are normally transferred as a string of fixed-size blocks. Alternatively, the contents may be transferred in compressed form if each FTP protocol entity applies an agreed compression algorithm to the field contents prior to transmission. Random access files are comprised of records of variable size called pages. Each record page has a header that includes a length and type field and positional information to indicate the position of the page relative to the total file contents. Each page is transferred between the two protocol entities in the same form. To handle multiple requests concurrently, all requests are initially sent to the master or control process on the well-known port. The master process creates a new process for each new connection. The master process performs all the control functions associated with the session, including the log on with password procedure and the definition of the structure and data types associated with the file(s) to be transferred. It also defines whether compression is to be used and the compression algorithm. Sometimes another process is created to handle the actual data transfer. In such cases two transport connections are established; one for exchanging control messages and the other for transferring files. The NVT format is normally used for the exchange of control messages except that option negotiation is not required.
Trivial File Transfer Protocol

FTP is relatively complex since it contains all the features that are needed for a variety of types and compression algorithms. If two devices are on the same LAN, then there is no need for this complexity. TFTP is intended primarily for LAN applications. It uses UDP rather than TCP because error rates on LANs are relatively low. To overcome the possibility of corrupted messages a simple Idle RQ error control procedure is incorporated into the protocol. With Idle RQ only a single message block may be sent until either an acknowledgement is returned or a timeout occurs. This is adequate because of the short delay times associated with LANs. TFTP uses just four message types that are also encoded in ASCII; Read request, Write request, Data Block and Acknowledgement. In common with FTP, a TFTP server can support multiple client transfer requests concurrently.
CP09: TCP/IP
56
EMOTOROLA LTD. 2001
Issue 1 Revision 4
21
FTP
FTP
Source File
Destination Source File
20
Client Server
CP09_5_3
CP09: TCP/IP
EMOTOROLA LTD. 2001
57
Simple Mail Transfer Protocol
Issue 1 Revision 4

SMTP manages the transfer of mail from one host computer system to another. It is not responsible for accepting mail from local users or for distributing received mail to its intended recipients. These are the responsibility of the local mail system. SMTP interacts with the local mail system and not the user. It is masked from any mail transfers local to the machine. Only when mail is to be sent to another machine or is received from a remote machine is SMTP scheduled to run. Normally, there is an input queue and an output queue at the interface between the local mail system and the client and server parts of the SMTP. The client is concerned with initiating the transfer of mail to another system while the server is concerned with receiving mail. The local mail system retains a mailbox for each user into which the user can deposit and retrieve mail. Each mailbox has a unique name that consists of a local part and a global part. The first is the name of the user and is unique only within the local system. The second, the identity of the host, must be unique within the total internet. It normally consists of a number of fields and the precise format varies for different types of establishment education, government, military, etc. There are two points to consider in the transfer of mail: the format of the mail and the SMTP used to transfer it from one machine to another. The mail format consists of a header and a body which themselves consist of a number of lines of ASCII text with a blank line separating the header from the body. Only ASCII text is accepted. Each line in the header contains a keyword followed by a text string with a colon separating the two. Some keywords are compulsory while others are optional. The minimum header is: TO: FROM: Or TO: REPLY TO: name of recipient name to send reply to name of recipient name of sender
A header can contain the following: TO: FROM: CC: SUBJECT: DATE: ENCRYPTED: encryption pointer RECEIVED FROM: gateway that forwarded the mail. Each gateway can add a RECEIVED FROM line to the header so that the route taken across the internet can be identified. name of recipient name of sender copies to
CP09: TCP/IP
58
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Simple Mail Transfer Protocol (SMTP)
Terminal Users
Terminal Users
Terminal Users
Operating System
Operating System
Operating System
Local Mail System
Local Mail System
Local Mail System
Client SMTP
Server SMTP
Client SMTP
Server SMTP
Client SMTP
Server SMTP
TCP/IP
TCP/IP
TCP/IP
Internetwork
CP09_5_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
59
Issue 1 Revision 4
Mail Transfer
After an item of mail (message) has been created the local mail systems determines from the name whether it is to be put in a mail box for local delivery or into the output queue ready for forwarding. Each message has: S S An envelope, the structure of which is strictly defined. The contents (the message itself).
One of the fields in the envelope is the destination address. It has the following generic form: local_portion@domain_name eg davew@xyz.co.uk
To send the mail, the client SMTP first ascertains the IP address of the destination host from the directory service, the domain name system (DNS). It then uses this IP address, and the well-known port address of SMTP (25), to initiate the setting up of a transport connection with the server SMTP in the destination host. Once a connection is established, the client initiates the transfer of the waiting mail to the server. Transferring the mail involves the exchange of SMTP Protocol Data Units (PDUs) known as commands. All commands are encoded as ASCII character strings and comprise either a 3-digit number or a textual command. They are transferred over the established transport connection using the TCP SEND / DELIVER user primitives. Once a TCP connection has been established, the server SMTP sends command 220 back to the client. The client responds with a HELO command and the identity of the client machine. The server responds with the identity of the server machine. This response is used as a record of the mail transaction. The client then sends a MAIL command followed by the FROM: line in the mail header. The server returns command 250. The client then sends the RCPT command followed by the TO: line in the mail header. This is again acknowledged by the 250 command. Subsequent lines in the header are sent in the same way. The client sends the DATA command to indicate the start of the mail contents. The server responds with a 354 command and the client sends the mail contents as a sequence of lines terminated by a line with a single period The server acknowledges receipt by returning a 250 command. The mail transfer phase is terminated when the client sends a QUIT command and the server returns a 221 command, following which, the transport connection is cleared. These are the basic functions associated with the SMTP but a number of additional functions are available with some implementations. For example, if the intended recipient no longer has a mailbox at the server, the SMTP server may return a forwarding address. Also, after a client SMTP has sent its e-mail, it may invite the server to send mail in the reverse direction before clearing the transport connection. (This allows a chat line to be established).
CP09: TCP/IP
510
EMOTOROLA LTD. 2001
Issue 1 Revision 4
SMTP Command Exchange
Client SMTP TCP connection established HELO: client name
Server SMTP TCP connection established 220: ready for mail Server name
MAIL FROM: senders name 250: okay RCPT TO: recipients name Either 550: recipient not here or 250: okay DATA Contents of the body part terminated by a line with a single period QUIT 221: destination closing TCP connection cleared TCP connection cleared 354: ready for mail
250: okay
CP09_5_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
511
Simple Network Management Protocol
Issue 1 Revision 4

SNMP is an application-layer protocol designed to facilitate the exchange of management information between network devices. By using SNMP data, such as packets per second and error rates, network administrators can more easily manage network performance and find and solve network problems. In SNMP, agents are modules that run on managed devices. Agents compile information about the managed devices and make this information available to network management systems (NMS) via the SNMP. A managed device can be any type of node on a network, including PCs, workstations, communication servers, printers, routers, bridges and hubs. Because some of the devices may have limited processing capability, the management software must be built in such a way as to minimise its own performance impact on the managed devices. The NMS is usually a workstation-calibre computer with a fast CPU, substantial memory and lots of disk space able to take on the management burden of the network. The NMS runs the network management applications that present management information to users through a graphical user interface (GUI). All managed objects are contained in the Management Information Base (MIB), which is essentially a standardised database of objects. (The current standard is MIB-II.) The GUI provides the user with a range of services to interrogate the information in the MIB, to initiate the entry and collection of additional information and to initiate configuration changes. SNMP is a simple request/response protocol. Four SNMP operations are defined: S S S S Get Get Next Set Trap Retrieves the current value(s) of a variable in an agent.. A traversal operation that retrieves the next value from a table or list within an agent. Sets a variable within an agent. Sent by the agent to asynchronously inform the NMS of some event.
The resulting messages Protocol Data Units (PDUs) generated by SNMP are all exchanged using UDP. Two sets of addresses have to be configured on managed objects, Access Communities are the names and IP addresses of devices which are allowed access to the MIB in the managed object. Typically, the user would configure the name (default: public) and the IP addresses of the NMSs on the network. Trap communities are the names and addresses to which network events (alarms, port failures, etc.) are sent. Typically, this information is also sent to the NMS.
CP09: TCP/IP
512
EMOTOROLA LTD. 2001
Issue 1 Revision 4
SNMP
User Interface NMS Network Management Application
Agent Managed device MIB
CP09_5_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
513
Issue 1 Revision 4
CP09: TCP/IP
514
EMOTOROLA LTD. 2001
Chapter 6
Domain Name Service
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 6 Domain Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Domain Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Structure and Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Server Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
61 61 62 62 64 66 68
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
The Domain Name Service
The Domain Name Service

Objectives
On completion of this chapter the student will be able to: S Describe the purpose and function of a Domain Name Service.
CP09: TCP/IP
EMOTOROLA LTD. 2001
61
Domain Name System
Issue 1 Revision 4
Domain Name System

In TCP/IP the network address is a 32-bit integer which, in dotted decimal form, can be up to 12 decimal digits. The port number adds a further three digits (8 bits). Within the real system environment users people and application processes (APs) are known by symbolic names rather than addresses. In the same way that users of the telephone network use directory services to find the number of a called party, so the directory services associated with TCP/IP are used to find the address of a destination user/AP. This address resolution service is the most frequently used of the directory services. Although names are essential for long addresses, they are also necessary for other reasons. Names isolate the users/APs from any knowledge of the network configuration which may, of course, change. A user AP should be able to be moved from one part of the network to another without other APs being aware of the move. Therefore, the directory service must provide not only an address resolution service, but also services to allow the contents of the directory to be changed and updated in a controlled way. The binding between the name and its address is said to be dynamic. The total directory service in the TCP/IP suite is called the domain name system. Two interrelated issues must be considered with any directory system. The first is the structure of the names and how their assignment is administered; the second is how the various directory services are to be implemented.
Name Structure and Administration

The Internet uses a hierarchical naming structure. This allows the assignment of numbers to be administered in a distributed fashion. There are a number of alternative partitioning possibilities, known as organisations or domains, at the highest level in the hierarchy. All hosts attached to a network or subnet of the Internet must be registered with one of these organisational domains. The choice of domain to be registered under is made to minimise the number of referrals. Hence, if a host is to be attached to an educational institution, since it is likely that most network transactions will involve hosts that are attached to its own network or to those of other educational institutions, it is registered within the EDU domain. Each domain has an appropriate naming hierarchy. In the EDU domain the next level in the hierarchy is the names of the different educational institutions, while in the COM domain it is each (registered) commercial organisation. Each component of a domain name is known as a label. Labels are written with the local label on the left and the top domain on the right, each separated by a period. Each label is simply the registered domain name for that level in the hierarchy. As indicated earlier, the adoption of a hierarchical structure means that names can be assigned locally rather than centrally. Thus, in the case of an educational institution, as long as the institution is registered with the EDU domain name authority, the authorised manager at that institution can assign names as well as IP addresses to hosts that are to be attached to that institutions network.
CP09: TCP/IP
62
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Domain Name System
Domain Name Hierarchy
Root
com
edu
gov
us
univ x
univ y
inst a
dept cs
dept ee
dept phy
Host A
Host B
Host C
CP09_6_1
Internet Top-Level Domains Domain Name COM EDU GOV MIL NET ORG INT XY Meaning Commercial organization Educational institution Government institution Military groups Internet (network support centres) Other organizations Internal organisations Country codes (as defined by X.500)
CP09: TCP/IP
EMOTOROLA LTD. 2001
63
Domain Name Server
Issue 1 Revision 4
Domain Name Server

Associated with each institution is a host that runs an application protocol/process known as the domain name server. Associated with this is the directory information base (DIB) which contains all the directory related information for that institution. When a new host is to be registered, the manager interactively enters the name and the IP address that have been assigned to that host into the DIB of the local domain name server. A user can then initiate transactions that involve the Internet. When initiating a network transaction involving a particular application protocol, a terminal user or AP will use the name of the host machine on which the server is running when communicating with its local client protocol. Before this protocol can initiate the setting up of a transport connection with the server, it must ascertain the IP address of the host in which the server runs. In a TCP/IP suite all server protocols/processes are allocated a fixed port number the well-known port so it is not necessary to maintain port numbers in the DIB. To obtain the IP address of a named server, each host has a client protocol process known as the name resolver. The sequence of events that the client protocol follows to carry out the name-to-address mapping is as follows: 1. 2. 3. 4. 5. 6. User issues request to client protocol. Client protocol passes name to resolver. Resolver passes name to DNS. DNS returns IP address to resolver. Resolver returns IP address to client protocol. Client protocol communicates with server using IP address.
Each name stored in the DIB is assigned an object type to identify it. A list of record types is shown opposite. The most common type of record is type A; host name and IP address. The next most common type is probably MX. It contains host names that act as mail exchangers for a given subdomain. The MX records enable a user to send e-mail to someone at a given subdomain without having to know the name of the mail gateway. Mail can be addressed to Bob@Blanlan.com without having to know that the name of the mail server is SMTP-GW. Otherwise, mail would have to be addressed to Bob@SMTP-GW.Blanlan.com.
Type A CNAME HINFO MINFO MX NS PTR SOA Host IP address
Meaning
Canonnical domain name for an alias CPU and OS information for a host Mailbox or mail list information Mail server name for the domain Name server (that has authority) for the domain Pointer to domain name Start of Authority multiple fields that specify which parts of the naming hierarchy a server implements
CP09: TCP/IP
64
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Domain Name Server
Domain Name Server
Terminal User Server Server Application Protocol User AP Names IP addresses Network Manager
OS 1 Server Application Protocol 2
OS 5 Name Resolver 4 TCP/IP IP addresses Names IP addresses 3
OS
Client Application Protocol 6
Name Resolver
MIB
TCP/IP
TCP/IP To/from other DNS
CP09_6_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
65
Message Format
Issue 1 Revision 4
Message Format
The standard message format for the domain name server is shown opposite. A resolver can have a number of messages outstanding at any time. The identification field is used to relate a subsequent response message to an earlier request message. The type of message request/response and additional qualifiers relating to the responses are given in the parameters field. Responses also contain information about the server(s) its authority (the part of the naming hierarchy it implements) and IP address. In addition, each request/response message can contain multiple requests/responses. The query from the client contains the following information: S S S S Name to be resolved Class of name (protocol group to be used) Type of answer desired (IP address associated with this name) An action code that specifies whether the name server should resolve the name completely (recursion requested).
DNS was designed to be protocol independent. The Class field in the query identifies the protocol group of the record of interest. It is possible to have multiple records that have the same data in the name field but different protocols. For TCP/IP users, the class field is IN for Internet.
CP09: TCP/IP
66
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Message Format
Message Format
1 Identification Parameter Number of questions Number of answers Number of authority fields
16
Number of additional fields Questions Section (32 bit) Answers Section (32 bit) Authority Fields (32 bits) Additional information fields (32 bits)
CP09_6_3
Bit Posn 1 25 6 7 8 9 1316
Meaning 0 = request, 1 = response 0000 = sandard, 0001 = inverse 1 = answer authoritative 1 = message truncated 1 = recursion desired (query) 1 recursion available (response) 0000 = no error 0001 = format error 0010 = server failure 0011 = server unknown
CP09: TCP/IP
EMOTOROLA LTD. 2001
67
Name Server Hierarchy
Issue 1 Revision 4

When a name server receives a query, it checks to see if the name is within the subdomain for which it has authority. If so, it looks the name up in its database and sends back the requested information, if present. If the name server cannot resolve the name completely, it checks to see what action code has been specified by the client. If the client has requested recursive resolution then the name server must query another appropriate name server for the address. This is known as a referral and the aim is to minimise the number of referrals that are needed. To achieve this, the servers are organised into a hierarchical structure. Lower level name servers know the IP address of the higher-level server for the domain and a higher-level server associated with each organisation incorporates a table containing the names and IP addresses of all the name servers registered with that domain hierarchy. On receipt of a request that it cannot resolve, the local domain name server creates and sends a referral request to the higher-level server. This checks the domain name associated with the request and, assuming it is for another server within the same domain, uses the name to access the IP address from its own DIB. It returns this in a response message to the local server. The local server then uses this IP address to make a direct request to the indicated server for the required IP address. A further level of referral would be required if a request involves an organisation in another domain. Eventually, referrals could arrive at the root server. In practice, the amount of information associated with the intermediate domain name servers is only modest since the number of entries in its referral table is determined by the number of institutions or organisations and not by the number of hosts at each site. To minimise the loading on the Internet, each local server maintains a record of the most recently referred names and their IP addresses together with the names and IP addresses of the servers that provided the addresses. On receipt of a request for which it does not have a local entry, it checks the name cache and, if an entry is present, responds with it. In the response message, it resets the authoritative flag to zero and puts the answer in the authority field together with the name and IP address of the server that provided the answer. This allows for the information being out-of-date. On receipt of the reply, the client can either accept the information or make a new request directly to the name server indicated. To ensure that the list of cached entries is reasonably up-to-date, a timeout period is associated with each entry. The value of this period is given by the server that provided the information. Hence, the timeout for every entry may be different. Once the timeout expires, the entry is removed and any new requests for that entry have to be referred.
CP09: TCP/IP
68
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Request / Response
Root
com
edu
gov
us
univ x
2
univ y
3
inst a
dept cs
1 2
dept ee
1
dept phy
14 order of request/response messages
Host A
Host B
Host Z
CP09_6_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
69
Issue 1 Revision 4
CP09: TCP/IP
610
EMOTOROLA LTD. 2001
Chapter 7
IP Version 6
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 7 IP Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPV4/IPV6 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicast Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extension Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jumbo Payload Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Options Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing of Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulating Security Payload Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication and Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Parameters Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neighbour Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
71 71 72 72 74 76 76 76 78 710 712 712 714 716 718 718 720 722 724 724 726 728 730 732 732 734
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IP Version 6
IP Version 6
Objectives
On completion of this chapter the student will be able to: S S Describe the main features of IP version 6. Describe the format of the IPv6 header
CP09: TCP/IP
EMOTOROLA LTD. 2001
71
Background
Issue 1 Revision 4
Background
It is predicted that the current address space available in IPV4 will become exhausted sometime between the years 2005 and 2015. This estimate is conservative and another explosion in the growth of the Internet may happen any time as new applications are developed. The addresses that do remain are largely of the wrong class. Many users would like to obtain a Class B address, but are unable to obtain one. A problem of almost equal importance to the lack of addresses is the size of routing tables in the current IPV4 based Internet. IPv6 has been designed to provide for performance improvements due to a reduction in the size of routing tables.
Main Features
Multicasting
Multicasting is becoming an increasingly important method of data transfer both in applications such as video conferencing and also in the Internet protocols themselves. It provides performance improvements over the use of broadcasting since many nodes will decide to ignore the datagram at an earlier stage. Multicast support in IPV4 is deficient in terms of limiting the scope of a multicast. It has also been slow to spread since its implementation has been optional. Multicast support will be available on all nodes running IPV6. IPV6 also introduces a new facility known as Anycasting.
Real-Time Support
Applications that involve the use of some real-time facilities, such as voice or video, continue to spread. Support for this type of application is limited in IPV4. The introduction of two new facilities, Priorities and Flow Labels, aims to address this problem.
Plug and Play

Plug-and-Play refers to the ability of hosts to Auto-configure themselves. One of the main components of Plug-and-Play is the Neighbour Discovery Protocol.
Security
Lack of security features is seen by many as one of the main deficiencies inherent in IPV4. The lack of Internet Addresses may limit the ability of the Internet to grow geographically. However the lack of security features prevents growth into many applications areas related to Internet Commerce. It is possible to add new security features to IPV4 but this is likely to involve a conversion almost as painful as the move to IPV6. Security is an integral part of IPV6. Any implementation of IPV6 must include certain security features. The security features provided are Authentication and Encryption.
CP09: TCP/IP
72
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Background
Background
Background S Lack of addresses, particularly class A and B S Size of routing tables Main Features S Multicast S Real-time support S Plug-and-play S Security
CP09: TCP/IP
EMOTOROLA LTD. 2001
73
IPV4/IPV6 Headers
Issue 1 Revision 4
IPV4/IPV6 Headers
The IPV6 datagram format is very different to that employed by IPV4. However a comparison of the two provides a useful introduction to the new format and the use of the various fields. The version field is still present but most of the others have been replaced, renamed or simply removed. Version will of course be set to 6 but this will not normally be used to de-multiplex IPV4 and IPV6. If both are being used on the same link then the Datalink layer should differentiate between the two and pass the datagram to the appropriate version of IP. For example, on Ethernet a content type of 86DD will be used to identify IPV6 rather than the familiar 0800 type-code for IPV4. The TTL (Time To Live) field has been renamed Hop Limit. This is a more accurate description of its use. The field was originally supposed to be incremented for each second that the datagram was queued at a router but, in practice, routers simply added one to it. Since there may now be more than one IP header, the IPV4 Protocol field has been replaced by a next header field. The last Extension header in the chain, or the basic header itself, will indicate a Transport Protocol header by specifying the protocol type, e.g. 6 for TCP. The functions provided by the TOS (Type of Service) Field in IPV4 are supported by means of the Flow Label and Traffic Class fields. The header has been made fixed format but more than one header may be used. Hence no IHL (Internet Header Length) field is required. It was the options field that made the IPV4 header of variable length. The new design makes use of Extension Headers to support facilities previously implemented through the use of options. Since there are now no Options, no Padding is required. The IPV4 header also includes a Total Length field; this has been replaced by the Payload Length field. Since the header is now fixed length, it is unnecessary to include it in the calculation of length. Several of the IPV4 header fields have been removed as a result of a change in the way in which the size of IP datagrams is controlled. In IPV4, datagrams are fragmented if they reach a network with an MTU that is less than the packet size. This process involves the use of the Identification, Fragment Offset and Flags fields. In Ipv6 all networks must carry a payload of at least 1280 octets. If a host wishes to send packets which are larger than this, then it should use MTU Discovery as defined in RFC1981. Header Checksums have been dropped in IPV6. The underlying Datalink layer protocol is assumed to provide adequate error checking. Removal of this function from IPV6 means that the overhead of checking and updating the checksum has been removed from each router along the path to the destination host.
CP09: TCP/IP
74
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IPV4/IPV6 Headers
IP4 / IP6 Headers
10
11
12
13
14
15
16
Version
Header Length Type of Service Total Length Identification M Fragment offset Protocol TimetoLive Header checksum Source IP address Destination IP address Options/Padding Data
0 VER
3 4
11
15 16
23 24
31
Traffic Class Payload Length
Flow Label Next Header Source Address Destination Address
Hop Limit
CPO9_7_3
CP09: TCP/IP
EMOTOROLA LTD. 2001
75
Addressing
Issue 1 Revision 4
Addressing
IPv6 uses 128 bits (16-octets) for addressing
Address Representation
Address are represented as groupings of four hex characters e.g. AEC8:0000:0000:5632:0000:0000:3456:23AE Leading zeros may be omitted in each of the groupings e.g. AEC8:0:0:5632:0:0:3456:23AE Any number of zeros may also be indicated by :: but this can only occur once in an address e.g. AEC8::5632:0:0:3456:23AE One special form of address is created by prepending 96 zeros to an IPV4 address. This could be written as ::192.0.0.1 Although address allocation will still be inefficient due to the hierarchical nature of the allocation scheme, even conservative estimates predict 1564 addresses available per square meter of the earths surface. This large address space makes autoconfiguration possible and the deep hierarchies that can be created provides the opportunity for simplified routing and reduced routing table size.
Types of Address
S S S Unicast Multicast Anycast
CP09: TCP/IP
76
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Addressing
Addressing
Unicast Multicast Anycast
CPO9_7_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
77
Addressing
Issue 1 Revision 4
Unicast
One sender sends to one receiver
There are several forms of unicast address assignment in IPv6: Unicast Addresses are viewed as contiguous bit-wise maskable addresses. The length of the mask to use is defined in a Subnet Prefix field that is carried in many messages. The use of the Subnet Prefix together with an IPV6 address provides a mechanism similar to CIDR (Classless Inter Domain Router).
Provider Based Unicast Address

Provider based unicast addresses are used for global communications. They are similar in function to IPv4 addresses. The first 3 bits identify the address as a provider-oriented unicast address. The next field, (REGISTRY ID) identifies the internet address registry which assigns provider-identifiers (PROVIDER ID) to Internet service providers, which then assign portions of the address space to subscribers. The SUBSCRIBER ID distinguishes among multiple subscribers attached to the Internet Service Provider identified by the PROVIDER ID. The SUBNET ID identifies a specific physical link. There can be multiple subnets on the same physical link. A specific subnet cannot span multiple physical links. The INTERFACE ID identifies a single interface among the group of interfaces identified by the subnet prefix. Registries 10000 01000 11000 10100 Multi-national (IANA)
RIP MNCC Europe Internic North America APNIC Asia Specific
CP09: TCP/IP
78
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Addressing
Unicast
5 bits
16 bits
18 bits
24 bits
8 bits
16 bits
48 bits
010 Registry ID Provider ID Set to Zero Subscriber ID Set to Zero Subnet ID INTF ID
CPO9_7_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
79
Addressing
Issue 1 Revision 4
Multicast
One sender sends to a group of receivers
This type of addressing is becoming more important all the time. The business requirements for many Internets now include the ability to transmit video, news, financial and audio data to groups of hosts. Multicast, together with Flows and Reservation Protocols, provide the necessary support for these applications. Multicast is also used by several of the protocols controlling the operation of the Internet and is used in multimedia applications. Multicast support was introduced in IPV4 but its adoption has been very slow. It is however an integral part of the support which all routers must provide for IPV6. In IPV4 joining and leaving groups required the use of an additional protocol called IGMP. In IPV6 these functions have been incorporated into ICMP in IPV6. One problem with the use of multicast with IPV4 is the lack of any means of limiting the scope of a multicast other by the use of the TTL field. The scope field in IPV6 multicast addresses provides a higher degree of control.
CP09: TCP/IP
710
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Addressing
Multicast
11
15
31
0xFF
Flags
Scope Group ID Continued Group ID Continued Group ID Continued
Group ID
Flags
0 0 0 T
T = 0 Permanent T = 1 Transient
CP09_7_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
711
Multicast Scope
Issue 1 Revision 4
Multicast Scope
Multicast groups can be either transient or permanently assigned. The fourth of the flag bits is used to differentiate between the two. The permanently assigned addresses are defined by the Internet Authorities, whereas the transient addresses are chosen at random by a directory tool. A check is then performed to ensure that the randomly chosen address is unique. The meaning of a permanently assigned multicast address is independent of the scope value, whereas non-permanently assigned multicast addresses are meaningful only within a given scope. Solicited Node multicast addresses must be computed by each node for every Unicast or Anycast address assigned to it. If an Interface is assigned addresses for more than one ISP then this address will identify the interface regardless of the ISP.
Anycast
One sender sends to any one member of a group. An example of the use of anycast addresses is to send to any router that belongs to a particular ISP. It is necessary for a router to build a route for each anycast address that is active. In the case of RIP this involves adding one entry to the routing table for each anycast address. OSPF on the other hand relies upon a new link state record that indicates that an anycast group member is connected to a router. Hosts use the neighbour discovery protocol to communicate anycast address information to their local routers. Anycast addresses are allocated from the Unicast Address Space. Two restrictions are currently in place on their use: 1. 2. They must not be used as the source address of a packet. They must only be assigned to routers.
One required Anycast address, which must be supported by all routers, has been pre-defined. This is the Subnet Router Anycast Address. It consists of a 128-bit Subnet Prefix and 128 zero bits. Datagrams sent to this address will be delivered to one router on the Subnet. It is likely to be used when a node needs to communicate with one of the routers in a Subnet e.g. in Mobile Communications.
CP09: TCP/IP
712
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Multicast Scope
Multicast Scope
0 1 2 34 5 67 8 9D E F
Reserved Node Local Link Local Unassigned Site Local Unassigned Organisation Local Unassigned Global Reserved
CP09_7_7
CP09: TCP/IP
EMOTOROLA LTD. 2001
713
Multicast Scope
Issue 1 Revision 4
Local Use
Other special types of address are loopback, site local and link local. The loopback address is 0:0:0:0:0:0:0:1 and may be used by a node to send a message to itself. Link Local Addresses support the implementation of automatic configuration mechanisms. Link Local Addresses are designed to be used on single link. They must not be forwarded by routers. Site Local Addresses may be used by sites which are not connected to the Internet. If they later connect to the Internet, the Site Local prefix can be replaced by a Subscriber Prefix and the remainder of the address left unchanged. Datagrams which use the Site Local address should not be forwarded outside of the originating site.
CP09: TCP/IP
714
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Multicast Scope
Local Use
Link-Local-Use 10 bits 1111 1110 10 n bits 0 118 bits Interface ID
Site-Local-Use 10 bits 1111 1110 11 n bits 0 m bits Subnet ID 118 bits Interface ID
CP09_7_8
CP09: TCP/IP
EMOTOROLA LTD. 2001
715
Extension Headers
Issue 1 Revision 4
Extension Headers
In the case of IPV6 six extension headers have been defined. S S S S S S Hop-by-Hop Options Header Routing Header Fragment Header Destination Options Header Authentication Header Encapsulating Security Payload Header
CP09: TCP/IP
716
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Extension Headers
Extension Headers
HopbyHop Routing (type 0) Fragment Authentication Encapsulating Security Payload Destination Options
CP09_7_9
CP09: TCP/IP
EMOTOROLA LTD. 2001
717
Extension Headers
Issue 1 Revision 4
Hop-by-Hop
By using the Hop-by-Hop Options Header, the options are processed by every node along a packets delivery path rather than only at those listed as destinations. If this header is present then it must immediately follow the IPV6 header.
Jumbo Payload Option

The purpose of the Jumbo Payload option is to allow supercomputers to exchange packets that are so large that their length cannot be encoded in the 16 bits provided in the base IPV6 header. It should not be used if the length is less than 65535 octets or if the datagram contains a Fragment Header.
CP09: TCP/IP
718
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Extension Headers
Hop-by-Hop
Next Header
Header Ext Length Options
Jumbo Payload Option

194 Jumbo Payload Length Opt Data Length = 4
CP09_7_10
CP09: TCP/IP
EMOTOROLA LTD. 2001
719
Routing Header
Issue 1 Revision 4
Routing Header
The standard provides for various routing types with the header format differing from type to type apart from the first four fields, which are fixed. Only Routing Type 0 is currently specified. Routing Type 0 provides a means of implementing Loose Source Routing. In Ipv4 this was implemented as an option. However, this caused performance degradation as the datagrams were frequently placed in low priority queues and handled less efficiently in routers than datagrams without options. Source Routing is however important. For example it can be used to force the datagram to be routed via a particular ISP, perhaps in combination with Anycast addresses. The Routing Extension Header is more efficient than the use of IPV4 options, because a router only needs to process the header if the destination address of the datagram is one of its own IP addresses. The Hdr Ext Length field provides a means of determining the number of addresses in the list. It actually contains a number less than or equal to 46, which, when divided by two, gives the number of addresses in the header. i.e. the length in 8 octet units of the part of the header which contains the addresses. The Segments Left field is set to the number of addresses in the list which still have to be visited. If a router has processed the Routing Header, then it must update the destination address to contain the next address in the list before forwarding the datagram.
CP09: TCP/IP
720
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Routing Header
Routing Header Type 0
Next Header Reserved
Header Ext Length
Routing Type 0 Strict/Loose bit map
Segments Left
Address 1
Address 2
Address n
CP09_7_11
CP09: TCP/IP
EMOTOROLA LTD. 2001
721
Fragment Header
Issue 1 Revision 4
Fragment Header
No fragmentation of IPV6 datagrams takes place in the routers on the way to the destination. It is however possible to fragment large IPV6 datagrams at the source node and insert a Fragment Header into each fragment. The fields present in the fragment header are almost identical to those used to control fragmentation in IPV4. One exception is that the Dont Fragment bit is not required, as this is assumed for all IPV6 datagrams. Fragments are routed independently of each other and reassembled at the final destination.
CP09: TCP/IP
722
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Fragment Header
Fragment Header
0 Next Header
15 16
28 29
30 31
Reserved Fragment Offset Identification
RES M
CP09_7_12
CP09: TCP/IP
EMOTOROLA LTD. 2001
723
Destination Options Header
Issue 1 Revision 4

The Destination Options Header may occur more than once. The reason for this is that in some cases we may want the options to be processed only by the final destination. In which case the destination options should be placed immediately before the upper layer header. If however, we want the Destination Options to be processed by all destinations present in the Routing Header, in addition to the initial destination, then a Destination Options Header must be inserted before the Routing Header. Each option definition consists of three fields. These give the type, data length and data that represent the option. The first three bits of the Option Type field have special significance. The first two bits specify what a node should do if it does not recognise the Option Type. Possibilities include simply ignoring the option or more drastic action of discarding the datagram. Bit 3 of the Option Type field indicates whether or not the option data may change on the way to the packets final destination. This is significant when an Authentication Header is present. If the Option Data field can be changed then the Authentication mechanism must treat the field as if it contains all zeros.
Processing of Options
Options must be processed strictly in the order in which they occur.
CP09: TCP/IP
724
EMOTOROLA LTD. 2001
Issue 1 Revision 4
0 Next Header
15 16
31
Header Ext Len Options
Option Type
Option Data Length
Option Type
Option Type Option Data Length Option Data
8 bit identifier of the type of option 8 bits used to show the length of the Option Data field (in octets) Variable length field containing the Option Type specific data
CP09_7_13
CP09: TCP/IP
EMOTOROLA LTD. 2001
725
Authentication Header
Issue 1 Revision 4
The authentication data is calculated, based, not only on the content of the data and key, but also on the content of some fields in the base-IPV6 header and the extension headers. The Security Parameters Index identifies which key to use. It is not possible to base the authentication data on all base-IPV6 header and extension header fields since some of these may be modified by routers along the way. In the base-IPV6 header the hop count will change and so is treated as having a value of zero as far as the authentication process is concerned. Within the Option Type field, there is a bit (the C-bit), that identifies options containing data which may change en route and therefore are also treated as having a value of zero. The Routing Header also presents a problem to the authentication process, as the destination will change en route. The solution adopted here is to set the destination address in the base-IPV6 header and the values in the Routing Header to the values that they will contain upon reaching the final destination before performing the authentication calculation.
CP09: TCP/IP
726
EMOTOROLA LTD. 2001
Issue 1 Revision 4
7 Next Header
15 16
31
Length Reserved Security Parameters Index Authentication Data (Variable number of 32 Bit words)
CP09_7_14
CP09: TCP/IP
EMOTOROLA LTD. 2001
727
Encapsulating Security Payload Header
Issue 1 Revision 4

All of this header, except the Security Parameters Index, and all of any following extension headers is encrypted before being sent. When the default DES Cipher Block Chaining is being used an initialisation vector is used to insert a random element into the data. The Cipher Block Chaining ensures that this provides an input into later calculations. DES works with 64-bit word boundaries, therefore, padding may be required at the end of the Payload Data. The last field in the decrypted message contains a Payload Type field, i.e. the next header. This could be a Destination Options header or a higher-level protocol header.
CP09: TCP/IP
728
EMOTOROLA LTD. 2001
Issue 1 Revision 4
0 Security Parameters Index Initialisation Index (Variable Length) Encrypted Payload Data (Variable Length) Padding Reserved Padding Length Payload Type
CP09_7_15
CP09: TCP/IP
EMOTOROLA LTD. 2001
729
Security
Issue 1 Revision 4
Security
The new security features in IPV6 attempt to provide a means of ensuring that a datagram has arrived from an authorised source in an unaltered form and has not been read along the way. These are, to a great extent treated as two separate, albeit related problems and solutions are implemented through the use of two separate headers. These headers are known as the Authentication Header and Encapsulating Security Headers respectively. The standards provide for a variety of Authentication and Encryption protocols to be implemented. They have, however, mandated one protocol in each category. This ensures that all nodes are capable of providing secure communication. MD5 has been chosen as the initial authentication protocol and DES Cipher Block Chaining will provide the method of encryption. Where Will the Security Features Be Employed? S S S S S Hosts Mobile Hosts Between sites via the Internet Routing Protocols Autoconfiguration
Hosts requiring secure communication may run applications that request to send encrypted datagrams and receive only datagrams that have already been authenticated. Support for this requires changes to the sockets-library or any other network-programming interface which is in use. Communication with mobile hosts can be made secure by establishing a secure tunnel that connects to the home networks firewall. The firewall may act as a proxy for the mobile host during neighbour discovery. Communication from the home network will then be relayed to the mobile host via the firewall. Secure tunnels will also be established between the firewalls of two organisations or two sites of the same organisation. These can be used to provide secure communication via the Internet. Traffic between the two firewalls would be encapsulated within another IPV6 datagram. Encryption and authentication can then be applied. The original IPV6 headers will now cross the Internet in encrypted form. The authentication header will ensure that the data originated at the other firewall and has not been modified en route. Routing protocols require secure communication to prevent attackers from inserting spurious routing information into the Internet. The new Neighbour Discovery protocol also requires security features. This applies particularly to the situation where portable PCs are plugged into LANs.
CP09: TCP/IP
730
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Security
Security
Hosts Mobile Hosts Between sites via the Internet Routing Protocols Autoconfiguration
CP09_7_16
CP09: TCP/IP
EMOTOROLA LTD. 2001
731
Authentication and Encryption
Issue 1 Revision 4

A fundamental requirement of the authentication and encryption protocols is the use of private keys. The sender and the receiver must agree on the key to use. Keys may be manually distributed, obtained from a key server or agreed by means of a protocol. Key servers present their own problems such as authentication between the node and the key server. The use of key servers is likely to be the best solution to the problem of distributing keys to the members of a multicast group.
Security Parameters Index

Both authentication and encryption require that the value of a set of parameters is agreed between the senders and receivers before any exchange can occur. The use of a key is one of the parameters. Others may be the lifetime of the key and which algorithm to use. Once these are agreed we have a Security Association between the two parties. All authenticated and encrypted IPV6 datagrams contain a Security Parameters Index field. This field identifies the relevant association and can be used to index a table of security contexts.
CP09: TCP/IP
732
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
EMOTOROLA LTD. 2001
733
Neighbour Discovery
Issue 1 Revision 4
Neighbour Discovery
The Neighbour Discovery Protocol (RFC2461) provides the facilities that were previously incorporated into ARP (address resolution protocol), Router Discovery Protocol and ICMP redirect. It makes use of ICMP. Several ICMP message-types have been created for its use. The question of how to issue an ICMP request before you have obtained a mapping of IP-to- link layer address is resolved by the use of multicast addresses. The mechanism for creating the multicast address to use will vary from media to media. For Ethernet networks, Xerox has reserved the prefix 0x3333 for use with IPV6. This prefix is concatenated with the last 32 bits of the IPV6 multicast address to create the full link layer address. This protocol makes use of four caches.
Router List Cache

Contains one entry for each router from which adverts have been received.
Prefix Cache
Contains the prefixes that have been learned recently via router adverts.
Destinations Cache
Contains one entry for each destination and the IP address of the immediate neighbour to which datagrams for these destinations should be sent.
Neighbour Cache
Contains a map of the IP-to-media address of each immediate neighbour. Multicast Addresses FF02::1:0:0 to FF02::1:FFFF:FFFF are reserved for the equivalent of IPV4 ARP. The solicited node Multicast Address is formed by concentrating FF02:0:0:0:0:1 and the last 32 bits of the nodes IPV6 address.
CP09: TCP/IP
734
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Neighbour Discovery
Neighbour Discovery
0 3333 (Hex)
15
16
17 Low order 32 bits of IPV6 Multicst Address
Router List Cache Prefix Cache Destination Cache Neighbour Cache
CP09_7_18
CP09: TCP/IP
EMOTOROLA LTD. 2001
735
Neighbour Discovery
Issue 1 Revision 4
CP09: TCP/IP
736
EMOTOROLA LTD. 2001
Chapter 8
Automatic Configuration
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 8 Automatic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Automatic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reverse Address Resolution Protocol (RARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DHCP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of RARP, BOOTP/TFTP and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
81 81 82 84 86 88 88 810 812
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Objectives
On completion of this chapter the student will be able to: S Describe the function and concept of Automatic Configuration protocols.
CP09: TCP/IP
EMOTOROLA LTD. 2001
81
Issue 1 Revision 4

RARP provides the opposite function to ARP in that it returns an IP address given a valid hardware address. It is commonly used with diskless machines such as routers, printers or IP telephones. Valid IP addresses combined with valid hardware addresses are held on a RARP server. A client makes a RARP Request that is broadcast at data link level. The RARP server provides the correct IP address that is addressed to the clients hardware address.
CP09: TCP/IP
82
EMOTOROLA LTD. 2001
Issue 1 Revision 4
RARP
Hardware Address IP Address
Client
RARP Server
CP09_8_1
CP09: TCP/IP
EMOTOROLA LTD. 2001
83
Dynamic Host Configuration Protocol
Issue 1 Revision 4

There are occasions when static IP addresses can prove restrictive. Users of Laptop computers who regularly travel between offices in different parts of the country may want to connect up to a network. These network segments will be on different subnets. This will require the user to reconfigure their machine every time they visit another office. Another reason why subnets are used is to limit the amount of IP addresses in use. A Company that is allocated a Class C address and has four hundred nodes clearly cannot give an IP address to everyone in the company at the same time. It is however unlikely that everyone in the company will need to be on the network at the same time due to holidays, visiting clients etc. A solution to the above would be to allocate IP addresses only when needed. DHCP allows the network to do this. A user will lease an address for a specified period of time whereupon the address is released and placed in a pool of addresses for other users to lease.
CP09: TCP/IP
84
EMOTOROLA LTD. 2001
Issue 1 Revision 4
DHCP Broadcast Dynamic IP Address
Client
DHCP Server
CP09_8_2
CP09: TCP/IP
EMOTOROLA LTD. 2001
85
DHCP Operation
Issue 1 Revision 4
DHCP Operation
DHCP is used to lease an IP address to a computer or other node. In order to do this four main steps are carried out. 1. DHCP Discover is a message that is broadcast into the network at both the IP layer and the data link layer. It is addressed to UDP port 68. The datagram does not contain a valid return IP address as the node does not yet have one. The most important piece of information is therefore the senders hardware address. Once a DHCP server receives the request it can offer an IP address to the client. This is known as a DHCP offer. It is sent as a broadcast back to the originating computer. This is sent to UDP port 67 and contains the IP address and hardware address of the DHCP server. Other Information can include a valid IP subnet mask and the address of the default gateway. The client can then select one of the offers. If several offers are received it will normally select the first one. A DHCP request is then sent back to the DHCP server. This request is broadcast but contains the IP address of the server that issued the offer. The broadcast has the additional function of letting other servers know that their offer was not accepted. Lastly a DHCP Ack will acknowledge the acceptance of the offer. Also included in the acknowledgement will be the time limit that the IP address is leased for.
2.
3.
4.
CP09: TCP/IP
86
EMOTOROLA LTD. 2001
Issue 1 Revision 4
DHCP Operation
DHCP Operation
DHCP Discover DHCP Offer DHCP Request DHCP Acknowledgement
CP09_8_3
CP09: TCP/IP
EMOTOROLA LTD. 2001
87
DHCP Relay Agents
Issue 1 Revision 4
DHCP Relay Agents

It would be uneconomical to have a DHCP on every single LAN to provide IP addresses amongst a pool of users. It is therefore common to share a DHCP server amongst several LANs. This can lead to problems. DHCP messages are sent out using a broadcast hardware address and this cannot travel across routers. The solution is to use another host on the network as a proxy. It listens to the network for DHCP messages and forwards them to the DHCP server using the servers valid IP address. Return messages are subsequently forwarded on to the message originator.
Time Fields
Using DHCP, an address is leased from a pool of addresses for a period of time. When a DHCP request is acknowledged this time period is given to the host. The host can reapply to keep its address. It does this initially half way through the lease time. If it is unsuccessful it will try again after 75 percent of its lease time. If it is unsuccessful it will try for a final time 87.5 percent of the way through its lease time. After this it must reapply for a new IP address at the end of the lease period.
CP09: TCP/IP
88
EMOTOROLA LTD. 2001
Issue 1 Revision 4
DHCP Relay Agents
DHCP Proxy
It is uneconomical to have a DHCP on every LAN segment DHCP proxies can be used to listen for DHCP broadcasts on a LAN segment These can then be forwarded to a DHCP server by a proxy The Proxy is configured with the IP address of the DHCP server
CP09_8_4
CP09: TCP/IP
EMOTOROLA LTD. 2001
89
BOOTP
Issue 1 Revision 4
BOOTP
Diskless workstations need someway of finding out their IP address. They may also need to obtain their operating system. This is typically done using Trivial File Transfer Protocol. BOOTP devices are configured using a PROM chip to ask for their IP parameters and operating system. They work in a similar manner to DHCP and use the same port numbers. A BOOTP request will hopefully be answered with a reply that includes details of an IP configuration and also the image of the operating system needed. TFTP will then be used to download the operating system. The IP addresses assigned are static.
CP09: TCP/IP
810
EMOTOROLA LTD. 2001
Issue 1 Revision 4
BOOTP
BOOTP
BOOTP message IP Configuration and Operating System Information Client BOOTP Server
CP09_8_5
CP09: TCP/IP
EMOTOROLA LTD. 2001
811
Summary of RARP, BOOTP/TFTP and DHCP
Issue 1 Revision 4

S S S RARP provides an IP address only given a valid hardware address. This IP address is static. BOOTP provides a static IP configuration. It also provides a name of a file to be used for its operating system. TFTP is then used to download this file. DHCP provides dynamic IP addresses that are leased from a pool of addresses for a certain period of time. It Can also provide a name for a boot up file.
CP09: TCP/IP
812
EMOTOROLA LTD. 2001
Issue 1 Revision 4
RARP provides an IP address only given a valid hardware address. This IP address is static. BOOTP provides a static IP configuration. It also provides a name of a file to be used for its operating system. TFTP is then used to download this file. DHCP provides dynamic IP addresses that are leased from a pool of addresses for a certain period of time.
CP09_8_6
CP09: TCP/IP
EMOTOROLA LTD. 2001
813
Issue 1 Revision 4
CP09: TCP/IP
814
EMOTOROLA LTD. 2001
Chapter 9
Glossary of Terms
CP09: TCP/IP
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CP09: TCP/IP
ii
EMOTOROLA LTD. 2001
Issue 1 Revision 4
Chapter 9 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CP09: TCP/IP
EMOTOROLA LTD. 2001
iii
Issue 1 Revision 4
CP09: TCP/IP
iv
EMOTOROLA LTD. 2001
Issue 1 Revision 4
10BaseT wire
3270 3770 370/XA 5250 576 AAA AAI AAL AARP ABOM ACB ACB ACCS ACD ACDF ACE ACF ACF ACIA ACID ACK ACL ACP ACS ACSA ACSE ACSP ACTLU ACTPU ACU AD ADF ADMD
Technical name for ETHERNET implemented on twisted

Reference to a 3270 Data Stream Supporting Entity Reference to Remote Job Entry 370/ eXtended Architecture Reference to a 5250 Data Stream Supporting Entity The minimum datagram size that ALL hosts, including routers, must accommodate Autonomous Administrative Area Administration Authority Identifier ATM Adaptation Layer AppleTalk Address Resolution Protocol Abis Operations and Maintenance Application Control Block Access Method Control Block Automated Calling Card Service Automatic Call Distribution Access Control Decision Function Access Control List Entry Access Control Field Advanced Communications Function Access Control Inner Areas Atomicity, Consistency, Isolation, and Durability Positive Acknowledgement Access Control List Ancillary Control Process Access Control Store Access Control Specific Area Association Control Service Element Access Control Specific Point Activate Logical Unit Activate Physical Unit Auto Calling Unit Addendum Document to an OSI Standard Adapter Description File Administrative Management Domain
CP09: TCP/IP
EMOTOROLA LTD. 2001
91
Issue 1 Revision 4
ADP ADP ADPCM ADSP AE AEI AEP AET AF AFI AFP AI AIFF AIX ALS ALU AMI ANI ANS ANSI AP AP APB APD APDU API APIC APLI APP APPC APPC APPL APPN APT ARPA
Adapter Control Block AppleTalk Data Stream Protocol Adaptive Differential Pulse Code Modulation AppleTalk Data Stream Protocol Application Entity Application Entity Invocation AppleTalk Echo Protocol Application Entity Title Auxiliary Facility Authority and Format Identifier AppleTalk Filing Protocol Artificial Intelligence Audio Interchange File Format Advanced Interactive Executive Application Layer Structure Application Layer User Alternating Mark Inversion Automatic Number Identification American National Standard American National Standards Institute Application Process Argument Pointer Alpha Primary Bootstrap Avalanche Photodiode Application Protocol Data Unit Application Program Interface; Application Programming Interface Advanced Programming Interrupt Controller ACSE/Presentation Library Interface Applications Portability Profile Advanced PeertoPeer Communications Advanced ProgramtoProgram Communications Application Program Advanced PeertoPeer Networking Application Process Title Advanced Research Projects Agency CP09: TCP/IP
92
EMOTOROLA LTD. 2001
Issue 1 Revision 4
ARP ARQ ARS AS/400 ASC ASCII ASDC ASE ASN ASN.1 ASO ASP AST ASTLVL ASTSR ATM ATP ATS AU AVA BISDN B8ZS BACM BAR BAS BASIC BB BBS BC BCC BCS BCVT Bellcore BER BER
Address Resolution Protocol Automatic Repeat Request Automatic Route Selection Application System/400 Accredited Standard Committee American Standard Code for Information Interchange Abstract Service Definition Convention Application Service Element Abstract Syntax Notation Abstract Syntax Notation One Application Service Object Abstract Service Primitive; AppleTalk Session Protocol Asynchronous System Trap Asynchronous System Trap Level Asynchronous System Trap Summary Register Asynchronous Transfer Mode; Abstract Text Method AppleTAlk Transaction Protocol Abstract Test Suite Access Unit Attribute Value Assertion Broadband ISDN Bipolar 8Zeros Substitution Basic Access Control Model Base Address Register Basic Activity Subset Beginners Allpurpose Instruction Code Begin Bracket Bulletin Board System Begin Chain Block Check Character Basic Combined Subset Basic Class Virtual Terminal Bell Communications Research, Inc. Box Event Records Bit Error Rate
CP09: TCP/IP
EMOTOROLA LTD. 2001
93
Issue 1 Revision 4
GBP BIB BIS BISUP BITS BITNET BIU BMS BMU BNN BOC BOM bps BRI BSC BSS BSSMAP BTAM BTU CA CA CAD CAE CAF CAI CASE CATV CBD CBEMA CCA CCAF CCAF+ CCB CCB CCIRN
Border Gateway Protocol Backward Indicator Bit Bracket Initiation Stopped Broadband ISUP Building Integrated Timing Systems Because its Time Network Basic Information Unit Basic Mapping Support Basic Measurement Unit Boundary Network Node Bell Operating Company BeginningofMessage Bits Per Second Basic Rate Interface Binary Synchronous Communications Basic Synchronization Subset; Base Station Subsystem Base Station Subsystem Mobile Application Part Basic Telecommunications Access Method Basic Transmission Unit Channel Adapter Certification Authority Computeraided design Common Applications Environment Channel Auxiliary Facility ComputerAssisted Instruction Common Application Service Elements Community Antenna Television Changeback Declaration Computer & Business Equipment Manufacturers Association Conceptual Communication Area Call Control Agent Function Call Control Agent Function Plus Connection Control Block Channel Control Block Coordinating Committee for Intercontinental Research Networking CP09: TCP/IP
94
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CCIS CCITT CCO CCR CCS CCS CCU CCU CCW CD CD CDF CDI CDRM CDRSC CDS CDS CEBI CEI CEN/ELEC CEP CEPT CESID CF CGM CHILL CICS CIDR CIGOS CIM CIS CLI CLIST CLNP CLNS
Common Channel Interoffice Signaling Consultative Committee for International Telephone & Telegraph Context Control Object Commitment, Concurrency, and Recovery Common Communications Support Common Channel Signaling Central Control Unit Communications Control Unit Channel Command Word Countdown Counter Committee Draft Configuration Dataflow Change Direction Indicator Cross Domain Resource Manager CrossDomain Resource Conceptual Data Storage Conceptual Data Store Conditional End Bracket Indicator Connection Endpoint Identifier Committee European de Normalization Electrotechnique Connectionendpoint Conference of European Postal and Telecommunications Administrations Caller Emergency Service Identification Control Function Computer Graphics Metafile CCITT HighLevel Language Customer Information Control System Classless InterDomain Routing Canadian Interest Group on Open Systems Computer Integrated Manufacturing Card Informaiton Structure Connectionless Internetworking Command List Connectionless Network Protocol Connectionless Network Service
CP09: TCP/IP
EMOTOROLA LTD. 2001
95
Issue 1 Revision 4
CLSDST CLTP CLTS CMC CMIP CMIS CMIS CMISE CMOL CMOT CMS CMT CN CNM CNMA CNMI CNOS CNT CO COCF CODEC COI COM CONF CONS CORBA COS COS COTP COTS CP CP CPE CPH CPF
Close Destination Connectionless Transport Protocol Connectionless Transport Service Communications Management Configurations Common Management Information Protocol Common Management Information Service Common Management Information Service Common Management Information Service Element CMIP Over Logical Link Control CMIP Over TCP/IP Conversational Monitor System Connection Management Composite Node Communication Network Management Communication Network for Manufacturing Applications Communication Network Management Interface Change Number of Sessions Communications Name Table Central Office ConnectionOriented Convergence Function Coder/Decoder Connection Oriented Internetworking ContinuationofMessage DMPDU Confirm Connection Oriented Network Service Common ObjectOriented Request Broker Architecture ClassofService Corporation for Open Systems Connection Oriented Transport Protocol Connection Oriented Transport Service Control Point Control Program Customer Premises Equipment Call Party Handling Control Program Facility CP09: TCP/IP
96
EMOTOROLA LTD. 2001
Issue 1 Revision 4
CPI CPIC CPMS CRACF CRC CRST CRT CRV CSm CSMUX CSMA/CA CSMA/CD CSP CSN CSNET CSS CSU CTC CTCA CTCP CTS CUA CURACF CUT CVS CVT DACD DAD
Common Programming Interface Common Programming Interface with C Language Control Point Management Services CallRelated Radio Access Control Function Cyclical Redundancy Check ClusterRouteSetTest Cathode Ray Tube Call Reference Value Call Segment Model Circuit Switching Multiplexer Carrier Sense Multiple Access with Collision Avoidance Carrier Sense Multiple Access with Collision Detection Communications Scanner Processor Card Select Number Register Computer+Science Network Control, Signalling, and Status Store Channel Service Unit ChanneltoChannel ChanneltoChannel Adaptor Communication and Transport Control Program CleartoSend Channel Unit Address; Common User Access Call Unrelated Service Function Control Unit Terminal Connection View State Communications Vector Table Directory Access Control Domain Draft Addendum
DAF Distributed Architecture Framework; Framework for Distributed Applications; Destination Address Field DAP DAS DAT dB DCA Directory Access Protocol Dual Attachment Station; Dynamic Address Translation Decibels Document Content Architecture Dynamically Assigned Sockets
CP09: TCP/IP
EMOTOROLA LTD. 2001
97
Issue 1 Revision 4
DCC DCE DCS DDCMP DDIM DDM DDN DDP DDS DES DFC DECNET DFI DFT DHCP DH DIA DIB DIS DISP DISP DIT DIU DL DLC DLCEP DLCI DLPDU DLS DLSAP DLSDU DLU DMA DMD
Data Country Code Data Communications Equipment; Distributed Computing Environment; Data CircuitTerminating Equipment; Distributed Computing Environment Defined Context Set Digital Data Communication Message Protocol Device Driver Initialization Model Distributed Data Management Data Defense Network Datagram Delivery Protocol Digital Data Service Data Encryption Standard Data Flow Control Digital Equipment Equipments Network Architecture DSP Format Identifier Distributed Function Terminal Dynamic Host Configuration Protocol DMPDU Header Document Interchange Architecture Directory Information Base Draft International Standard Draft International Standardized Profile Directory Information Shadowing Protocol Directory Information Tree Distribution Interchange Unit Distribution List Data Link Control; Data Link Connection Data Link Connection Endpoint Data Link Connection Identifier Data Link Protocol Data Unit Data Link Service Data Link Service Access Point Data Link Service Data Unit Dependent Logical Unit Direct Memory Access Directory Management Domain CP09: TCP/IP
98
EMOTOROLA LTD. 2001
Issue 1 Revision 4
DMI DMO DMPDU DMTF DMUX DN DNS DNHR DoD DOP DOS DP DPG DPI DQDB DR DS DS3 DSn DSA DSAP DSD DSE DSL DSP DSP DSS 1 DSTINIT DSU DSUN DT DTE DTMF DTR
Digital Multiplexed Interface; Definition of Management Information; Desktop Management Interface Domain Management Organization Derived MAC Protocol Data Unit Desktop Management Task Force Double Multiplexer Distinguished Name Domain Name System Dynamic Nonhierarchical Routing U.S. Department of Defense Directory Operational Binding Management Protocol Disk Operating System Draft Proposal Dedicated Packet Group DotsPerInch Distributed Queue Dual Bus Definite Response Directory Services Telephony classification of leased line speed Digital Signaling Level n Directory Service Agent Destination Service Access Point Data Structure Definition DSA Specific Entries Digital Subscriber Line Directory Service Protocol Domain Specific Part Digital Subscriber Signaling System No. 1 Data Services Task Initialization Digital Services Unit Distribution Services Unit Name DMPDU Trailer Data Terminal Equipment DualTone Multifrequency Data Terminal Ready
CP09: TCP/IP
EMOTOROLA LTD. 2001
99
Issue 1 Revision 4
DU DUP DUA DVMRP E.164 EMail EAS EB EBCDIC EACK EARN ECA ECC ECH ECMA ECO ECSA EDI EDIFACT EDIM EDIME EDIMS EDIMS EDIN EDIUA EEI EGP EIA EISA EIT EN ENA ENV EOM EOT
Data Unit Data User Port Directory User Agent Distance Vector Multicast Routing Protocol An ATM address format specified by the ITUTS Electronic Mail Extended Area Service End Bracket Extended BinaryCoded Decimal Interchange Code Extended Acknowledgement European Academic Research Event Detection Point Enhanced Error Checking and Correction Echo Canceller with Hybrid European Computer Manufacturers Association Echo Control Object Exchange Carriers Standards Association Electronic Data Interchange EDI For Administration, Commerce and Transport EDI Message EDI Messaging Environment EDI Messaging System EDI Message Store EDI Notification EDIUser Agent External Environment Interface Exterior Gateway Protocol Electronic Industries Association Extended Industry Standard Architecture Encoded Information type End Node Extended Network Addressing European Prestandards EndofMessage DMPDU EndofTransmission CP09: TCP/IP
910
EMOTOROLA LTD. 2001
Issue 1 Revision 4
EP ER ER EREP ES ESA ESA ESCON ESF ESH ESIS ESS ESTELLE ETB ETR ETX EUnet EUUG EWOS FA FADU FARNET FAS FAT FC FCC FCS FDCO FDDI FDDIFO FDM FDR FDT FDX FEC
Emulation Program Explicit Route Exception Response Environmental Recording Editing and Printing End System Enterprise Systems Architecture Enhanced Subarea Addressing Enterprise System Connectivity Extended Superframe Format End System Hello End System Intermediate System Electronic Switching System Extended State Transition Language EndofText Block Early Token Release EndofText European UNIX network European UNIX Users Group European Workshop on Open Systems Framework Advisory File Access Data Unit Federation of American Research Networks Frame Alignment Sequence File Allocation Table Frame Control Field Federal Communications Commission Frame Check Sequence Field Definition Control Object Fiber Distributed Data Interface FDDI FollowOn (FDDI) Frequency Division Multiplexing Field Definition Record Formal Description Technique Full Duplex Field Entry Condition
CP09: TCP/IP
EMOTOROLA LTD. 2001
911
Issue 1 Revision 4
FEE FEI FEICO FEIR FEP FEPCO FEPR FER FFOL FID FIPS FISU FM FMH FOD FOR FNC FRICC FR FRMR FS FSG FSM FTAM FTP FYI FX Gb Gbps GDMO GDS GFI GFP GGP GMT
Field Entry Event Field Entry Instruction Field Entry Instruction Control Object Field Entry Instruction Record Front End Processor Field Entry Pilot Control Object Field Entry Pilot Record Field Entry Reaction FDDI Followon LAN Format Identification Federal Information Processing Standard Fill In Signal Unit Function Management Function Management Header Office Document Format Forward Transfer Federal Networking Council Federal Research Internet Coordinating committee Family of Requirement Frame Reject Frame Status Field SGML Interchange Format Finite State Machine File Transfer and Access Management File Transfer Protocol in TCP/IP For Your Information Foreign Exchange Service Gigabits Gigabits Per Second Guidelines for the Definition of Managed Objects Generalized Data Stream General Format Indicator Global Functional Plane GatewaytoGateway Protocol Greenwich Meantime CP09: TCP/IP
912
EMOTOROLA LTD. 2001
Issue 1 Revision 4
GPS GOSIP GSA GTF GWNCP GWSSCP HAL HMUX HCL HCS HDB3 HDLC HDX HISAP HLR HMP HOB HPSAP HRC HSLN HTML HTTP Hz IAB IANA IADCS IAN IAP IBM IC ICD ICF ICI ICMP ICV
Global Positioning System Government OSI Protocol General Services Administration Generalized Trace Facility Gateway NCP Gateway SSCP Hardware Abstraction Layer Hybrid Multiplexer Hardware Compatibility List Header Check Sequence HighDensity Bipolar 3 zeros High Level Data Link Control Half Duplex Hybrid IsochronousMAC Service Access Point Home location Register Host Monitoring Protocol Head of Bus Hybrid packetMAC Service Access Point Hybrid Ring Control Highspeed Local Network Hypertext Markup Language Hypertext Transfer Protocol Hertz (cycles per second) Internet Architecture Board Internet Assigned Number Authority Interactivity Defined Context Set Integrated Analog Network Inner Administrative Point International Business Machines Corporations Interexchange Carrier International Code Designator Isochronous Convergence Function Interface Control Information Internet Control Message Protocol Integrity Check Value
CP09: TCP/IP
EMOTOROLA LTD. 2001
913
Issue 1 Revision 4
IDI IDN IDN IDP IDP IDU IEC IEC IEEE IEN IF IETF IESG IGP IGMP IGRP ILD ILU IMAC IMIL IML IMPDU IMS IN IND INN INTAP IOC IOCP IONL IP IPng IPv4 IPv6 IPC
Initial Domain Identifier Integrated Digital Network Interface Definition Notation Initial Domain Part Internetwork Datagram Packet Interface Data Unit Interexchange Carrier International Electrotechnical Commission Institute of Electrical and Electronic Engineers Internet Engineering Notes Information Flow Internet Engineering Task Force Internet Engineering Steering Group Interior Gateway Protocol Internet Group Management Protocol Internet Gateway Routing Protocol Injection Laser Diode Independent Logical Unit Isochronous Media Access Control International Managed Information Library Initial Microcode Load Initial MAC Protocol Data Unit Information Management System Intelligent Network Indication Intermediate Network Node Interoperability Technology Association for Information Processing Input/Output Control Input/Output Control Program Internal Organization of Network Layer Internet Protocol IP Next Generation IP version 4 IP version 6 Interprocess Communication CP09: TCP/IP
914
EMOTOROLA LTD. 2001
Issue 1 Revision 4
IPDS IPI IPICS IPL IPM IPMUA IPMS IPN IPR IPX IR IRN IRQ IRTF IS ISA ISAM ISC ISCF ISDN ISH ISIS ISO ISODE ISP ISPBX ISPSN ISSI ISUP IT ITC ITU ITUTS IUT IVDT
Intelligent Printer Data Stream Initial Protocol Identifier ISP Implementation Conformance Statement Initial Program Load Interpersonal Message Interpersonal Messaging User Agent Interpersonal Messaging System Interpersonal Notification Isolated Pacing Response Internetwork Packet Exchange Internet Router Intermediate Routing Node Interrupt Request Lines Internet Research Task Force International Standard Industry Standard Architecture IndexSequential Access Method Inter System Communications in CICS Inter Systems Control Facility Integrated Services Digital Network Intermediate System Hello Intermediate SystemtoIntermediate System International Standards Organization ISO Development Environment International Standard Profile Integrated Services Private Branch Exchange Initial Synchronization Point Serial Number Inter Switching System Interface ISDN User Part Information Technology Independent Telephone Company International Telecommunication Union International Telecommunication UnionTelecommunication Section Implementation Under Test Integrated Voice/Data Terminal
CP09: TCP/IP
EMOTOROLA LTD. 2001
915
Issue 1 Revision 4
IWU IXC JCL JES JTC JTM KA9Q kb kbps kHz km LAB LAB LAN LANSUP LAP LAPB LAPD LAPS LATA LCF LCN LE LEC LED LEN LI LIB LIC LIDB LIS LLAP LLC LME LMI
Interworking Unit Interexchange Carrier Job Control Language Job Entry Subsystem Joint Technical Committee Job Transfer and Manipulation TCP/IP implementation for amateur radio Kilobits Kilobits per second Kilohertz Kilometers Latency Adjustment Buffer Line Attachment Base Local Area Network LAN Adapter NDIS Support Link Access Procedure Link Access Procedure Balanced Link Access Procedures on the Dchannel LAN Adapter and Protocol Support Local Access and Transport Area Log Control Function Logical Channel Number Local Exchange Local Exchange Carrier LightEmitting Diode Low Entry Networking Length Indicator Line Interface Base Line Interface Coupler Line Information Database Logical IP Subnet LocalTalk Link Access Protocol Logical Link Control Layer Management Entity Layer Management Interface CP09: TCP/IP
916
EMOTOROLA LTD. 2001
Issue 1 Revision 4
LOCKD LOTOS LPD LPDA LPR LRC LSE LSL LSS LSSU LT LU m MAC MAC MACE MACF MAN MAP MAU MAU Mb MBA MBONE Mbps MBZ MCA MCF MCI MCP MCR MD MFA MFJ MFS
Lock Manager Daemon Language of Temporal Ordering Specifications Line Printer Daemon Link Problem Determination Application Line Printer Longitudinal Redundancy Check Local System Environment Link Support Layer Lowspeed Scanner Link Status Signal Unit Local Termination Logical Unit Meters Media Access Control Medium Access Control Macintosh Audio Compression and Expansion Multiple Association Control Function Metropolitan Area Network Manufacturing Automation Protocol Media Access Unit Multistation Access Unit Megabits MASSBUS Adapter Multicast BackBONE Megabits Per Second Must be Zero Microchannel Architecture MAC Convergence Function Microwave Communications, Inc. MAC Convergence Protocol Monitor Console Routine Management Domain Management Functional Areas Modified Final Judgment Message Formatting Services in IMS
CP09: TCP/IP
EMOTOROLA LTD. 2001
917
Issue 1 Revision 4
MH MHS MHS MHz MIB MIC MID MILNET MIM MIME MIN MIPS MIS MIT MLID MMF MMI MMS MOSS MOTIS MOT MPAF MRO ms MS MS MSC MSCP MSN MSNF MSS MST MSU MTA MTACP
Message Handling Package Message Handling Service Message Handling System Megahertz Management Information Base Media Interface Connector Message Identifier Military Network Management Information Model Multipurpose Internet Mail Extension Mobile Identification Number; Multiple Interaction Negotiation Million Instructions Per Second Management Information Systems Managed Information Tree Multiple Link Interface Driver Multimode Fiber Man Machine Interface Manufacturing Message Specification Maintenance and Operator Subsystem Message Oriented Text Interchange System Means of Testing Mid Page Allocation Field Multiregion Operation in CICS Millisecond Management Services Message Store Mobile Switching Center Mass Storage Control Protocol Multiple Systems Networking Multiple Systems Networking Facility MAN Switching System; Maximum Segment Size Multiplexed Slotted and Token Ring Management Services Unit Message Transfer Agent Magnetic Tape Ancillary Control Process CP09: TCP/IP
918
EMOTOROLA LTD. 2001
Issue 1 Revision 4
MTBF MTTD MTOR MTP MTS MTSE MTU MVS/XA MVS/370 MVS NAK NAP NAU NBP NC NC NCB NCCF NCEP NCP NCP NCS NCTE NDIS NFS NIB NIC NIF NISDN NIS NIST NIUF NJE NLM NLDM
Mean Time Between Failures Mean Time of Diagnosis Mean Time of Repair Message Transfer Part Message Transfer System Message Transfer Service Element Maximum Transfer Unit Multiple Virtual Storage/Extended Architecture Multiple Virtual Storage/370 Multiple Virtual Systems Negative Acknowledgement in BSC Network Access Provider Network Addressable Unit NameBinding Protocol Network Connection Numerical Controller Node Control Block Network Communications Control Facility Network Connection Endpoint Network Control Program Network Core Protocol Network Computing System Network ChannelTerminating Equipment Network Driver Interface Specification Network File System Node Identification Block Network Interface Card Network Information File Narrow Band ISDN Names Information Socket National Institute of Standards and Technology North American ISDN Users Forum Network Job Entry NetWare Loadable Module Network Logical Data Manager
CP09: TCP/IP
EMOTOROLA LTD. 2001
919
Issue 1 Revision 4
nm NM NMP NMVT NMS NN NOC NPA NPAI NPDA NPDU NPM NPSI NRN NRZ NRZI ns NS NSAP NSDU NSF NTFS NTO NVLAP OAF OAM OAM&P OCn OC3 OCA OCC ODA ODI ODIF ODINSUP
Nanometer Network Management Network Management Process Network Management Vector Transport Network Management Station Network Node Network Operations Center Numbering Plan Area Network Protocol Control Information Network Problem Determination Application Network Protocol Data Unit Netview Performance Monitor NCP Packet Switching Interface Nonreceipt Notification Non ReturntoZero Non ReturntoZero Inverted Nanosecond Network Service Network Service Access Points Network Service Data Unit National Science Foundation Windows NT File System Network Terminal Option National Voluntary Accreditation Program Origination Address Field Operations, administration, and maintenance Operations Administration, Maintenance and Provisioning Optical Carrier level n 155 million bits per second over fiber Open Communication Architectures Other Common Carrier Office Document Architecture Open DataLink Interface Office Document Interchange Format ODI NSIS Support CP09: TCP/IP
920
EMOTOROLA LTD. 2001
Issue 1 Revision 4
ODP OIT OIW OLRT OLU OM ONA ONC OPNDST O/R OS/400 OS OSE OSF OSI OSI/CS OSIE OSILL OSIUL OSPF OSNS PMAC PA PABX PAD PAF PAI PAM PANS PAP PBX PC PC PCCU PCEP
Open Distributed Processing Object Identifier Tree OSI Implementation Workshop Online Realtime Originating Logical Unit Object Management Open Network Architecture Open Network Computing Open Destination Originator/Recipient Operating System/400 for the AS/400 Computer Operating System Open Systems Environment Open Software Foundation Open Systems Interconnection OSI Communications Subsystem Open System Interconnection Environment Open Systems Interconnection Lower Layers Open Systems Interconnection Upper Layers Open Shortest Path First Open Systems Network Services Packet Switched Media Access Control Prearbitrated Private Automatic Branch Exchange Packet Assembler Disassembler PreArbitrated Function Protocol Address Information Pass Along Message Pretty Amazing New Stuff Printer Access Protocol Private Branch Exchange Path Control Personal Computer Physical Communications Control Unit Presentation Connection Endpoint
CP09: TCP/IP
EMOTOROLA LTD. 2001
921
Issue 1 Revision 4
PCI PCM PCO PCTR PDAD PDAU PDC pDISP PDN PDU PDV PELS PEM PEP PETS PH PhC PhCEP PhL PhPDU PhS PhSAP PhSAP PhSDU PHY PICS PIN PING PIP PIU PIXIT PKCS PLC PLCP
Protocol Control Information; Presentation Context Identifier; Peripheral Component Interconnect bus Pulse Code Modulation Points of Control and Observation Protocol Conformance Test Report Proposed Draft Addendum Physical Delivery Access Unit Packet Data Channel Proposed Draft International Standard Profile Public Data Network Protocol Data Unit Presentation Data Value Picture Elements Privacy Enhanced Mail Partition Emulation Program Parameterized Executable Test Suite Packet Handler or Packet Handling Physical Layer Connection Physical Connection EndPoint Physical Layer Physical Layer Protocol Data Unit Physical Layer Service Physical Layer SAP Physical Layer Service Access Point Physical Layer Service Data Unit Physical Layer Protocol Information Conformance Statement PositiveIntrinsic Negative Photodiode Packet Internet Groper Program Initialization Parameters Path Information Unit Protocol Implementation eXtra Information for Testing Public Key Cryptosystems Programmable Logic Controller Physical Layer Convergence Protocol CP09: TCP/IP
922
EMOTOROLA LTD. 2001
Issue 1 Revision 4
PLMN PLP PLS PLU PM PMD POI POP POSI POSIX POTS PPDU PPO PPP PPSDN PRI PRMD PS PSAP PSC PSDN PSN PSPDN PSTN PSTN PTF PTLXAU PTN PTT PU PUC PUCP PUMS PUP PUT
Public Land Mobile Network Packet Layer Protocol Primary Link Station; Physical Signalling Primary Logical Unit Protocol Machine Physical Layer Medium Dependent Point of Intitiation; Program Operator Interface Point of Presence Promoting Conference for OSI Portable Operating System Interface Plain Old Telephone Service Presentation Protocol Data Unit Primary Program Operator PointtoPoint Protocol Public Packet Switched Data Network Primary Rate Interface Private Management Domain Presentation Services Public Safety Answering Point Public Service Commission Packet Switched Data Network Packet Switched Network Packet Switched Public Data Network Public Switched Telephone Network Public Switched Telephone Network Program Temporary Fix Public Telex Access Unit Public Telephone Network Post, Telegraph and Telephone Physical Unit Public Utility Commission Physical Unit Control Point Physical Unit Management Services Parc Universal Packet Program Update Tape
CP09: TCP/IP
EMOTOROLA LTD. 2001
923
Issue 1 Revision 4
PVC PVN P1 P2 P3 P5 P7 QA QAF QC QEC QMF QOS QPSX QUIPU RAM RARE RARP RAS RBOC RD RD RDA RDA RDI RDN RDP RDT RECFMS REJ REQ RESP RESYNC RFC
Private Virtual Circuit Private Virtual Network Protocol 1 (message transfer protocol/MHS/X.400) Protocol 2 (interpersonal messaging MHS/X.400) Protocol 3 (submission and delivery protocol/MHS/X.400) Protocol 5 (Teletext access protocol) Protocol 7 (message store access protocol in X.400) Queued Arbitrated Queued Arbitrated Function Quiesce Complete Quiesce at EndofChain Query Management Facility Quality of Service Queued Packet and Synchronous Switch X.500 Conformant Directory Services in ISODE Random Access Memory Reseaux Associes poir la Recherche Europeenne; European Asosciation of Research Networks Reverse Address Resolution Protocol Remote Access Service Regional Bell Operating Company Routing Domain Route Redirection Relative Distinguished Names Remote Database Access Restricted Digital Information Relative Distinguished Name Reliable Datagram Protocol Resource Definition Table Record Formatted Maintenance Statistics Reject Request Response Resynchronization Request For Change CP09: TCP/IP
924
EMOTOROLA LTD. 2001
Issue 1 Revision 4
RFP RFQ RH RH RIB RIF RIM RIP RIPE by EUnet RISC RJE RM RMT RN RNAA RNR ROSE RPC RPL RPOA RQ RR RS RSF RSP RTM RTMP RTO RTR RTS RTSE RTT RU RU
Request for Proposal Request for Price Quotation Response Header Request Header Routing Information Base Routing Information Field Request Initialization Mode Router Information Protocol Reseaux IP Europeens; European continental TCP/IP network operated Reduced Instruction Set Computer Remote Job Entry Reference Model Ring Management Receipt Notification Request Network Address Assignment Receiver Not Ready Remote Operations Service Element Remote Procedure Call in OSF/DCE; Remote Procedure Call Request Parameter List; Remote Program Load Recognized Private Operating Agency Request Counter Receiver Ready Relay System Remote Support Facility Response Response Time Monitor Routing Table Maintenance Protocol Round Trip TimeOut Ready to Receive Request to Send Reliable Transfer Service Element Round Trip Time Request Unit Response Unit
CP09: TCP/IP
EMOTOROLA LTD. 2001
925
Issue 1 Revision 4
S/390 s SA SA SA SAA SAA SABM SACF SACK SAF SALI SAM SAMBE SAO SAP SAP SAPI SAS SAS SASE SATS SAW SBA SBI SC SC SCC SCCP SCEP SCP SCS SCSI SCTR SDH
IBMs System/390 Hardware Architecture Second Source Address field Subarea Sequenced Application System Applications Architecture Specific Administrative Areas Set Asynchronous Mode Balanced Single Association Control Function Selective Acknowledgement SACF Auxiliary Facility Source Address Length Indicator Security Accounts Manager Set Asynchronous Mode Balanced Extended Single Association Object Service Access Point Service Advertising Protocol Service Access Point Identifier SingleAttachment Station Statically Assigned Sockets Specific Application Service Element Selected Abstract Test Suite Session Awareness Data Set Buffer Address Stop Bracket Initiation Session Connection Subcommittee Specialized Common Carrier Signaling Connection Control Part Session Connection Endpoint Service Control Point System Conformance Statement Small Computer System Interface System Conformance Test Report Synchronous Digital Hierarchy CP09: TCP/IP
926
EMOTOROLA LTD. 2001
Issue 1 Revision 4
SDIF SDL SDLC SDN SDSE SDU SE SG SGFS SGML SIA SID SIM SIO SIP SLU SMAE SMASE SMB SMDR SMDS SMF SMF SMFA SMI SMIB SMP SMS SMT SMTP SNA SNAP SNAcF SNAcP SNADS
Standard Document Interchange Format System Description Language Synchronous Data Link Control Software Defined Network Shadowed DSA Entries Service Data Unit Session Entity Study Group Special Group on Functional Standardization Standard Generalized Markup Language Stable Implementation Agreements Security ID Set Initialization Mode Start I/O SMDS Interface Protocol Secondary Logical Unit System Management Application Entity Systems Management Application Service Element Server Message Block Station Message Detail Recording Switched Multi Megabit Data Service Single Mode Fiber System Management Facility Systems Management Functional Area Structure of the OSI Management Information Service Stored Message Information Base System Modification Program Service Management System Station Management Standard Simple Mail Transfer Protocol System Network Architecture Subnetwork Attachment Point Subnetwork Access Function Subnetwork Access Protocol SNA Distribution Services
CP09: TCP/IP
EMOTOROLA LTD. 2001
927
Issue 1 Revision 4
SNARE SNCP SNDCP SNI SNI SNI SNICP SNMP SNPA SNRM SOA SONET SP SPAG SPC SPDU SPE SPF SPI SPM SPSN SQL SRH SS SS SS6 SS7 SSA SSAP SSAP SSCP SSDU SSM STA ST
Subnetwork Address Routing Entity Single Node Control Point Subnetwork Dependent Convergence Protocol SubscriberNetwork Interface SNA Network Interconnection SNA Network Interface Subnetwork Independent Convergence Protocol Simple Network Management Protocol Subnetwork Point of Attachment Set Normal Response Mode Start Of Authority Synchronous Optical Network Signaling Point Standards Promotion and Applications Group Signaling Point Code Session Protocol Data Unit Synchronous Payload Envelope Shortest Path First Subsequent Protocol Identifier FDDI to SONET Physical Layer Mapping Standard Synchronization Point Survival Number Structured Query Language SNARE Request Hello Switching System Session Service Signaling System Number 6 Signaling System Number 7 Subschema Specific Area Source Service Access Point Session Service Access Point System Services Control Point Session Service Data Unit Single Segment Message DMPDU Spanning Tree Algorithms Sequenced Terminal CP09: TCP/IP
928
EMOTOROLA LTD. 2001
Issue 1 Revision 4
STD STM STM STMn STP STP STP STSn SUERM SUT SVA SVC SWS SYN Protocol SYNC T3 T TA TC TCP TAG TAP TC TCAM TCB TCEP TCM TCP TCP/IP TCT TDM TDMA TE TELNET
Standard Synchronous Transfer Mode Station Management Synchronous Transport Module level n Shielded Twisted Pair Service Transaction Program in LU 6.2 Signal Transfer Point Synchronous Transport Signal level n Signal Unit Error Rate Monitor System Under Test Shared Virtual Area Switched Virtual Circuit Silly Window Syndrome Synchronizing Segment; Synchronous Character in IBMs Bisync Synchronization A designation of telephony used over DS3 speed lines Transport Terminal Adaptor Technical Committee Transmission Control Protocol Technology Advisory Group Trace Analysis Program Transport Connection or Technical Committee Telecommunications Access Method Task Control Block Transport Connection Endpoint Time Compression Multiplexing Transmission Control Protocol Transmission Control Protocol/Internet Protocol Terminal Control Table in CICS Time Division Multiplexing Time Division Multiple Access Terminal Equipment Remote Logon in TCP/IP
CP09: TCP/IP
EMOTOROLA LTD. 2001
929
Issue 1 Revision 4
TEP TFTP TG TH THT TIC TINA TINAC TI RPC TLI TLMAU TLV TLXAU TMP TMS TOP TOS TN3270 TP TP TP TPDU TPPMD TPS TPSP TPSU TPSUI TP 0 TP 1 TP 2 TP 3 TP 4 TR TR TRA
Transport End Point Trivial File Transfer Protocol Transmission Group Transmission Header Token Holding Timer TokenRing Interface Coupler Telecommunications Information Network Architecture Telecommunication Information Network Architecture Consortium Transport Independent RPC Transport Layer Interface Telematic Access Unit Type, Length, and Value Telex Access Unit Text Management Protocol Time Multiplexed Switching Technical and Office Protocol Type of Service A version of TELNET that implements IBM 3270 data stream Transaction Program Transaction Processing Transport Protocol Transport Protocol Data Unit Twisted Pair PMD Two Processor Switch Transaction Processing Service Provider Transaction Processing Service User TPSU Invocation TP class 0 simple TP class 1 basic error recovery TP class 2 multiplexing TP class 3 error recovery and multiplexing TP class 4 error detection and recovery Technical Report Token Ring Token Ring Adapter CP09: TCP/IP
930
EMOTOROLA LTD. 2001
Issue 1 Revision 4
TRPB TRSS TRT TS TS TSAP TSC TSDU TSCF TSI TSO TSR TSS TTCN TTL TTP TTP TTRT TTY TUP TVX TWX UA UA UART UDI UDP UOW UPS URL UserASE USS UT UTC UTP
Truncated Reverse Path Broadcast TokenRing Subsystem Token Rotation Timer Transaction Services Transport Service Transport Service Access Point Transmission Subsystem Controller Transport Service Data Unit Target System Control Facility Time Slot Interchange Time Sharing Option Terminate and Stay Resident Program Transmission Subsystem Tree and Tabular Combined Notation Time to Live Timed Token Protocol Transport Test Platform Target Token Rotation Time Teletype Telephone User Part Valid Transmission Timer (FDDI) Teletypewriter Exchange Service Unnumbered Acknowledgement User Agent; Unsequenced Application Universal Asynchronous Receiver and Transmitter Unrestricted Digital Information User Datagram Protocol UnitofWork Uninterruptable Power Supply Universal Resource Locator User Application Service Element Unformatted System Services Unsequenced Terminal Coordinated Universal Time Unshielded Twisted Pair
CP09: TCP/IP
EMOTOROLA LTD. 2001
931
Issue 1 Revision 4
UUCP VAC VAN VAS vBNS VCI VDT VESA VLR VLSI VPI/VCI VM VMD VM/SP VPN VR VRPWS VS VSAM VSE VT VTAM VTE VTP VTPM VTSE WACA WACI WAN WAVAR WBC WD WG WNM
UNIXtoUNIX Copy Program Value Added Carrier Value Added Network Value Added Service A reference to the 155 Mbps deployment of an Internet backbone to have been implemented in 1995 Virtual Channel Identifier (DQDB) Video Display Terminal Video Electronics Standards Association Visitor Location Register Very Large Scale Integration Virtual Path Identifier and a Virtual Call Identifier Virtual Machine Virtual Manufacturing Device Virtual Machine System Product Virtual Private Network Virtual Route Virtual Route Pacing Window Size Virtual Storage Virtual Storage Access Method Virtual Storage Extended Virtual Terminal Virtual Telecommunications Access Method Virtual Terminal Environment Virtual Terminal Protocol Virtual Terminal Protocol Machine Virtual Terminal Service Element Write Access Connection Acceptor Write Access Connection Initiator Wide Area Network Write Access Variable Wideband Channel Working Document Working Group workgroup Node Manger CP09: TCP/IP
932
EMOTOROLA LTD. 2001
Issue 1 Revision 4
WP WWW X X.25 X.400 XAPIA XDR XDS XI XID XNS XTI XUDTS ZIP ZIS
Working Party The world wide web The X Window System An ITUTX standard; a transport layer service The ITUTS protocol for electronic mail X.400 API Association External Data Representation X/Open Directory Services API SNA X.25 Interface Exchange Identification Xerox Network Standard X/Open Transport Interface Extended Unitdata Service Zone Information Protocol Zone Information Socket
CP09: TCP/IP
EMOTOROLA LTD. 2001
933

CP09

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CP09

Uploaded by

Copyright:

Available Formats

CHAPTER 1 DATA COMMUNICATION

CHAPTER 2 INTERNET PROTOCOL

CHAPTER 3 ROUTING PROTOCOLS

CHAPTER 4 TRANSPORT PROTOCOLS

CHAPTER 5 APPLICATION PROTOCOLS

CHAPTER 6 DOMAIN NAME SERVICE

CHAPTER 8 AUTOMATIC CONFIGURATION

Issue 1 Revision 4 Training Manual

FOR TRAINING PURPOSES ONLY

Issue 1 Revision 4 FOR TRAINING PURPOSES ONLY

Positin mark for TED spine

Training Manual Issue 1 Revision 4 Course Training Manual

FOR TRAINING PURPOSES ONLY

Copyrights, notices and trademarks

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

FOR TRAINING PURPOSES ONLY

Chapter 1 Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 2 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

FOR TRAINING PURPOSES ONLY

260 260 260 260 260 268

Chapter 3 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 4 Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

Chapter 5 Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 6 Domain Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FOR TRAINING PURPOSES ONLY

Chapter 8 Automatic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 9 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

About this manual

FOR TRAINING PURPOSES ONLY

Special key sequences

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

First aid in case of electric shock

First aid in case of electric shock

FOR TRAINING PURPOSES ONLY

Reporting safety issues

Reporting safety issues

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

Warnings and cautions

Warnings and cautions

Example and format

Example and format

FOR TRAINING PURPOSES ONLY

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

FOR TRAINING PURPOSES ONLY

Human exposure to radio frequency energy (PCS1900 only)

Human exposure to radio frequency energy (PCS1900 only)

Maximum permitted exposures

Power density (S)

FOR TRAINING PURPOSES ONLY

EMOTOROLA LTD. 2001

Human exposure to radio frequency energy (PCS1900 only)

Maximum permitted exposure ceilings

1.287mW/cm 2 1.313mW/cm 2 6.433mW/cm 2