cp09

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


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


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


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


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 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


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


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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



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


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


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


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


GSM-100-202 Operating Information: OMC SystemAdministration

68P02901W13

GSM-100-712 Software Release Notes: OMC System 68P02901W71

Issue 1 Revision 4Motorola GSM manual set


CP09: TCP/IP


Scaleable OMC

The following Scaleable OMC manuals replace the equivalent Tandem OMC manuals inthe GSM manual set:

Categorynumber


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


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


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


CP09: TCP/IP


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


CP09: TCP/IP



CP09: TCP/IP


Chapter 1

Data Communication

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


Issue 1 Revision 4 Data Communication


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


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


CP09: TCP/IP


Data Communication and Distributed Processing

CP09_1_1

ISP ISP

X.25

PSTN PSTN

FrameRelay

Issue 1 Revision 4Communication System Functions


CP09: TCP/IP


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


CP09: TCP/IP


Communication System Functions

CP09_1_2

Naming and Addressing

Fragmenting

Flow Control

Synchronization

Priority

Error Control

Issue 1 Revision 4OSI Reference Model


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


The Internet

CP09_1_5

Network

Router

IP Host Virtual Network

Issue 1 Revision 4TCP/IP (DoD) Architecture


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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



CP09: TCP/IP



CP09: TCP/IP


Chapter 2

Internet Protocol

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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 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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


Host ID

110 Net ID Host ID


10 Net ID

Issue 1 Revision 4Class D, E


CP09: TCP/IP


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


CP09: TCP/IP


Address Format (D, E)

CP09_2_3

ClassD223–239 1110 Multicast Address


ClassE240–254 Host ID


1111 Reserved for Future Use

Issue 1 Revision 4Example Addresses


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


Subnet Masking

CP09_2_8

Class B128–191


NET ID HOST ID

11111111 11111111 11111111 00000000

NET ID SUBNET ID HOST ID

Issue 1 Revision 4Logical ‘AND’


CP09: TCP/IP


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’


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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



CP09: TCP/IP




CP09: TCP/IP


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


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


Class B

Class C



CP09: TCP/IP


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.



CP09: TCP/IP


IP Datagram

LAN Header IP Header TCP Header User Data

MAC Addresses

IP Addresses

CP09_2_14

Issue 1 Revision 4IP Header


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


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


CP09: TCP/IP



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


CP09: TCP/IP


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


CP09: TCP/IP



CP09_2_20



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


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



CP09: TCP/IP



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


Total length

Identification

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16



CP09: TCP/IP



CP09_2_22


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


. . . 0 . . . . = Normal Delay


. . . . . . 00 = Reserved

522 bytes

25598

0 x 4000

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment

. . 0 . . . . . . . . . . . . . = Last Fragment


14 seconds/hops


Destination Address

No IP Options

6 (TCP)

0 x E60

128.52.46.32

137.28.1.2

(Checksum Good)



CP09: TCP/IP



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.



CP09: TCP/IP



CP09_2_23


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]


CP09: TCP/IP


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]


CP09: TCP/IP


IP Fragmentation

CP09_2_25


Total Length

Identification

Fragment Control

100 bytes

35087

0 x 4000

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment

. . 1 . . . . . . . . . . . . . = More Fragments


First Fragment


Total Length

Identification

Fragment Control

100 bytes

35087

0 x 200A

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment

. . 1 . . . . . . . . . . . . . = More Fragments


Second Fragment

CPO9_2_25a


Total Length

Identification

Fragment Control

100 bytes

35087

0 x 2014

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment


Third Fragment


Total Length

Identification

Fragment Control

88 bytes

35087

0 x 1E

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment

. . 0 . . . . . . . . . . . . . = Last Fragments


Last Fragment

. . 1 . . . . . . . . . . . . . = More Fragments



CP09: TCP/IP



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.



CP09: TCP/IP



CP09_2_26


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


. . . 0 . . . . = Normal Delay


. . . . . . 00 = Reserved

522 bytes

25598

0 x 00

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment

. . 0 . . . . . . . . . . . . . = Last Fragment


14 seconds/hops


Destination Address

No IP Options

6 (TCP)

0 x E60

128.52.46.32

137.28.1.2

(Checksum Good)



CP09: TCP/IP



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.



CP09: TCP/IP



CP09_2_27


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


. . . 0 . . . . = Normal Delay


. . . . . . 00 = Reserved

522 bytes

25598

0 x 00

0 . . . . . . . . . . . . . . . = Reserved

. 0 . . . . . . . . . . . . . . = May Fragment

. . 0 . . . . . . . . . . . . . = Last Fragment


14 seconds/hops


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


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)


ICMP – Internet Control Message Protocol

Issue 1 Revision 4ICMP Message Types


CP09: TCP/IP


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


CP09: TCP/IP


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)


CP09: TCP/IP


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)


CP09: TCP/IP


ICMP Message Types

Type

0

3

4

5

8

11

12

13

14

15

16

17

18

Definition

Echo Reply

Destination Unreachable

Source Quench

Redirect

Echo Request

Time Exceeded

Parameter Problem

Timestamp Request

Timestamp Reply

Information Request

Information Reply

Address Mask Request

Address Mask Reply

Code(s)

0

0 - 13

4

0 - 3

0

0 - 1

0

0

0

0

0

0

0

CP09_2_34



CP09: TCP/IP


ICMP – Echo Request (Ping)

CP09_2_35



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)



CP09: TCP/IP


ICMP – Echo Reply (Ping)

CP09_2_36



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)



CP09: TCP/IP


ICMP – Destination Unreachable

CP09_2_37


TypeCode


No IP OptionsICMP – Internet Control Message Protocol

Decode Status

ICMP ChecksumOriginal IP Header is following:


Type of Service


Fragment Control

Time to Live

ChecksumProtocol


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



CP09: TCP/IP


ICMP – Destination Unreachable

CP09_2_38


TypeCode



Decode Status



Type of Service


Fragment Control

Time to Live

ChecksumProtocol



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



CP09: TCP/IP


ICMP – Redirect

CP09_2_39


TypeCode



Decode Status

ICMP Checksum

Original IP Header is following:Decode Status

VersionType of Service


Fragment Control

Time to Live

ChecksumProtocol



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



CP09: TCP/IP


ICMP Time Exceed

CP09_2_40


TypeCode



Decode Status



Type of Service


Fragment Control

Time to Live

ChecksumProtocol



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


CP09: TCP/IP


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


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)


CP09: TCP/IP


Chapter 3

Routing Protocols

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


Issue 1 Revision 4 Routing Protocols


CP09: TCP/IP


Routing Protocols

Objectives


� Describe the purpose and use of routing protocols.

Issue 1 Revision 4Routing and Routing Tables


CP09: TCP/IP


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


CP09: TCP/IP


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


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


Distance001120

Next Router

222.222.222.2222.222.222.2222.222.222.2

Router 1

Router 2

Router 3

Issue 1 Revision 4Internet Architecture


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


EGP / BGP

CP09_3_5

Core Router Core Router

AS ASASAS

EGP EGP EGP EGP

Issue 1 Revision 4Interior Distance Vector Protocols


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP



CP09: TCP/IP


Chapter 4

Transport Protocols

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




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


CP09: TCP/IP


Issue 1 Revision 4 Transport Protocols


CP09: TCP/IP


Transport Protocols

Objectives


� 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


CP09: TCP/IP


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


CP09: TCP/IP


Message Transfer

CP09_4_1

Diagram number

LAN/WAN

Header

IPHeader

TCP/UDPHeader User Data

LAN/WANTrailer


IP

Telnet SMTP FTP TFTP SNMP DNS

UDPTCP

Protocol Stack

Message Format



CP09: TCP/IP


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


CP09: TCP/IP


Addressing Concepts

CP09_4_2


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


CP09: TCP/IP


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


CP09: TCP/IP


UDP Concepts

CP09_4_3


IP

TFTP SNMP DNS

UDP

69 161 53

17

0800

122.45.2.5

00:08:F2:C5:28

Issue 1 Revision 4UDP Format


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


TCP Concepts

CP09_4_5


IP

FTP

TCP

06

1025

IP

FTP

TCP

06

Reliable TCP Connection

Unreliable IP Datagram

21

Issue 1 Revision 4TCP Segment


CP09: TCP/IP


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


CP09: TCP/IP


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


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


CP09: TCP/IP


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


CP09: TCP/IP


TCP Header Decode

CP09_4_7

TCP – Transmission Control Protocol

Decode Status

Source Port

Destination Port

Sequence 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


Issue 1 Revision 4Flags


CP09: TCP/IP


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


CP09: TCP/IP


TCP Decode

CP09_4_8


Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

Kind

Window

– –

21

1050

1243040

3778555

0 x 60

0110 . . . . = Header Length = 24



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset



32768

0 x 9257

0

(Checksum Good)

(FTP)

(Unknown)

0 x 12

Option Length


2

4

1460


Issue 1 Revision 4Flags


CP09: TCP/IP


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


CP09: TCP/IP


TCP Decode

CP09_4_9


Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

Kind

Window

– –

21

1050

1243040

3778555

0 x 60

0110 . . . . = Header Length = 24



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset



32768

0 x 9257

0

(Checksum Good)

(FTP)

(Unknown)

0 x 12

Option Length


2

4

1460


Issue 1 Revision 4Establishing a TCP Session


CP09: TCP/IP


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


CP09: TCP/IP


Establishing a TCP Session

CP09_4_10

SYN

SYN, ACK

ACK

Host A Host B

Issue 1 Revision 4Establishing a TCP Session – 1


CP09: TCP/IP


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


CP09: TCP/IP


Establishing a TCP Session – 1

CP09_4_11

A

B

C


Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

Kind

Window

– –

1025

21

5419543

0

0 x 60

0110 . . . . = Header Length = 24


. . . 1 . . . . = Not Acknowledged

. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset



8192

0 x D9FE

0

(Checksum Good)

(Unknown)

(FTP)

0 x 02

Option Length


2

4

1460




CP09: TCP/IP



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.



CP09: TCP/IP



CP09_4_12

C

B

A


Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

Kind

Window

– –

21

1025

21045782

5419544

0 x 60

0110 . . . . = Header Length = 24



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset



32768

0 x 56DE

0

(Checksum Good)

(FTP)

(Unknown)

0 x 12

Option Length


2

4

1442




CP09: TCP/IP



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.



CP09: TCP/IP



CP09_4_13

B

A


Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

Window

– –

1025

21

5419544

21045729

0 x 50

0101 . . . . = Header Length = 24



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset

. . . . . . 0 . = No Synchronize Sequence Numbers


8652

0 x CCBD

0

(Checksum Good)

(Unknown)

(FTP)

0 x 10

No TCP Options

Issue 1 Revision 4Terminating a TCP Session


CP09: TCP/IP


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


CP09: TCP/IP


Terminating a TCP Session

CP09_4_14

ACK

FIN, ACK

ACK

Host A Host B

FIN

DATA

DATA



CP09: TCP/IP


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.



CP09: TCP/IP



CP09_4_15


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


Data Offset

Flags

- -

1027

20

5453089

21114996

0 x 50

0101 . . . . = Header Length = 20

(Unknown)

(FTP Data)

0 x 10



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset



Window

Checksum

Urgent Pointer 0

0 x 3BIF

8652

(Checksum Good)

No TCP Options



CP09: TCP/IP


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.



CP09: TCP/IP



CP09_4_17

TCP – Transmission Control ProtocolCLIENT

Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

No TCP Options

Window

- -

1027

20

5453089

21114996

0 x 50

0101 . . . . = Header Length = 20



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset


. . . . . . . 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


Data Offset

Flags

Checksum

Urgent Pointer

No TCP Options

Window

- -

20

1027

21114996

5453090

0 x 50

0101 . . . . = Header Length = 20



. . . . 0 . . . = No Push

. . . . . 0 . . = No Reset



32767

0 x DCEA

0

(Checksum Good)

(FTP Data)

(Unknown)

0 x 10



CP09: TCP/IP


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.



CP09: TCP/IP


Terminating a TCP Session – Reset

CP09_4_19


Decode Status

Source Port

Destination Port

Sequence Number


Data Offset

Flags

Checksum

Urgent Pointer

No TCP Options

Window

- -

21

1025

21046141

5419651

0 x 50

0101 . . . . = Header Length = 20



. . . . 0 . . . = No Push

. . . . . 1 . . = Reset



32661

0 x 6CE9

0

(Checksum Good)

(FTP)

(Unknown)

0 x 14



CP09: TCP/IP



CP09: TCP/IP


Chapter 5

Application Protocols

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


Issue 1 Revision 4 Application Protocols


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


Client-Server Model

Server

CP09_5_1

Client

ServerClient

Request to awell–knownport FTPTELNET etc.

Reponse toclient’s port

Issue 1 Revision 4Telnet


CP09: TCP/IP


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


CP09: TCP/IP


Telnet

CP09_5_2

Client

Operating System

Telnet

NetworkVirtual

Terminal

Client

Operating System

Telnet

NetworkVirtual

Terminal

23

Issue 1 Revision 4File Transfer Protocol (FTP)


CP09: TCP/IP


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)


CP09: TCP/IP


File Transfer Protocol (FTP)

CP09_5_3

Client

21

SourceFile

FTP

Server

DestinationFile

FTP

20

SourceFile

Issue 1 Revision 4Simple Mail Transfer Protocol


CP09: TCP/IP


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


REPLY TO: name to send reply to

A header can contain the following:


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


CP09: TCP/IP


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


CP09: TCP/IP


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

eg [email protected]

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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP



CP09: TCP/IP


Chapter 6

Domain Name Service

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


Issue 1 Revision 4 The Domain Name Service


CP09: TCP/IP


The Domain Name Service

Objectives


� Describe the purpose and function of a Domain Name Service.

Issue 1 Revision 4Domain Name System


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP



CP09: TCP/IP


Chapter 7

IP Version 6

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


Issue 1 Revision 4 IP Version 6


CP09: TCP/IP


IP Version 6

Objectives


� Describe the main features of IP version 6.

� Describe the format of the IPv6 header

Issue 1 Revision 4Background


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


IP4 / IP6 Headers

CPO9_7_3

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


Fragment offset

Header checksumSource IP address

Destination IP addressOptions/Padding

Data


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


CP09: TCP/IP


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


CP09: TCP/IP


Addressing

CPO9_7_4

Unicast·

Anycast·Multicast·



CP09: TCP/IP


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



CP09: TCP/IP


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



CP09: TCP/IP


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.



CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


Multicast Scope

CP09_7_7

0123–456–789–DEF

ReservedNode – LocalLink – LocalUnassignedSite LocalUnassignedOrganisation – LocalUnassignedGlobalReserved

Issue 1 Revision 4Multicast Scope


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


Extension Headers

CP09_7_9

Hop–by–Hop

Routing (type 0)

Fragment

Destination Options

Authentication

Encapsulating Security Payload

·

·

·

·

·

·

Issue 1 Revision 4Extension Headers


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


Fragment Header

CP09_7_12

0 7 15 31Fragment OffsetReserved

Identification

Next Header16 28 29 30

MRES

Issue 1 Revision 4Destination Options Header


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


Security

CP09_7_16

Hosts

Mobile Hosts

Between sites via the Internet

Routing Protocols

Autoconfiguration

·

····

Issue 1 Revision 4Authentication and Encryption


CP09: TCP/IP


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


CP09: TCP/IP


Authentication and Encryption

Issue 1 Revision 4Neighbour Discovery


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP



CP09: TCP/IP


Chapter 8

Automatic Configuration

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


Issue 1 Revision 4 Automatic Configuration


CP09: TCP/IP


Automatic Configuration

Objectives


� Describe the function and concept of Automatic Configuration protocols.

Issue 1 Revision 4Reverse Address Resolution Protocol (RARP)


CP09: TCP/IP


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)


CP09: TCP/IP


RARP

CP09_8_1

Client RARP Server

Hardware Address

IP Address

Issue 1 Revision 4Dynamic Host Configuration Protocol


CP09: TCP/IP


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


CP09: TCP/IP


Dynamic Host Configuration Protocol

CP09_8_2

Client DHCP Server

DHCP Broadcast

Dynamic IP Address

Issue 1 Revision 4DHCP Operation


CP09: TCP/IP


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


CP09: TCP/IP


DHCP Operation

CP09_8_3

DHCP Discover

DHCP Offer

DHCP Request

DHCP Acknowledgement

·

···

Issue 1 Revision 4DHCP Relay Agents


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


BOOTP

CP09_8_5

Client BOOTP Server

BOOTP message

IP Configuration andOperating System Information

Issue 1 Revision 4Summary of RARP, BOOTP/TFTP and DHCP


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP



CP09: TCP/IP


Chapter 9

Glossary of Terms

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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

Issue 1 Revision 4


CP09: TCP/IP


Issue 1 Revision 4


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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


CP09: TCP/IP


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

cp09

Documents

fibre optic

radio frequency

safety issue

jumbo payload

reporting

synchronize

default subnet

asynchronous