CHAPTER 2INTERNET PROTOCOL
CHAPTER 3ROUTING PROTOCOLS
CHAPTER 4TRANSPORT PROTOCOLS
CHAPTER 5APPLICATION PROTOCOLS
CHAPTER 1DATA COMMUNICATION
CHAPTER 7IP VERSION 6
CHAPTER 8AUTOMATIC
CONFIGURATION
CHAPTER 6DOMAIN NAME SERVICE
TCP/IP
Training Manual
Issue 1 Revision 4
FOR TRAININGPURPOSES ONLY
CP09
FOR TRAININGPURPOSES ONLY
Issue 1 Revision 4
Training M
anual
TC
P/IP
Issue 1 Revision 4
Course
TCP/IP
Course
CP09
Pos
itin
mar
k fo
r TE
D s
pine
TrainingManual
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Issue 1 Revision 4
CP09TCP/IP
� Motorola 1993, 1994, 1995, 1996, 1997, 1998, 1999All Rights ReservedPrinted in the U.K.
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Copyrights, notices and trademarks
CopyrightsThe Motorola products described in this document may include copyrighted Motorola computerprograms stored in semiconductor memories or other media. Laws in the United States and othercountries preserve for Motorola certain exclusive rights for copyright computer programs, including theexclusive right to copy or reproduce in any form the copyright computer program. Accordingly, anycopyright Motorola computer programs contained in the Motorola products described in this documentmay 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 byimplication, estoppel or otherwise, any license under the copyrights, patents or patent applications ofMotorola, except for the rights that arise by operation of law in the sale of a product.
RestrictionsThe software described in this document is the property of Motorola. It is furnished under a licenseagreement 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 bylaw. No part of the software or documentation may be reproduced, transmitted, transcribed, storedin a retrieval system, or translated into any language or computer language, in any form or by anymeans, without prior written permission of Motorola.
AccuracyWhile reasonable efforts have been made to assure the accuracy of this document, Motorolaassumes no liability resulting from any inaccuracies or omissions in this document, or from the useof the information obtained herein. Motorola reserves the right to make changes to any productsdescribed herein to improve reliability, function, or design, and reserves the right to revise thisdocument and to make changes from time to time in content hereof with no obligation to notify anyperson of revisions or changes. Motorola does not assume any liability arising out of the applicationor use of any product or circuit described herein; neither does it convey license under its patentrights of others.
Trademarks
and MOTOROLA are trademarks of Motorola Inc.UNIX is a registered trademark in the United States and other countries, licensed exclusively throughX/Open Company Limited.Tandem , Integrity , Integrity S2 , and Non-Stop-UX are trademarks of Tandem ComputersIncorporated.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.
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
General information 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Important notice 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Purpose 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About this manual 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross references 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text conventions 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
First aid in case of electric shock 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warning 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artificial respiration 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Burns treatment 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reporting safety issues 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedure 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Warnings and cautions 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warnings 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cautions 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General warnings 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warning labels 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specific warnings 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High voltage 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RF radiation 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laser radiation 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lifting equipment 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Do not ... 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Battery supplies 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toxic material 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Human exposure to radio frequency energy (PCS1900 only) 8. . . . . . . . . . . . . . . . . . . . . . Introduction 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definitions 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum permitted exposures 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum permitted exposure ceilings 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example calculation 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power density measurements 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other equipment 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beryllium health and safety precautions 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Health issues 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inhalation 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Skin contact 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eye contact 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling procedures 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disposal methods 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product life cycle implications 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General cautions 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caution labels 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specific cautions 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fibre optics 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static discharge 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Devices sensitive to static 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special handling techniques 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Motorola GSM manual set 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic manuals 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tandem OMC 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scaleable OMC 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related manuals 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service manuals 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Category number 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Catalogue number 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ordering manuals 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 1Data Communication i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Communication 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Communication and Distributed Processing 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication System Functions 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming and Addressing 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmenting 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Control 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronisation 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priority 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Control 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OSI Reference Model 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seven Layer Model for Open System Interconnection (OSI) 1–6. . . . . . . . . . . . . . . . .
Background 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request for Comment (RFC) 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Internet 1–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP (DoD) Architecture 1–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Layering 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing Concepts 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Numbers 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host Addressing 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Address 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaces 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 2Internet Protocol i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction 2–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Address Format 2–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class A, B, C 2–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class D, E 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class D 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class E 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY v
Example Addresses 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved Addresses 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved Address Examples 2–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnets 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Subnet Masks 2–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Masking 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical ‘AND’ 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Mask: Example 1 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Mask: Example 2 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Mask Table: Class A 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Field 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Length Field 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Type of Service Field 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Length Field 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification Field 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmentation 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flags [D, M] 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment offset 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time-to-Live Field 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Field 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Header Checksum 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Address Field 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Address Field 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Option Field Variable 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding Variable 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Variable 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options Type Field 2–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Record Route 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Timestamp 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loose Source Routing 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strict Source Routing 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Address Resolution (ARP) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reverse Address Resolution Protocol (RARP) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Control Message Protocol (ICMP) 2–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ICMP Message Types 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Echo Request/Echo Reply (0 and 8) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Unreachable (3) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Quench (4) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redirect (5) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYvi
Time Exceeded (11) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Problem (12) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TimeStamp Request/Reply (13, 14) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Request/Reply (15, 16) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Mask Request/Reply (17,18) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Datagram 2–68. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 3Routing Protocols i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Protocols 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing and Routing Tables 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Architecture 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Protocols 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distance Vector Protocols 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link-State Protocols 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special Distance Vector Protocols 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Gateway to Gateway Protocol 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exterior Gateway Protocol 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interior Distance Vector Protocols 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RIP 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Gateway Routing Protocol (IGRP) 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Link State Protocols 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First (OSPF) 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Hierarchy 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4Transport Protocols i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Protocols 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP Suite 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Datagram Protocol 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Transfer 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing Concepts 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host addressing 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Addressing 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UDP Concepts 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UDP Format 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Header 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmission Control Protocol 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP Segment 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Source and Destination Port 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence Number 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgement number 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Offset 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY vii
Flags 4–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Window 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checksum 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Urgent Pointer 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointer 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session 4–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session – 1 4–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session – 2 4–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session – 3 4–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminating a TCP Session 4–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session 4–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session – Reset 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5Application Protocols i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Protocols 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Layer 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client-Server Model 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Telnet 5–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Transfer Protocol (FTP) 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trivial File Transfer Protocol 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple Mail Transfer Protocol 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mail Transfer 5–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple Network Management Protocol 5–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 6Domain Name Service i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Domain Name Service 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domain Name System 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Structure and Administration 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domain Name Server 6–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message Format 6–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Name Server Hierarchy 6–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 7IP Version 6 i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Version 6 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background 7–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Features 7–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPV4/IPV6 Headers 7–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing 7–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Representation 7–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Address 7–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unicast 7–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicast 7–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYviii
Multicast Scope 7–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anycast 7–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Use 7–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extension Headers 7–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hop-by-Hop 7–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jumbo Payload Option 7–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Header 7–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fragment Header 7–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Destination Options Header 7–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing of Options 7–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication Header 7–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Encapsulating Security Payload Header 7–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security 7–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication and Encryption 7–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Parameters Index 7–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Neighbour Discovery 7–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 8Automatic Configuration i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automatic Configuration 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Address Resolution Protocol (RARP) 8–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Host Configuration Protocol 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Operation 8–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Relay Agents 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Fields 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP 8–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of RARP, BOOTP/TFTP and DHCP 8–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 9Glossary of Terms i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4 General information
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1
General information
Important notice
If this manual was obtained when you attended a Motorola training course, it will not beupdated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If itwas supplied under normal operational circumstances, to support a major softwarerelease, then corrections will be supplied automatically by Motorola in the form ofGeneral Manual Revisions (GMRs).
Purpose
Motorola Global System for Mobile Communications (GSM) Technical Education manualsare intended to support the delivery of Technical Education only and are not intended toreplace the use of Customer Product Documentation.
Failure to comply with Motorola’s operation, installation and maintenanceinstructions may, in exceptional circumstances, lead to serious injury or death.
WARNING
These manuals are not intended to replace the system and equipment training offered byMotorola, although they can be used to supplement and enhance the knowledge gainedthrough such training.
About thismanual
Issue 1 Revision 4General information
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2
Cross references
Throughout this manual, cross references are made to the chapter numbers and sectionnames. The section name cross references are printed bold in text.
This manual is divided into uniquely identified and numbered chapters that, in turn, aredivided into sections. Sections are not numbered, but are individually named at the topof each page, and are listed in the table of contents.
Text conventions
The following conventions are used in the Motorola GSM manuals to represent keyboardinput 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 environmentalvariables that appear on the screen are shown like this.
Special key sequences
Special key sequences are represented as follows:
CTRL-c Press the Control and c keys at the same time.
ALT-f Press the Alt and f keys at the same time.
| Press the pipe symbol key.
CR or RETURN Press the Return (Enter) key. The Return key isidentified with the ↵ symbol on both the X terminal andthe SPARCstation keyboards. The SPARCstationkeyboard Return key is also identified with the wordReturn.
Issue 1 Revision 4 First aid in case of electric shock
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3
First aid in case of electric shock
Warning
Do not touch the victim with your bare hands until the electric circuit isbroken.Switch off. If this is not possible, protect yourself with dry insulatingmaterial and pull or push the victim clear of the conductor.
WARNING
Artificialrespiration
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. Do not attempt to remove clothing adhering to the burn.
2. If help is available, or as soon as artificial respiration is no longer required, coverthe wound with a dry dressing.
3. Do not apply oil or grease in any form.
Issue 1 Revision 4Reporting safety issues
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4
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. Make the equipment concerned safe, for example, by removing power.
2. Make no further attempt to tamper with the equipment.
3. Report the problem directly to GSM MCSC +44 (0)1793 430040 (telephone) andfollow up with a written report by fax +44 (0)1793 430987 (fax).
4. Collect evidence from the equipment under the guidance of the MCSC.
Issue 1 Revision 4 Warnings and cautions
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5
Warnings and cautions
Introduction
The following describes how warnings and cautions are used in this manual and in allmanuals 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, forexample, the use of adhesives and solvents, as well as those inherent in the equipment.
Example and format
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 orunterminated fibre optic cables connected to data in/out connectors.
WARNING
Cautions
Definition
A caution means that there is a possibility of damage to systems, or individual items ofequipment within a system. However, this presents no danger to personnel.
Example and format
Do not use test equipment that is beyond its calibration due date when testingMotorola base stations.
CAUTION
Issue 1 Revision 4General warnings
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY6
General warnings
Introduction
Observe the following warnings during all phases of operation, installation andmaintenance of the equipment described in the Motorola GSM manuals. Failure tocomply with these warnings, or with specific warnings elsewhere in the Motorola GSMmanuals, violates safety standards of design, manufacture and intended use of theequipment. Motorola assumes no liability for the customer’s failure to comply with theserequirements.
Warning labelsPersonnel working with or operating Motorola equipment must comply with any warninglabels fitted to the equipment. Warning labels must not be removed, painted over orobscured in any way.
Specificwarnings
Warnings particularly applicable to the equipment are positioned on the equipment andwithin the text of this manual. These must be observed by all personnel at all times whenworking with the equipment, as must any other warnings given in text, on the illustrationsand on the equipment.
High voltageCertain Motorola equipment operates from a dangerous high voltage of 230 V ac singlephase or 415 V ac three phase mains which is potentially lethal. Therefore, the areaswhere the ac mains power is present must not be approached until the warnings andcautions 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 mustbe set to off and locked.
Within the United Kingdom (UK) regard must be paid to the requirements of theElectricity at Work Regulations 1989. There may also be specific country legislationwhich need to be complied with, depending on where the equipment is used.
RF radiationHigh RF potentials and electromagnetic fields are present in the base station equipmentwhen in operation. Ensure that all transmitters are switched off when any antennaconnections have to be changed. Do not key transmitters connected to unterminatedcavities or feeders.
Refer to the following standards:
� ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to HumanExposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
� CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields HighFrequency (10kHz to 300GHz).
Laser radiationDo not look directly into fibre optic cables or optical data in/out connectors. Laserradiation can come from either the data in/out connectors or unterminated fibre opticcables connected to data in/out connectors.
Issue 1 Revision 4 General warnings
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7
Liftingequipment
When dismantling heavy assemblies, or removing or replacing equipment, the competentresponsible person must ensure that adequate lifting facilities are available. Whereprovided, lifting frames must be used for these operations. When equipments have to bemanhandled, reference must be made to the Manual Handling of Loads Regulations1992 (UK) or to the relevant manual handling of loads legislation for the country in whichthe equipment is used.
Do not ...... substitute parts or modify equipment.
Because of the danger of introducing additional hazards, do not install substitute parts orperform any unauthorized modification of equipment. Contact Motorola if in doubt toensure 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 materialBeryllium or its oxide Beryllia or both. These materials are especially hazardous if:
� Beryllium materials are absorbed into the body tissues through the skin, mouth, ora 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.
Issue 1 Revision 4Human exposure to radio frequency energy (PCS1900 only)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8
Human exposure to radio frequency energy (PCS1900 only)
IntroductionThis equipment is designed to generate and radiate radio frequency (RF) energy. Itshould be installed and maintained only by trained technicians. Licensees of the FederalCommunications Commission (FCC) using this equipment are responsible for insuringthat its installation and operation comply with FCC regulations designed to limit humanexposure to RF radiation in accordance with the American National Standards InstituteIEEE Standard C95.1-1991, IEEE Standard for Safety Levels with Respect to HumanExposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
DefinitionsThis standard establishes two sets of maximum permitted exposure limits, one forcontrolled environments and another, that allows less exposure, for uncontrolledenvironments. These terms are defined by the standard, as follows:
Uncontrolled environmentUncontrolled environments are locations where there is the exposure of individuals whohave no knowledge or control of their exposure. The exposures may occur in livingquarters or workplaces where there are no expectations that the exposure levels mayexceed those shown for uncontrolled environments in the table of maximum permittedexposure ceilings.
Controlled environment
Controlled environments are locations where there is exposure that may be incurred bypersons who are aware of the potential for exposure as a concomitant of employment, byother cognizant persons, or as the incidental result of transient passage through areaswhere analysis shows the exposure levels may be above those shown for uncontrolledenvironments but do not exceed the values shown for controlled environments in thetable of maximum permitted exposure ceilings.
Maximumpermittedexposures
The maximum permitted exposures prescribed by the standard are set in terms ofdifferent parameters of effects, depending on the frequency generated by the equipmentin question. At the frequency range of this Personal Communication System equipment,1930-1970MHz, the maximum permitted exposure levels are set in terms of powerdensity, whose definition and relationship to electric field and magnetic field strengths aredescribed by the standard as follows:
Power density (S)Power per unit area normal to the direction of propagation, usually expressed in units ofwatts per square metre (W/m2) or, for convenience, units such as milliwatts per squarecentimetre (mW/cm2). For plane waves, power density, electric field strength (E) andmagnetic field strength (H) are related by the impedance of free space, 377 ohms. Inparticular,
� ���
���� ���� ��
where E and H are expressed in units of V/m and A/m, respectively, and S in units ofW/m2. Although many survey instruments indicate power density units, the actualquantities measured are E or E2 or H or H2.
Issue 1 Revision 4 Human exposure to radio frequency energy (PCS1900 only)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9
Maximumpermittedexposureceilings
Within the frequency range, the maximum permitted exposure ceiling for uncontrolledenvironments is a power density (mW/cm2) that equals f/1500, where f is the frequencyexpressed in MHz, and measurements are averaged over a period of 30 minutes. Themaximum permitted exposure ceiling for controlled environments, also expressed inmW/cm2, is f/300 where measurements are averaged over 6 minutes. Applying theseprinciples to the minimum and maximum frequencies for which this equipment is intendedto be used yields the following maximum permitted exposure levels:
Uncontrolled Environment Controlled Environment
1930MHz 1970MHz 1930MHz 1970MHz
Ceiling 1.287mW/cm2 1.313mW/cm2 6.433mW/cm2 6.567mW/cm2
If you plan to operate the equipment at more than one frequency, compliance should beassured at the frequency which produces the lowest exposure ceiling (among thefrequencies 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 demonstratingcompliance, but this equipment operates at power levels orders of magnitude higher, andthe exclusion is not applicable.
Whether a given installation meets the maximum permitted exposure ceilings depends, inpart, upon antenna type, antenna placement and the output power to which thisequipment is adjusted. The following example sets forth the distances from the antennato which access should be prevented in order to comply with the uncontrolled andcontrolled environment exposure limits as set forth in the ANSI IEEE standards andcomputed above.
Issue 1 Revision 4Human exposure to radio frequency energy (PCS1900 only)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY10
Examplecalculation
For a base station with the following characteristics, what is the minimum distance fromthe antenna necessary to meet the requirements of an uncontrolled environment?
Transmit frequency 1930MHz
Base station cabinet output power, P +39.0dBm (8 watts)
Antenna feeder cable loss, CL 2.0dB
Antenna input power Pin P–CL = +39.0–2.0 = +37.0dB (5watts)
Antenna gain, G 16.4dBi (43.65)
Using the following relationship:
� ������
���
Where W is the maximum permissible power density in W/m2 and r is the safe distancefrom the antenna in metres, the desired distance can be calculated as follows:
� �����
���� �
������ �
��� ����� � �����
where W = 12.87 W/m2 was obtained from table listed above and converting frommW/cm2 to W/m2.
The above result applies only in the direction of maximum radiation of theantenna. Actual installations may employ antennas that have defined radiationpatterns and gains that differ from the example set forth above. The distancescalculated can vary depending on the actual antenna pattern and gain.
NOTE
Power densitymeasurements
While installation calculations such as the above are useful and essential in planning anddesign, validation that the operating facility using this equipment actually complies willrequire making power density measurements. For information on measuring RF fields fordetermining compliance with ANSI IEEE C95.1-1991, see IEEE Recommended Practicefor 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 bepurchased 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 thisequipment are urged to consult these standards in determining whether a giveninstallation complies with the applicable limits.
Other equipmentWhether a given installation meets ANSI standards for human exposure to radiofrequency radiation may depend not only on this equipment but also on whether theenvironments being assessed are being affected by radio frequency fields from otherequipment, the effects of which may add to the level of exposure. Accordingly, the overallexposure may be affected by radio frequency generating facilities that exist at the timethe licensee’s equipment is being installed or even by equipment installed later.Therefore, the effects of any such facilities must be considered in site selection and indetermining whether a particular installation meets the FCC requirements.
Issue 1 Revision 4 Beryllium health and safety precautions
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 11
Beryllium health and safety precautions
Introduction
Beryllium (Be), is a hard silver/white metal. It is stable in air, but burns brilliantly inOxygen.
With the exception of the naturally occurring Beryl ore (Beryllium Silicate), all Berylliumcompounds and Beryllium metal are potentially highly toxic.
Health issues
Beryllium Oxide is used within some components as an electrical insulator. Captivewithin the component it presents no health risk whatsoever. However, if the componentshould 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 symptomsof Berylliosis are similar to Pneumonia and may be identified by all or any of thefollowing:
Mild poisoning causes fever, shortness of breath, and a cough that producesyellow/green sputum, or occasionally bloodstained sputum. Inflammation of the mucousmembranes of the nose, throat, and chest with discomfort, possibly pain, and difficultywith swallowing and breathing.
Severe poisoning causes chest pain and wheezing which may progress to severeshortness of breath due to congestion of the lungs. Incubation period for lung symptomsis 2–20 days.
Exposure to moderately high concentrations of Beryllium in air may produce a veryserious condition of the lungs. The injured person may become blue, feverish with rapidbreathing and raised pulse rate. Recovery is usual but may take several months. Therehave been deaths in the acute stage.
Chronic response. This condition is more truly a general one although the lungs aremainly affected. There may be lesions in the kidneys and the skin. Certain featuressupport the view that the condition is allergic. There is no relationship between thedegree of exposure and the severity of response and there is usually a time lag of up to10 years between exposure and the onset of the illness. Both sexes are equallysusceptible. The onset of the illness is insidious but only a small number of exposedpersons develop this reaction.
First aid
Seek immediate medical assistance. The casualty should be removed immediately fromthe exposure area and placed in a fresh air environment with breathing supported withOxygen where required. Any contaminated clothing should be removed. The casualtyshould be kept warm and at rest until medical aid arrives.
Issue 1 Revision 4Beryllium health and safety precautions
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY12
Skin contact
Possible irritation and redness at the contact area. Persistent itching and blisterformations can occur which usually resolve on removal from exposure.
First aid
Wash area thoroughly with soap and water. If skin is broken seek immediate medicalassistance.
Eye contact
May cause severe irritation, redness and swelling of eyelid(s) and inflammation of themucous membranes of the eyes.
First aid
Flush eyes with running water for at least 15 minutes. Seek medical assistance as soonas possible.
Handlingprocedures
Removal of components from printed circuit boards (PCBs) is to take place only atMotorola approved repair centres.
The removal station will be equipped with extraction equipment and all other protectiveequipment necessary for the safe removal of components containing Beryllium Oxide.
If during removal a component is accidently opened, the Beryllium Oxide dust is to bewetted into a paste and put into a container with a spatula or similar tool. Thespatula/tool used to collect the paste is also to be placed in the container. The containeris then to be sealed and labelled. A suitable respirator is to be worn at all times duringthis operation.
Components which are successfully removed are to be placed in a separate bag, sealedand labelled.
Disposalmethods
Beryllium Oxide or components containing Beryllium Oxide are to be treated ashazardous waste. All components must be removed where possible from boards and putinto sealed bags labelled Beryllium Oxide components. These bags must be given to thesafety and environmental adviser for disposal.
Under no circumstances are boards or components containing Beryllium Oxide to be putinto the general waste skips or incinerated.
Product life cycleimplications
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 suchhazardous waste as part of its Total Customer Satisfaction philosophy and will arrangefor the most environmentally “friendly” disposal available at that time.
Issue 1 Revision 4 General cautions
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 13
General cautions
Introduction
Observe the following cautions during operation, installation and maintenance of theequipment described in the Motorola GSM manuals. Failure to comply with thesecautions or with specific cautions elsewhere in the Motorola GSM manuals may result indamage to the equipment. Motorola assumes no liability for the customer’s failure tocomply with these requirements.
Caution labels
Personnel working with or operating Motorola equipment must comply with any cautionlabels fitted to the equipment. Caution labels must not be removed, painted over orobscured in any way.
Specific cautions
Cautions particularly applicable to the equipment are positioned within the text of thismanual. These must be observed by all personnel at all times when working with theequipment, as must any other cautions given in text, on the illustrations and on theequipment.
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 bymishandling. Wear an approved earth strap when adjusting or handling digital boards.
See Devices sensitive to static for further information.
Issue 1 Revision 4Devices sensitive to static
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY14
Devices sensitive to static
Introduction
Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer ofinsulation that is susceptible to damage from electrostatic charge. Such a charge appliedto the leads of the device could cause irreparable damage.
These charges can be built up on nylon overalls, by friction, by pushing the hands intohigh insulation packing material or by use of unearthed soldering irons.
MOS devices are normally despatched from the manufacturers with the leads shortedtogether, for example, by metal foil eyelets, wire strapping, or by inserting the leads intoconductive plastic foam. Provided the leads are shorted it is safe to handle the device.
Special handlingtechniques
In the event of one of these devices having to be replaced observe the followingprecautions when handling the replacement:
� 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 toreplace 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 cottonoverall is preferable.
� If possible work on an earthed metal surface. Wipe insulated plastic work surfaceswith an anti-static cloth before starting the operation.
� All metal tools should be used and when not in use they should be placed on anearthed surface.
� Take care when removing components connected to electrostatic sensitivedevices. These components may be providing protection to the device.
When mounted onto printed circuit boards (PCBs), MOS devices are normally lesssusceptible to electrostatic damage. However PCBs should be handled with care,preferably by their edges and not by their tracks and pins, they should be transferreddirectly from their packing to the equipment (or the other way around) and never leftexposed on the workbench.
Issue 1 Revision 4 Motorola GSM manual set
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 15
Motorola GSM manual set
Introduction
The following manuals provide the information needed to operate, install and maintain theMotorola GSM equipment.
Generic manuals
The following are the generic manuals in the GSM manual set, these manuals arerelease dependent:
Categorynumber
Name Cataloguenumber
GSM-100-101 System Information: General 68P02901W01
GSM-100-201 Operating Information: GSM System Operation 68P02901W14
GSM-100-311 Technical Description: OMC in a GSM System 68P02901W31
GSM-100-313 Technical Description: OMC Database Schema 68P02901W34
GSM-100-320 Technical Description: BSS Implementation 68P02901W36
GSM-100-321 Technical Description: BSS CommandReference
68P02901W23
GSM-100-403 Installation & Configuration: GSM SystemConfiguration
68P02901W17
GSM-100-423 Installation & Configuration: BSS Optimization 68P02901W43
GSM-100-501 Maintenance Information: Alarm Handling atthe OMC
68P02901W26
GSM-100-521 Maintenance Information: Device StateTransitions
68P02901W57
GSM-100-523 Maintenance Information: BSS FieldTroubleshooting
68P02901W51
GSM-100-503 Maintenance Information: GSM StatisticsApplication
68P02901W56
GSM-100-721 Software Release Notes: BSS/RXCDR 68P02901W72
Tandem OMC
The following Tandem OMC manuals are part of the GSM manual set for systemsdeploying Tandem S300 and 1475:
Categorynumber
Name Cataloguenumber
GSM-100-202 Operating Information: OMC SystemAdministration
68P02901W13
GSM-100-712 Software Release Notes: OMC System 68P02901W71
Issue 1 Revision 4Motorola GSM manual set
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY16
Scaleable OMC
The following Scaleable OMC manuals replace the equivalent Tandem OMC manuals inthe GSM manual set:
Categorynumber
Name Cataloguenumber
GSM-100-202 Operating Information: Scaleable OMC SystemAdministration
68P02901W19
GSM-100-413 Installation & Configuration: Scaleable OMCClean Install
68P02901W47
GSM-100-712 Software Release Notes: Scaleable OMCSystem
68P02901W74
Related manuals
The following are related Motorola GSM manuals:
Categorynumber
Name Cataloguenumber
GSM-001-103 System Information: BSS Equipment Planning 68P02900W21
GSM-002-103 System Information: DataGen 68P02900W22
GSM-005-103 System Information: Advance OperationalImpact
68P02900W25
GSM-008-403 Installation & Configuration: Expert Adviser 68P02900W36
Service manuals
The following are the service manuals in the GSM manual set, these manuals are notrelease dependent. The internal organization and makeup of service manual sets mayvary, they may consist of from one to four separate manuals, but they can all be orderedusing the overall catalogue number shown below:
Categorynumber
Name Cataloguenumber
GSM-100-020 Service Manual: BTS 68P02901W37
GSM-100-030 Service Manual: BSC/RXCDR 68P02901W38
GSM-105-020 Service Manual: M-Cell2 68P02901W75
GSM-106-020 Service Manual: M-Cell6 68P02901W85
GSM-201-020 Service Manual: M-Cellcity 68P02901W95
GSM-202-020 Service Manual: M-Cellaccess 68P02901W65
GSM-101-SERIES ExCell4 Documentation Set 68P02900W50
GSM-103-SERIES ExCell6 Documentation Set 68P02900W70
GSM-102-SERIES TopCell Documentation Set 68P02901W80
GSM-200-SERIES M-Cellmicro Documentation Set 68P02901W90
Issue 1 Revision 4 Motorola GSM manual set
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 17
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.
Cataloguenumber
The Motorola 68P catalogue number is used to order manuals.
Orderingmanuals
All orders for Motorola manuals must be placed with your Motorola Local Office orRepresentative. Manuals are ordered using the catalogue number. Remember, specifythe manual issue required by quoting the correct suffix letter.
Issue 1 Revision 4Motorola GSM manual set
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY18
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 1
Data Communication
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 1Data Communication i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Communication 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Communication and Distributed Processing 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication System Functions 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming and Addressing 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmenting 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Control 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronisation 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priority 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Control 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OSI Reference Model 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seven Layer Model for Open System Interconnection (OSI) 1–6. . . . . . . . . . . . . . . . .
Background 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request for Comment (RFC) 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Internet 1–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP (DoD) Architecture 1–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Layering 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing Concepts 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Numbers 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host Addressing 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Address 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaces 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 Data Communication
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–1
Data Communication
Objectives
On completion of this chapter the student will be able to:
� Describe the basic objectives and functions of data communication networks.
� Describe the OSI Reference model.
� Describe basic addressing concepts.
Issue 1 Revision 4Data Communication and Distributed Processing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–2
Data Communication and Distributed ProcessingThe factors driving distributed processing are:
1. Technological advances are changing the price-performance ratio in favour ofmultiple low-cost, high-performance systems.
2. Interconnections and communication costs are falling dramatically.
3. Users are demanding more economical, rapid, sophisticated and reliable facilities.
The proliferation of personal computers throughout organisations for a wide variety ofbusiness functions has resulted in an ever-increasing need for personal computers tocommunicate with each other. As well as intercommunication among personalcomputers, the communications network must facilitate communication with centraliseddata processing facilities and the sources of corporate data. Several networkingtechnologies have been developed to support this intercommunication.
Local Area Networks (LANs), such as Ethernet and Token Ring, are defined by the IEEEas data communication systems that allow a number of independent devices tocommunicate directly with each other over moderate distances on a shared transmissionmedium. LANs can be used for shared data, application and device access, electronicmail, process monitoring in a factory environment and even for alarm and securitysystems. The most interesting feature of the LAN is its capability to support co-operativeapplications in which an application runs partly on a LAN station and partly on a LANserver or possibly a mainframe. Although LANs generally operate at moderate speeds(10 Mbps), the increase in processing capability of the individual workstations has led tothe development of more sophisticated multi-media applications which require higherspeeds. 100Mbps Ethernet is becoming more common with 1 Gbps Ethernet availableand Asynchronous Transfer Mode (ATM) multi-media LANs also being deployed.
The range of LAN applications can be significantly extended by interconnecting severalnetworks over Wide Area Network (WAN) connections. WANs allow interconnection overthousands of miles, thus removing the traditional distance limitations of the LAN. MostWANs are provided by the public telecommunications service providers, but de-regulationhas seen many private operators competing in this market reducing costs significantly.Some WAN technologies, such as X.25 and Frame Relay have been designedspecifically for the transport of data. However, the Public Switched Telephone Network(PSTN) allows users with modems to have access to data services through InternetService Providers (ISPs) and is responsible for the huge growth in data communicationservices to the home. ISDN has improved the performance of dial-up connections andB-ISDN, based on Asynchronous Transfer Mode (ATM), will allow bandwidth-on-demandfor the more sophisticated multi-media applications now being run on even the mostbasic of PCs.
In between the LAN and the WAN is the Metropolitan Area Network (MAN). A typicalMAN provides voice, data and video communications at speeds of 45-600 Mbps atdistances ranging from 1 to 50 miles.
Recent years have seen a large growth in internet working. Protocols have beendeveloped that allow any device on one LAN to be connected to any device on anotherLAN if both LANs are connected to the Internet.
Issue 1 Revision 4 Data Communication and Distributed Processing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–3
Data Communication and Distributed Processing
CP09_1_1
ISP ISP
X.25
PSTN PSTN
FrameRelay
Issue 1 Revision 4Communication System Functions
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–4
Communication System FunctionsWhen networks are connected over many LAN-WAN-LAN links there must be an efficientand reliable method for ensuring that all data transmitted from one node reaches therequired destination. The following are some of the most important functions of thecommunication system.
Naming andAddressing
A communication system manipulates names for objects. These objects can be suchitems as processes, ports, mailboxes, systems and sessions between users. Userstypically supply names in symbolic form (such [email protected]) and then the communication systemrestates this form into a network address. The communication system must maintaintranslation 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, thecommunication system must fragment a single message into multiple segments andreassemble it before delivery to the end user. For instance, the maximum frame size forEthernet is 1518 bytes. The typical maximum frame size for Token Ring is 5000 bytes. AWAN might have a maximum transmission unit size of 128 bytes. Segmentation andre-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 assumptionthat not all users demand those services simultaneously. When the resulting trafficexceeds the network throughput capacity, network flow control is designed to optimisenetwork performance by regulating the flow of information between a pair ofcommunicating entities.
Synchronisation
Before devices can communicate, their interactions must be synchronised. Receiversmust operate at the same rate as transmitters. When data resources are shared ordistributed, it is necessary to co-ordinate the distributed resources to ensure they remainsynchronised.
Priority
A communication system can differentiate between high and low priority traffic. Highpriority traffic suffers less delay, low priority traffic is not lost but may be buffered whilehigh priority traffic is being processed. This is becoming a very important aspect ofnetworking 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 communicationsystems. Error control functions include error detection, error correction and recovery.
Issue 1 Revision 4 Communication System Functions
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–5
Communication System Functions
CP09_1_2
Naming and Addressing
Fragmenting
Flow Control
Synchronization
Priority
Error Control
Issue 1 Revision 4OSI Reference Model
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–6
OSI Reference ModelThe International Standards Organisation has adopted a layered approach for thereference model for Open Systems Interconnection (OSI). The complete communicationsystem is broken down into a number of layers, each of which performs a well-definedfunction.
Each layer provides a well-defined function in the context of the overall communicationssubsystem. The layers operate according to a defined protocol (set of rules) byexchanging messages, both user data and control information, with a peer (similar) layerin a remote system. Each layer has a well-defined interface to the layers immediatelyabove and below. A layer provides a service to the layer above and requests servicesfrom the layer below. The implementation of a particular layer is independent of all otherlayers.
Seven LayerModel for OpenSystemInterconnection(OSI)
� The application layer provides the user interface to a range of network services.
� The presentation layer converts the internal syntax of the application layer intosuitable abstract data syntax and data transfer syntax, and can include encryptionfor data security.
� The session layer is responsible for setting up and clearing a communicationchannel between two presentation layers for the duration of the complete networktransaction.
� The transport layer acts as the interface between the higher application-orientedlayers and the underlying network-dependent layers. It provides a networkindependent reliable message delivery service to the session layer.
� The network layer performs such functions as addressing, routing and flowcontrol across the user-to-network interface.
� The data link layer builds on the physical connection provided by a particularnetwork to provide a reliable information transfer facility. It performs such functionsas error detection and recovery. The data link layer may be able to correct errorsor arrange for retransmission.
� The physical layer is concerned with the physical and electrical interfacesbetween equipment on the network.
Issue 1 Revision 4 OSI Reference Model
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–7
OSI Reference Model
CP09_ch01_03
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical layer
AL (7)
PL (6)
SL (5)
TL (4)
NL (3)
DLL (2)
PL (1)
Network Node
Issue 1 Revision 4Background
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–8
BackgroundTCP/IP is the protocol suite that is used with the Internet. The origins of the Internet canbe traced back to the 1960s and was initially developed by the Defence AdvancedResearch Projects Agency (DARPA) of the American Department of Defence (DoD).
In the late 1960’s DARPA set out to accomplish the inter-connectivity of networks withthe resulting outcome of ARPANET, requiring the use of dedicated processors andleased point-to-point lines. The main development efforts centred on the design of anetwork that could withstand the loss of physical sections. Other design goals includedthe development of a flexible network that allowed the addition and removal of nodes withthe minimum of impact. The network also had to be able to connect computers ofdifferent makes and allow them to communicate effectively. The ARPANET research ledto the development of a new network protocol involving packet switching.
In order to interconnect different networks using incompatible hardware and software toARPANET, TCP/IP was developed.
TCP and IP protocols were accepted as DoD standards in 1979. DoD mandating that allnetworks connected to the ARPANET use TCP/IP; thus the Internet was born.
DARPA also funded TCP/IP implementation on UNIX operating systems in co-operationwith the University of California, Berkeley and distributed the code free of charge with theoperating system code itself. This spread TCP/IP throughout the universities andresearch centres.
Request forComment (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 technicalreports called Request For Comments, or RFC’s. The Network Information Centre (NIC)distribute RFC’s to the community electronically, using the Internet or by postal mail.
Issue 1 Revision 4 Background
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–9
Background
CP09_1_4
Research project funded by DARPA
ARPA and ARPANET set up to link military CPUs
DARPA funded Berkeley UNIX
Standards published as RFCs
Issue 1 Revision 4The Internet
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–10
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 dependentcommunications technology. New software inserted between this and theapplications programs, would hide the low-level details, and make the collectionof networks appear to be one large virtual network. This interconnection schemeis called an internetwork or internet. So there are two main goals:
� Universal Communication Services, that hides the physical network and provides acommon, universal ’interface’ for all applications. It does not require the users tounderstand 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 bothnetworks. However, this in itself does not guarantee the interconnection we areseeking, since it does not ensure that the computer will cooperage with othermachines which wish to communicate. To create a viable internet, we needcomputers that ALSO shuffle (and route) packets from one network to the other,these are called internet gateways.
From the network’s viewpoint, a gateway is just a normal host, to the user, gateways aretransparent. The user only sees one large internet.
The advantage of providing interconnection at the network permits application programsthat communicate over the Internet, not to know the details of the underlyingconnections. They can run without change on any machine. Only the software whichdeals with the machine’s physical connection needs to change if a new/different physicalconnection is used. Also users, do not need to understand or remember how thenetworks connect or what traffic they carry. Networks which participate in the internet arelike motorways throughout the UK, each network agrees to handle transit traffic inexchange for the right to send traffic through the internet. Typically users are unaffectedand unaware of the extra traffic on their local network.
Issue 1 Revision 4 The Internet
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–11
The Internet
CP09_1_5
Network
Router
IP Host Virtual Network
Issue 1 Revision 4TCP/IP (DoD) Architecture
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–12
TCP/IP (DoD) ArchitectureTCP/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:
� TELNET - the protocol which allows for remote terminal connections.
� SMTP - Simple Mail Transfer Protocol, which is an electronic mail process thatallows users to compose memos and send them to individuals or groups ofindividuals.
� FTP - File Transfer Protocol, that allows users to send or receive arbitrarily largefiles or programs or data.
� SNMP - Simple Network Management protocol, used to facilitate the exchange ofmanagement information between network devices.
Transport
Provides for end-to-end transfer of the application data. The examples at this level are:
� 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 otherhost, regardless of the network or the destination.
It is at this level that routing functions occur. There are several protocols that can beimplemented at this level which assist the IP in delivering data.
� IP - Internet Protocol, is the protocol used here. It does not provide reliability, flowcontrol or error recovery.
Network Access
This is the interface to the actual network hardware. The TCP/IP protocols do not specifythat a particular network must be used. Almost every network interface is available,illustrating the flexibility of the Internetwork (IP) layer. Examples of the networks usedare:
� Ethernet, Token Ring, FDDI
� X.25, Frame Relay, ATM
Issue 1 Revision 4 TCP/IP (DoD) Architecture
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–13
DoD Architecture
CP09_1_6
Process
Host-to-Host
Internet
Network Access
Process or application
End-to-end exchangebetween processes
Data exchange betweenhosts regardless of network
Data exchange between deviceson the same network
Issue 1 Revision 4Layering
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–14
LayeringTo control the journey of user data from one host on the internet to another the user datahas to pass through the underlying levels of protocol. Each level will append some of itsown 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 tothe PDU at each level is as follows:
� Process: Segments - as formed by Application Process
� Host: Datagrams - as formed by UDP/TCP
� Internet: Datagrams - as formed by IP
� Network: varies according to the technology (e.g. frame, packet, cell etc.)
Issue 1 Revision 4 Layering
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–15
Layering
CP09_1_7
Message or streams
Host–to–Host packets
IP Datagrams
Network Frames
Encapsulation
TCP Segment
IP Datagram
Network frame/packet
Process
Host–to–Host
Internet
NetworkInterface
TCP–H User DataNI–H IP–H
TCP–H User DataNI–H IP–H
TCP–H User DataIP–H
TCP–H User Data
User Data
Issue 1 Revision 4Addressing Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–16
Addressing Concepts
Port Numbers
Processes are identified with a 16-bit number. A process at a source host must know theport number at which its target process resides. The IAB (Internet Activities Board), haspublished a list of port numbers for all commonly used processes. These ports are knownas “Well Known Ports ” and are in the range of 1 -1023. An example is that SNMP is onport 161. However, in many cases, it is only the server process that has the well-knownport number associated with it. The client process which makes the request uses a portnumber larger than 1024 that has been randomly allocated to it for a particular session.
ProtocolAddressing
An 8-bit field in the IP header identifies the protocol which is encapsulated within the IPdatagram. The following are typical protocol identifiers:-
TCP 06
UDP 17
ICMP 01
Host Addressing
Each host which resides on a particular network must uniquely identify itself with anetwork address. IP uses a 32-bit address, which is referred to as a dotted decimalnumber. IP uses this address in order to recognise the network and the host on thatnetwork. An example address is:-
122.45.2.5
Physical Address
Each device on a network has a unique physical address, which is sometimes known asthe hardware address or MAC address. This is a 48-bit address written in hexadecimalformat. Again, this must not be duplicated. The hardware address is normally encodedinto a network interface card by either switches or more commonly, by software. Anexample 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 passits PDU down to that level; which in turn passes its PDU to the network access level fortransmission on the network.
The use of any individual level in the architecture is not expressly required, since it ispossible for applications to invoke the services of any one of the levels directly. Howeversince the majority of applications require a reliable end-to-end service they make use ofTCP.
Issue 1 Revision 4 Addressing Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 1–17
Addressing Concepts
CP09_1_9
Telnet SMTP FTP
TCP UDP
23 25 21
TFTP SNMP DNS
69 161 53
IPARP RARP
06 17
Network Physical Medium
0806 80350800
122.45.2.5
00:09:00:F2:C5:28
Issue 1 Revision 4Addressing Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY1–18
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 2
Internet Protocol
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 2Internet Protocol i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction 2–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Address Format 2–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class A, B, C 2–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class D, E 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class D 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class E 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Addresses 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved Addresses 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved Address Examples 2–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnets 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Subnet Masks 2–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Masking 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical ‘AND’ 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Mask: Example 1 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Mask: Example 2 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnet Mask Table: Class A 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Field 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Length Field 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Type of Service Field 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Length Field 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identification Field 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragmentation 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flags [D, M] 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment offset 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time-to-Live Field 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Field 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Header Checksum 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Header Description 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Address Field 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Address Field 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Option Field Variable 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding Variable 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Variable 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options Type Field 2–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Record Route 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Timestamp 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loose Source Routing 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strict Source Routing 2–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Address Resolution (ARP) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reverse Address Resolution Protocol (RARP) 2–52. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Control Message Protocol (ICMP) 2–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ICMP Message Types 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Echo Request/Echo Reply (0 and 8) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Destination Unreachable (3) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Quench (4) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redirect (5) 2–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Time Exceeded (11) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Problem (12) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TimeStamp Request/Reply (13, 14) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Request/Reply (15, 16) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Mask Request/Reply (17,18) 2–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Datagram 2–68. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4 Internet Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–1
Internet Protocol
Objectives
On completion of this chapter the student will be be able to:
� Describe the IP address format.
� State the reason for using subnets and describe the structure of sub–net masks.
� Describe the format of the IP datagram.
Issue 1 Revision 4Introduction
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–2
IntroductionTCP/IP is a family of protocols used for computer communications. The letters stand forTransmission Control Protocol / Internet Protocol, but the full name is rarely used. TCPand IP are both individual protocols that can be discussed separately, but they are notthe only two protocols used in the family. Often, a TCP/IP user does not use the TCPprotocol itself, but some other protocol from the family. To talk about using TCP/IP in thissituation is still proper, however, because the name applies generically to the use of anyprotocol in the family.
The TCP/IP suite includes protocols such as Internet protocol (IP), Address ResolutionProtocol (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 numerousothers. An understanding of all the protocols in the family is not a prerequisite to knowinghow a network works. This section concentrates on the IP and ARP protocols. Thisfocus, coupled with a minimal discussion of a particular link protocol (Ethernet), illustrateshow 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 nothave to be connected to the same wire (LAN). IP is a network protocol and providesaddressing information to allow routers to forward datagrams to the final destination. IPprovides for fragmentation if required to allow data to traverse networks having differentmaximum size packets. IP provides an ‘unreliable’ service, meaning that it does notguarantee the delivery of datagrams. If a datagram gets lost or arrives out of sequence, itis up to higher layer protocols to detect and retransmit.
To have a basic understanding of how information travels across a routed network, it isonly necessary to understand the answers to the following six questions:
1. What is the format of an address in this protocol?
2. How do devices get an address?
3. How is the address mapped onto a physical address?
4. How does an end node find a router?
5. How do routers learn the topology of the network?
6. How do users find services on the network?
Issue 1 Revision 4 Introduction
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–3
Introduction
CP09_2_1
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?
Issue 1 Revision 4Address Format
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–4
Address Format
Class A, B, C
To ensure that all hosts have a unique identifier, a 32-bit integer is used for each IPaddress. Three different address classes are defined to allow for the different sizes ofnetworks 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 isintended for use with a different size network. The class to which an address belongs canbe determined by looking at the first 4 bits of the first octet of the address. According tothe class, the remaining three octets may specify a network identifier (netid) and/or ahost identifier (hostid).
Class A addresses are used by networks that have a large number of attached hosts andclass C addresses provide lots of networks with a small number of hosts to be connectedto the internet.
To make it easier to work with IP addresses, the 32 bits are broken into 4 octets. Theseare converted into their equivalent decimal form with a dot between each. This is knownas dotted decimal. e.g.
10000000 00000011 00000010 00000011 = 128.3.2.3
Note: Class A addresses will have the first octet in the range: 1 – 126
Class B addresses will have the first octet in the range: 128 – 191
Class C addresses will have the first octet in the range: 192 – 223
Issue 1 Revision 4 Address Format
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–5
Address Format (A, B, C)
CP09_2_2
Class A1-126
Class B128-191
Class C192-223
0 Net ID Host ID
OCTET 4OCTET 1 OCTET 2 OCTET 3
OCTET 4OCTET 1 OCTET 2 OCTET 3
Host ID
110 Net ID Host ID
OCTET 4OCTET 1 OCTET 2 OCTET 3
10 Net ID
Issue 1 Revision 4Class D, E
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–6
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 areco-operating in some way, to arrange for network transmissions to be sent to allmembers 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.
Issue 1 Revision 4 Class D, E
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–7
Address Format (D, E)
CP09_2_3
ClassD223–239 1110 Multicast Address
OCTET 4OCTET 1 OCTET 2 OCTET 3
ClassE240–254 Host ID
OCTET 4OCTET 1 OCTET 2 OCTET 3
1111 Reserved for Future Use
Issue 1 Revision 4Example Addresses
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–8
Example AddressesClass 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 ‘1’s or all ‘0’s 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.
Issue 1 Revision 4 Example Addresses
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–9
Example Addresses
Network Net ID First Host Last HostFirst A 1.0.0.0 1.0.0.1 1.255.255.254
Last A 126.0.0.0 126.0.0.1 126.255.255.254
First B 128.0.0.0 128.0.0.1 128.255.255.254
Last B 191.255.0.0 191.255.0.1 191.255.255.254
First C 192.0.0.0 192.0.0.1 192.255.255.254
Last C 223.255.255.0 223.255.255.1 223.255.255.254
Issue 1 Revision 4Reserved Addresses
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–10
Reserved AddressesSome addresses within the class parameters are reserved for particular functions, andshould not be assigned to networks or hosts.
Network or host IDs of all ‘1’s or all ‘0’s are reserved along with the network id of127.0.0.0 or any network above 223.
There are some special case addresses which the Internet is required to filter out andthus will not go into the ‘Big Wide World’. These are:-
Network 10.0.0.0
Network 172.16.0.0
Network 192.168.255.0
Issue 1 Revision 4 Reserved Addresses
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–11
Reserved Addresses
CP09_2_5
Net ID Host ID
Internal Loopback127
0s
0s
0s
1s 1s
Valid 1s
This Host
Broadcast
Directed Broadcast
Issue 1 Revision 4Reserved Address Examples
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–12
Reserved Address ExamplesNetwork ID 127 is reserved for Internal loopback tests. This provides a confidence test ofthe protocol stack downwards to the IP network level. To test your own local host youshould always be able to ‘ping’ 127.0.0.1
All four octets with a value of all ‘0’s means that the host does not know its host ID nor towhich network it belongs. The host could also be in a situation where it knows its host IDbut 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 ‘1’s is a broadcast address to all hosts on my network.
All host address bits with a value of all ‘1’s is a broadcast address to all host in theadvertised network.
Issue 1 Revision 4 Reserved Address Examples
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–13
Reserved Address Examples
127 0 0 1
0 0 0 0
150 1 255 255
255 255 255 255
Local Loopback Test
What is my address?
Broadcast all Hostson my Network
Broadcast all Hostson Network 150.1.0.0
CP09_2_5b
Issue 1 Revision 4Subnets
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–14
SubnetsAlthough this basic structure is adequate for most addressing purposes, the introductionof 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 onthe site would have to participate in the overall internet routing function. The efficiency ofany routing scheme is strongly influenced by the number of routing nodes that make upthe internet. The concept of subnets has been introduced to de-couple the routersassociated with a single site from the overall internet routing function. Essentially, insteadof each LAN associated with a site having its own netid, only the site is allocated aninternet 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 toa complete site rather than to a single network. Hence, since only a single gatewayattached to a local site network performs internet-wide routing, the netid is considered asthe internet part. For a single netid, with a number of associated subnetworks, the hostidpart consists of two subfields: a subnetid part and a local hostid part. Because thesehave only local significance they are known as the local part.
Normally, organisations building their own intranet also want to be connected to theInternet. The Internet Network Information Centre (InterNIC) assigns network numbers toapplicants and ensures that each network number is globally unique. Sometimes, whenan organisation connects to the Internet through an Internet Service Provider (ISP) theISP provides the network number. In addition, many large organisations have internalnetwork administrators in charge of assigning IP addresses to individual users within thecompany. Most IP devices require manual configuration. The person installing the devicemust obtain a unique and correct IP address and type it in, usually along with otherinformation such as IP broadcast address, subnet mask and default gateway address.
Issue 1 Revision 4 Subnets
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–15
Subnets
CPO6_2_6
SubnetGateway
IP Gateway
Internet
All traffic to128.3.0.0
Subnet 128.3.2.0
128.3.2.1 128.3.2.2
Subnet 128.3.4.0 Subnet 128.3.3.0
128.3.4.1 128.3.4.2 128.3.3.1 128.3.3.2
Issue 1 Revision 4Default Subnet Masks
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–16
Default Subnet MasksIf it is not required that you use subnetting, then a default subnet mask must beconfigured in each network device for the type of address class being used.
Remember that subnet masks have all ‘1’s in the network portion of the address and ‘1’sand ‘0’s in the subnet and host portion.
Then, if no subnet is required, the default subnet mask is simply all ‘1’s in the net ID andall ‘0’s in the host ID.
Issue 1 Revision 4 Default Subnet Masks
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–17
Default Subnet Masks
CP09_2_7
255 0 0 0
255 255 0 0
255 255 255 0
Class A
Class B
Class C
Issue 1 Revision 4Subnet Masking
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–18
Subnet MaskingBecause of the possibly wide range of subnets associated with different site networks, noattempt 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 iskept by the internet gateway and routers at the site.
The subnet mask is obtained by placing ‘1’s into the network and subnet portions of theaddress, and ‘0’s into the remaining host portion of the address.
Hence, an address mask of 11111111 11111111 11111111 00000000 means that the first 3bytes 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 bewritten as 255.255.255.0.
On a class B network, the above mask would be interpreted as meaning that the first 2bytes are the internetid, the 3rd byte the subnetid and the 4th byte the hostid. Byteboundaries are normally used to simplify decoding but this is not essential. All hostsattached to the network have the same internet routing part but the presence of apossibly large number of subnets and associated routers is transparent to the internetgateways for routing purposes.
Issue 1 Revision 4 Subnet Masking
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–19
Subnet Masking
CP09_2_8
Class B128–191
OCTET 4OCTET 1 OCTET 2 OCTET 3
NET ID HOST ID
11111111 11111111 11111111 00000000
NET ID SUBNET ID HOST ID
Issue 1 Revision 4Logical ‘AND’
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–20
Logical ‘AND’A subnet mask is used by IP to determine whether an IP datagram is destined for a localhost or a host on another subnetwork. A process called ‘logical anding’ is used tocompare 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 associatedwith its IP address. Regardless whether an IP network is not connected to the Internet oranother network, each host will still require a subnet mask.
Issue 1 Revision 4 Logical ‘AND’
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–21
Logical ‘AND’
CP09_2_9
11111111 11111111 11111111 00000000
10000000 11110000 11000001 01100101
10000000 11110000 11000001 00000000
128 240 193 101
255 255 255 0
128 240 193 0
Net 128.240Host 193.101
Subnet Mask
Net 128.240SN 193(host 101)
Class B
Issue 1 Revision 4Subnet Mask: Example 1
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–22
Subnet Mask: Example 1The simplest way of defining subnet masks in your organisation is insert ‘1’s in thehighest bit positions of the host octet immediately adjacent to the net ID. It isrecommended 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;-
� 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 followingformula:-
(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 thetotal 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 hostsfor a non-subnetted Class B address.
Issue 1 Revision 4 Subnet Mask: Example 1
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–23
Subnet Mask: Example 1
CP09_2_10
11111111 11111111 11110000 00000000
Class B
Octet 1 Octet 4Octet 2 Octet 3
Net ID Host ID
Net ID SN Host ID
Issue 1 Revision 4Subnet Mask: Example 2
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–24
Subnet Mask: Example 2A 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 commonsubnet mask. If there are disagreements on the subnet mask, datagrams will not berouted 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
Issue 1 Revision 4 Subnet Mask: Example 2
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–25
Subnet Mask: Example 2
CP09_2_11
255 255 255 240
213 67 101 28
213 67 101 16 12
Class C Address
Applied Subnet Mask
Result with Mask applied
Net 213.67.101
Net Subnet 16Host 12
Issue 1 Revision 4Subnet Mask Table: Class A
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–26
Subnet Mask Table: Class AWhen planning an IP network, you may have to choose the number of subnet bitsrequired 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 of16 are given. Therefore, new subnets start at 16 and multiples thereof.
Issue 1 Revision 4 Subnet Mask Table: Class A
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–27
Subnet Mask Table: Class A
CP09_2_12
1 bit2 bits3 bits4 bits5 bits6 bits7 bits8 bits
9 bits10 bits11 bits12 bits13 bits14 bits15 bits16 bits
17 bits18 bits19 bits20 bits21 bits22 bits
255.128.0.0255.192.0.0255.224.0.0255.240.0.0255.248.0.0255.252.0.0255.254.0.0255.255.0.0
255.255.128.0255.255.192.0255.255.224.0255.255.240.0255.255.248.0255.255.252.0255.255.254.0255.255.255.0
255.255.255.128255.255.255.192255.255.255.224255.255.255.240255.255.255.248255.255.255.252
026
143062
126254
5101,0222,0464,0948,190
16,38232,76665,534
131,070262,142524,286
1,048,5742,097,1504,194,302
8,388,6084,194,3022,097,1501,048,574
524,286262,142131,070
65,534
32,76616,382
8,1904,0942,0461,022
510254
126623014
62
128643216
8421
128643216
8421
128643216
84
No. bits Subnet Mask No. of Networks No. of Hosts Chunks
Issue 1 Revision 4Subnet Mask Table: Class A
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–28
Issue 1 Revision 4 Subnet Mask Table: Class A
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–29
Subnet Mask Table: Class B and Class C
CP09_2_13
1 bit2 bits3 bits4 bits5 bits6 bits7 bits8 bits
9 bits10 bits11 bits12 bits13 bits14 bits
255.128.0.0255.192.0.0255.224.0.0255.240.0.0255.248.0.0255.252.0.0255.254.0.0255.255.0.0
255.255.128.0.0255.255.192.0.0255.255.224.0.0255.255.240.0.0255.255.248.0.0255.255.252.0.0
026
143062
126254
5101,0222,0464,0948,190
16,382
32,76616,382
8,1904,0942,0461,022
510254
126623014
62
128643216
8421
128643216
84
No. bits Subnet Mask No. of Networks No. of Hosts Chunks
1 bit2 bits3 bits4 bits5 bits6 bits7 bits
255.255.255.128255.255.255.192255.255.255.224255.255.255.240255.255.255.248255.255.255.252255.255.255.254
026
143062
126
126623014
620
128643216
842
No. bits Subnet Mask No. of Networks No. of Hosts Chunks
Class B
Class C
Issue 1 Revision 4Subnet Mask Table: Class A
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–30
IP DatagramAn 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, thisheader contains the source and destination IP addresses.
LAN Header
This header contains information for the underlying network. IP does not specify whattype of underlying network is used, however, for this course we will assume an EthernetLAN. Therefore, this header, amongst other things, will contain the MAC addresses ofthe immediate source and destination.
IP provides a Datagram service. It is a connectionless service and delivery of datagramsis on a ‘best-effort’ basis.
Issue 1 Revision 4 Subnet Mask Table: Class A
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–31
IP Datagram
LAN Header IP Header TCP Header User Data
MAC Addresses
IP Addresses
CP09_2_14
Issue 1 Revision 4IP Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–32
IP HeaderBefore considering the various functions and protocols associated with IP, the format ofthe IP data unit or datagram must be considered. The format for the datagram is shownopposite.
Its basic format is a header containing information for IP to use, and data that is onlyrelevant to the higher layer protocols.
The IP datagram header is a minimum of 20 octets long.
Issue 1 Revision 4 IP Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–33
IP Header
CP09_2_16
Version Header Length Type of Service
Total length
Identification
Fragment offset
Header checksum
Source IP address
Destination IP address
Options/Padding
Time–to–Live Protocol
0 D M
Data
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–34
IP Header Description
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 ofthe datagram header in multiples of 32-bit words. The minimum length is 5, whichequates to 20 octets. If the datagram contains options, these must be in multiples of 32bits. Any unused octets must be filled with padding.
CP09_2_17
Version Header Length Type of Service
Total length
Identification
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4 IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–35
IP Header Description
CP09_2_18
IP – Internet Protocol
Decode Status
Version
Type of Service
– –
4 Header Length: 20
Total Length
Identification
Fragment Control
Protocol
Checksum
Source Address
Time to Live
0 x 00
000 . . . . . = Routine Precedence
. . . 0 . . . . = Normal Delay
. . . . 0 . . . = Normal Throughput
. . . . . . 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
. . . . . 0 . . = Normal Reliability
Destination Address
No IP Options
6 (TCP)
0 x E60
128.52.46.32
137.28.1.2
(Checksum Good)
Issue 1 Revision 4Type of Service Field
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–36
Type of Service Field
8 bits
This field allows an application process to specify the preferred attributes associated withthe route and is, therefore, used by each gateway during route selection, if a number ofroutes are available. The options being Precedence, Delay, Throughput, Reliability andCost.
Precedence:
This provides a measure of the relative importance of the datagram. There are eightlevels of precedence and IP will attempt to provide preferential treatment for higher valuedatagrams. 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 encounteringdelay.
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 thenetwork administrator (money, hops etc).
CP09_2_19
Precedence D T R C O
1 2 3 4 5 6 7 8
Bits123
000001010011100101110111
Precedence ValuesMeaning
RoutinePriorityImmediateFlashFlash OverrideCriticalInternetwork ControlNetwork Control
Bit
45678
Meaning
DelayThroughputReliabilityCostNot Used
Normal DelayNormal ThroughputNormal ReliabilityNormal Cost
Low DelayHigh ThrougputHigh ReliabilityLow Cost
“1” value“0” value
Issue 1 Revision 4 Type of Service Field
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–37
IP Header Description
CP09_2_20
Version Header Length Type of Service
IP – Internet Protocol
Decode StatusVersion
Type of Service
– –4 Header Length: 20
Total LengthIdentification
Fragment Control
Protocol
Checksum
Source Address
Time to Live
0 x 00000 . . . . . = Routine Precedence. . . 0 . . . . = Normal Delay. . . . 0 . . . = Normal Throughput
. . . . . . 00 = Reserved522 bytes255980 x 40000 . . . . . . . . . . . . . . . = Reserved. 0 . . . . . . . . . . . . . . = May Fragment. . 0 . . . . . . . . . . . . . = Last Fragment. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes14 seconds/hops
. . . . . 0 . . = Normal Reliability
Destination Address
No IP Options
6 (TCP)
0 x E60
128.52.46.32
137.28.1.2
(Checksum Good)
Total Length
Identification
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–38
IP Header Description
Total LengthField
16 bits
This field defines the total length of the datagram including the header and the user dataportion. This is specified in octets. As the field is 16 bits in length then the maximumlength of a datagram is 65,535 octets.
IdentificationField
16 bits
User messages may be transferred across the internet in multiple datagrams, with theidentification field being used to allow a destination host to relate different datagrams tothe same user message. Although this number is unique to a datagram, if a messagehas been fragmented into several datagrams, then each of the datagrams which are partof 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 ofa sequence of datagrams.
CP09_2_21
Version Header Length Type of Service
Total length
Identification
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4 IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–39
IP Header Description
CP09_2_22
IP – Internet Protocol
Decode Status
Version
Type of Service
– –
4 Header Length: 20
Total Length
Identification
Fragment Control
Protocol
Checksum
Source Address
Time to Live
0 x 00
000 . . . . . = Routine Precedence
. . . 0 . . . . = Normal Delay
. . . . 0 . . . = Normal Throughput
. . . . . . 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
. . . . . 0 . . = Normal Reliability
Destination Address
No IP Options
6 (TCP)
0 x E60
128.52.46.32
137.28.1.2
(Checksum Good)
Issue 1 Revision 4IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–40
IP Header Description
Fragmentation
Fragmenting the datagram means dividing it up into several smaller datagrams. Theheader 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 onlyreassembled by the destination host. If, however, any one of the smaller datagrams thatmake up the complete message gets lost, then all of the received fragments belonging tothe same will be discarded.
Issue 1 Revision 4 IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–41
IP Header Description
CP09_2_23
Version Header Length Type of Service
0 D M
IP Header IP Data
IP HDR IP HDRFragment Fragment
O D M
1 2 3 4 16
Offset
Bit
1
2
3
Meaning
Reserved
D Flag
M Flag
”0” Value
Must be zero
May Fragment
Last Fragment
”1” Value
Don’t fragment
More fragments to come
Total Length
Identification
Fragment Offset
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4Flags [D, M]
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–42
Flags [D, M]
3 bits
The next 3 bits are known as flag bits of which only 2 are currently used. These are usedto 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 byintermediate gateways. The D-bit is set to ‘1’ indicates that the datagram should not befragmented.
The lowest bit, known as the “more fragments” or M bit, is used in the re-assemblyprocedure associated with user data transfer involving fragmented datagrams. The M-bitset 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 thedata contained in this fragment was situated in the original whole datagram. This field ismeasured in units of 8 octets. The last fragment may have padding in this field if theremaining data does not complete an 8 octet boundary.
Issue 1 Revision 4 Flags [D, M]
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–43
IP Fragmentation
CP09_2_25
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
First 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
Second Fragment
CPO9_2_25a
IP – Internet Protocol
Total Length
Identification
Fragment Control
100 bytes
35087
0 x 2014
0 . . . . . . . . . . . . . . . = Reserved
. 0 . . . . . . . . . . . . . . = May Fragment
. . . 0 0000 0001 0100 = Fragment Offset = 160 bytes
Third 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
Last Fragment
. . 1 . . . . . . . . . . . . . = More Fragments
Issue 1 Revision 4IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–44
IP Header Description
Time-to-LiveField
8 bits
This field is set by the sender and defines the maximum time, for which a datagram canbe in transit across the internet. More commonly, this defines the maximum number ofhops through the network that a datagram can make. Each router, via which thedatagram passes, will decrement by 1 the value. When the datagram encounters a routerwith 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 theTransport layer protocol being carried by this datagram, and thus to which layer 4 serviceIP is to pass the datagram.
E.g. ICMP 0116 110
TCP 0616 610
UDP 1116 1710
HeaderChecksum
16 bits
This resultant value from a polynomial calculation performed on the IP header aloneensures the integrity of the header values. As the checksum calculation must beperformed at each router and only the header values may change and not the data, thenby only checking the header reduces any delay of the datagram as it passes through therouter.
Issue 1 Revision 4 IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–45
IP Header Description
CP09_2_26
IP – Internet Protocol
Decode Status
Version
Type of Service
– –
4 Header Length: 20
Total Length
Identification
Fragment Control
Protocol
Checksum
Source Address
Time to Live
0 x 00
000 . . . . . = Routine Precedence
. . . 0 . . . . = Normal Delay
. . . . 0 . . . = Normal Throughput
. . . . . . 00 = Reserved
522 bytes
25598
0 x 00
0 . . . . . . . . . . . . . . . = Reserved
. 0 . . . . . . . . . . . . . . = May Fragment
. . 0 . . . . . . . . . . . . . = Last Fragment
. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes
14 seconds/hops
. . . . . 0 . . = Normal Reliability
Destination Address
No IP Options
6 (TCP)
0 x E60
128.52.46.32
137.28.1.2
(Checksum Good)
Issue 1 Revision 4IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–46
IP Header Description
Source AddressField
32 bits
The 32-bit IP address of the host sending the datagram.
DestinationAddress Field
32 bits
The 32-bit IP address of the destination host.
Option FieldVariable
This field is used in selected datagrams to carry additional information relating to one ormore of, security, source routing, route recording, stream identification and timestamp. Itis mainly used for network testing and de-bugging.
Padding Variable
This field represents ‘0’s which are used to ensure that the header ends on a 32-bitboundary.
Data Variable
This is the data being carried in the datagram and is passed to a higher layer protocol asspecified in the ‘protocol options’ field. The total length of the data field plus the header isa maximum of 65,535 octets.
Issue 1 Revision 4 IP Header Description
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–47
IP Header Description
CP09_2_27
IP – Internet Protocol
Decode Status
Version
Type of Service
– –
4 Header Length: 20
Total Length
Identification
Fragment Control
Protocol
Checksum
Source Address
Time to Live
0 x 00
000 . . . . . = Routine Precedence
. . . 0 . . . . = Normal Delay
. . . . 0 . . . = Normal Throughput
. . . . . . 00 = Reserved
522 bytes
25598
0 x 00
0 . . . . . . . . . . . . . . . = Reserved
. 0 . . . . . . . . . . . . . . = May Fragment
. . 0 . . . . . . . . . . . . . = Last Fragment
. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes
14 seconds/hops
. . . . . 0 . . = Normal Reliability
Destination Address
No IP Options
6 (TCP)
0 x E60
128.52.46.32
137.28.1.2
(Checksum Good)
Issue 1 Revision 4Options Type Field
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–48
Options Type FieldThe Options Field of the header is made up of the first octet describing the options typeparameters, 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) 1 octet Defines the option field.
Length Field 1 octet Shows the length in octets of the option data, type and length fields.
Options Data Field n octets 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 iffragmentation has occurred.
Class
Class“00” – 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.
Issue 1 Revision 4 Options Type Field
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–49
Options
CP09_2_28
1 2 3 4 5 6 7 8
Cf Class Options Number
1 2 3 4 5 6 7 8
Options Length Field
1 2 3 4 5 6 7 8
n Octets of Options Data
0000111
00000010000000
00000000010011100100000100001101001
End of Options ListNo OperationRecord RouteInternet TimestampSecurityLoose Source RoutingStrict Source Routing
Copy Flag Options Class Option Number Description
Option Field
Issue 1 Revision 4Options
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–50
Options
Record Route
This option causes each router to place its IP address into the option field as thedatagram travels through the network. This list is used to ascertain the path whichdatagrams are using to reach their destination.
InternetTimestamp
This option allows a datagram to be sent through the network and gather timestampsfrom 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 informationand prevent them from leaving a secure environment.
Loose SourceRouting
This is a management option that allows a datagram to be directed through a particularset of routers using a pre-defined list of IP addresses of routers that must be traversed insequence. A loose source route allows other routers to be used between those defined.
Strict SourceRouting
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.
Issue 1 Revision 4 Options
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–51
Options
CP09_2_28
1 2 3 4 5 6 7 8
Cf Class Options Number
1 2 3 4 5 6 7 8
Options Length Field
1 2 3 4 5 6 7 8
n Octets of Options Data
0000111
00000010000000
00000000010011100100000100001101001
End of Options ListNo OperationRecord RouteInternet TimestampSecurityLoose Source RoutingStrict Source Routing
Copy Flag Options Class Option Number Description
Option Field
Issue 1 Revision 4Address Resolution (ARP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–52
Address Resolution (ARP)On a LAN, devices communicate with each other using a hardware or Medium AccessControl (MAC) address. This is normally created at time of manufacture. It is a 6-byteaddress and is unique for every Network Interface Card (NIC). For instance, every deviceconnected to an Ethernet LAN has a NIC, and each NIC has a unique 6-byte MACaddress. Address Resolution Protocol (ARP) allows TCP/IP users to discover the MACaddress to which an IP datagram should be sent.
When an IP device wishes to initiate communications with another IP device, it firstcompares the destination network address with its own network address. The netmaskallows it to determine how many bytes have been allocated for the network address. Ifthe netids are the same, then the target device is on the same LAN. (Either on the samewire or separated by bridges.) The sending device sends an ARP request to all deviceson the LAN using the hardware broadcast address of all 1s. The ARP request containsthe sender’s 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 originator’s MACaddress 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 calledthe ARP cache. As long as the mapping is in the cache the devices can communicatewithout further ARP requests, thus reducing the amount of broadcast traffic. The timeoutfor the cache is normally configurable; anything from 30 seconds to hours. The shorterthe timeout period, the more broadcast traffic that may be generated. However, if longtimeouts are used and a device has its NIC changed, it cannot be contacted until theentry is updated.
Reverse AddressResolutionProtocol (RARP)
The IP and MAC addresses of a host are normally held in permanent storage and areread 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 toobtain its own IP address. On start-up, the host broadcasts a RARP request. The RARPrequest request is responded to by a server that holds all the IP to MAC addresses forthe 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 theIP datagam has to be sent to a router. A host is normally manually configured with the IPaddress of the default router. The sending host first discovers the MAC address of therouter by sending an ARP request to the default router’s IP address. On receiving areply, the host can now send an IP packet using the destination node’s IP address andthe MAC address of the default router. The router receives the packet and forwards it onthe appropriate route towards the destination network.
Issue 1 Revision 4 Address Resolution (ARP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–53
ARP Request
CP09_2_28a
Hardware Type
Protocol Type
Operation
Source Hardware Address
Source IP Address
Destination Hardware Address
Destination IP Address
HLEN PLEN
HLEN = MAC address lengthPLEN = IP address lengthOperation: 1. ARP Request
2. ARP response3. RARP request4. RARP response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4Address Resolution (ARP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–54
ARP Request
CP09_2_29
Decode Status
Frame Length
Destination Address
Source Address
Frame Format
Ethertype
Frame Checksum
––
64
FF–FF–FF–FF–FF–FF (Group, Locally Administered Address)
00–80–C7–49–56–96 (OUI = XIRCOM, Universally Administered Address)
Ethernet DIX V2
0x806 (ARP)
Good. Frame Check Sequence 00 00 00 00
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
0x01
00–80–C7–49–56–96
198.85.45.1
00–00–00–00–00–00
198.85.45.252
(Ethernet)
(DoD Internet Protocol)
(REQUEST)
ARP – Address Resolution Protocol
IEEE 802.3/Ethernet DIX V2 Header
Issue 1 Revision 4 Address Resolution (ARP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–55
ARP Reply
CP09_2_30
Decode Status
Frame Length
Destination Address
Source Address
Frame Format
Ethertype
Frame Checksum
––
64
00–80–C7–49–56–96 (OUI = ZIRCOM. Individual. Universally Administered Address)
00–00–C0–FD–50–00 (OUI = WESTERN DIGITAL. Universally Administered Address)
Ethernet DIX V2
0x806 (ARP)
Good. Frame Check Sequence 00 00 00 00
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
00–00–C0–FD–50–60
198.85.45.252
00–80–C7–49–56–96
198.85.45.1
(Ethernet)
(DoD Internet Protocol)
(REPLY)
ARP – Address Resolution Protocol
IEEE 802.3/Ethernet DIX V2 Header
Issue 1 Revision 4Internet Control Message Protocol (ICMP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–56
Internet Control Message Protocol (ICMP)Because IP is providing a connection-less system, then each gateway or host operatesindependently and IP itself does not assist the sender to test connectivity or learn aboutfailures. ICMP forms an integral part of IP and must be implemented by every IPmodule. It is used by both hosts and gateways to report errors and to provide informationabout 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 errorson 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 ofthat 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 8 bits Contains the error code for the datagram being reported – zero if not used
Checksum 16 bits Checksum algorithm for the ICMP header and message
Parameters 32 bits Variable, depending on the option
Data Variable contains more information. It will always includethe IP header and first 64 data bits of the datagram causing the problem. The reason for returning more thanthe 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.
CP09_2_31
IP Header
Checksum
Parameters/Data
(Dependent on message type)
Type Code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Issue 1 Revision 4 Internet Control Message Protocol (ICMP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–57
ICMP Decode
CP09_2_32
. . .
. . .
. . .Time to Live
ProtocolChecksum
Source AddressDestination Address
No IP Options
. . .
. . .
. . .32 seconds/hops1 (ICMP)0x7514 (Checksum Good)198.85.45.1198.85.39.1
Decode StatusTypeCode
ICMP ChecksumIdentifier
Sequence NumberEcho Data
––80 x 495C256768[32 byte(s) of data]
(Echo)
Checksum Good)
IP – Internet Protocol
ICMP – Internet Control Message Protocol
Issue 1 Revision 4ICMP Message Types
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–58
ICMP Message TypesThere are different types of ICMP message, and some of them have code numbers toprovide a more meaningful reason for the message.
EchoRequest/EchoReply (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 theoriginator as an Echo Reply. This routine is more commonly used as ‘ping’ .
DestinationUnreachable (3)
This message is returned if a router is unable to deliver a datagram. The values of thecode field help to provide a reason why a datagram failed to arrive at its destination.
Code 0 Network Unreachable
Code 1 Host Unreachable
Code 2 Protocol Unreachable
Code 3 Port Unreachable
Code 4 Fragmentation Blocked
Code 5 Source Route Failed
Code 6 Target Network Unknown
Code 7 Target Host Unknown
Code 8 Source Host Isolated
Code 9 Target Network Prohibited
Code 10 Target Host Prohibited
Code 11 Network Type-of-Service Problem
Code 12 Host Type-of-Service Problem
Code 13 Communication Administratively Prohibited
Source Quench(4)
This message will be sent if a gateway or host if it does not have enough resources toprocess incoming datagrams and is therefore forced to discard any more incomingdatagrams. This message provides an imperfect form of flow control. Whilst thestandards do not specify by how much a device ought slow down when it has received asource 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 isa better route to reach the destination. The Redirect message includes the IP address ofthe router which the host should use for future datagrams. This information is added tothe host’s routing table.
Issue 1 Revision 4 ICMP Message Types
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–59
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
Issue 1 Revision 4Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–60
Time Exceeded (11)This message is generated if either the Time to Live field has reached zero at a gatewayor a host has not been able to reassemble a fragmented datagram within its time limit.
Code 0 Time to Live Exceeded
Code 1 Time to Reassemble Exceeded
ParameterProblem (12)
This message is sent to indicate that there is a value in the IP header that could not beunderstood.
TimeStampRequest/Reply(13, 14)
This message is sent to obtain the time from the clock of a remote device. This could beused for performance statistics or clock synchronisation.
InformationRequest/Reply(15, 16)
This message is sent to obtain the network number that the requesting host is on if it isnot known.
Address MaskRequest/Reply(17,18)
This message is sent to allow a node to discover the subnet mask of the network towhich it is connected. The node may direct the request to a known address, probably arouter, or may broadcast the request to the network.
Issue 1 Revision 4 Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–61
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
Issue 1 Revision 4Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–62
ICMP – Echo Request (Ping)
CP09_2_35
IP – Internet Protocol
ICMP – Internet Control Message Protocol
Source Address
Destination Address
No IP Options
198.85.45.1
198.85.39.1
Decode Status
Type
Code
ICMP Checksum
Identifier
Sequence Number
Echo data
––
8
0
0x495C
256
768
[32 byte(s) of data]
(Echo)
(Checksum Good)
Issue 1 Revision 4 Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–63
ICMP – Echo Reply (Ping)
CP09_2_36
IP – Internet Protocol
ICMP – Internet Control Message Protocol
Source Address
Destination Address
No IP Options
198.85.39.1
198.85.45.1
Decode Status
Type
Code
ICMP Checksum
Identifier
Sequence Number
Echo data
––
8
0
0x515C
256
768
[32 byte(s) of data]
(Echo)
(Checksum Good)
Issue 1 Revision 4Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–64
ICMP – Destination Unreachable
CP09_2_37
IP – Internet Protocol
TypeCode
Source AddressDestination Address
No IP OptionsICMP – Internet Control Message Protocol
Decode Status
ICMP ChecksumOriginal IP Header is following:
Decode StatusVersion
Type of Service
Total LengthIdentification
Fragment Control
Time to Live
ChecksumProtocol
Source AddressDestination Address
No IP Options8 bytes of original datagram data
198.85.38.109198.85.45.57
– –33
(Destination Unreachable)(Port Unreachable)
0 x AB9B (Checksum Good)
– –40 x 00
Header Length: 20
000 . . . . . = Routine Precedence. . . 0 . . . . = Normal Delay. . . . 0 . . . = Normal Throughput. . . . . 0 . . = Normal Reliability. . . . . . 00 = Reserved522 bytes255980 x 40000 . . . . . . . . . . . . . . . = Reserved. 0 . . . . . . . . . . . . . . = May Fragment. . 0 . . . . . . . . . . . . . = Last Fragment. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes31 seconds/hops17 (UDP)0 x 9992 (Checksum Good)198.85.45.57198.85.38.109
00 8A 00 8A 00 DF 4F 6E
Issue 1 Revision 4 Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–65
ICMP – Destination Unreachable
CP09_2_38
IP – Internet Protocol
TypeCode
Source AddressDestination Address
No IP OptionsICMP – Internet Control Message Protocol
Decode Status
ICMP ChecksumOriginal IP Header is following:
Decode StatusVersion
Type of Service
Total LengthIdentification
Fragment Control
Time to Live
ChecksumProtocol
Source AddressDestination Address
No IP Options8 bytes of original datagram data
198.85.39.254198.85.39.1
– –34
(Destination Unreachable)(Fragmentation needed and DF bit set)
0 x 8E3A (Checksum Good)
– –40 x 00
Header Length: 20
000 . . . . . = Routine Precedence. . . 0 . . . . = Normal Delay. . . . 0 . . . = Normal Throughput. . . . . 0 . . = Normal Reliability. . . . . . 00 = Reserved1500 bytes15610 x 40000 . . . . . . . . . . . . . . . = Reserved. 1 . . . . . . . . . . . . . . = Don’t Fragment. . 0 . . . . . . . . . . . . . = Last Fragment. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes31 seconds/hops6 (TCP)0 x 6E5B (Checksum Good)198.85.39.1198.85.45.252
04 2C 00 14 04 82 64 19
Issue 1 Revision 4Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–66
ICMP – Redirect
CP09_2_39
IP – Internet Protocol
TypeCode
Source AddressDestination Address
No IP OptionsICMP – Internet Control Message Protocol
Decode Status
ICMP Checksum
Original IP Header is following:Decode Status
VersionType of Service
Total LengthIdentification
Fragment Control
Time to Live
ChecksumProtocol
Source AddressDestination Address
No IP Options8 bytes of original datagram data
198.85.45.252198.85.45.1
– –33
(Redirect)(Redirect datagrams for the Host)
0 x B14F (Checksum Good)
– –40 x 00
Header Length: 20
000 . . . . . = Routine Precedence. . . 0 . . . . = Normal Delay. . . . 0 . . . = Normal Throughput. . . . . 0 . . = Normal Reliability. . . . . . 00 = Reserved60 bytes171520 x 000 . . . . . . . . . . . . . . . = Reserved. 0 . . . . . . . . . . . . . . = May Fragment. . 0 . . . . . . . . . . . . . = Last Fragment. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes32 seconds/hops1 (ICMP)0 x 7714 (Checksum Good)198.85.45.1198.85.39.1
08 00 4B 5C 01 00 01 00
Gateway Internet Address 198.85.45.253
Issue 1 Revision 4 Time Exceeded (11)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 2–67
ICMP Time Exceed
CP09_2_40
IP – Internet Protocol
TypeCode
Source AddressDestination Address
No IP OptionsICMP – Internet Control Message Protocol
Decode Status
ICMP ChecksumOriginal IP Header is following:
Decode StatusVersion
Type of Service
Total LengthIdentification
Fragment Control
Time to Live
ChecksumProtocol
Source AddressDestination Address
No IP Options8 bytes of original datagram data
198.85.45.252198.85.45.1
– –110
(Time Exceeded)(Time to live exceeded in transit)
0 x A0A3 (Checksum Good)
– –40 x 00
Header Length: 20
000 . . . . . = Routine Precedence. . . 0 . . . . = Normal Delay. . . . 0 . . . = Normal Throughput. . . . . 0 . . = Normal Reliability. . . . . . 00 = Reserved60 bytes184320 x 000 . . . . . . . . . . . . . . . = Reserved. 0 . . . . . . . . . . . . . . = May Fragment. . 0 . . . . . . . . . . . . . = Last Fragment. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes0 seconds/hops1 (ICMP)0 x 8D14 (Checksum Good)198.85.45.1198.85.43.1
08 00 3F 5C 01 00 0D 00
Issue 1 Revision 4IP Datagram
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY2–68
IP DatagramIEEE 8 – 2.3/Ethernet DIX V2 Header
Decode Status – –Frame Length
Destination AddressSource Address
Frame FormatEthertype
Frame Checksum
6400–00–C0–FD–50–00 (OUI = WESTERN DIGITAL. Individual, Universally Administered Address)00–80–C7–49–56–96 (OUI = XIRCOM. Universally Administered Address)Ethernet DIX V20 x 800 (IP)Good Frame Check Sequence 00 00 00 00
IP – Internet ProtocolDecode Status – –
VersionType of Service
Total LengthIdentification
Fragment Control
40 x 00000 . . . . . = Routine Precedence. . . 0 . . . . = Normal Delay. . . . 0 . . . = Normal Throughput. . . . . 0 . . = Normal Reliability
Header Length: 20
. . . . . . 00 = Reserved44 bytes291840 x 40000 . . . . . . . . . . . . . . . = Reserved. 1 . . . . . . . . . . . . . . = Don’t Fragment. . 0 . . . . . . . . . . . . . = Last Fragment. . . 0 0000 0000 0000 = Fragment Offset = 0 bytes
Time to LiveProtocol
ChecksumSource Address
Destination AddressNo IP Options
32 seconds/hops6 (TCP)0 x 124 (Checksum Good)198.85.45.1198.85.45.252
TCP – Transmission Control ProtocolDecode Status – –
Source PortDestination Port
211050124304037785550 x 600110 . . . . = Header Length = 24
(FTP)
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
WindowChecksum
Urgent PointerKind
Option LengthMaximum Segment Size
327680 x 92570
(Checksum Good)
24
Sequence NumberAcknowledgement Number
Data Offset
Flags
(Unknown)
1460
(Maximum Segment Size)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 3
Routing Protocols
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 3Routing Protocols i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Protocols 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing and Routing Tables 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Architecture 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Protocols 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distance Vector Protocols 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link-State Protocols 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special Distance Vector Protocols 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Gateway to Gateway Protocol 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exterior Gateway Protocol 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interior Distance Vector Protocols 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RIP 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Gateway Routing Protocol (IGRP) 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Link State Protocols 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First (OSPF) 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Hierarchy 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 Routing Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–1
Routing Protocols
Objectives
On completion of this chapter the student will be able to:
� Describe the purpose and use of routing protocols.
Issue 1 Revision 4Routing and Routing Tables
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–2
Routing and Routing TablesFor routers to fulfil their role, they need to know which networks are reachable and howto get to them. To accomplish this routers store information about the topology of thenetwork. 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 sendpackets 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 ARPprotocol to find the MAC address of the destination node. When the cost is non-zero, therouting table indicates the IP address of the “next hop” router. The sending router makesan ARP request to the next hop router and encapsulates the datagram in a data link layerpacket addressed to the MAC address of the next router. When this router receives thepacket, it checks its routing table to determine if the packet can be delivered locally orhas to be sent to another router.
If the destination network (or default network) does not appear in the routing table, thenthe packet cannot be delivered and is dropped. This could happen for a variety ofreasons, 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 InternetControl 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 gettingthrough.
Routing tables can be set up manually or dynamically. Sometimes a combination of bothmethods is used. For manual configurations, the user has to enter the details in the fieldsof the routing table. This is the usual method of connecting over WAN links. Dynamicacquisition of routing tables is achieved by means of one or more routing protocols. InTCP/IP networks the most common protocol is Routing Information Protocol (RIP). RIP isa simple protocol that enables routers to tell each other what networks they know aboutand how far away they are. With this information, routers can assemble a table of everynetwork on an internet, enabling packets to be sent from any network to any othernetwork. However, this could entail excessively large tables, especially if connected tothe Internet, greatly increasing the processing time and slowing data throughput.Provision is made to clump many networks together in a default route represented by theIP address 0.0.0.0. Routers advertising connectivity to 0.0.0.0 are essentially saying, ifyou 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 efficientprotocols are being developed. Many networks are changing to Open Shortest Path First(OSPF) because there is less broadcast traffic and topology changes are more rapidlydisseminated.
Issue 1 Revision 4 Routing and Routing Tables
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–3
Routing and Routing Tables
CP09_3_1
Net 1128.10.0.0
Net 2192.52.7.0
Net 4200.15.22.0
Net 3137.103.0.0
Net 5130.200.0.0Net 6
222.222.222.0
NetworkNet 1Net 2Net 3Net 4Net 5Net 6
NetworkNet 1Net 2Net 3Net 4Net 5Net 6
Distance110010
Next Router222.222.222.1222.222.222.1
200.15.22.3
Distance221010
Next Router200.15.22.1200.15.22.1200.15.22.1
200.15.22.1
128.10.0.3 192.52.7.1
137.103.0.3200.15.22.1
200.15.22.3222.222.222.2
222.222.222.1
Router 1
Router 2 Router 3
NetworkNet 1Net 2Net 3Net 4Net 5Net 6
Distance001120
Next Router
222.222.222.2222.222.222.2222.222.222.2
Router 1
Router 2
Router 3
Issue 1 Revision 4Internet Architecture
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–4
Internet ArchitectureThe basis for all TCP/IP routing decisions is a table of routing information maintained byeach device. Entries in the table can be static, entered by the system administrator ordynamic, gathered from information exchanged between routing devices using a routingprotocol. Each entry in the table contains a destination and router address pair. For agiven destination address, the router address indicates the host to which an IP datagramshould be forwarded to reach that destination. IP routing specifies that IP datagramstravel through the internetworks one hop at a time. The entire route is not known at theoutset. Instead, at each stop, the next step is calculated by matching the destinationaddress within the datagram with an entry in the current node’s routing table.
Routing devices in the Internet have traditionally been called gateways but are informallycalled routers and are organised hierarchically. Some routers are used to moveinformation through one particular group of networks under the same administrativeauthority and control (such an entity is called an autonomous system). Routers usedwithin an autonomous system are called interior gateways. The combined Internet isconsidered as a core backbone network to which a number of autonomous systems areattached. Routers that move information between autonomous systems are calledexterior gateways.
If every gateway and host system contained a separate entry in its routing table for allother systems, the size of the routing tables and the amount of processing andtransmission capacity needed to maintain the tables would be excessive and, for theInternet, unmanageable. Instead, the total routing information is organised hierarchically.
� Hosts maintain sufficient routing information to forward datagrams to other hosts oran interior gateway(s) that is (are) attached to the same network.
� Interior gateways maintain sufficient routing information to forward datagrams tohosts or other interior gateways within the same autonomous system.
� Exterior gateways maintain sufficient routing information to forward datagramseither 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 isused by hosts to maintain their own tables, A number of interior gateway protocols areavailable, any one of which can be used within an autonomous system. An ExteriorGateway 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 adefault 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 wouldnormally be the gateway attached to the Internet.
Issue 1 Revision 4 Internet Architecture
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–5
Internet Architecture
CP09_3_2
ExteriorGateway
InteriorGateway
InteriorGateway
InteriorGateway
AS
AS
AS
IGP
IGP
IGP
IGP AS
EGP
EGP EGP
EGP
Core Network
CoreGateway
CoreGateway
CoreGateway
CoreGateway
Issue 1 Revision 4Routing Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–6
Routing ProtocolsIn order for routers to exchange routing information, they need to implement a commonrouting protocol. There are two general ways in which routing protocols can work; eitherby a router which advertises costs to all networks which it is aware or by advertising thecosts to use the links from that router. These two methods are known as Distance-vectorand Link-state protocols respectively.
Distance VectorProtocols
The way in which distance-vector protocols work is by all participating routers periodicallybroadcasting the state of their routing tables to all other routers. Each router receiving arouting table, compares the entries with its own routing table and decides whether it canreach the listed networks at a lower cost via this new route. If it can, then it over-writesthe old entry with the new one. Protocols differ in the criteria used to broadcast a routingtable, as some protocols broadcast after a set time interval (determined by anadministrator), and others only broadcast after a routing table change.
Link-StateProtocols
Most routing protocols of this type use the Shortest Path First (SPF) algorithm,developed in the late 1980s. Routers that implement an SPF protocol advertiseinformation 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 informationon to each of the other routers that it is connected to. In this way, this link informationfrom one original router is very quickly broadcast to every other router in the autonomoussystem. As each router learns the information about all other routers, it can build a mapof the autonomous system, containing each network, each router and each link with itsassociated “cost”. Routers then use this map to decide on the best way to routedatagrams towards their destination.
Issue 1 Revision 4 Routing Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–7
Routing Protocols
CP09_3_3
Router
Router
Network 3 at 5 hops Network 27 at 14 hops
Link 1, to net12, costs 12 Link 2, to router5, costs 4
Destination Next Hop MetricRouter 1
� Link State
� Distance Vector
Issue 1 Revision 4Special Distance Vector Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–8
Special Distance Vector ProtocolsDue to the different amounts of information that gateways need to exchange, dependanton their type, there are three types of routing protocol. Core gateways exchange routinginformation using a special protocol which was originally one known as GGP; exteriorgateways use a protocol known as EGP; and interior gateways can use any protocol theylike.
The Gateway toGatewayProtocol
This was the original distance-vector protocol used solely by the core gateways toexchange routing information about all networks. The type of information exchangedusing GGP is simply of the form (N,C) where N is a network reachable by the sendinggateway, and C is the cost to reach the network, in hops. A directly connected network, issaid to be at a distance of zero hops. Whenever a gateway becomes aware of a newnetwork, or a network becomes unreachable, or a routing table entry changes due toreceipt of new information from another GGP gateway, a gateway sends a GGPmessage to its GGP neighbours advertising this fact. By using this method, coregateways build routing tables that contain entries (routes to destination networks) thathave the lowest hop count.
Issue 1 Revision 4 Special Distance Vector Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–9
Gateway to Gateway Protocol (GGP)
CP09_3_4
Core Router
Core Router
Core Router
Core Router
Core Network GGPGGP
GGP
GGP
Issue 1 Revision 4Special Distance Vector Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–10
Exterior GatewayProtocol
EGP was the first interdomain reachability protocol to gain widespread acceptance in theInternet. However, because of its inherent weaknesses it is being replaced by the BorderGateway Protocol.
Although EGP is a dynamic routing protocol, it uses a very simple design. It does not usemetrics and therefore cannot make true intelligent routing decisions. EGP routingupdates contain network reachability information. In other words, they specify that certainnetworks are reachable through certain nodes.
EGP has three primary functions. First, routers running EGP establish a set ofneighbours. These neighbours are simply routers with which an EGP router wishes toshare reachability information; there is no implication of geographic proximity. Second,EGP routers poll their neighbours to check that they are still alive. Third, EGP routerssend update messages containing information about the reachability of networks withintheir ASs.
EGP does not interpret the distance metrics contained in routing update messages. EGPuses the field to indicate whether a path exists. The distance value can only be used tocompare paths if those paths exist wholly within a particular AS. For this reason, EGP ismore a reachability protocol than a true routing protocol. This restriction puts topologylimitations on the structure of the Internet. The EGP portion of the Internet must be a treestructure in which a core gateway is the root and there must be no loops between otherASs in the tree. This is a primary limitation of EGP.
Border GatewayProtocol
BGP is an inter-AS routing protocol developed for use in the Internet. Unlike EGP, BGPcan detect routing loops. Although designed as an inter-AS protocol, BGP can be usedboth within and between ASs. Two BGP neighbours communicating between ASs mustreside on the same physical network. BGP routers within the same AS communicate witheach other to ensure that they have a consistent view of the AS and to determine whichBGP 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 containsthe string of ASs through which the specified network may be reached. These updatemessages 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 requireperiodic refresh of the entire routing table. Instead, routers running BGP retain the latestversion of each peer routing table. Although BGP maintains a routing table with allfeasible paths to a particular network, it only advertises the primary path in its updatemessages.
The BGP metric is an arbitrary unit number specifying the degree of preference of aparticular path. These metrics are typically assigned by the network administratorthrough configuration files.
Issue 1 Revision 4 Special Distance Vector Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–11
EGP / BGP
CP09_3_5
Core Router Core Router
AS ASASAS
EGP EGP EGP EGP
Issue 1 Revision 4Interior Distance Vector Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–12
Interior Distance Vector ProtocolsBecause interior gateways, by definition, are administered by one authority, then thatauthority can decide on the routing protocol to be used. The first standarised interiorrouting 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 ultimatedestination, the next hop on the way to that destination and a metric. The metricindicates the distance, in number of hops, to the destination. RIP maintains only the bestroute to the destination. When new information provides a better route, this informationreplaces the old route information. Network topology changes are reflected in routingupdate messages. For example, when a router detects a link failure, it recalculates itsroutes and sends routing update messages. Each router receiving a routing updatemessage 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 theprotocol. These include that the protocol does not detect loops; it uses a hop countnumber of 16 to mean “infinity”, and therefore unreachable; and routing updatespropagate through the network slowly (known as slow convergence) and soinconsistencies can occur. These problems aside, a gateway that uses the hop-countmetric to determine routes may not always pick the “best” route available. To overcomethis last restriction, the much newer protocol, OSPF, looks at many properties ofparticular routes before deciding which is “best”.
RIP ensures that each router sends a complete copy of its routing table to all itsneighbouring routers every 30 seconds. If no update for a route is received, after 180seconds the route is declared invalid. After 300 seconds, if no update is received, theroute is removed from the table.
Interior GatewayRouting Protocol(IGRP)
IGRP is a routing protocol developed by Cisco to overcome the limitations of RIP. Inparticular, RIP’s 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 linkhad the same metric as a 2Mbps link.) The popularity of Cisco and the robustness ofIGRP have encouraged many organisations with large internetworks to replace RIP withIGRP.
IGRP uses a combination of metrics. Internetwork delay, bandwidth, reliability and loadare all factored into the routing decision. Network administrators can set the weightingfactors for each of these metrics. IGRP uses either the administrator set or the defaultweightings to automatically calculate optional routes.
IGRP sends updates every 90 seconds. A route is declared invalid if no update isreceived for 270 seconds and removed from the table after 630 seconds.
Issue 1 Revision 4 Interior Distance Vector Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–13
Interior Distance Vector Protocols
CP09_3_6
N3
N1
N2 N4
DestinationN1N2N3N4Default
Next StepRT1DirectRT3RT3RT1
Metric20133
Router 2
RT4
RT7
RT1
RT2 RT3 RT5 RT6
EGP
Issue 1 Revision 4Link State Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–14
Link State ProtocolsA gateway running a link-state protocol works by advertising the states of all of itslinks/interfaces to those gateways to which it is connected. These other gateways, in turnpass 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 eachlink and the address of the network or gateway at the remote end of each link. From thisinformation gathered from all other gateways, a gateway now draws a conceptual map ofthe system. Of course, once the information from each gateway has reached every othergateway, they all have a similar map from which they can obtain the “best” route for anydestination network.
Open ShortestPath First (OSPF)
OSPF was created for IP networks by the IGP working group of the Internet EngineeringTask 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 otherrouters in the autonomous system. Information on attached interfaces, metrics used andother variables are included in OSPF Link State Advertisements (LSAs). As OSPFrouters gather link state information, they use the SPF algorithm to calculate the shortestpath to each node. As a link state algorithm, OSPF contrasts with RIP and IGRP, whichare distance vector routing protocols.
RoutingHierarchy
OSPF can operate within a hierarchy. The largest entity within the hierarchy is theautonomous system (AS). OSPF is an interior gateway protocol although it is alsocapable 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 networksand attached hosts. Routers with multiple interfaces can participate in multiple areas.These routers, which are called area border routers, maintain separate topologicaldatabases for each area. The topological database is essentially an overall picture ofnetworks in relationship to routers. The topological database contains the collection ofLSAs received from all routers in the same area. Because routers within the same areashare the same information, they have identical topological databases. The term domainis sometimes used to describe a portion of the network in which all routers have identicaltopological databases. An area’s topology is invisible to entities outside the area. Bykeeping area topologies separate, OSPF passes less routing traffic than if the AS werenot partitioned.
An OSPF backbone is responsible for distributing information between areas. It consistsof all area border routers, networks not wholly contained in a single domain and theirattached routers. The figure opposite shows an internetwork with several areas (thebackbone is also an area). In this figure, Routers 4, 5, 6, 10, 11 and 12 make up thebackbone. If host H3 in Area 3 wishes to send a packet to host H2 in Area 2, the packetis 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 packetthrough 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 domaintopologies to the backbone.
Issue 1 Revision 4 Link State Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 3–15
Routing Hierarchy
Area 1
CP09_3_7
RT2
RT3
RT1
RT6
RT4
RT5
RT7
RT9
RT8
RT10
RT11
RT12
RT13
H2
Area 2
Area 3H3
Issue 1 Revision 4Link State Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY3–16
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 4
Transport Protocols
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 4Transport Protocols i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Protocols 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP Suite 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Datagram Protocol 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Transfer 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing Concepts 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host addressing 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Addressing 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process Addressing 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UDP Concepts 4–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UDP Format 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UDP Header 4–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmission Control Protocol 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP Segment 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Source and Destination Port 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence Number 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgement number 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Offset 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flags 4–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Window 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checksum 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Urgent Pointer 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointer 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Padding 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session 4–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session – 1 4–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session – 2 4–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Establishing a TCP Session – 3 4–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminating a TCP Session 4–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session 4–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating a TCP Session – Reset 4–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 Transport Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–1
Transport Protocols
Objectives
On completion of this chapter the student will be able to:
� 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.
Issue 1 Revision 4TCP/IP Suite
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–2
TCP/IP SuiteThe Host-to-host level (OSI Transport Layer) is the third of the four conceptual TCP/IPlevels. Its primary duty is to provide communication from one application program toanother. This is often called end-to-end communication. In the TCP/IP protocol suitethere are two main protocols provided at this level.
So far we have considered the frames of the datalink layer and the datagrams of the IPlayer. The IP data is encapsulated by the IP datagram, which is in turn encapsulated bythe frame.
At this layer, there are two separate options, UDP or TCP, dependant on the type ofservice required by the user’s application. One of these protocols is carried in the datafield of the IP datagram.
Once information has been transferred to the correct machine by IP, then it has to bepassed to the relevant application-level service. Multiplexing and de-multiplexing datafrom many applications to and from the IP layer and directing data to the correctapplication is one of the responsibilities of the transport layer.
User DatagramProtocol
The User Datagram Protocol provides a connectionless, unreliable service. It allows datato be transmitted to a machine or a group of machines without the need to establish aconnection. Single datagrams are sent to a remote node without the requirement forresponses to indicate that the datagram has arrived.
TransmissionControl Protocol
The Transmission Control Protocol provides a connection-oriented service. TCP has allthe features necessary to provide a reliable service between two devices. In achievingreliability, it adds a significant amount of overhead to manage acknowledgements, flowcontrol, timers and connection management facilities. It has more overhead than UDP interms of both the processing power required and the size of the network headers it uses.
MessageTransfer
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 completemessage transfer unit (MTU) that is transmitted/received by a host. At the networkinterface it comprises the LAN/WAN frame header, the information (user data) field andan associated trailer (end-of-frame marker plus CRC). The IP address is used to routedatagrams to a specific host. Also, the protocol field in the datagram header indicates theattached protocol within the host to which the user data part of the datagram should besent. This may be a protocol associated with IP or one of the transport protocols, UDP orTCP.
As can be seen, UDP and TCP can both support multiple applications. Hence for thetransport level to relay the user data to the appropriate application protocol, there is anaddress field in the header of each transport level PDU. In the TCP/IP suite this is knownas the (protocol) port address. With TCP/IP, the composite address of an applicationprotocol is the internet-wide IP address of the host plus the additional protocol portaddress.
Issue 1 Revision 4 TCP/IP Suite
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–3
Message Transfer
CP09_4_1
Diagram number
LAN/WAN
Header
IPHeader
TCP/UDPHeader User Data
LAN/WANTrailer
Network Physical Medium
IP
Telnet SMTP FTP TFTP SNMP DNS
UDPTCP
Protocol Stack
Message Format
Issue 1 Revision 4Addressing Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–4
Addressing ConceptsCommunication protocols in a layered hierarchy use a technique called multiplexing anddemultiplexing. We have already seen some of this when studying the IP layer. Whensending a message, the source computer includes extra bits that encode the messagetype, originating process, and protocols used. Eventually, all messages are placed intonetwork frames for transfer. The slide shows how software at the network interface layeruses the frame type field to decide how to handle the incoming frame. It is calleddemultiplexing the frame. In order that the choice can be made, software in the sourcemachine must have set the frame type field before transmission. The process thencontinues through the layers. The demultiplexed frames that contain the IP datagramsare passed to the IP module; the IP software extracts the datagram and demultiplexesfurther based on the protocol address. This is then passed to the next module, forexample TCP, which uses the process address to decide which application the data isdestined.
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.
ProtocolAddressing
In the IP header, which indicates the transport protocol being used. The 8-bit field in theIP header addresses the protocol being used above IP. Each protocol has a well-knownport number, which addresses it; for example TCP is port 6.
ProcessAddressing
In the transport protocol. Each process (application) that wants to communicate withanother process identifies itself to the transport protocols (TCP and UDP) by one or moreports. A port is a 16-bit number, used by the transport protocols to identify whichapplication protocol, or process, it must deliver incoming messages. Both UDP and TCPuse well-known numbers in the destination port field to indicate the service required.These standardised port numbers are called well-known ports and the standardapplications well-known services.
Issue 1 Revision 4 Addressing Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–5
Addressing Concepts
CP09_4_2
Network Physical Medium
IP
Telnet SMTP FTP TFTP SNMP DNS
UDPTCP
23 25 21 69 161 53
06 17
0806 0800
ARP RARP
122.45.2.5
00:08:F2:C5:28
8035
20
Issue 1 Revision 4UDP Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–6
UDP ConceptsIn the TCP/IP protocol suite, the User Datagram Protocol (UDP) provides one of themechanisms 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 machineto another. It provides:
� 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 canprocess them.
UDP is basically an application interface to IP. In addition to the user process, each UDPmessage contains both a destination port number and source port number, making itpossible for the UDP software to deliver the message to the correct recipient and for therecipient to send a reply.
UDP software accepts UDP datagrams from the IP software and demultiplexes thembased on the UDP port address. Other port numbers may be assigned using dynamicbinding. That is, where the target machine provides the correct port number for a callingapplication 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 ownheader to what it regards as user data from UDP. Finally the network interface layerembeds 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 removesone 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 tothe datagram that UDP passed to IP on the source machine. Also, the data that UDPdelivers to a user process on the receiving machine will be exactly the data that a userprocess passed to UDP on the sending machine.
Issue 1 Revision 4 UDP Concepts
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–7
UDP Concepts
CP09_4_3
Network Physical Medium
IP
TFTP SNMP DNS
UDP
69 161 53
17
0800
122.45.2.5
00:08:F2:C5:28
Issue 1 Revision 4UDP Format
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–8
UDP FormatEach UDP message is called a user datagram (or UDP datagram) and consists of twoparts:
� 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 theport to which replies should be addressed. This field is optional, if not used it should bezero.
Destination Port
16-bit UDP protocol port number. Specifies the unique port number of the destinationprocess.
Length
16-bits. Contains the count of octets in the UDP datagram, including the header anddata. 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 bythe sending entity. Remember that IP does not compute a checksum on the data portionof a datagram which means that the UDP checksum provides the only way to guaranteethat data arrived intact and should be used. The checksum is performed on a pseudoheader consisting of information obtained from the IP (source and destination IPaddresses, protocol number and UDP length), as well as the UDP header and data itself.
Standard applications are available using UDP, and these include:
� 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)
Issue 1 Revision 4 UDP Format
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–9
UDP Format
CPO9_4_4
Source Port
Destination Port
Length
Checksum
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Data
UDP = User Datagram Protocol
Decode StatusSource Port
Destination PortUDP Length
Checksum
––520520920x00
(RIP)(RIP)
(Checksum not sent)
Issue 1 Revision 4Transmission Control Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–10
Transmission Control ProtocolHere 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 applicationprotocols such as Telnet and FTP use TCP as the underlying protocol.
TCP is a connection-orientated, end-to-end, reliable protocol providing logicalconnections 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-levelprocesses. This principle is applied to TCP as for UDP.
Within TCP, a pair of sockets uniquely defines a connection. That is, by a pair ofprocesses, on the same or different systems that are exchanging information. These twoprocesses communicate with one another over the TCP connection.
The need for a service such as TCP becomes more meaningful when we consider theneeds of the application programs, which often need to send large volumes of databetween computers. Using an unreliable, connectionless delivery system becomestedious when transferring large volumes, since it requires that the programmers builderror detection and recovery into each application program. Therefore, one goal of thenetwork protocol research project was to find a general-purpose solution to the problemof providing a reliable stream delivery that all applications could use. Having such aprotocol helps to isolate application programs from the details of networking, and makesit possible to define a uniform interface that dictates how application programs make useof 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 touse it over a single network like Ethernet, as well as over the complex Internet.
Issue 1 Revision 4 Transmission Control Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–11
TCP Concepts
CP09_4_5
Network Physical Medium
IP
FTP
TCP
06
1025
IP
FTP
TCP
06
Reliable TCP Connection
Unreliable IP Datagram
21
Issue 1 Revision 4TCP Segment
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–12
TCP SegmentThe unit of transfer (or PDU) between the TCP modules on two machines is called asegment. Segments are exchanged:
� 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 foracknowledgement piggybacking. In practice piggybacking only occurs when the recipientdelays acknowledgements.
Each segment is divided into two parts:
� A header, called the TCP header
� The data from the application process
Issue 1 Revision 4 TCP Segment
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–13
TCP Segment
CPO9_4_6
Source Port
Destination Port
Sequence Number
Acknowledgement Number
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Acknowledgement Number
Window
Checksum
Urgent Pointer
Options/Padding
Data Offset 0 0 0 0 0 0 URG ACK PSH RST SYN FIN
Data
Sequence Number
Issue 1 Revision 4Source and Destination Port
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–14
Source and Destination Port(16 bits each)
A port is a 16-bit number and is used by TCP to identify a connection to the applicationlayer service. A port is unique within a host. Some port numbers are dynamicallyassigned 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 thedestination port identifies the application service that the datagram is intended for.
SequenceNumber
(32-bits)
In TCP, the sequence number is a count of octets within the data stream. The sequencenumber identifies the position in the overall data stream of the first octet of data in thesegment. The initial sequence number is generated randomly, and is synchronised duringconnection establishment.
Acknowledgement number
(32-bits)
The acknowledgement number acknowledges correct receipt of all octets up to theacknowledgement number and shows the number of the next octet that is expected to bereceived from the host.
TCP acknowledgements do not refer to received segments, instead they use the positionof 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 receiverexpects to receive.
Data Offset
(4-bits)
Contains an integer that specifies the number of 32-bit words in the TCP header. Itindicates 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 headervaries depending on the options selected.
Issue 1 Revision 4 Source and Destination Port
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–15
TCP Header Decode
CP09_4_7
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
Kind
Window
– –
21
1050
1243040
3778555
0 x 60
0110 . . . . = Header Length = 24
. . 0 . . . . . = No Urgent Pointer
. . . 1 . . . . = Acknowledgement
. . . . 0 . . . = No Push
. . . . . 0 . . = No Reset
. . . . . . 1 . = Synchronize Sequence Numbers
. . . . . . . 0 = No End of data flow from sender
32768
0 x 9257
0
(Checksum Good)
(FTP)
(Unknown)
0 x 12
Option Length
Maximum Segment Size
2
4
1460
(Maximum Segment Size)
Issue 1 Revision 4Flags
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–16
Flags(6 bits)
Some segments carry only an acknowledgement, some carry data, while others carryrequests to open and close connections. The flags (or pointers) are used to determinethe 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 inthe data field which is the end of urgent data. Urgent data is data, which should beprocessed 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 beforcibly closed.
SYN
Synchronise Flag. This is used at the beginning of a connection set-up between twonodes. At this stage the sequence numbers to be used for the rest of the dialogue arebeing synchronised.
FIN
Finish Flag. This is used to terminate a TCP connection. When one device has no moredata to transmit, it sends a segment with the FIN flag set. When both ends of aconnection have sent the FIN flag, then the connection is closed.
Issue 1 Revision 4 Flags
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–17
TCP Decode
CP09_4_8
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
Kind
Window
– –
21
1050
1243040
3778555
0 x 60
0110 . . . . = Header Length = 24
. . 0 . . . . . = No Urgent Pointer
. . . 1 . . . . = Acknowledgement
. . . . 0 . . . = No Push
. . . . . 0 . . = No Reset
. . . . . . 1 . = Synchronize Sequence Numbers
. . . . . . . 0 = No End of data flow from sender
32768
0 x 9257
0
(Checksum Good)
(FTP)
(Unknown)
0 x 12
Option Length
Maximum Segment Size
2
4
1460
(Maximum Segment Size)
Issue 1 Revision 4Flags
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–18
Window
(16 bits)
This is the number of octets that the source host will accept from the other end beforerequiring the other end to wait for an acknowledgement. The window is used forflow-control.
The window size increases and decreases in response to network congestion and to hostresource 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 computethe checksum, the TCP software on the sending machine prepends the same pseudoheader (pseudo IP header) that was seen for UDP. The pseudo header allows thereceiver to verify that the segment has reached its correct destination. This includes botha 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 notifywhatever 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 tonormal. 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 theTCP header. There is only one option normally used with TCP, which is the MaximumSegment Size and is used during the start of a TCP session, in order to advertise themaximum segment size which should be sent. The only currently used option is ‘Kind’.
Kind 2 Maximum Segment Size
1 No Operation
0 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.
Issue 1 Revision 4 Flags
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–19
TCP Decode
CP09_4_9
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
Kind
Window
– –
21
1050
1243040
3778555
0 x 60
0110 . . . . = Header Length = 24
. . 0 . . . . . = No Urgent Pointer
. . . 1 . . . . = Acknowledgement
. . . . 0 . . . = No Push
. . . . . 0 . . = No Reset
. . . . . . 1 . = Synchronize Sequence Numbers
. . . . . . . 0 = No End of data flow from sender
32768
0 x 9257
0
(Checksum Good)
(FTP)
(Unknown)
0 x 12
Option Length
Maximum Segment Size
2
4
1460
(Maximum Segment Size)
Issue 1 Revision 4Establishing a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–20
Establishing a TCP SessionBefore any data can be transferred, a connection has to be established between the twoprocesses. 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 itacknowledges 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 aconnection has been established.
The three-way handshake accomplishes two important tasks:
� It guarantees that both sides are ready to transfer data (and that they know thestate 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 machinechooses an initial sequence number that is used to identify octets in the stream it issending.
Issue 1 Revision 4 Establishing a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–21
Establishing a TCP Session
CP09_4_10
SYN
SYN, ACK
ACK
Host A Host B
Issue 1 Revision 4Establishing a TCP Session – 1
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–22
Establishing a TCP Session – 1At the beginning of every TCP session, the source and destination devices go through a3-step handshake process to establish the session.
Step 1
1. The source device (Client) initiating the session generates a random sequencenumber and sets the Acknowledgement number to zero.
2. The SYN flag is set to ‘1’ which indicates that the Client is requesting that thedestination (Server) is to synchronise onto this sequence number.
3. The Client uses the Option field to advertise the Maximum Segment size, whichthe Client will be able to receive from the Server.
Issue 1 Revision 4 Establishing a TCP Session – 1
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–23
Establishing a TCP Session – 1
CP09_4_11
A
B
C
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
Kind
Window
– –
1025
21
5419543
0
0 x 60
0110 . . . . = Header Length = 24
. . 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
8192
0 x D9FE
0
(Checksum Good)
(Unknown)
(FTP)
0 x 02
Option Length
Maximum Segment Size
2
4
1460
(Maximum Segment Size)
Issue 1 Revision 4Establishing a TCP Session – 2
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–24
Establishing a TCP Session – 2
Step 2
1. The Server generates a random sequence number and also acknowledges theClient’s TCP segment by setting the acknowledgement number to a value of theClient’s previous sequence number incremented by one.
2. The SYN flag is set to ‘1’ which indicates that the Server is requesting that theClient is to synchronise onto this sequence number.
The ACK flag is set to ‘1’ to indicate that the Server is returning a validacknowledgement to the Client.
3. The Server uses the Option field to advertise the Maximum Segment size, whichthe Server will be able to receive from the Client.
Issue 1 Revision 4 Establishing a TCP Session – 2
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–25
Establishing a TCP Session – 2
CP09_4_12
C
B
A
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
Kind
Window
– –
21
1025
21045782
5419544
0 x 60
0110 . . . . = Header Length = 24
. . 0 . . . . . = No Urgent Pointer
. . . 1 . . . . = Acknowledgement
. . . . 0 . . . = No Push
. . . . . 0 . . = No Reset
. . . . . . 1 . = Synchronize Sequence Numbers
. . . . . . . 0 = No End of data flow from sender
32768
0 x 56DE
0
(Checksum Good)
(FTP)
(Unknown)
0 x 12
Option Length
Maximum Segment Size
2
4
1442
(Maximum Segment Size)
Issue 1 Revision 4Establishing a TCP Session – 3
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–26
Establishing a TCP Session – 3
Step 3
1. The Client acknowledges the Server’s TCP segment by setting theacknowledgement number to a value of the Server’s previous sequence numberincremented by one.
2. The ACK flag is set to ‘1’ indicating that the Client is returning a validacknowledgement number to the Server.
Issue 1 Revision 4 Establishing a TCP Session – 3
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–27
Establishing a TCP Session – 3
CP09_4_13
B
A
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
Window
– –
1025
21
5419544
21045729
0 x 50
0101 . . . . = Header Length = 24
. . 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
8652
0 x CCBD
0
(Checksum Good)
(Unknown)
(FTP)
0 x 10
No TCP Options
Issue 1 Revision 4Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–28
Terminating a TCP SessionTerminating the connection is done implicitly by sending a TCP segment with the FIN flagset. This means that there is no more data to be transmitted in that direction. As theconnection is full duplex, with two independent data streams, the FIN segment onlycloses 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. Theconnection is ”deleted” once the data stream is closed in both directions.
This procedure ensures that both sides have received all outstanding data, and that bothsides agree to closure termination before actual termination.
One problem that could occur is that the FIN segment arrives at the other side before thelast data segment. TCP would accept the FIN, close the connection, and lose the lastsegment of data. To avoid this a sequence number is associated with each FIN, and thisnumber is designed such that it occurs after the last actual octet of transmitted data. Thismeans that the receiving TCP, upon getting the FIN, will wait if necessary for late-arrivingdata before closing the connection.
A more serious problem is the potential loss of segments and the potential presence ofobsolete segments. To overcome this TCP requires that each side explicitly acknowledgethe FIN segment from the other module, using an ACK, with the sequence number of theFIN to be acknowledged.
Issue 1 Revision 4 Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–29
Terminating a TCP Session
CP09_4_14
ACK
FIN, ACK
ACK
Host A Host B
FIN
DATA
DATA
Issue 1 Revision 4Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–30
Terminating aTCP Session
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 aClient.
Step 2 The Client acknowledges the TCP segment by setting theacknowledgement number to a value of the Server’s previous sequence numberincremented by one.
The Client acknowledges the 384 octets of FTP data and increments theacknowledgement number by one.
Issue 1 Revision 4 Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–31
Terminating a TCP Session
CP09_4_15
TCP – Transmission Control Protocol
FTP Data – File Transfer Protocol Data
SERVER
Decode StatusSource Port
Destination PortSequence Number
Acknowledgement NumberData Offset
Flags
- -201027211146115430890 x 500101 . . . . = Header Length = 20
(FTP Data)(Unknown)
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
WindowChecksum
Urgent Pointer 00 x EDA032768
(Checksum Good)
No TCP Options
Decode StatusData [384 bytes of data]
– –
CP09_4_16
TCP – Transmission Control ProtocolCLIENT
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
- -
1027
20
5453089
21114996
0 x 50
0101 . . . . = Header Length = 20
(Unknown)
(FTP Data)
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 0
0 x 3BIF
8652
(Checksum Good)
No TCP Options
Issue 1 Revision 4Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–32
Terminating aTCP Session
Step 3 The Client then sends a TCP segment to the Server with the FIN flag isset to ‘1’ (End of Data Flow from Sender).
Step 4 The Server acknowledges the TCP segment by setting theacknowledgement number to a value of the Client’s previous sequence numberincremented by one.
Issue 1 Revision 4 Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–33
Terminating a TCP Session
CP09_4_17
TCP – Transmission Control ProtocolCLIENT
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
No TCP Options
Window
- -
1027
20
5453089
21114996
0 x 50
0101 . . . . = Header Length = 20
. . 0 . . . . . = No Urgent Pointer
. . . 1 . . . . = Acknowledgement
. . . . 0 . . . = No Push
. . . . . 0 . . = No Reset
. . . . . . 0 . = No Synchronize Sequence Numbers
. . . . . . . 1 = End of data flow from sender
8652
0 x 3B1E
0
(Checksum Good)
(Unknown)
(FTP Data)
0 x 11
CP09_4_18
TCP – Transmission Control ProtocolSERVER
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
No TCP Options
Window
- -
20
1027
21114996
5453090
0 x 50
0101 . . . . = Header Length = 20
. . 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
32767
0 x DCEA
0
(Checksum Good)
(FTP Data)
(Unknown)
0 x 10
Issue 1 Revision 4Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–34
Terminating aTCP Session –Reset
Another method of terminating a TCP session is by sending a TCP segment with theReset 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 orwhen communications with the host at the other end of the session has been lost.
Issue 1 Revision 4 Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 4–35
Terminating a TCP Session – Reset
CP09_4_19
TCP – Transmission Control Protocol
Decode Status
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data Offset
Flags
Checksum
Urgent Pointer
No TCP Options
Window
- -
21
1025
21046141
5419651
0 x 50
0101 . . . . = Header Length = 20
. . 0 . . . . . = No Urgent Pointer
. . . 1 . . . . = Acknowledgement
. . . . 0 . . . = No Push
. . . . . 1 . . = Reset
. . . . . . 0 . = No Synchronize Sequence Numbers
. . . . . . . 0 = No End of data flow from sender
32661
0 x 6CE9
0
(Checksum Good)
(FTP)
(Unknown)
0 x 14
Issue 1 Revision 4Terminating a TCP Session
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY4–36
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 5
Application Protocols
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 5Application Protocols i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Protocols 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Layer 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client-Server Model 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Telnet 5–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Transfer Protocol (FTP) 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trivial File Transfer Protocol 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple Mail Transfer Protocol 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mail Transfer 5–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple Network Management Protocol 5–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 Application Protocols
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–1
Application Protocols
Objectives
On completion of this chapter the student will be able to describe the following applicationprotocols:
� Telnet.
� File Transfer Protocol (FTP)
� Simple Mail Transfer Protocol (SMTP)
� Simple Network Management Protocol (SNMP)
Issue 1 Revision 4Process Layer
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–2
Process LayerThe highest-level protocols of the TCP/IP suite are called application protocols (APs).They communicate with applications on other Internet hosts and provide the interfacesand facilities to the user. The most widely used higher level applications, which arestandardised and shipped with most TCP/IP implementations are:
� 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 UDPprovides an unreliable service, it is often easier to build applications on top of TCP,as are the three application protocols given above.
Client-ServerModel
TCP is a peer-to-peer, connection orientated protocol. The primary form of interactionbetween co-operating application programs is known as the client-server model.
� 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 sameor different systems. The server accepts requests that arrive over the network, performtheir service, and return the result to the requester (client).
Users usually invoke the client part of the application by building a request for a particularservice which then sends it to the server part by using TCP/IP as the transportmechanism.
The server is a program that starts its execution before an interaction begins with aclient. It receives requests from the clients and sends responses. A server can usuallydeal 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 clientsknow to which IP socket they must direct their requests. The client, however, allocates anarbitrary, unused, non-reserved port for its communication.
Those clients that wish to communicate with a server that does not have a well-knownport number must have another mechanism for learning which port their requests mustbe directed. The mechanism is usually achieved by employing some registration service.
Issue 1 Revision 4 Process Layer
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–3
Client-Server Model
Server
CP09_5_1
Client
ServerClient
Request to awell–knownport FTPTELNET etc.
Reponse toclient’s port
Issue 1 Revision 4Telnet
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–4
TelnetThe client Telnet protocol / process is accessed through the local operating system eitherby a user application or, more usually, by a user at a terminal. It provides services toenable a user to log on to the operating system of a remote machine, to initiate therunning of a program on that machine and then to interact with it as if the user terminalwere running on the same machine. All commands and data entered at the user terminalare passed by the local operating system to the client Telnet process which then passesthem, using the reliable stream service provided by TCP, to the correspondent serverTelnet. The latter issues the commands on behalf of the user, through the local operatingsystem, to the interactive process. Any data output by the interactive process is returnedin the same way for display on the client terminal.
The two Telnet protocols communicate with each other using commands that areencoded in a standard format known as “network virtual terminal” (NVT). The characterset used for the commands is ASCII. All input and output data relating to an interaction isalso transferred as ASCII. If this is different from the local character set being used, thecorresponding 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 themost significant bit is 0, all the characters have their normal meaning. An extra set ofcommand characters is defined by setting the most significant bit to 1.
Issue 1 Revision 4 Telnet
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–5
Telnet
CP09_5_2
Client
Operating System
Telnet
NetworkVirtual
Terminal
Client
Operating System
Telnet
NetworkVirtual
Terminal
23
Issue 1 Revision 4File Transfer Protocol (FTP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–6
File Transfer Protocol (FTP)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, thisgenerates much network traffic, and requires a reliable end-to-end transport protocol likeTCP.
A client FTP can be accessed either by a user at a terminal or by a user applicationprocess. Normally, a single client can support multiple users concurrently. It provideseach user with a similar set of services to those available with most file systems. Thus auser can list directories, create new files, read existing files, perform update operationson files, delete files and so on. Similarly, a server FTP can respond to requests frommultiple clients concurrently. On receipt of each request, the server FTP interacts with itslocal file system to carry out the request as if it had been generated locally.
Three file structures are supported; unstructured, structured and random access. Fourdata types are supported; 8-bit binary, variable length binary, ASCII and EBCDIC. TheFTP server accesses each file from the local file system and transfers it to the client FTPin an appropriate way according to its defined structure.
An unstructured file is sent as a transparent bit stream. Structured files consist of fixedsize records of a defined type. The contents of such files are normally transferred as astring of fixed-size blocks. Alternatively, the contents may be transferred in compressedform if each FTP protocol entity applies an agreed compression algorithm to the fieldcontents prior to transmission. Random access files are comprised of records of variablesize called pages. Each record page has a header that includes a length and type fieldand positional information to indicate the position of the page relative to the total filecontents. 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 orcontrol process on the well-known port. The master process creates a new process foreach new connection. The master process performs all the control functions associatedwith the session, including the log on with password procedure and the definition of thestructure and data types associated with the file(s) to be transferred. It also defineswhether compression is to be used and the compression algorithm. Sometimes anotherprocess is created to handle the actual data transfer. In such cases two transportconnections are established; one for exchanging control messages and the other fortransferring files. The NVT format is normally used for the exchange of control messagesexcept that option negotiation is not required.
Trivial FileTransfer Protocol
FTP is relatively complex since it contains all the features that are needed for a variety oftypes and compression algorithms. If two devices are on the same LAN, then there is noneed for this complexity. TFTP is intended primarily for LAN applications. It uses UDPrather than TCP because error rates on LANs are relatively low. To overcome thepossibility of corrupted messages a simple Idle RQ error control procedure isincorporated into the protocol. With Idle RQ only a single message block may be sentuntil either an acknowledgement is returned or a timeout occurs. This is adequatebecause of the short delay times associated with LANs. TFTP uses just four messagetypes that are also encoded in ASCII; Read request, Write request, Data Block andAcknowledgement. In common with FTP, a TFTP server can support multiple clienttransfer requests concurrently.
Issue 1 Revision 4 File Transfer Protocol (FTP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–7
File Transfer Protocol (FTP)
CP09_5_3
Client
21
SourceFile
FTP
Server
DestinationFile
FTP
20
SourceFile
Issue 1 Revision 4Simple Mail Transfer Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–8
Simple Mail Transfer ProtocolSMTP manages the transfer of mail from one host computer system to another. It is notresponsible for accepting mail from local users or for distributing received mail to itsintended recipients. These are the responsibility of the local mail system. SMTP interactswith the local mail system and not the user. It is masked from any mail transfers local tothe machine. Only when mail is to be sent to another machine or is received from aremote machine is SMTP scheduled to run. Normally, there is an input queue and anoutput queue at the interface between the local mail system and the client and serverparts of the SMTP. The client is concerned with initiating the transfer of mail to anothersystem while the server is concerned with receiving mail.
The local mail system retains a mailbox for each user into which the user can depositand retrieve mail. Each mailbox has a unique name that consists of a local part and aglobal 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 normallyconsists of a number of fields and the precise format varies for different types ofestablishment – education, government, military, etc.
There are two points to consider in the transfer of mail: the format of the mail and theSMTP used to transfer it from one machine to another. The mail format consists of aheader and a body which themselves consist of a number of lines of ASCII text with ablank 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 colonseparating the two. Some keywords are compulsory while others are optional. Theminimum header is:
TO: name of recipient
FROM: name of sender
Or
TO: name of recipient
REPLY TO: name to send reply to
A header can contain the following:
TO: name of recipient
FROM: name of sender
CC: copies to
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 takenacross the internet can be identified.
Issue 1 Revision 4 Simple Mail Transfer Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–9
Simple Mail Transfer Protocol (SMTP)
CP09_5_4
Operating System
Local Mail System
TCP/IP
ClientSMTP
ServerSMTP
Operating System
Local Mail System
TCP/IP
ClientSMTP
ServerSMTP
Operating System
Local Mail System
TCP/IP
ClientSMTP
ServerSMTP
Internetwork
Terminal Users Terminal Users Terminal Users
Issue 1 Revision 4Simple Mail Transfer Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–10
Mail Transfer
After an item of mail (message) has been created the local mail systems determinesfrom the name whether it is to be put in a mail box for local delivery or into the outputqueue ready for forwarding. Each message has:
� 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 genericform:
local_portion@domain_name
To send the mail, the client SMTP first ascertains the IP address of the destination hostfrom 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 transportconnection with the server SMTP in the destination host. Once a connection isestablished, the client initiates the transfer of the waiting mail to the server.
Transferring the mail involves the exchange of SMTP Protocol Data Units (PDUs) knownas commands. All commands are encoded as ASCII character strings and compriseeither a 3-digit number or a textual command. They are transferred over the establishedtransport connection using the TCP SEND / DELIVER user primitives.
Once a TCP connection has been established, the server SMTP sends command 220back to the client. The client responds with a HELO command and the identity of theclient machine. The server responds with the identity of the server machine. Thisresponse is used as a record of the mail transaction. The client then sends a MAILcommand followed by the FROM: line in the mail header. The server returns command250. The client then sends the RCPT command followed by the TO: line in the mailheader. This is again acknowledged by the 250 command. Subsequent lines in theheader are sent in the same way.
The client sends the DATA command to indicate the start of the mail contents. Theserver responds with a 354 command and the client sends the mail contents as asequence of lines terminated by a line with a single period The server acknowledgesreceipt by returning a 250 command. The mail transfer phase is terminated when theclient 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 additionalfunctions are available with some implementations. For example, if the intended recipientno 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 thereverse direction before clearing the transport connection. (This allows a chat line to beestablished).
Issue 1 Revision 4 Simple Mail Transfer Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–11
SMTP Command Exchange
CP09_5_5
TCP connection established
HELO: client name
MAIL FROM: sender’s name
RCPT TO: recipient’s name
DATA
Contents of the body partterminated by a line witha single period
QUIT
TCP connection cleared TCP connection cleared
221: destination closing
250: okay
354: ready for mail
250: okayor
Either550: recipient not here
250: okay
Server name
220: ready for mail
TCP connection established
Server SMTPClient SMTP
Issue 1 Revision 4Simple Network Management Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–12
Simple Network Management ProtocolSNMP is an application-layer protocol designed to facilitate the exchange ofmanagement information between network devices. By using SNMP data, such aspackets per second and error rates, network administrators can more easily managenetwork performance and find and solve network problems.
In SNMP, agents are modules that run on managed devices. Agents compile informationabout the managed devices and make this information available to network managementsystems (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 managementsoftware must be built in such a way as to minimise its own performance impact on themanaged 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 thenetwork. The NMS runs the network management applications that present managementinformation to users through a graphical user interface (GUI). All managed objects arecontained in the Management Information Base (MIB), which is essentially astandardised database of objects. (The current standard is MIB-II.) The GUI provides theuser with a range of services to interrogate the information in the MIB, to initiate the entryand collection of additional information and to initiate configuration changes.
SNMP is a simple request/response protocol. Four SNMP operations are defined:
� Get Retrieves the current value(s) of a variable in an agent..
� Get Next A traversal operation that retrieves the next value from a tableor list within an agent.
� Set Sets a variable within an agent.
� Trap Sent by the agent to asynchronously inform the NMS of some event.
The resulting messages – Protocol Data Units (PDUs) – generated by SNMP are allexchanged using UDP.
Two sets of addresses have to be configured on managed objects, Access Communitiesare the names and IP addresses of devices which are allowed access to the MIB in themanaged object. Typically, the user would configure the name (default: public) and the IPaddresses of the NMSs on the network. Trap communities are the names and addressesto which network events (alarms, port failures, etc.) are sent. Typically, this information isalso sent to the NMS.
Issue 1 Revision 4 Simple Network Management Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 5–13
SNMP
CP09_5_6
NetworkManagementApplication
User Interface
MIB
Agent
MIB
Agent
MIB
Agent
NMS
Managed device Managed device Managed device
Issue 1 Revision 4Simple Network Management Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY5–14
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 6
Domain Name Service
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 6Domain Name Service i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Domain Name Service 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 6–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domain Name System 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Structure and Administration 6–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domain Name Server 6–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message Format 6–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Name Server Hierarchy 6–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 The Domain Name Service
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 6–1
The Domain Name Service
Objectives
On completion of this chapter the student will be able to:
� Describe the purpose and function of a Domain Name Service.
Issue 1 Revision 4Domain Name System
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY6–2
Domain Name SystemIn TCP/IP the network address is a 32-bit integer which, in dotted decimal form, can beup to 12 decimal digits. The port number adds a further three digits (8 bits). Within thereal system environment users – people and application processes (APs) – are known bysymbolic names rather than addresses. In the same way that users of the telephonenetwork use directory services to find the number of a called party, so the directoryservices 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 otherreasons. Names isolate the users/APs from any knowledge of the network configurationwhich may, of course, change. A user AP should be able to be moved from one part ofthe network to another without other APs being aware of the move. Therefore, thedirectory service must provide not only an address resolution service, but also services toallow the contents of the directory to be changed and updated in a controlled way. Thebinding 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. Twointerrelated issues must be considered with any directory system. The first is thestructure of the names and how their assignment is administered; the second is how thevarious directory services are to be implemented.
Name StructureandAdministration
The Internet uses a hierarchical naming structure. This allows the assignment ofnumbers to be administered in a distributed fashion. There are a number of alternativepartitioning possibilities, known as organisations or domains, at the highest level in thehierarchy.
All hosts attached to a network or subnet of the Internet must be registered with one ofthese organisational domains. The choice of domain to be registered under is made tominimise the number of referrals. Hence, if a host is to be attached to an educationalinstitution, since it is likely that most network transactions will involve hosts that areattached to its own network or to those of other educational institutions, it is registeredwithin the EDU domain.
Each domain has an appropriate naming hierarchy. In the EDU domain the next level inthe hierarchy is the names of the different educational institutions, while in the COMdomain it is each (registered) commercial organisation. Each component of a domainname is known as a label. Labels are written with the local label on the left and the topdomain on the right, each separated by a period. Each label is simply the registereddomain name for that level in the hierarchy.
As indicated earlier, the adoption of a hierarchical structure means that names can beassigned locally rather than centrally. Thus, in the case of an educational institution, aslong as the institution is registered with the EDU domain name authority, the authorisedmanager at that institution can assign names as well as IP addresses to hosts that are tobe attached to that institution’s network.
Issue 1 Revision 4 Domain Name System
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 6–3
Domain Name Hierarchy
CP09_6_1
Root
com edu gov us
univx
univy
insta
deptcs
deptee
deptphy
HostA
HostB
HostC
Internet Top-Level Domains
DomainName
Meaning
COM Commercial organization
EDU Educational institution
GOV Government institution
MIL Military groups
NET Internet (network support centres)
ORG Other organizations
INT Internal organisations
XY Country codes (as defined by X.500)
Issue 1 Revision 4Domain Name Server
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY6–4
Domain Name ServerAssociated with each institution is a host that runs an application protocol/process knownas 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 isto be registered, the manager interactively enters the name and the IP address that havebeen assigned to that host into the DIB of the local domain name server. A user can theninitiate transactions that involve the Internet.
When initiating a network transaction involving a particular application protocol, a terminaluser or AP will use the name of the host machine on which the server is running whencommunicating with its local client protocol. Before this protocol can initiate the setting upof a transport connection with the server, it must ascertain the IP address of the host inwhich the server runs. In a TCP/IP suite all server protocols/processes are allocated afixed port number – the well-known port – so it is not necessary to maintain port numbersin the DIB.
To obtain the IP address of a named server, each host has a client protocol processknown as the name resolver. The sequence of events that the client protocol follows tocarry out the name-to-address mapping is as follows:
1. User issues request to client protocol.
2. Client protocol passes name to resolver.
3. Resolver passes name to DNS.
4. DNS returns IP address to resolver.
5. Resolver returns IP address to client protocol.
6. 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 recordtypes is shown opposite. The most common type of record is type A; host name and IPaddress. The next most common type is probably MX. It contains host names that act asmail exchangers for a given subdomain. The MX records enable a user to send e-mail tosomeone at a given subdomain without having to know the name of the mail gateway.Mail can be addressed to [email protected] without having to know that the name of themail server is SMTP-GW. Otherwise, mail would have to be addressed [email protected].
Type Meaning
A Host IP address
CNAME Canonnical domain name for an alias
HINFO CPU and OS information for a host
MINFO Mailbox or mail list information
MX Mail server name for the domain
NS Name server (that has authority) for the domain
PTR Pointer to domain name
SOA Start of Authority – multiple fields that specify whichparts of the naming hierarchy a server implements
Issue 1 Revision 4 Domain Name Server
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 6–5
Domain Name Server
ClientApplication
Protocol
NameResolver
NameResolver
ServerApplication
Protocol
TCP/IP TCP/IP TCP/IP
OS OS OS
ServerApplication
Protocol
User AP
MIB
Network Manager
Terminal User
IP addresses IP addressesNames
1 2 5
6 4 3
To/fromother DNS
Names
IP addresses
Server
CP09_6_2
Issue 1 Revision 4Message Format
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY6–6
Message FormatThe standard message format for the domain name server is shown opposite.
A resolver can have a number of messages outstanding at any time. The identificationfield is used to relate a subsequent response message to an earlier request message.The type of message – request/response – and additional qualifiers relating to theresponses are given in the parameters field. Responses also contain information aboutthe server(s) – its authority (the part of the naming hierarchy it implements) and IPaddress. In addition, each request/response message can contain multiplerequests/responses.
The query from the client contains the following information:
� 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 namecompletely (recursion requested).
DNS was designed to be protocol independent. The Class field in the query identifies theprotocol group of the record of interest. It is possible to have multiple records that havethe same data in the “name” field but different protocols. For TCP/IP users, the class fieldis IN for Internet.
Issue 1 Revision 4 Message Format
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 6–7
Message Format
CP09_6_3
Identification
Parameter
Number of questions
Number of answers
Number of authority fields
Number of additional fields
Questions Section (32 bit)
Answers Section (32 bit)
Additional information fields (32 bits)
1 16
Authority Fields (32 bits)
BitPosn
Meaning
1 0 = request, 1 = response
2–5 0000 = sandard, 0001 = inverse
6 1 = answer authoritative
7 1 = message truncated
8 1 = recursion desired (query)
9 1 – recursion available (response)
13–16 0000 = no error
0001 = format error
0010 = server failure
0011 = server unknown
Issue 1 Revision 4Name Server Hierarchy
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY6–8
Name Server HierarchyWhen a name server receives a query, it checks to see if the name is within thesubdomain for which it has authority. If so, it looks the name up in its database and sendsback the requested information, if present. If the name server cannot resolve the namecompletely, it checks to see what “action code” has been specified by the client. If theclient has requested recursive resolution then the name server must query anotherappropriate name server for the address. This is known as a referral and the aim is tominimise the number of referrals that are needed. To achieve this, the servers areorganised into a hierarchical structure.
Lower level name servers know the IP address of the higher-level server for the domainand a higher-level server associated with each organisation incorporates a tablecontaining the names and IP addresses of all the name servers registered with thatdomain hierarchy. On receipt of a request that it cannot resolve, the local domain nameserver creates and sends a referral request to the higher-level server. This checks thedomain name associated with the request and, assuming it is for another server withinthe same domain, uses the name to access the IP address from its own DIB. It returnsthis in a response message to the local server. The local server then uses this IPaddress 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 inanother domain. Eventually, referrals could arrive at the root server. In practice, theamount of information associated with the intermediate domain name servers is onlymodest since the number of entries in its referral table is determined by the number ofinstitutions 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 mostrecently referred names and their IP addresses together with the names and IPaddresses of the servers that provided the addresses. On receipt of a request for which itdoes 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 andputs the answer in the authority field together with the name and IP address of the serverthat provided the answer. This allows for the information being out-of-date. On receipt ofthe reply, the client can either accept the information or make a new request directly tothe name server indicated.
To ensure that the list of cached entries is reasonably up-to-date, a timeout period isassociated with each entry. The value of this period is given by the server that providedthe information. Hence, the timeout for every entry may be different. Once the timeoutexpires, the entry is removed and any new requests for that entry have to be referred.
Issue 1 Revision 4 Name Server Hierarchy
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 6–9
Request / Response
Root
com edu gov us
univx
univy
insta
deptcs
deptee
deptphy
HostA
HostB
HostZ
21
23
4
1
1–4 order ofrequest/response messages
CP09_6_4
Issue 1 Revision 4Name Server Hierarchy
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY6–10
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 7
IP Version 6
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 7IP Version 6 i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Version 6 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 7–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background 7–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Features 7–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPV4/IPV6 Headers 7–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing 7–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Representation 7–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Address 7–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unicast 7–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicast 7–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multicast Scope 7–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anycast 7–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Use 7–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extension Headers 7–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hop-by-Hop 7–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jumbo Payload Option 7–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Header 7–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fragment Header 7–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Destination Options Header 7–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing of Options 7–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication Header 7–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Encapsulating Security Payload Header 7–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security 7–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Authentication and Encryption 7–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Parameters Index 7–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Neighbour Discovery 7–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 IP Version 6
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–1
IP Version 6
Objectives
On completion of this chapter the student will be able to:
� Describe the main features of IP version 6.
� Describe the format of the IPv6 header
Issue 1 Revision 4Background
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–2
BackgroundIt is predicted that the current address space available in IPV4 will become exhaustedsometime between the years 2005 and 2015. This estimate is conservative and anotherexplosion in the growth of the Internet may happen any time as new applications aredeveloped. The addresses that do remain are largely of the wrong class. Many userswould 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 routingtables in the current IPV4 based Internet. IPv6 has been designed to provide forperformance 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 inapplications such as video conferencing and also in the Internet protocols themselves. Itprovides performance improvements over the use of broadcasting since many nodes willdecide to ignore the datagram at an earlier stage. Multicast support in IPV4 is deficient interms of limiting the scope of a multicast. It has also been slow to spread since itsimplementation has been optional. Multicast support will be available on all nodes runningIPV6. 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 introductionof 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 maincomponents 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 inIPV4. The lack of Internet Addresses may limit the ability of the Internet to growgeographically. However the lack of security features prevents growth into manyapplications areas related to Internet Commerce. It is possible to add new securityfeatures to IPV4 but this is likely to involve a conversion almost as painful as the move toIPV6. Security is an integral part of IPV6. Any implementation of IPV6 must includecertain security features. The security features provided are Authentication andEncryption.
Issue 1 Revision 4 Background
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–3
Background
Background� Lack of addresses, particularly class A and B� Size of routing tables
Main Features� Multicast� Real-time support� Plug-and-play� Security
Issue 1 Revision 4IPV4/IPV6 Headers
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–4
IPV4/IPV6 HeadersThe IPV6 datagram format is very different to that employed by IPV4. However acomparison of the two provides a useful introduction to the new format and the use of thevarious fields.
The version field is still present but most of the others have been replaced, renamed orsimply removed. Version will of course be set to 6 but this will not normally be used tode-multiplex IPV4 and IPV6. If both are being used on the same link then the Datalinklayer should differentiate between the two and pass the datagram to the appropriateversion of IP. For example, on Ethernet a content type of 86DD will be used to identifyIPV6 rather than the familiar 0800 type-code for IPV4.
The TTL (Time To Live) field has been renamed Hop Limit. This is a more accuratedescription of its use. The field was originally supposed to be incremented for eachsecond that the datagram was queued at a router but, in practice, routers simply addedone to it.
Since there may now be more than one IP header, the IPV4 Protocol field has beenreplaced by a next header field. The last Extension header in the chain, or the basicheader 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 bymeans of the Flow Label and Traffic Class fields.
The header has been made fixed format but more than one header may be used. Henceno IHL (Internet Header Length) field is required. It was the options field that made theIPV4 header of variable length. The new design makes use of Extension Headers tosupport facilities previously implemented through the use of options. Since there are nowno Options, no Padding is required.
The IPV4 header also includes a Total Length field ; this has been replaced by thePayload Length field. Since the header is now fixed length, it is unnecessary to include itin the calculation of length.
Several of the IPV4 header fields have been removed as a result of a change in the wayin which the size of IP datagrams is controlled. In IPV4, datagrams are fragmented if theyreach a network with an MTU that is less than the packet size. This process involves theuse of the Identification , Fragment Offset and Flags fields . In Ipv6 all networks mustcarry a payload of at least 1280 octets. If a host wishes to send packet’s which are largerthan this, then it should use MTU Discovery as defined in RFC1981.
Header Checksums have been dropped in IPV6. The underlying Datalink layer protocol isassumed to provide adequate error checking. Removal of this function from IPV6 meansthat the overhead of checking and updating the checksum has been removed from eachrouter along the path to the destination host.
Issue 1 Revision 4 IPV4/IPV6 Headers
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–5
IP4 / IP6 Headers
CPO9_7_3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Total LengthIdentification
Fragment offset
Header checksumSource IP address
Destination IP addressOptions/Padding
Data
Version Header Length Type of Service
O D MTime–to–Live Protocol
0 3 4 11 15 16 23 24 31
VER Traffic Class Flow LabelPayload Length Next Header Hop Limit
Source Address
Destination Address
Issue 1 Revision 4Addressing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–6
AddressingIPv6 uses 128 bits (16-octets) for addressing
AddressRepresentation
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 anaddress
e.g.
AEC8::5632:0:0:3456:23AE
One special form of address is created by prepending 96 zeros to an IPV4 address. Thiscould be written as
::192.0.0.1
Although address allocation will still be inefficient due to the hierarchical nature of theallocation scheme, even conservative estimates predict 1564 addresses available persquare meter of the earth’s surface. This large address space makes autoconfigurationpossible and the deep hierarchies that can be created provides the opportunity forsimplified routing and reduced routing table size.
Types of Address
� Unicast
� Multicast
� Anycast
Issue 1 Revision 4 Addressing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–7
Addressing
CPO9_7_4
Unicast·
Anycast·Multicast·
Issue 1 Revision 4Addressing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–8
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 ofthe mask to use is defined in a Subnet Prefix field that is carried in many messages. Theuse of the Subnet Prefix together with an IPV6 address provides a mechanism similar toCIDR (Classless Inter Domain Router).
Provider Based Unicast Address
Provider based unicast addresses are used for global communications. They are similarin 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 addressspace to subscribers. The SUBSCRIBER ID distinguishes among multiple subscribersattached to the Internet Service Provider identified by the PROVIDER ID. The SUBNETID identifies a specific physical link. There can be multiple subnets on the same physicallink. A specific subnet cannot span multiple physical links. The INTERFACE ID identifiesa single interface among the group of interfaces identified by the subnet prefix.
Registries
10000 Multi-national (IANA)
01000 RIP MNCC – Europe
11000 Internic – North America
10100 APNIC – Asia Specific
Issue 1 Revision 4 Addressing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–9
Unicast
CPO9_7_5
3
010
5 bits
Registry ID
16 bits
Provider ID
18 bits
Set to Zero
24 bits
Subscriber ID
8 bits
Set to Zero
16 bits
Subnet ID
48 bits
INTF ID
Issue 1 Revision 4Addressing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–10
Multicast
One sender sends to a group of receivers
This type of addressing is becoming more important all the time. The businessrequirements for many Internets now include the ability to transmit video, news, financialand audio data to groups of hosts. Multicast, together with Flows and ReservationProtocols, provide the necessary support for these applications. Multicast is also used byseveral of the protocols controlling the operation of the Internet and is used in multimediaapplications. Multicast support was introduced in IPV4 but its adoption has been veryslow. 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 theuse of multicast with IPV4 is the lack of any means of limiting the scope of a multicastother by the use of the TTL field. The scope field in IPV6 multicast addresses provides ahigher degree of control.
Issue 1 Revision 4 Addressing
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–11
Multicast
CP09_7_6
0 7 11 15 31
0xFF Flags Group IDScopeGroup ID ContinuedGroup ID ContinuedGroup ID Continued
0 0 0 T T = 0 PermanentT = 1 Transient
Flags
Issue 1 Revision 4Multicast Scope
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–12
Multicast ScopeMulticast groups can be either transient or permanently assigned. The fourth of the flagbits is used to differentiate between the two. The ‘permanently assigned’ addresses aredefined by the Internet Authorities, whereas the transient addresses are chosen atrandom by a directory tool. A check is then performed to ensure that the randomlychosen address is unique.
The meaning of a permanently assigned multicast address is independent of the scopevalue, whereas non-permanently assigned multicast addresses are meaningful onlywithin a given scope.
Solicited Node multicast addresses must be computed by each node for every Unicast orAnycast address assigned to it. If an Interface is assigned addresses for more than oneISP 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 aparticular ISP. It is necessary for a router to build a route for each anycast address that isactive. In the case of RIP this involves adding one entry to the routing table for eachanycast address. OSPF on the other hand relies upon a new link state record thatindicates that an anycast group member is connected to a router. Hosts use theneighbour discovery protocol to communicate anycast address information to their localrouters.
Anycast addresses are allocated from the Unicast Address Space. Two restrictions arecurrently in place on their use:
1. They must not be used as the source address of a packet.
2. They must only be assigned to routers.
One required Anycast address, which must be supported by all routers, has beenpre-defined. This is the Subnet Router Anycast Address. It consists of a 128-bit SubnetPrefix and 128 zero bits. Datagrams sent to this address will be delivered to one routeron the Subnet. It is likely to be used when a node needs to communicate with one of therouters in a Subnet e.g. in Mobile Communications.
Issue 1 Revision 4 Multicast Scope
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–13
Multicast Scope
CP09_7_7
0123–456–789–DEF
ReservedNode – LocalLink – LocalUnassignedSite LocalUnassignedOrganisation – LocalUnassignedGlobalReserved
Issue 1 Revision 4Multicast Scope
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–14
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 messageto itself.
Link Local Addresses support the implementation of automatic configurationmechanisms. Link Local Addresses are designed to be used on single link. They mustnot be forwarded by routers.
Site Local Addresses may be used by sites which are not connected to the Internet. Ifthey later connect to the Internet, the Site Local prefix can be replaced by a SubscriberPrefix and the remainder of the address left unchanged. Datagrams which use the SiteLocal address should not be forwarded outside of the originating site.
Issue 1 Revision 4 Multicast Scope
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–15
Local Use
CP09_7_8
10 bits
1111 1110 10
n bits
0
118 bits
Interface ID
10 bits
1111 1110 11
n bits
0
118 bits
Interface ID
m bits
Subnet ID
Link-Local-Use
Site-Local-Use
Issue 1 Revision 4Extension Headers
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–16
Extension HeadersIn the case of IPV6 six extension headers have been defined.
� Hop-by-Hop Options Header
� Routing Header
� Fragment Header
� Destination Options Header
� Authentication Header
� Encapsulating Security Payload Header
Issue 1 Revision 4 Extension Headers
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–17
Extension Headers
CP09_7_9
Hop–by–Hop
Routing (type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
·
·
·
·
·
·
Issue 1 Revision 4Extension Headers
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–18
Hop-by-Hop
By using the Hop-by-Hop Options Header, the options are processed by every nodealong a packet’s delivery path rather than only at those listed as destinations. If thisheader is present then it must immediately follow the IPV6 header.
Jumbo PayloadOption
The purpose of the Jumbo Payload option is to allow supercomputers to exchangepackets that are so large that their length cannot be encoded in the 16 bits provided inthe base IPV6 header. It should not be used if the length is less than 65535 octets or ifthe datagram contains a Fragment Header.
Issue 1 Revision 4 Extension Headers
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–19
Hop-by-Hop
CP09_7_10
Header ExtLengthNext Header
Options
Jumbo Payload Length
194 Opt Data Length = 4
Jumbo Payload Option
Issue 1 Revision 4Routing Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–20
Routing HeaderThe standard provides for various routing types with the header format differing from typeto type apart from the first four fields, which are fixed. Only Routing Type 0 is currentlyspecified.
Routing Type 0 provides a means of implementing Loose Source Routing. In Ipv4 thiswas implemented as an option. However, this caused performance degradation as thedatagrams were frequently placed in low priority queues and handled less efficiently inrouters than datagrams without options.
Source Routing is however important. For example it can be used to force the datagramto be routed via a particular ISP, perhaps in combination with Anycast addresses. TheRouting Extension Header is more efficient than the use of IPV4 options, because arouter only needs to process the header if the destination address of the datagram is oneof its own IP addresses.
The Hdr Ext Length field provides a means of determining the number of addresses inthe list. It actually contains a number less than or equal to 46, which, when divided bytwo, gives the number of addresses in the header. i.e. the length in 8 octet units of thepart of the header which contains the addresses.
The “Segments Left” field is set to the number of addresses in the list which still have tobe visited.
If a router has processed the Routing Header, then it must update the destinationaddress to contain the next address in the list before forwarding the datagram.
Issue 1 Revision 4 Routing Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–21
Routing Header – Type 0
CP09_7_11
Next HeaderHeader Ext
LengthRouting Type 0
Segments Left
Reserved Strict/Loose bit map
Address 1
Address 2
Address n
Issue 1 Revision 4Fragment Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–22
Fragment HeaderNo fragmentation of IPV6 datagrams takes place in the routers on the way to thedestination. It is however possible to fragment large IPV6 datagrams at the source nodeand insert a Fragment Header into each fragment. The fields present in the fragmentheader are almost identical to those used to control fragmentation in IPV4. Oneexception is that the Don’t Fragment bit is not required, as this is assumed for all IPV6datagrams. Fragments are routed independently of each other and reassembled at thefinal destination.
Issue 1 Revision 4 Fragment Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–23
Fragment Header
CP09_7_12
0 7 15 31Fragment OffsetReserved
Identification
Next Header16 28 29 30
MRES
Issue 1 Revision 4Destination Options Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–24
Destination Options HeaderThe Destination Options Header may occur more than once. The reason for this is that insome cases we may want the options to be processed only by the final destination. Inwhich case the destination options should be placed immediately before the upper layerheader. If however, we want the Destination Options to be processed by all destinationspresent in the Routing Header, in addition to the initial destination, then a DestinationOptions Header must be inserted before the Routing Header.
Each option definition consists of three fields. These give the type, data length and datathat represent the option. The first three bits of the Option Type field have specialsignificance.
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 thedatagram. Bit 3 of the Option Type field indicates whether or not the option data maychange on the way to the packet’s final destination. This is significant when anAuthentication Header is present. If the Option Data field can be changed then theAuthentication mechanism must treat the field as if it contains all zeros.
Processing ofOptions
Options must be processed strictly in the order in which they occur.
Issue 1 Revision 4 Destination Options Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–25
Destination Options Header
CP09_7_13
0 7 15 31Header Ext Len
Options
Next Header168
Option Type Option TypeOption Data Length
Option TypeOption Data Length
Option Data
8 bit identifier of the type of option8 bits used to show the length ofthe Option Data field (in octets)Variable length field containing theOption Type specific data
Issue 1 Revision 4Authentication Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–26
Authentication HeaderThe 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 extensionheaders. The Security Parameters Index identifies which key to use.
It is not possible to base the authentication data on all base-IPV6 header and extensionheader fields since some of these may be modified by routers along the way. In thebase-IPV6 header the hop count will change and so is treated as having a value of zeroas far as the authentication process is concerned. Within the Option Type field, there is abit (the C-bit), that identifies options containing data which may change en route andtherefore are also treated as having a value of zero. The Routing Header also presents aproblem to the authentication process, as the destination will change en route. Thesolution adopted here is to set the destination address in the base-IPV6 header and thevalues in the Routing Header to the values that they will contain upon reaching the finaldestination before performing the authentication calculation.
Issue 1 Revision 4 Authentication Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–27
Authentication Header
CP09_7_14
7 15 31
LengthSecurity Parameters Index
Next Header
168
Reserved
Authentication Data(Variable number of 32 Bit words)
Issue 1 Revision 4Encapsulating Security Payload Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–28
Encapsulating Security Payload HeaderAll of this header, except the Security Parameters Index, and all of any followingextension headers is encrypted before being sent. When the default “DES Cipher BlockChaining” is being used an initialisation vector is used to insert a random element into thedata. The Cipher Block Chaining ensures that this provides an input into latercalculations. DES works with 64-bit word boundaries, therefore, padding may be requiredat the end of the Payload Data. The last field in the decrypted message contains aPayload Type field, i.e. the next header. This could be a Destination Options header or ahigher-level protocol header.
Issue 1 Revision 4 Encapsulating Security Payload Header
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–29
Encapsulating Security Payload Header
CP09_7_15
Security Parameters Index
Initialisation Index(Variable Length)
Payload Data(Variable Length)
Padding
Reserved Padding Length Payload Type
Encrypted
0
Issue 1 Revision 4Security
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–30
SecurityThe new security features in IPV6 attempt to provide a means of ensuring that adatagram has arrived from an authorised source in an unaltered form and has not beenread along the way. These are, to a great extent treated as two separate, albeit relatedproblems and solutions are implemented through the use of two separate headers.These headers are known as the Authentication Header and Encapsulating SecurityHeaders respectively. The standards provide for a variety of Authentication andEncryption protocols to be implemented. They have, however, mandated one protocol ineach category. This ensures that all nodes are capable of providing securecommunication. MD5 has been chosen as the initial authentication protocol and DESCipher Block Chaining will provide the method of encryption.
Where Will the Security Features Be Employed?
� Hosts
� Mobile Hosts
� Between sites via the Internet
� Routing Protocols
� Autoconfiguration
Hosts requiring secure communication may run applications that request to sendencrypted datagrams and receive only datagrams that have already been authenticated.Support for this requires changes to the sockets-library or any othernetwork-programming interface which is in use.
Communication with mobile hosts can be made secure by establishing a secure tunnelthat connects to the home network’s firewall. The firewall may act as a proxy for themobile host during neighbour discovery. Communication from the home network will thenbe relayed to the mobile host via the firewall.
Secure tunnels will also be established between the firewalls of two organisations or twosites of the same organisation. These can be used to provide secure communication viathe Internet. Traffic between the two firewalls would be encapsulated within another IPV6datagram. Encryption and authentication can then be applied. The original IPV6 headerswill now cross the Internet in encrypted form. The authentication header will ensure thatthe data originated at the other firewall and has not been modified en route.
Routing protocols require secure communication to prevent attackers from insertingspurious routing information into the Internet.
The new Neighbour Discovery protocol also requires security features. This appliesparticularly to the situation where portable PCs are plugged into LANs.
Issue 1 Revision 4 Security
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–31
Security
CP09_7_16
Hosts
Mobile Hosts
Between sites via the Internet
Routing Protocols
Autoconfiguration
·
····
Issue 1 Revision 4Authentication and Encryption
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–32
Authentication and EncryptionA fundamental requirement of the authentication and encryption protocols is the use ofprivate keys. The sender and the receiver must agree on the key to use. Keys may bemanually distributed, obtained from a key server or agreed by means of a protocol. Keyservers present their own problems such as authentication between the node and the keyserver. The use of key servers is likely to be the best solution to the problem ofdistributing keys to the members of a multicast group.
SecurityParameters Index
Both authentication and encryption require that the value of a set of parameters is agreedbetween the senders and receivers before any exchange can occur. The use of a key isone 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. Allauthenticated 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 securitycontexts.
Issue 1 Revision 4 Authentication and Encryption
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–33
Authentication and Encryption
Issue 1 Revision 4Neighbour Discovery
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–34
Neighbour DiscoveryThe Neighbour Discovery Protocol (RFC2461) provides the facilities that were previouslyincorporated into ARP (address resolution protocol), Router Discovery Protocol andICMP redirect. It makes use of ICMP. Several ICMP message-types have been createdfor its use. The question of how to issue an ICMP request before you have obtained amapping of IP-to- link layer address is resolved by the use of multicast addresses. Themechanism for creating the multicast address to use will vary from media to media. ForEthernet networks, Xerox has reserved the prefix 0x3333 for use with IPV6. This prefix isconcatenated with the last 32 bits of the IPV6 multicast address to create the full linklayer 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 neighbourto 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 equivalentof IPV4 ARP.
The solicited node Multicast Address is formed by concentrating FF02:0:0:0:0:1 and thelast 32 bits of the nodes IPV6 address.
Issue 1 Revision 4 Neighbour Discovery
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 7–35
Neighbour Discovery
CP09_7_18
3333 (Hex) Low order 32 bits of IPV6 Multicst Address
0 15 16 17
Router List Cache
Prefix Cache
Destination Cache
Neighbour Cache
·
···
Issue 1 Revision 4Neighbour Discovery
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY7–36
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 8
Automatic Configuration
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 8Automatic Configuration i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automatic Configuration 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 8–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Address Resolution Protocol (RARP) 8–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Host Configuration Protocol 8–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Operation 8–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP Relay Agents 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Fields 8–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BOOTP 8–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of RARP, BOOTP/TFTP and DHCP 8–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4 Automatic Configuration
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–1
Automatic Configuration
Objectives
On completion of this chapter the student will be able to:
� Describe the function and concept of Automatic Configuration protocols.
Issue 1 Revision 4Reverse Address Resolution Protocol (RARP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–2
Reverse Address Resolution Protocol (RARP)RARP provides the opposite function to ARP in that it returns an IP address given a validhardware address. It is commonly used with diskless machines such as routers, printersor 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 serverprovides the correct IP address that is addressed to the client’s hardware address.
Issue 1 Revision 4 Reverse Address Resolution Protocol (RARP)
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–3
RARP
CP09_8_1
Client RARP Server
Hardware Address
IP Address
Issue 1 Revision 4Dynamic Host Configuration Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–4
Dynamic Host Configuration ProtocolThere are occasions when static IP addresses can prove restrictive. Users of Laptopcomputers who regularly travel between offices in different parts of the country may wantto connect up to a network. These network segments will be on different subnets. Thiswill 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. ACompany that is allocated a Class C address and has four hundred nodes clearly cannotgive an IP address to everyone in the company at the same time. It is however unlikelythat everyone in the company will need to be on the network at the same time due toholidays, visiting clients etc.
A solution to the above would be to allocate IP addresses only when needed. DHCPallows the network to do this. A user will lease an address for a specified period of timewhereupon the address is released and placed in a pool of addresses for other users tolease.
Issue 1 Revision 4 Dynamic Host Configuration Protocol
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–5
Dynamic Host Configuration Protocol
CP09_8_2
Client DHCP Server
DHCP Broadcast
Dynamic IP Address
Issue 1 Revision 4DHCP Operation
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–6
DHCP OperationDHCP is used to lease an IP address to a computer or other node. In order to do thisfour main steps are carried out.
1. DHCP Discover is a message that is broadcast into the network at both the IPlayer and the data link layer. It is addressed to UDP port 68. The datagram doesnot contain a valid return IP address as the node does not yet have one. The mostimportant piece of information is therefore the sender’s hardware address.
2. 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 originatingcomputer. This is sent to UDP port 67 and contains the IP address and hardwareaddress of the DHCP server. Other Information can include a valid IP subnet maskand the address of the default gateway.
3. The client can then select one of the offers. If several offers are received it willnormally select the first one. A DHCP request is then sent back to the DHCPserver. This request is broadcast but contains the IP address of the server thatissued the offer. The broadcast has the additional function of letting other serversknow that their offer was not accepted.
4. Lastly a DHCP Ack will acknowledge the acceptance of the offer. Also included inthe acknowledgement will be the time limit that the IP address is leased for.
Issue 1 Revision 4 DHCP Operation
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–7
DHCP Operation
CP09_8_3
DHCP Discover
DHCP Offer
DHCP Request
DHCP Acknowledgement
·
···
Issue 1 Revision 4DHCP Relay Agents
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–8
DHCP Relay AgentsIt would be uneconomical to have a DHCP on every single LAN to provide IP addressesamongst a pool of users. It is therefore common to share a DHCP server amongstseveral LANs.
This can lead to problems. DHCP messages are sent out using a broadcast hardwareaddress and this cannot travel across routers. The solution is to use another host on thenetwork as a proxy. It listens to the network for DHCP messages and forwards them tothe DHCP server using the server’s valid IP address. Return messages are subsequentlyforwarded on to the message originator.
Time Fields
Using DHCP, an address is leased from a pool of addresses for a period of time. When aDHCP request is acknowledged this time period is given to the host. The host canre–apply to keep its address. It does this initially half way through the lease time. If it isunsuccessful it will try again after 75 percent of its lease time. If it is unsuccessful it willtry for a final time 87.5 percent of the way through its lease time. After this it mustre–apply for a new IP address at the end of the lease period.
Issue 1 Revision 4 DHCP Relay Agents
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–9
DHCP Proxy
CP09_8_4
It is uneconomical to have a DHCP onevery LAN segment
·
The Proxy is configured with the IP addressof the DHCP server
·These can then be forwarded to a DHCPserver by a proxy
·DHCP proxies can be used to listen forDHCP broadcasts on a LAN segment
·
Issue 1 Revision 4BOOTP
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–10
BOOTPDiskless workstations need someway of finding out their IP address. They may also needto 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 andoperating system. They work in a similar manner to DHCP and use the same portnumbers.
A BOOTP request will hopefully be answered with a reply that includes details of an IPconfiguration and also the image of the operating system needed. TFTP will then beused to download the operating system. The IP addresses assigned are static.
Issue 1 Revision 4 BOOTP
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–11
BOOTP
CP09_8_5
Client BOOTP Server
BOOTP message
IP Configuration andOperating System Information
Issue 1 Revision 4Summary of RARP, BOOTP/TFTP and DHCP
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–12
Summary of RARP, BOOTP/TFTP and DHCP� 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 beused 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 fora certain period of time. It Can also provide a name for a boot up file.
Issue 1 Revision 4 Summary of RARP, BOOTP/TFTP and DHCP
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 8–13
Summary of RARP, BOOTP/TFTP and DHCP
CP09_8_6
RARP provides an IP address only given a validhardware address. This IP address is static.
·
DHCP provides dynamic IP addresses that are leasedfrom a pool of addresses for a certain period of time.
·
BOOTP provides a static IP configuration. It alsoprovides a name of a file to be used for its operatingsystem. TFTP is then used to download this file.
·
Issue 1 Revision 4Summary of RARP, BOOTP/TFTP and DHCP
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY8–14
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY i
Chapter 9
Glossary of Terms
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYii
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY iii
Chapter 9Glossary of Terms i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLYiv
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–1
10Base–T Technical name for ETHERNET implemented on twistedwire
3270 Reference to a 3270 Data Stream Supporting Entity
3770 Reference to Remote Job Entry
370/XA 370/ eXtended Architecture
5250 Reference to a 5250 Data Stream Supporting Entity
576 The minimum datagram size that ALL hosts, including routers, mustaccommodate
AAA Autonomous Administrative Area
AAI Administration Authority Identifier
AAL ATM Adaptation Layer
AARP AppleTalk Address Resolution Protocol
ABOM A–bis Operations and Maintenance
ACB Application Control Block
ACB Access Method Control Block
ACCS Automated Calling Card Service
ACD Automatic Call Distribution
ACDF Access Control Decision Function
ACE Access Control List Entry
ACF Access Control Field
ACF Advanced Communications Function
ACIA Access Control Inner Areas
ACID Atomicity, Consistency, Isolation, and Durability
ACK Positive Acknowledgement
ACL Access Control List
ACP Ancillary Control Process
ACS Access Control Store
ACSA Access Control Specific Area
ACSE Association Control Service Element
ACSP Access Control Specific Point
ACTLU Activate Logical Unit
ACTPU Activate Physical Unit
ACU Auto Calling Unit
AD Addendum Document to an OSI Standard
ADF Adapter Description File
ADMD Administrative Management Domain
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–2
ADP Adapter Control Block
ADP AppleTalk Data Stream Protocol
ADPCM Adaptive Differential Pulse Code Modulation
ADSP AppleTalk Data Stream Protocol
AE Application Entity
AEI Application Entity Invocation
AEP AppleTalk Echo Protocol
AET Application Entity Title
AF Auxiliary Facility
AFI Authority and Format Identifier
AFP AppleTalk Filing Protocol
AI Artificial Intelligence
AIFF Audio Interchange File Format
AIX Advanced Interactive Executive
ALS Application Layer Structure
ALU Application Layer User
AMI Alternating Mark Inversion
ANI Automatic Number Identification
ANS American National Standard
ANSI American National Standards Institute
AP Application Process
AP Argument Pointer
APB Alpha Primary Bootstrap
APD Avalanche Photodiode
APDU Application Protocol Data Unit
API Application Program Interface; Application Programming Interface
APIC Advanced Programming Interrupt Controller
APLI ACSE/Presentation Library Interface
APP Applications Portability Profile
APPC Advanced Peer–to–Peer Communications
APPC Advanced Program–to–Program Communications
APPL Application Program
APPN Advanced Peer–to–Peer Networking
APT Application Process Title
ARPA Advanced Research Projects Agency
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–3
ARP Address Resolution Protocol
ARQ Automatic Repeat Request
ARS Automatic Route Selection
AS/400 Application System/400
ASC Accredited Standard Committee
ASCII American Standard Code for Information Interchange
ASDC Abstract Service Definition Convention
ASE Application Service Element
ASN Abstract Syntax Notation
ASN.1 Abstract Syntax Notation One
ASO Application Service Object
ASP Abstract Service Primitive; AppleTalk Session Protocol
AST Asynchronous System Trap
ASTLVL Asynchronous System Trap Level
ASTSR Asynchronous System Trap Summary Register
ATM Asynchronous Transfer Mode; Abstract Text Method
ATP AppleTAlk Transaction Protocol
ATS Abstract Test Suite
AU Access Unit
AVA Attribute Value Assertion
B–ISDN Broadband ISDN
B8ZS Bipolar 8–Zeros Substitution
BACM Basic Access Control Model
BAR Base Address Register
BAS Basic Activity Subset
BASIC Beginners All–purpose Instruction Code
BB Begin Bracket
BBS Bulletin Board System
BC Begin Chain
BCC Block Check Character
BCS Basic Combined Subset
BCVT Basic Class Virtual Terminal
Bellcore Bell Communications Research, Inc.
BER Box Event Records
BER Bit Error Rate
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–4
GBP Border Gateway Protocol
BIB Backward Indicator Bit
BIS Bracket Initiation Stopped
BISUP Broadband ISUP
BITS Building Integrated Timing Systems
BITNET Because its Time Network
BIU Basic Information Unit
BMS Basic Mapping Support
BMU Basic Measurement Unit
BNN Boundary Network Node
BOC Bell Operating Company
BOM Beginning–of–Message
bps Bits Per Second
BRI Basic Rate Interface
BSC Binary Synchronous Communications
BSS Basic Synchronization Subset; Base Station Subsystem
BSSMAP Base Station Subsystem Mobile Application Part
BTAM Basic Telecommunications Access Method
BTU Basic Transmission Unit
CA Channel Adapter
CA Certification Authority
CAD Computer–aided design
CAE Common Applications Environment
CAF Channel Auxiliary Facility
CAI Computer–Assisted Instruction
CASE Common Application Service Elements
CATV Community Antenna Television
CBD Changeback Declaration
CBEMA Computer & Business Equipment Manufacturers Association
CCA Conceptual Communication Area
CCAF Call Control Agent Function
CCAF+ Call Control Agent Function Plus
CCB Connection Control Block
CCB Channel Control Block
CCIRN Coordinating Committee for Intercontinental Research Networking
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–5
CCIS Common Channel Interoffice Signaling
CCITT Consultative Committee for International Telephone & Telegraph
CCO Context Control Object
CCR Commitment, Concurrency, and Recovery
CCS Common Communications Support
CCS Common Channel Signaling
CCU Central Control Unit
CCU Communications Control Unit
CCW Channel Command Word
CD Countdown Counter
CD Committee Draft
CDF Configuration Dataflow
CDI Change Direction Indicator
CDRM Cross Domain Resource Manager
CDRSC Cross–Domain Resource
CDS Conceptual Data Storage
CDS Conceptual Data Store
CEBI Conditional End Bracket Indicator
CEI Connection Endpoint Identifier
CEN/ELEC Committee European de Normalization Electrotechnique
CEP Connection–endpoint
CEPT Conference of European Postal and Telecommunications Administrations
CESID Caller Emergency Service Identification
CF Control Function
CGM Computer Graphics Metafile
CHILL CCITT High–Level Language
CICS Customer Information Control System
CIDR Classless Inter–Domain Routing
CIGOS Canadian Interest Group on Open Systems
CIM Computer Integrated Manufacturing
CIS Card Informaiton Structure
CLI Connectionless Internetworking
CLIST Command List
CLNP Connectionless Network Protocol
CLNS Connectionless Network Service
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–6
CLSDST Close Destination
CLTP Connectionless Transport Protocol
CLTS Connectionless Transport Service
CMC Communications Management Configurations
CMIP Common Management Information Protocol
CMIS Common Management Information Service
CMIS Common Management Information Service
CMISE Common Management Information Service Element
CMOL CMIP Over Logical Link Control
CMOT CMIP Over TCP/IP
CMS Conversational Monitor System
CMT Connection Management
CN Composite Node
CNM Communication Network Management
CNMA Communication Network for Manufacturing Applications
CNMI Communication Network Management Interface
CNOS Change Number of Sessions
CNT Communications Name Table
CO Central Office
COCF Connection–Oriented Convergence Function
CODEC Coder/Decoder
COI Connection Oriented Internetworking
COM Continuation–of–Message DMPDU
CONF Confirm
CONS Connection Oriented Network Service
CORBA Common Object–Oriented Request Broker Architecture
COS Class–of–Service
COS Corporation for Open Systems
COTP Connection Oriented Transport Protocol
COTS Connection Oriented Transport Service
CP Control Point
CP Control Program
CPE Customer Premises Equipment
CPH Call Party Handling
CPF Control Program Facility
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–7
CPI Common Programming Interface
CPI–C Common Programming Interface with C Language
CPMS Control Point Management Services
CRACF Call–Related Radio Access Control Function
CRC Cyclical Redundancy Check
CRST Cluster–Route–Set–Test
CRT Cathode Ray Tube
CRV Call Reference Value
CSm Call Segment Model
CS–MUX Circuit Switching Multiplexer
CSMA/CA Carrier Sense Multiple Access with Collision Avoidance
CSMA/CD Carrier Sense Multiple Access with Collision Detection
CSP Communications Scanner Processor
CSN Card Select Number Register
CSNET Computer+Science Network
CSS Control, Signalling, and Status Store
CSU Channel Service Unit
CTC Channel–to–Channel
CTCA Channel–to–Channel Adaptor
CTCP Communication and Transport Control Program
CTS Clear–to–Send
CUA Channel Unit Address; Common User Access
CURACF Call Unrelated Service Function
CUT Control Unit Terminal
CVS Connection View State
CVT Communications Vector Table
DACD Directory Access Control Domain
DAD Draft Addendum
DAF Distributed Architecture Framework; Framework for DistributedApplications; Destination Address Field
DAP Directory Access Protocol
DAS Dual Attachment Station; Dynamically Assigned Sockets
DAT Dynamic Address Translation
dB Decibels
DCA Document Content Architecture
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–8
DCC Data Country Code
DCE Data Communications Equipment; Distributed Computing Environment;Data Circuit–Terminating Equipment; Distributed Computing Environment
DCS Defined Context Set
DDCMP Digital Data Communication Message Protocol
DDIM Device Driver Initialization Model
DDM Distributed Data Management
DDN Data Defense Network
DDP Datagram Delivery Protocol
DDS Digital Data Service
DES Data Encryption Standard
DFC Data Flow Control
DECNET Digital Equipment Equipment’s Network Architecture
DFI DSP Format Identifier
DFT Distributed Function Terminal
DHCP Dynamic Host Configuration Protocol
DH DMPDU Header
DIA Document Interchange Architecture
DIB Directory Information Base
DIS Draft International Standard
DISP Draft International Standardized Profile
DISP Directory Information Shadowing Protocol
DIT Directory Information Tree
DIU Distribution Interchange Unit
DL Distribution List
DLC Data Link Control; Data Link Connection
DLCEP Data Link Connection End–point
DLCI Data Link Connection Identifier
DLPDU Data Link Protocol Data Unit
DLS Data Link Service
DLSAP Data Link Service Access Point
DLSDU Data Link Service Data Unit
DLU Dependent Logical Unit
DMA Direct Memory Access
DMD Directory Management Domain
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–9
DMI Digital Multiplexed Interface; Definition of Management Information;Desktop Management Interface
DMO Domain Management Organization
DMPDU Derived MAC Protocol Data Unit
DMTF Desktop Management Task Force
DMUX Double Multiplexer
DN Distinguished Name
DNS Domain Name System
DNHR Dynamic Nonhierarchical Routing
DoD U.S. Department of Defense
DOP Directory Operational Binding Management Protocol
DOS Disk Operating System
DP Draft Proposal
DPG Dedicated Packet Group
DPI Dots–Per–Inch
DQDB Distributed Queue Dual Bus
DR Definite Response
DS Directory Services
DS3 Telephony classification of leased line speed
DS–n Digital Signaling Level n
DSA Directory Service Agent
DSAP Destination Service Access Point
DSD Data Structure Definition
DSE DSA Specific Entries
DSL Digital Subscriber Line
DSP Directory Service Protocol
DSP Domain Specific Part
DSS 1 Digital Subscriber Signaling System No. 1
DSTINIT Data Services Task Initialization
DSU Digital Services Unit
DSUN Distribution Services Unit Name
DT DMPDU Trailer
DTE Data Terminal Equipment
DTMF Dual–Tone Multifrequency
DTR Data Terminal Ready
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–10
DU Data Unit
DUP Data User Port
DUA Directory User Agent
DVMRP Distance Vector Multicast Routing Protocol
E.164 An ATM address format specified by the ITU–TS
E–Mail Electronic Mail
EAS Extended Area Service
EB End Bracket
EBCDIC Extended Binary–Coded Decimal Interchange Code
EACK Extended Acknowledgement
EARN European Academic Research
ECA Event Detection Point
ECC Enhanced Error Checking and Correction
ECH Echo Canceller with Hybrid
ECMA European Computer Manufacturers’ Association
ECO Echo Control Object
ECSA Exchange Carriers Standards Association
EDI Electronic Data Interchange
EDIFACT EDI For Administration, Commerce and Transport
EDIM EDI Message
EDIME EDI Messaging Environment
EDIMS EDI Messaging System
EDI–MS EDI Message Store
EDIN EDI Notification
EDI–UA EDI–User Agent
EEI External Environment Interface
EGP Exterior Gateway Protocol
EIA Electronic Industries Association
EISA Extended Industry Standard Architecture
EIT Encoded Information type
EN End Node
ENA Extended Network Addressing
ENV European Pre–standards
EOM End–of–Message DMPDU
EOT End–of–Transmission
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–11
EP Emulation Program
ER Explicit Route
ER Exception Response
EREP Environmental Recording Editing and Printing
ES End System
ESA Enterprise Systems Architecture
ESA Enhanced Subarea Addressing
ESCON Enterprise System Connectivity
ESF Extended Superframe Format
ESH End System Hello
ES–IS End System Intermediate System
ESS Electronic Switching System
ESTELLE Extended State Transition Language
ETB End–of–Text Block
ETR Early Token Release
ETX End–of–Text
EUnet European UNIX network
EUUG European UNIX User’s Group
EWOS European Workshop on Open Systems
FA Framework Advisory
FADU File Access Data Unit
FARNET Federation of American Research Networks
FAS Frame Alignment Sequence
FAT File Allocation Table
FC Frame Control Field
FCC Federal Communications Commission
FCS Frame Check Sequence
FDCO Field Definition Control Object
FDDI Fiber Distributed Data Interface
FDDI–FO FDDI Follow–On (FDDI)
FDM Frequency Division Multiplexing
FDR Field Definition Record
FDT Formal Description Technique
FDX Full Duplex
FEC Field Entry Condition
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–12
FEE Field Entry Event
FEI Field Entry Instruction
FEICO Field Entry Instruction Control Object
FEIR Field Entry Instruction Record
FEP Front End Processor
FEPCO Field Entry Pilot Control Object
FEPR Field Entry Pilot Record
FER Field Entry Reaction
FFOL FDDI Follow–on LAN
FID Format Identification
FIPS Federal Information Processing Standard
FISU Fill In Signal Unit
FM Function Management
FMH Function Management Header
FOD Office Document Format
FOR Forward Transfer
FNC Federal Networking Council
FRICC Federal Research Internet Coordinating committee
FR Family of Requirement
FRMR Frame Reject
FS Frame Status Field
FSG SGML Interchange Format
FSM Finite State Machine
FTAM File Transfer and Access Management
FTP File Transfer Protocol in TCP/IP
FYI For Your Information
FX Foreign Exchange Service
Gb Gigabits
Gbps Gigabits Per Second
GDMO Guidelines for the Definition of Managed Objects
GDS Generalized Data Stream
GFI General Format Indicator
GFP Global Functional Plane
GGP Gateway–to–Gateway Protocol
GMT Greenwich Mean–time
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–13
GPS Global Positioning System
GOSIP Government OSI Protocol
GSA General Services Administration
GTF Generalized Trace Facility
GWNCP Gateway NCP
GWSSCP Gateway SSCP
HAL Hardware Abstraction Layer
H–MUX Hybrid Multiplexer
HCL Hardware Compatibility List
HCS Header Check Sequence
HDB3 High–Density Bipolar – 3 zeros
HDLC High Level Data Link Control
HDX Half Duplex
HI–SAP Hybrid Isochronous–MAC Service Access Point
HLR Home location Register
HMP Host Monitoring Protocol
HOB Head of Bus
HP–SAP Hybrid packet–MAC Service Access Point
HRC Hybrid Ring Control
HSLN High–speed Local Network
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
Hz Hertz (cycles per second)
IAB Internet Architecture Board
IANA Internet Assigned Number Authority
IADCS Inter–activity Defined Context Set
IAN Integrated Analog Network
IAP Inner Administrative Point
IBM International Business Machines Corporations
IC Interexchange Carrier
ICD International Code Designator
ICF Isochronous Convergence Function
ICI Interface Control Information
ICMP Internet Control Message Protocol
ICV Integrity Check Value
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–14
IDI Initial Domain Identifier
IDN Integrated Digital Network
IDN Interface Definition Notation
IDP Initial Domain Part
IDP Internetwork Datagram Packet
IDU Interface Data Unit
IEC Interexchange Carrier
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
IEN Internet Engineering Notes
IF Information Flow
IETF Internet Engineering Task Force
IESG Internet Engineering Steering Group
IGP Interior Gateway Protocol
IGMP Internet Group Management Protocol
IGRP Internet Gateway Routing Protocol
ILD Injection Laser Diode
ILU Independent Logical Unit
IMAC Isochronous Media Access Control
IMIL International Managed Information Library
IML Initial Microcode Load
IMPDU Initial MAC Protocol Data Unit
IMS Information Management System
IN Intelligent Network
IND Indication
INN Intermediate Network Node
INTAP Interoperability Technology Association for Information Processing
IOC Input/Output Control
IOCP Input/Output Control Program
IONL Internal Organization of Network Layer
IP Internet Protocol
IPng IP Next Generation
IPv4 IP version 4
IPv6 IP version 6
IPC Interprocess Communication
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–15
IPDS Intelligent Printer Data Stream
IPI Initial Protocol Identifier
IPICS ISP Implementation Conformance Statement
IPL Initial Program Load
IPM Interpersonal Message
IPM–UA Interpersonal Messaging User Agent
IPMS Interpersonal Messaging System
IPN Interpersonal Notification
IPR Isolated Pacing Response
IPX Internetwork Packet Exchange
IR Internet Router
IRN Intermediate Routing Node
IRQ Interrupt Request Lines
IRTF Internet Research Task Force
IS International Standard
ISA Industry Standard Architecture
ISAM Index–Sequential Access Method
ISC Inter System Communications in CICS
ISCF Inter Systems Control Facility
ISDN Integrated Services Digital Network
ISH Intermediate System Hello
IS–IS Intermediate System–to–Intermediate System
ISO International Standards Organization
ISODE ISO Development Environment
ISP International Standard Profile
ISPBX Integrated Services Private Branch Exchange
ISPSN Initial Synchronization Point Serial Number
ISSI Inter Switching System Interface
ISUP ISDN User Part
IT Information Technology
ITC Independent Telephone Company
ITU International Telecommunication Union
ITU–TS International Telecommunication Union–Telecommunication Section
IUT Implementation Under Test
IVDT Integrated Voice/Data Terminal
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–16
IWU Interworking Unit
IXC Interexchange Carrier
JCL Job Control Language
JES Job Entry Subsystem
JTC Joint Technical Committee
JTM Job Transfer and Manipulation
KA9Q TCP/IP implementation for amateur radio
kb Kilobits
kbps Kilobits per second
kHz Kilohertz
km Kilometers
LAB Latency Adjustment Buffer
LAB Line Attachment Base
LAN Local Area Network
LANSUP LAN Adapter NDIS Support
LAP Link Access Procedure
LAPB Link Access Procedure Balanced
LAPD Link Access Procedures on the D–channel
LAPS LAN Adapter and Protocol Support
LATA Local Access and Transport Area
LCF Log Control Function
LCN Logical Channel Number
LE Local Exchange
LEC Local Exchange Carrier
LED Light–Emitting Diode
LEN Low Entry Networking
LI Length Indicator
LIB Line Interface Base
LIC Line Interface Coupler
LIDB Line Information Database
LIS Logical IP Subnet
LLAP LocalTalk Link Access Protocol
LLC Logical Link Control
LME Layer Management Entity
LMI Layer Management Interface
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–17
LOCKD Lock Manager Daemon
LOTOS Language of Temporal Ordering Specifications
LPD Line Printer Daemon
LPDA Link Problem Determination Application
LPR Line Printer
LRC Longitudinal Redundancy Check
LSE Local System Environment
LSL Link Support Layer
LSS Low–speed Scanner
LSSU Link Status Signal Unit
LT Local Termination
LU Logical Unit
m Meters
MAC Media Access Control
MAC Medium Access Control
MACE Macintosh Audio Compression and Expansion
MACF Multiple Association Control Function
MAN Metropolitan Area Network
MAP Manufacturing Automation Protocol
MAU Media Access Unit
MAU Multistation Access Unit
Mb Megabits
MBA MASSBUS Adapter
MBONE Multicast BackBONE
Mbps Megabits Per Second
MBZ Must be Zero
MCA Microchannel Architecture
MCF MAC Convergence Function
MCI Microwave Communications, Inc.
MCP MAC Convergence Protocol
MCR Monitor Console Routine
MD Management Domain
MFA Management Functional Areas
MFJ Modified Final Judgment
MFS Message Formatting Services in IMS
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–18
MH Message Handling Package
MHS Message Handling Service
MHS Message Handling System
MHz Megahertz
MIB Management Information Base
MIC Media Interface Connector
MID Message Identifier
MILNET Military Network
MIM Management Information Model
MIME Multipurpose Internet Mail Extension
MIN Mobile Identification Number; Multiple Interaction Negotiation
MIPS Million Instructions Per Second
MIS Management Information Systems
MIT Managed Information Tree
MLID Multiple Link Interface Driver
MMF Multimode Fiber
MMI Man Machine Interface
MMS Manufacturing Message Specification
MOSS Maintenance and Operator Subsystem
MOTIS Message Oriented Text Interchange System
MOT Means of Testing
MPAF Mid Page Allocation Field
MRO Multiregion Operation in CICS
ms Millisecond
MS Management Services
MS Message Store
MSC Mobile Switching Center
MSCP Mass Storage Control Protocol
MSN Multiple Systems Networking
MSNF Multiple Systems Networking Facility
MSS MAN Switching System; Maximum Segment Size
MST Multiplexed Slotted and Token Ring
MSU Management Services Unit
MTA Message Transfer Agent
MTACP Magnetic Tape Ancillary Control Process
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–19
MTBF Mean Time Between Failures
MTTD Mean Time of Diagnosis
MTOR Mean Time of Repair
MTP Message Transfer Part
MTS Message Transfer System
MTSE Message Transfer Service Element
MTU Maximum Transfer Unit
MVS/XA Multiple Virtual Storage/Extended Architecture
MVS/370 Multiple Virtual Storage/370
MVS Multiple Virtual Systems
NAK Negative Acknowledgement in BSC
NAP Network Access Provider
NAU Network Addressable Unit
NBP Name–Binding Protocol
NC Network Connection
NC Numerical Controller
NCB Node Control Block
NCCF Network Communications Control Facility
NCEP Network Connection End–point
NCP Network Control Program
NCP Network Core Protocol
NCS Network Computing System
NCTE Network Channel–Terminating Equipment
NDIS Network Driver Interface Specification
NFS Network File System
NIB Node Identification Block
NIC Network Interface Card
NIF Network Information File
NISDN Narrow Band ISDN
NIS Names Information Socket
NIST National Institute of Standards and Technology
NIUF North American ISDN Users’ Forum
NJE Network Job Entry
NLM NetWare Loadable Module
NLDM Network Logical Data Manager
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–20
nm Nanometer
NM Network Management
NMP Network Management Process
NMVT Network Management Vector Transport
NMS Network Management Station
NN Network Node
NOC Network Operations Center
NPA Numbering Plan Area
NPAI Network Protocol Control Information
NPDA Network Problem Determination Application
NPDU Network Protocol Data Unit
NPM Netview Performance Monitor
NPSI NCP Packet Switching Interface
NRN Non–receipt Notification
NRZ Non Return–to–Zero
NRZI Non Return–to–Zero Inverted
ns Nanosecond
NS Network Service
NSAP Network Service Access Points
NSDU Network Service Data Unit
NSF National Science Foundation
NTFS Windows NT File System
NTO Network Terminal Option
NVLAP National Voluntary Accreditation Program
OAF Origination Address Field
OAM Operations, administration, and maintenance
OAM&P Operations Administration, Maintenance and Provisioning
OC–n Optical Carrier level n
OC3 155 million bits per second over fiber
OCA Open Communication Architectures
OCC Other Common Carrier
ODA Office Document Architecture
ODI Open Data–Link Interface
ODIF Office Document Interchange Format
ODINSUP ODI NSIS Support
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–21
ODP Open Distributed Processing
OIT Object Identifier Tree
OIW OSI Implementation Workshop
OLRT Online Realtime
OLU Originating Logical Unit
OM Object Management
ONA Open Network Architecture
ONC Open Network Computing
OPNDST Open Destination
O/R Originator/Recipient
OS/400 Operating System/400 for the AS/400 Computer
OS Operating System
OSE Open Systems Environment
OSF Open Software Foundation
OSI Open Systems Interconnection
OSI/CS OSI Communications Subsystem
OSIE Open System Interconnection Environment
OSILL Open Systems Interconnection Lower Layers
OSIUL Open Systems Interconnection Upper Layers
OSPF Open Shortest Path First
OSNS Open Systems Network Services
P–MAC Packet Switched Media Access Control
PA Pre–arbitrated
PABX Private Automatic Branch Exchange
PAD Packet Assembler Disassembler
PAF Pre–Arbitrated Function
PAI Protocol Address Information
PAM Pass Along Message
PANS Pretty Amazing New Stuff
PAP Printer Access Protocol
PBX Private Branch Exchange
PC Path Control
PC Personal Computer
PCCU Physical Communications Control Unit
PCEP Presentation Connection End–point
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–22
PCI Protocol Control Information; Presentation Context Identifier; PeripheralComponent Interconnect bus
PCM Pulse Code Modulation
PCO Points of Control and Observation
PCTR Protocol Conformance Test Report
PDAD Proposed Draft Addendum
PDAU Physical Delivery Access Unit
PDC Packet Data Channel
pDISP Proposed Draft International Standard Profile
PDN Public Data Network
PDU Protocol Data Unit
PDV Presentation Data Value
PELS Picture Elements
PEM Privacy Enhanced Mail
PEP Partition Emulation Program
PETS Parameterized Executable Test Suite
PH Packet Handler or Packet Handling
PhC Physical Layer Connection
PhCEP Physical Connection End–Point
PhL Physical Layer
PhPDU Physical Layer Protocol Data Unit
PhS Physical Layer Service
Ph–SAP Physical Layer SAP
PhSAP Physical Layer Service Access Point
PhSDU Physical Layer Service Data Unit
PHY Physical Layer
PICS Protocol Information Conformance Statement
PIN Positive–Intrinsic Negative Photodiode
PING Packet Internet Groper
PIP Program Initialization Parameters
PIU Path Information Unit
PIXIT Protocol Implementation eXtra Information for Testing
PKCS Public Key Cryptosystems
PLC Programmable Logic Controller
PLCP Physical Layer Convergence Protocol
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–23
PLMN Public Land Mobile Network
PLP Packet Layer Protocol
PLS Primary Link Station; Physical Signalling
PLU Primary Logical Unit
PM Protocol Machine
PMD Physical Layer Medium Dependent
POI Point of Intitiation; Program Operator Interface
POP Point of Presence
POSI Promoting Conference for OSI
POSIX Portable Operating System Interface
POTS Plain Old Telephone Service
PPDU Presentation Protocol Data Unit
PPO Primary Program Operator
PPP Point–to–Point Protocol
PPSDN Public Packet Switched Data Network
PRI Primary Rate Interface
PRMD Private Management Domain
PS Presentation Services
PSAP Public Safety Answering Point
PSC Public Service Commission
PSDN Packet Switched Data Network
PSN Packet Switched Network
PSPDN Packet Switched Public Data Network
PSTN Public Switched Telephone Network
PSTN Public Switched Telephone Network
PTF Program Temporary Fix
PTLXAU Public Telex Access Unit
PTN Public Telephone Network
PTT Post, Telegraph and Telephone
PU Physical Unit
PUC Public Utility Commission
PUCP Physical Unit Control Point
PUMS Physical Unit Management Services
PUP Parc Universal Packet
PUT Program Update Tape
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–24
PVC Private Virtual Circuit
PVN Private Virtual Network
P 1 Protocol 1 (message transfer protocol/MHS/X.400)
P 2 Protocol 2 (interpersonal messaging MHS/X.400)
P 3 Protocol 3 (submission and delivery protocol/MHS/X.400)
P 5 Protocol 5 (Teletext access protocol)
P 7 Protocol 7 (message store access protocol in X.400)
QA Queued Arbitrated
QAF Queued Arbitrated Function
QC Quiesce Complete
QEC Quiesce at End–of–Chain
QMF Query Management Facility
QOS Quality of Service
QPSX Queued Packet and Synchronous Switch
QUIPU X.500 Conformant Directory Services in ISODE
RAM Random Access Memory
RARE Reseaux Associes poir la Recherche Europeenne; EuropeanAsosciation of Research Networks
RARP Reverse Address Resolution Protocol
RAS Remote Access Service
RBOC Regional Bell Operating Company
RD Routing Domain
RD Route Re–direction
RDA Relative Distinguished Names
RDA Remote Database Access
RDI Restricted Digital Information
RDN Relative Distinguished Name
RDP Reliable Datagram Protocol
RDT Resource Definition Table
RECFMS Record Formatted Maintenance Statistics
REJ Reject
REQ Request
RESP Response
RESYNC Resynchronization
RFC Request For Change
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–25
RFP Request for Proposal
RFQ Request for Price Quotation
RH Response Header
RH Request Header
RIB Routing Information Base
RIF Routing Information Field
RIM Request Initialization Mode
RIP Router Information Protocol
RIPE Reseaux IP Europeens; European continental TCP/IP network operatedby EUnet
RISC Reduced Instruction Set Computer
RJE Remote Job Entry
RM Reference Model
RMT Ring Management
RN Receipt Notification
RNAA Request Network Address Assignment
RNR Receiver Not Ready
ROSE Remote Operations Service Element
RPC Remote Procedure Call in OSF/DCE; Remote Procedure Call
RPL Request Parameter List; Remote Program Load
RPOA Recognized Private Operating Agency
RQ Request Counter
RR Receiver Ready
RS Relay System
RSF Remote Support Facility
RSP Response
RTM Response Time Monitor
RTMP Routing Table Maintenance Protocol
RTO Round Trip Time–Out
RTR Ready to Receive
RTS Request to Send
RTSE Reliable Transfer Service Element
RTT Round Trip Time
RU Request Unit
RU Response Unit
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–26
S/390 IBM’s System/390 Hardware Architecture
s Second
SA Source Address field
SA Subarea
SA Sequenced Application
SAA System Applications Architecture
SAA Specific Administrative Areas
SABM Set Asynchronous Mode Balanced
SACF Single Association Control Function
SACK Selective Acknowledgement
SAF SACF Auxiliary Facility
SALI Source Address Length Indicator
SAM Security Accounts Manager
SAMBE Set Asynchronous Mode Balanced Extended
SAO Single Association Object
SAP Service Access Point
SAP Service Advertising Protocol
SAPI Service Access Point Identifier
SAS Single–Attachment Station
SAS Statically Assigned Sockets
SASE Specific Application Service Element
SATS Selected Abstract Test Suite
SAW Session Awareness Data
SBA Set Buffer Address
SBI Stop Bracket Initiation
SC Session Connection
SC Subcommittee
SCC Specialized Common Carrier
SCCP Signaling Connection Control Part
SCEP Session Connection End–point
SCP Service Control Point
SCS System Conformance Statement
SCSI Small Computer System Interface
SCTR System Conformance Test Report
SDH Synchronous Digital Hierarchy
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–27
SDIF Standard Document Interchange Format
SDL System Description Language
SDLC Synchronous Data Link Control
SDN Software Defined Network
SDSE Shadowed DSA Entries
SDU Service Data Unit
SE Session Entity
SG Study Group
SGFS Special Group on Functional Standardization
SGML Standard Generalized Markup Language
SIA Stable Implementation Agreements
SID Security ID
SIM Set Initialization Mode
SIO Start I/O
SIP SMDS Interface Protocol
SLU Secondary Logical Unit
SMAE System Management Application Entity
SMASE Systems Management Application Service Element
SMB Server Message Block
SMDR Station Message Detail Recording
SMDS Switched Multi Megabit Data Service
SMF Single Mode Fiber
SMF System Management Facility
SMFA Systems Management Functional Area
SMI Structure of the OSI Management Information Service
SMIB Stored Message Information Base
SMP System Modification Program
SMS Service Management System
SMT Station Management Standard
SMTP Simple Mail Transfer Protocol
SNA System Network Architecture
SNAP Subnetwork Attachment Point
SNAcF Subnetwork Access Function
SNAcP‘ Subnetwork Access Protocol
SNADS SNA Distribution Services
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–28
SNARE Subnetwork Address Routing Entity
SNCP Single Node Control Point
SNDCP Subnetwork Dependent Convergence Protocol
SNI Subscriber–Network Interface
SNI SNA Network Interconnection
SNI SNA Network Interface
SNICP Subnetwork Independent Convergence Protocol
SNMP Simple Network Management Protocol
SNPA Subnetwork Point of Attachment
SNRM Set Normal Response Mode
SOA Start Of Authority
SONET Synchronous Optical Network
SP Signaling Point
SPAG Standards Promotion and Applications Group
SPC Signaling Point Code
SPDU Session Protocol Data Unit
SPE Synchronous Payload Envelope
SPF Shortest Path First
SPI Subsequent Protocol Identifier
SPM FDDI to SONET Physical Layer Mapping Standard
SPSN Synchronization Point Survival Number
SQL Structured Query Language
SRH SNARE Request Hello
SS Switching System
SS Session Service
SS6 Signaling System Number 6
SS7 Signaling System Number 7
SSA Subschema Specific Area
SSAP Source Service Access Point
SSAP Session Service Access Point
SSCP System Services Control Point
SSDU Session Service Data Unit
SSM Single Segment Message DMPDU
STA Spanning Tree Algorithms
ST Sequenced Terminal
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–29
STD Standard
STM Synchronous Transfer Mode
STM Station Management
STM–n Synchronous Transport Module level n
STP Shielded Twisted Pair
STP Service Transaction Program in LU 6.2
STP Signal Transfer Point
STS–n Synchronous Transport Signal level n
SUERM Signal Unit Error Rate Monitor
SUT System Under Test
SVA Shared Virtual Area
SVC Switched Virtual Circuit
SWS Silly Window Syndrome
SYN Synchronizing Segment; Synchronous Character in IBM’s BisyncProtocol
SYNC Synchronization
T3 A designation of telephony used over DS3 speed lines
T Transport
TA Terminal Adaptor
TC Technical Committee
TCP Transmission Control Protocol
TAG Technology Advisory Group
TAP Trace Analysis Program
TC Transport Connection or Technical Committee
TCAM Telecommunications Access Method
TCB Task Control Block
TCEP Transport Connection End–point
TCM Time Compression Multiplexing
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TCT Terminal Control Table in CICS
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
TE Terminal Equipment
TELNET Remote Logon in TCP/IP
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–30
TEP Transport End Point
TFTP Trivial File Transfer Protocol
TG Transmission Group
TH Transmission Header
THT Token Holding Timer
TIC Token–Ring Interface Coupler
TINA Telecommunications Information Network Architecture
TINA–C Telecommunication Information Network Architecture Consortium
TI RPC Transport Independent RPC
TLI Transport Layer Interface
TLMAU Telematic Access Unit
TLV Type, Length, and Value
TLXAU Telex Access Unit
TMP Text Management Protocol
TMS Time Multiplexed Switching
TOP Technical and Office Protocol
TOS Type of Service
TN3270 A version of TELNET that implements IBM 3270 data stream
TP Transaction Program
TP Transaction Processing
TP Transport Protocol
TPDU Transport Protocol Data Unit
TP–PMD Twisted Pair PMD
TPS Two Processor Switch
TPSP Transaction Processing Service Provider
TPSU Transaction Processing Service User
TPSUI TPSU Invocation
TP 0 TP class 0 – simple
TP 1 TP class 1 – basic error recovery
TP 2 TP class 2 – multiplexing
TP 3 TP class 3 – error recovery and multiplexing
TP 4 TP class 4 – error detection and recovery
TR Technical Report
TR Token Ring
TRA Token Ring Adapter
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–31
TRPB Truncated Reverse Path Broadcast
TRSS Token–Ring Subsystem
TRT Token Rotation Timer
TS Transaction Services
TS Transport Service
TSAP Transport Service Access Point
TSC Transmission Subsystem Controller
TSDU Transport Service Data Unit
TSCF Target System Control Facility
TSI Time Slot Interchange
TSO Time Sharing Option
TSR Terminate and Stay Resident Program
TSS Transmission Subsystem
TTCN Tree and Tabular Combined Notation
TTL Time to Live
TTP Timed Token Protocol
TTP Transport Test Platform
TTRT Target Token Rotation Time
TTY Teletype
TUP Telephone User Part
TVX Valid Transmission Timer (FDDI)
TWX Teletypewriter Exchange Service
UA Unnumbered Acknowledgement
UA User Agent; Unsequenced Application
UART Universal Asynchronous Receiver and Transmitter
UDI Unrestricted Digital Information
UDP User Datagram Protocol
UOW Unit–of–Work
UPS Uninterruptable Power Supply
URL Universal Resource Locator
User–ASE User Application Service Element
USS Unformatted System Services
UT Unsequenced Terminal
UTC Coordinated Universal Time
UTP Unshielded Twisted Pair
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY9–32
UUCP UNIX–to–UNIX Copy Program
VAC Value Added Carrier
VAN Value Added Network
VAS Value Added Service
vBNS A reference to the 155 Mbps deployment of an Internet backbone tohave been implemented in 1995
VCI Virtual Channel Identifier (DQDB)
VDT Video Display Terminal
VESA Video Electronics Standards Association
VLR Visitor Location Register
VLSI Very Large Scale Integration
VPI/VCI Virtual Path Identifier and a Virtual Call Identifier
VM Virtual Machine
VMD Virtual Manufacturing Device
VM/SP Virtual Machine System Product
VPN Virtual Private Network
VR Virtual Route
VRPWS Virtual Route Pacing Window Size
VS Virtual Storage
VSAM Virtual Storage Access Method
VSE Virtual Storage Extended
VT Virtual Terminal
VTAM Virtual Telecommunications Access Method
VTE Virtual Terminal Environment
VTP Virtual Terminal Protocol
VTPM Virtual Terminal Protocol Machine
VTSE Virtual Terminal Service Element
WACA Write Access Connection Acceptor
WACI Write Access Connection Initiator
WAN Wide Area Network
WAVAR Write Access Variable
WBC Wideband Channel
WD Working Document
WG Working Group
WNM workgroup Node Manger
Issue 1 Revision 4
�MOTOROLA LTD. 2001
CP09: TCP/IP
FOR TRAINING PURPOSES ONLY 9–33
WP Working Party
WWW The world wide web
X The X Window System
X.25 An ITU–TX standard; a transport layer service
X.400 The ITU–TS protocol for electronic mail
XAPIA X.400 API Association
XDR External Data Representation
XDS X/Open Directory Services API
XI SNA X.25 Interface
XID Exchange Identification
XNS Xerox Network Standard
XTI X/Open Transport Interface
XUDTS Extended Unitdata Service
ZIP Zone Information Protocol
ZIS Zone Information Socket