Download as pdf or txt
Download as pdf or txt
You are on page 1of 16

INTERNETPROTOCOL(IP)

INTERNETPROTOCOL(IP)
DARPAINTERNETPROGRAMPROTOCOL SPECIFICATION

RFC791revisesfollowingaspects:
Addressing errorhandling optioncodes option codes thesecurity Precedence Compartments handlingrestrictionfeaturesoftheinternet protocol.

(RFC791)

InternetProtocol(Motivation)
Designedforuseininterconnectedsystemsofpacket switchedcomputercommunicationnetworks. Providesfortransmittingblocksofdatacalleddatagrams d f bl k f d ll d d fromsourcestodestinations. Providesforfragmentationandreassemblyoflong datagrams,ifnecessary,fortransmissionthrough"small packet"networks.

InternetProtocol(Scope)
Specificallylimitedinscopetoprovidethe functionsnecessarytodeliverapackageofbits(a datagram)fromasourcetoadestinationoveran y interconnectedsystemofnetworks. Therearenomechanismstoaugmentendtoend datareliability,flowcontrol,sequencing,orother servicescommonlyfoundinhosttohost protocols.

Interface
ATCPmodulewouldcallontheinternetmodule totakeaTCPsegment(includingtheTCPheader anduserdata)asthedataportionofaninternet datagram. Th TCP TheTCPmodulewouldprovidetheaddresses d l ld id th dd andotherparametersintheinternetheaderto theinternetmoduleasargumentsofthecall. Theinternetmodulewouldthencreatean internetdatagramandcallonthelocalnetwork interfacetotransmittheinternetdatagramto carryittothenextgatewayordestinationhost.
MajorDuties:

Interface

LogicalAddressing: addsaheaderwithlogicaladdressoforiginalsender and/orreceiver Routing:Routeorswitchthepacketstotheirfinaldestinationpassingthrough differentnetworks

Operation
Implementstwobasicfunctions:addressingandfragmentation. Theinternetmodulesusetheaddressescarriedintheinternet headertotransmitdatagrams towardtheirenddestinations. Theselectionofapathfortransmissioniscalledrouting. FieldsintheIPheaderisusedtofragmentandreassemble datagrams whennecessaryfortransmissionthrough"smallpacket" networks. Treatseachdatagramasanindependententityunrelatedtoany otherdatagram. Noconnectionsorlogicalcircuits(virtualorotherwise).

Operation(contd)
TheIPusesfourkeymechanismsin providingitsservice: TypeofService Ti TimetoLive Li Options,and HeaderChecksum.

Operation(contd)
TheIPdoesnotprovideareliablecommunication facility. Therearenoacknowledgmentseitherendtoend orhopbyhop.Thereisnoerrorcontrolfor or hop by hop There is no error control for data,onlyaheaderchecksum.Thereareno retransmissions.Thereisnoflowcontrol. ErrorsdetectedmaybereportedviatheInternet ControlMessageProtocol(ICMP)whichis implementedintheinternetprotocolmodule.

RelationtoOtherProtocols
Internetprotocolinterfacesononesidetothehigherlevelhosttohostprotocols andontheothersidetothelocalnetworkprotocol.

ModelofOperation

source
message segment
Ht M M M M

(Involvingoneintermediategateway)
Thesourceapplicationprogrampreparesitsdataandcallsonitslocalinternet moduletosendthatdataasadatagram.Arguments:thedestinationIPaddress andotherparameters. Theinternetmodulepreparesadatagramheaderandattachesthedatatoit. Theinternetmoduledeterminesalocalnetworkaddressforthisinternetaddress, inthiscaseitisthe(MAC)addressofagateway.Itsendsthisdatagramandthe localnetworkaddresstothelocalnetworkinterface. Thelocalnetworkinterfacecreatesalocalnetworkheader,andattachesthe g , datagramtoit,thensendstheresultviathelocalnetwork. Thedatagramarrivesatagatewayhostwrappedinthelocalnetworkheader,the localnetworkinterfacestripsoffthisheader,andturnsthedatagramovertothe internetmodule.Theinternetmoduledeterminesfromtheinternetaddressthat thedatagramistobeforwardedtoanotherhostinasecondnetwork.The internetmoduledeterminesalocalnetaddressforthedestinationhost.Itcallson thelocalnetworkinterfaceforthatnetworktosendthedatagram. Thislocalnetworkinterfacecreatesalocalnetworkheaderandattachesthe datagramsendingtheresulttothedestinationhost.Atthisdestinationhostthe datagramisstrippedofthelocalnetheaderbythelocalnetworkinterfaceand handedtotheinternetmodule. Theinternetmoduledeterminesthatthedatagramisforanapplicationprogram inthishost.Itpassesthedatatotheapplicationprograminresponsetoasystem call,passingthesourceaddressandotherparametersasresultsofthecall.

ModelofOperation

datagram Hn Ht frame Hl Hn Ht

application transport network link physical link physical switch

destination
M Ht Hl Hn Ht Hn Ht M M M

Hn Ht Hl Hn Ht

M M

application transport network link physical

network link physical

Hn Ht

router

Addressing
Name indicateswhatweseek. Address indicateswhereitis. Aroute indicateshowtogetthere. Theinternetprotocoldealsprimarilywith addresses. dd Higherlevel(i.e.,hosttohostorapplication) protocolsmakesthemappingfromnamesto addresses. Theinternetmodulemapsinternetaddressesto localnetaddresses.

Addressing(contd)
Addressesarefixedlengthoffouroctets(32 bits). Beginswithanetworknumber,followedby localaddress(calledthe rest field) local address (called the "rest"field). Therearefiveformatsorclassesofinternet addresses.

Addressing(contd)

Fragmentation
Fragmentationofaninternetdatagramis necessarywhenitoriginatesinalocalnetthat allowsalargepacketsizeandmusttraversea localnetthatlimitspacketstoasmallersizeto reachitsdestination. Aninternetdatagramcanbemarked"don't fragment."Anyinternetdatagramsomarkedis nottobeinternetfragmentedunderany circumstances.Ifinternetdatagrammarked don'tfragmentcannotbedeliveredtoits destinationwithoutfragmentingit,itistobe discardedinstead.

IP datagram Header

IPDatagramHeader
Version: 4bits.VersionofIP.4forIPv4,6forIPv6. HeaderLength: 4bits.Datagramheaderin4bytewords.4x InternetHeaderLengthisthelengthoftheinternetheaderin32 bitwords,andthuspointstothebeginningofthedata.Note that theminimumvalueforacorrectheaderis5. DifferentiatedServices(TypeofService): 8bits ClassofdatagramforQoS desired. Indicatesthequalityofservicedesired.Networksmayoffer serviceprecedence,meaningthattheyaccepttrafficonlyabove acertainprecedenceattimesofhighload.Thereisathreeway tradeoffbetweenlowdelay,highreliabilityandhighthroughput.
Thistypeofserviceindicationistobeusedbygatewaystoselectthe actualtransmissionparametersforaparticularnetwork,thenetwork tobeusedforthenexthop,orthenextgatewaywhenroutingan internetdatagram.

The total length field defines the total length of the datagram including the header.

IPDatagramHeader(TypeofService)
Bits02:Precedence 111Networkcontrol. 110Internetworkcontrol. 101CRITIC/ECP. 100Flashoverride. l h d 011Flash. 010Immediate. 001Priority. 000Routine. Bit3:Delay
0Normaldelay. 1Lowdelay.

IPDatagramHeader(TypeofService)
Thetypeofserviceisusedtospecifythetreatmentofthe datagramduringitstransmissionthroughtheinternet system. TheuseoftheDelay,Throughput,andReliabilityindications mayincreasethecost(insomesense)oftheservice.In manynetworksbetterperformanceforoneofthese parametersiscoupledwithworseperformanceonanother. Exceptforveryunusualcasesatmosttwoofthesethree Except for very unusual cases at most two of these three indicationsshouldbeset. TheNetworkControlprecedencedesignationisintendedto beusedwithinanetworkonly.Theactualuseandcontrol ofthatdesignationisuptoeachnetwork.TheInternetwork Controldesignationisintendedforusebygatewaycontrol originatorsonly.Iftheactualuseoftheseprecedence designationsisofconcerntoaparticularnetwork,itisthe responsibilityofthatnetworktocontroltheaccessto,and useof,thoseprecedencedesignations.

Bit4:Throughput
0Normalthroughput. 1Highthroughput.

Bit5:Reliability
0Normalreliability. 1Highreliability.

Bits67:Reservedforfuture
use.

IPDatagramHeader(TotalLength)
TotalLength: 16bits.LengthofData+Header
Thisfieldallowsthelengthofadatagramtobeupto 65,535bytes,althoughsuchlongdatagrams are impracticalformosthostsandnetworks.Allhostsmust bepreparedtoacceptdatagrams ofupto576bytes, regardlessofwhethertheyarrivewholeorinfragments. Itisrecommendedthathostssenddatagrams largerthan 576bytesonlyifthedestinationispreparedtoaccept 576 b t l if th d ti ti i dt t thelargerdatagrams. Thenumber576isselectedtoallowareasonablesized datablocktobetransmittedinadditiontotherequired headerinformation.Forexample,thissizeallowsadata blockof512octetsplus64headeroctetstofitina datagram.Themaximalinternetheaderis60octets,and atypicalinternetheaderis20octets,allowinga marginforheadersofhigherlevelprotocols.

IPDatagramHeader
(Identification,Flag,Offset)
Identification:16bit. Identifyingvalueassignedbythesendertoaidinassembling thefragmentsofadatagram. Flag:3bits.Controlflags: Bit0:reservedandmustbezero Bit1:Dontfragmentbit(DF) Bit 1 D t f t bit (DF)
0Mayfragment, 1Dontfragment. 1Morefragments.

Bit2:Morefragmentsbit(MF)
0Lastfragment,

FragmentOffset: 13bits. Indicateswherethisfragmentbelongsinthedatagram.The fragmentoffsetismeasuredinunitsof8bytes(64bits).Thefirst fragmenthasoffsetzero.

Fragmentation(Identification)
Theinternetfragmentationandreassembly procedureneedstobeabletobreakadatagraminto analmostarbitrarynumberofpiecesthatcanbe laterreassembled.Thereceiverofthefragments usestheidentificationfield toensurethat fragmentsofdifferentdatagrams arenotmixed. Theoriginatingprotocolmoduleofaninternet datagramsetstheidentificationfieldtoavaluethat mustbeuniqueforthatsourcedestinationpairand protocolforthetimethedatagramwillbeactivein theinternetsystem.Theoriginatingprotocol moduleofacompletedatagramsetsthemore fragmentsflagtozeroandthefragmentoffsetto zero.

Fragmentation(Offset,Flag)
Thefragmentoffset(13bit)fieldtellsthereceiverthe positionofafragmentintheoriginaldatagram.Thefragment offsetandlengthdeterminetheportionoftheoriginal datagramcoveredbythisfragment. Thisformatallows2**13=8192fragmentsof8octetseachfor atotalof65,536octets.Notethatthisisconsistentwiththe datagramtotallengthfield(ofcourse,theheaderiscountedin thetotallengthandnotinthefragments). the total length and not in the fragments). Themorefragmentsflagindicates(bybeingreset)thelast fragment. Whenfragmentationoccurs,someoptionsarecopied,but othersremainwiththefirstfragmentonly. Theidentification,offsetandflagprovidesufficientinformation toreassembledatagrams.

Fragmentation
Fragmentation example

Thefieldswhichmaybeaffectedby fragmentationinclude: optionsfield g g morefragmentsflag fragmentoffset internetheaderlengthfield totallengthfield headerchecksum


20.26

Detailed fragmentation example

IPDatagramHeader
(TimetoLive) Timetolive:8bits.
TheTimetoLiveisanindicationofanupperboundon thelifetimeofaninternetdatagram.Itissetbythe senderofthedatagramandreducedatthepoints alongtheroutewhereitisprocessed.Ifthetimeto along the route where it is processed If the time to livereacheszerobeforetheinternetdatagramreaches itsdestination,theinternetdatagramisdestroyed. Thetimetolivecanbethoughtofasaselfdestruct timelimit. Setapproximatelytotwotimesthemaxnumberof routesbetweenanytwohosts.

20.27

IPDatagramHeader(Protocol)
Protocol:8bits.
Thisfieldindicatesthenextlevelprotocolusedinthe dataportionoftheinternetdatagram.Thevaluesfor variousprotocolsarespecifiedin"AssignedNumbers".

IPDatagramHeader(Protocol) Examples
Decimal Keyword Protocol 1 ICMP 2 IGMP 4 IP 5 ST 6 TCP 8 EGP 17 UDP 41 IPv6 42 SDRP 43 IPv6Route 44 IPv6Frag 45 IDRP 58 IPv6ICMP 59 IPv6NoNxt 60 IPv6Opts 83 VINES InternetControlMessage InternetGroupManagement IP inIP(encapsulation) Stream TransmissionControl ExteriorGatewayProtocol UserDatagram Ipv6 SourceDemandRoutingProtocol RoutingHeaderforIPv6 FragmentHeaderforIPv6 InterDomainRoutingProtocol ICMPforIPv6 NoNextHeaderforIPv6 DestinationOptionsforIPv6 VINES

89

OSPF

OpenShortestPathFirst

134254unassigned,255reservedbyIANA www.iana.org/assignments/protocolnumbers

IPDatagramHeader(Checksum)
Checksum: 16bit.Checksumoftheheaderonly.
Averificationthattheinformationusedinprocessingdatagramhasbeen transmittedcorrectly.Thedatamaycontainerrors.Iftheheaderchecksum fails,theinternetdatagramisdiscardedatoncebytheentitywhichdetectsthe error. Sincesomeheaderfieldschange(e.g.,timetolive),thisisrecomputedand verifiedateachpointthattheinternetheaderisprocessed.

Example 10.23

Algorithm:Thechecksumfieldisthe16bitone'scomplement
oftheone'scomplementsumofall16bitwordsintheheader. Forpurposesofcomputingthechecksum,thevalueofthe checksumfieldiszero. Thisisasimpletocomputechecksumandexperimentalevidence indicatesitisadequate,butitisprovisionalandmaybereplaced byaCRCprocedure,dependingonfurtherexperience.
10.32

Example of checksum calculation in IPv4

IPDatagramHeader(Remaining)
SourceAddress: 32bit.IPaddressofthesource. DestinationAddress: 32bit.IPaddressof destination. Options: variable.Usedfornetworktestingand debugging.
TheOptionsprovideforcontrolfunctionsneededorusefulinsome situationsbutunnecessaryforthemostcommoncommunications.The optionsincludeprovisionsfortimestamps,security,andspecialrouting.

20.33

Ethernet II Frame Structure

IPHeaderFieldsAndFunctions
IdentificationField
EachpacketisgivenauniqueIDvaluewhensent

IPHeaderFieldsAndFunctions (continued)
TimetoLive(TTL)Field
Denotestheremaininglifetimeofthepacket

FlagsField
Threebitslong Typically,fragmentationisallowed

ProtocolField
Indicates what is coming up next Indicateswhatiscomingupnext

HeaderChecksumField
ProvideserrordetectiononthecontentsoftheIP headeronly

FragmentOffsetField
Showswheretoplacepacketsdatawhen fragmentsarereassembled
GuidetoTCP/IP,ThirdEdtion 37

SourceAddressField
TheIPaddressoftheIPhostthatsentthepacket
GuidetoTCP/IP,ThirdEdtion 38

IPHeaderFieldsAndFunctions (continued)
DestinationAddressField
Canincludeaunicast,multicast,orbroadcast address Final destination of the packet Finaldestinationofthepacket

Figure 20.14 Taxonomy of options in IPv4

OptionsFields
ExistprimarilytoprovideadditionalIProuting controls Canbeusefulwhentestingordebuggingcodeor specificconnections
GuidetoTCP/IP,ThirdEdtion 39 20.40

SendingIPDatagrams
RequirementsforbuildinganIPdatagram packettotransmitonthewire
IPaddressesofthesourceanddestination Hardware address of the source and next hop Hardwareaddressofthesourceandnexthop router

RouteResolutionProcess
EnablesIPhosttodetermineifdesired destinationislocalorremote LocalorRemoteDestination?
U UpondeterminationofIPaddress d t i ti f IP dd
IPhostcomparesnetworkportionofdestination addresstoitsownlocalnetworkaddress

IPhost
CanuseamanuallyentereddestinationIPaddress ortheDNStoobtainadestinationsIPaddress
GuidetoTCP/IP,ThirdEdtion 41

GuidetoTCP/IP,ThirdEdtion

42

Route Resolution Process (continued)

Route Resolution Process (continued)


ThesourceIPaddressis10.1.0.1,subnetmask255.255.0.0 Thelocalnetworknumberis10.1.0.0 ThedestinationIPaddressis10.2.0.2,thenetaddressis 10.2.0.0 Sourceanddestinationnetworkdoesnotmatch.So destinationisremote destination is remote Sourcemustgothroughtheroutertoreachdestination Thesourceneedsthehardwareaddressoftherouter Thesourceexaminesitsroutingtables ThesourcetransmitsARPforinterfaceoftherouters hardwareaddress.

43

IfRemote,WhichRouter?
Typesofroutetableentries
Hostrouteentry Networkrouteentry

TransportLayerTCP/IPProtocols

Receiving gateway typically does one of the Receivinggatewaytypicallydoesoneofthe following


Forwardspacket SendsanICMPreply SendsanICMPreplyindicatingthatitisunclear wheretosendthepacket
GuidetoTCP/IP,ThirdEdtion 45

Source: Chapter5:GuidetoTCP/IPbyLauraChappell

Objectives
Understandthekeyfeaturesandfunctionsof theUserDatagramProtocol Explainthemechanismsthatdrive segmentation,reassembly,andretransmission segmentation reassembly and retransmission fortheTransmissionControlProtocol ChoosebetweenusingUserDatagram ProtocolandTransmissionControlProtocol

UDP and TCP use port numbers to define the source and destination processes or applications

TransportLayerTCP/IP Protocols

47

TransportLayerTCP/IP Protocols

48

Figure23.9Userdatagramformat

Table23.1WellknownportsusedwithUDP

IPheaderprotocolfield=17

UDPlength=IPlength IPheaderslength
23.49 23.50

Figure23.10Pseudoheader forchecksumcalculation

51

23.52

Example 23.2 Figure 23.11 shows the checksum calculation for a very small user datagram with only 7 bytes of data. Because the number of bytes of data is odd, padding is added for checksum calculation. The pseudoheader as well as the padding will be dropped when the user datagram is delivered to IP.

UDPHeaderFieldsandFunctions (continued)
SourcePortNumberfield
Definestheapplicationorprocessthatsendsthe packetusingtheUDPheader

Figure23.11

Well known port numbers (0 Through 1023) Wellknownportnumbers(0Through1023)


Assignedtocoreservices thatsystemsoffer

Registeredportnumbers(1024Through 49151)
Assignedtoindustryapplicationsandprocesses

Dynamicports
23.53 TransportLayerTCP/IP Protocols 54 Usedastemporaryports forspecific

UDP AConnectionlessTransport LayerProtocol


Connectionlessprotocols
Providethesimplestkindoftransportservices

OverviewofUDP
UDPlimitations
Noreliabilitymechanisms Nodeliveryguarantees No connection handling Noconnectionhandling IdentifiesApplicationlayerprotocolconveyed ChecksumforentiremessagecarriedinUDP header Nobufferingservices Nosegmentation
TransportLayerTCP/IP Protocols 56

UDP
U db Usedbyapplicationsthatcontaintheirown li i h i h i connectionorientedtimeoutvaluesandretry counters Runsupto40percentfasterthanTCP

TransportLayerTCP/IP Protocols

55

UDPHeaderFieldsandFunctions
UDPheadersmainfunction
Todefinetheprocessorapplicationthatisusing theIPandUDPNetworkandTransportlayers

UDPHeaderFieldsandFunctions (continued)
DestinationPortNumberField
Definesdestinationapplicationorprocessthat usestheIPandUDPheaders

Length field Lengthfield UDPheaderfields


SourcePortNumberfield DestinationPortNumberfield Lengthfield Checksumfield
57

DefinesthelengthofthepacketfromtheUDP headertotheendofvaliddata

Checksumfieldisoptional

TransportLayerTCP/IP Protocols

58

TCP AConnectionOriented Protocol


Functionsofconnectionorientedprotocols
Createalogicalconnection directlybetweentwo peersonaninternetwork Track the transfer of data and ensure it arrives Trackthetransferofdataandensureitarrives successfully Usesequencenumbertracking Haveatimeoutmechanism Havearetrymechanism
TransportLayerTCP/IP Protocols

Figure 23.16 TCP segment format at least 20 bytes long


IP header - protocol field = 06

59

60

10

Figure23.17Controlfield

Table23.3Descriptionofflagsinthecontrolfield

23.61

TransportLayerTCP/IP Protocols

62

Table23.2WellknownportsusedbyTCP

TransportLayerTCP/IP Protocols

63

23.64

Figure23.13Streamdelivery

TCPHeaderFieldsandFunctions (continued)
WindowSizeField TCPChecksumField UrgentPointerField TCPOptionsField(s)

The bytes of data being transferred in each connection are numbered by TCP. The numbering starts with a randomly generated number.
TransportLayerTCP/IP Protocols

23.65

66

11

OverviewofTCP
TCPoffersconnectionorientedserviceswith
Sequencing,errorrecovery Slidingwindowmechanism

TCP h t TCPhosts
Createavirtualconnection witheachotherusing ahandshakeprocess

TCP
Transfersdataasacontinuousstreamofbytes

MaximumTCPsegmentsizeis65,495bytes
TransportLayerTCP/IP Protocols 67 TransportLayerTCP/IP Protocols 68

TCPStartupConnectionProcess
Beginswithhandshakebetweentwohosts Onehostinitiatesthehandshaketoanother hostto
E Ensurethedestinationhostisavailable th d ti ti h t i il bl Ensurethedestinationhostislisteningonthe destinationportnumber Informdestinationhostofinitiatorssequence number
TransportLayerTCP/IP Protocols 69 TransportLayerTCP/IP Protocols 70

Figure23.18Connectionestablishmentusingthreewayhandshaking

SYN segment and SYN + ACK segment cannot carry data, but they each consume one sequence number. An ACK segment, if carrying no data, consumes no sequence number.
TransportLayerTCP/IP Protocols 71 23.72

12

73

74

TCPHalfOpenConnections
Occurwhenthehandshakeprocessdoesnot endsuccessfullywithafinalACK Halfopenconnection communication sequenceoccursinthefollowingorder sequence occurs in the following order
SYN>>>>> <<<<<ACKSYN <<<<<ACKSYN <<<<<ACKSYN
75 TransportLayerTCP/IP Protocols 76

TCPKeepAliveProcess
Canmaintainconnectionwhenthereisno datasentacrossthewire TCPkeepalives
Di bl d b d f lt DisabledbydefaultonWindows2000,Windows Wi d 2000 Wi d Server2003,andWindowsXP

TCPConnectionTermination
Requiresfourpackets
Host1
SendsaTCPpacketwiththeFINandACKflagsset

Host 2 Host2
SendsanACKinresponse ThensendsaTCPpacketwithFINandACKflagsset

KeepAliveTimesetting
Defineshowlongtowaitbeforesendingthefirst TCPkeepalivepacket
TransportLayerTCP/IP Protocols 77

Host1
ReturnsACKresponse

TransportLayerTCP/IP Protocols

78

13

TransportLayerTCP/IP Protocols

79

TransportLayerTCP/IP Protocols

80

TCPSequenceand AcknowledgmentProcess
Guaranteesthatpacketsareorderedproperly andprotectsagainstmissingsegments Duringhandshakeprocess
E h id f Eachsideofconnectionselectsitsownstarting ti l t it t ti sequencenumber Eachsideincrementsitssequencenumbervalue bytheamountofdataincludedintheoutbound packet
TransportLayerTCP/IP Protocols TransportLayerTCP/IP Protocols

81

82

TCPErrorDetectionandError RecoveryProcess
Retransmissiontimer
Firsterrordetectionanderrorrecovery mechanism Retransmission timeout (RTO) Retransmissiontimeout(RTO)
Valuespecifiedbytimer

Retransmissionoperationincrements
1stretransmit:RTOseconds 2ndretransmit:2xRTOseconds 3rdretransmit:4xRTOseconds TransportLayerTCP/IP 4thretransmit:8xRTOseconds 84 Protocols 5h i 16 RTO d

TransportLayerTCP/IP Protocols

83

14

TCPCongestionControl
Congestion
Theoverloadingofthenetworkorareceiver

Overloadingofthenetwork
Occurs when there is too much data on the Occurswhenthereistoomuchdataonthe networkmedium

Overloadingareceiver
Occurswhenthenumberofdatabytesisgreater thantheadvertisedwindow

Currentwindow
TransportLayerTCP/IP Protocols

Alwaysthelesserofwhatthenetworkand receivercanhandle 85

TransportLayerTCP/IP Protocols

86

TCPCongestionControl (continued)
TCPhasfourdefinedcongestioncontrol mechanisms
SlowStart Congestion Avoidance CongestionAvoidance FastRetransmit FastRecovery

TransportLayerTCP/IP Protocols

87

TransportLayerTCP/IP Protocols

88

TCPSlidingWindow
Usedtodeterminetheamountof unacknowledgeddatathatcangooutonthe wirefromanysender Nagle algorithm Naglealgorithm
Whensmalldatasegmentsarebeingsent,butnot acknowledged,noothersmallsegmentscanbe sent

SillyWindowSyndrome(SWS)
TransportLayerTCP/IP Protocols 89 TransportLayerTCP/IP Protocols

CausedwhenenoughdataissenttoaTCPhostto fillitsreceiverbuffer 90 Puts receiver in a zero window state

15

TCPHeaderFieldsandFunctions
SourcePortNumberField DestinationPortNumberField SequenceNumberField AcknowledgmentNumberField HeaderLengthField

ChoosingBetweenTCPandUDP
BecauseTCPisrobustandreliable
Itcarriesalotofbaggage,including
Additionalheaderfields ExplicitmetamessagesintheformofTCPmessages

Forsomelightweightservices,suchas MicrosoftMessengerService
TCPisoverkillandUDPisusedinstead

TCP
Nolongerasimportantasitoncewasbecause
TransportLayerTCP/IP Protocols 91 TransportLayerTCP/IP Protocols

Longhaulandlocalareanetworkshavesignificantly increasedspeed,capacity,andreliability 92

Summary
Transportlayerprotocolscomeintwotypes
Connectionlessandconnectionoriented

Summary(continued)
TransmissionControlProtocol
Heavyweight,connectionorientedprotocolthat helpsnametheTCP/IPprotocolsuite

UserDatagramProtocol
Th Theconnectionlessprotocolassociatedwith i l l i d ih TCP/IPprotocolsuite

TCP header TCPheader


Longerandmorecomplex, Includesavarietyofflags,values,andmessage types

UDPheaderisshortandsimple,consistingof
AprotocolidentifierintheIPheader Anoptionalchecksumvalue Sourceanddestinationportaddresses
TransportLayerTCP/IP Protocols 93

TransportLayerTCP/IP Protocols

94

Summary(continued)
Appropriate(andhistorical)usesforUDP
ConcentrateonApplicationlayerservicesthat managetheirownreliabilityandconnections

Appropriate (and historical) uses for TCP Appropriate(andhistorical)usesforTCP


Concentrateonprovidingreliabledeliveryofuser services

TransportLayerTCP/IP Protocols

95

16

You might also like