Chapter 4: Transport Layer
Chapter 4: Transport LayerMagda El ZarkiProf. of CSUC Irvine
Chapter 4: Transport LayerOur goals: understand principlesbehind transportlayer services: multiplexing/demultiplexingreliable data transferflow controlcongestion control learn about transportlayer protocols in theInternet: UDP: connectionlesstransportTCP: connection-orientedtransportTCP congestion control
Chapter 4 outline 4.1 Transport-layerservices 4.2 Multiplexing anddemultiplexing 4.3 Connectionlesstransport: UDP 4.4 Principles ofreliable data transfer 4.5 Connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management 4.6 Principles ofcongestion control 4.7 TCP congestioncontrol
Transport services and protocolslogical communicationbetween app processesrunning on different hosts transport protocols run in endsystems send side: breaks appmessages into segments,passes to network layer rcv side: reassemblessegments into messages,passes to app layer more than one transportprotocol available to apps Internet: TCP and UDP provideapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysical
Transport vs. network layernetwork layer: logicalcommunicationbetween hosts transport layer: logicalcommunicationbetween processes relies on, enhances,network layer services
Internet transport-layer protocols reliable, in-orderdelivery (TCP) congestion controlflow controlconnection setup unreliable, unordereddelivery: UDP no-frills extension of“best-effort” IP services not available: delay guarantees bandwidth guaranteesapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworknetworkdata linkphysicaldata linkphysicalnetworkdata linkphysicalapplicationtransportnetworkdata linkphysical
Chapter 4 outline 4.1 Transport-layerservices 4.2 Multiplexing anddemultiplexing 4.3 Connectionlesstransport: UDP 4.4 Principles ofreliable data transfer 4.5 Connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management 4.6 Principles ofcongestion control 4.7 TCP congestioncontrol
Multiplexing/demultiplexingMultiplexing at send host:gathering data from multiplesockets, enveloping each datawith header (later used fordemultiplexing)Demultiplexing at rcv host:delivering received segmentsto correct socket socketapplicationtransportnetworklink ationtransportnetworklinklinkphysicalhost 1physicalhost 2physicalhost 3
How demultiplexing works host receives IP datagramseach datagram has sourceIP address, destination IPaddress each datagram carries 1transport-layer segment each segment has sourceport, and destination portnumbers host uses IP addresses & portnumbers to direct segment toappropriate socket 32 bitssource port #dest port #other header fieldsapplicationdata(message)TCP/UDP segment format
Connectionless demultiplexing Create sockets with portnumbers:DatagramSocket mySocket1 newDatagramSocket(12534);DatagramSocket mySocket2 newDatagramSocket(12535); UDP socket identified bytwo-tuple:(dest IP address, dest port number) When host receives UDPsegment: checks destination portnumber in segmentdirects UDP segment tosocket with that portnumber IP datagrams with samedest port number, butdifferent source IPaddresses and/or sourceport numbers directedto same socket
Connectionless demux (cont)DatagramSocket serverSocket new DatagramSocket(6428);P2SP: 6428DP: 9157clientIP: AP1P1P3SP: 9157DP: 6428SP provides “return address”SP: 6428DP: 5775serverIP: CSP: 5775DP: 6428ClientIP:B
Connection-oriented demux TCP socket identifiedby 4-tuple: source IP addresssource port numberdest IP addressdest port number recv host uses all fourvalues to directsegment to appropriatesocket Server host may supportmany simultaneous TCPsockets: each socket identified byits own 4-tuple Web servers havedifferent sockets foreach connecting client non-persistent HTTP willhave different socket foreach request
Connection-oriented demux(cont)P1P4P5P2P6P1P3SP: 5775DP: 80S-IP: BD-IP:CclientIP: ASP: 9157DP: 80S-IP: AD-IP:CserverIP: CSP: 9157DP: 80S-IP: BD-IP:CClientIP:B
Connection-oriented demux:Threaded Web ServerP1P2P4P1P3SP: 5775DP: 80S-IP: BD-IP:CclientIP: ASP: 9157DP: 80S-IP: AD-IP:CserverIP: CSP: 9157DP: 80S-IP: BD-IP:CClientIP:B
Chapter 3 outline 3.1 Transport-layerservices 3.2 Multiplexing anddemultiplexing 3.3 Connectionlesstransport: UDP 3.4 Principles ofreliable data transfer 3.5 Connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management 3.6 Principles ofcongestion control 3.7 TCP congestioncontrol
UDP: User Datagram Protocol [RFC 768] “no frills,” “bare bones”Internet transportprotocol “best effort” service, UDPsegments may be: lost delivered out of orderto app connectionless: no handshaking betweenUDP sender, receiver each UDP segmenthandled independentlyof othersWhy is there a UDP? no connectionestablishment (which canadd delay) simple: no connection stateat sender, receiver small segment header no congestion control: UDPcan blast away as fast asdesired
UDP: more often used for streamingmultimedia apps loss tolerant rate sensitiveLength, inbytes of UDPsegment,includingheader other UDP uses DNS SNMP reliable transfer over UDP:add reliability atapplication layer application-specificerror recovery!32 bitssource port #dest port #lengthchecksumApplicationdata(message)UDP segment format
UDP checksumGoal: detect “errors” (e.g., flipped bits) intransmitted segmentSender:Receiver:sequence of 16-bitintegers checksum: addition (1’scomplement sum) ofsegment contents sender puts checksumvalue into UDP checksumfieldreceived segment check if computed checksumequals checksum field value: NO - error detected YES - no error detected.But maybe errorsnonetheless? More later . treat segment contents as compute checksum of
Internet Checksum Example Note When adding numbers, a carryout from themost significant bit needs to be added to theresult Example: add two 16-bit integers1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Chapter 4 outline 4.1 Transport-layerservices 4.2 Multiplexing anddemultiplexing 4.3 Connectionlesstransport: UDP 4.4 Principles ofreliable data transfer 4.5 Connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management 4.6 Principles ofcongestion control 4.7 TCP congestioncontrol
Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)
Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)
Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)
Reliable data transfer: getting startedrdt send(): called from above,(e.g., by app.). Pass data todeliver to receiver upper layersendsideudt send(): called by rdt,to transfer packet overunreliable channel to receiverdeliver data(): called by rdtto deliver data to upper layerreceivesiderdt rcv(): called when packetarrives on rcv-side of channel
Reliable data transfer: getting startedWe’ll: incrementally develop sender, receiver sides ofreliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow on both directions! use finite state machines (FSM) to specifysender, receiverstate: when in this“state” next stateuniquely determinedby next eventstate1event causing state transitionactions taken on state transitioneventactionsstate2
Rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver read data from underlying channelWait forcall fromaboverdt send(data)packet make pkt(data)udt send(packet)senderWait forcall frombelowrdt rcv(packet)extract (packet,data)deliver data(data)receiver
Rdt2.0: channel with bit errors underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells senderthat pkt received OKnegative acknowledgements (NAKs): receiver explicitlytells sender that pkt had errorssender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr- sender
rdt2.0: FSM specificationrdt send(data)sndpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λsenderreceiverrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)
rdt2.0: operation with no errorsrdt send(data)snkpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)
rdt2.0: error scenariordt send(data)snkpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)
rdt2.0 has a fatal flaw!What happens if ACK/NAK corrupted? sender doesn’t know whathappened at receiver! can’t just retransmit:possible duplicateHandling duplicates: sender retransmits currentpkt if ACK/NAK garbled sender adds sequencenumber to each pkt receiver discards (doesn’tdeliver up) duplicate pktstop and waitSender sends one packet,then waits for receiverResponse – rdt 3.0
rdt2.1: sender, handles garbled ACK/NAKsrdt send(data)sndpkt make pkt(0, data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&Wait forcall 0 fromaboverdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt)( corrupt(rcvpkt) isNAK(rcvpkt) )udt send(sndpkt)Wait forACK orNAK 0rdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt)Λrdt rcv(rcvpkt) &&( corrupt(rcvpkt) isNAK(rcvpkt) )udt send(sndpkt)ΛWait forACK orNAK 1Wait forcall 1 fromaboverdt send(data)sndpkt make pkt(1, data, checksum)udt send(sndpkt)
rdt2.1: receiver, handles garbled ACK/NAKsrdt rcv(rcvpkt) && notcorrupt(rcvpkt)&& has seq0(rcvpkt)rdt rcv(rcvpkt) && (corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)sndpkt make pkt(ACK, chksum)udt send(sndpkt)rdt rcv(rcvpkt) && (corrupt(rcvpkt)sndpkt make pkt(NAK, chksum)udt send(sndpkt)rdt rcv(rcvpkt) &¬ corrupt(rcvpkt) &&has seq1(rcvpkt)sndpkt make pkt(ACK, chksum)udt send(sndpkt)sndpkt make pkt(NAK, chksum)udt send(sndpkt)Wait for0 frombelowWait for1 frombelowrdt rcv(rcvpkt) && notcorrupt(rcvpkt)&& has seq1(rcvpkt)extract(rcvpkt,data)deliver data(data)sndpkt make pkt(ACK, chksum)udt send(sndpkt)rdt rcv(rcvpkt) &¬ corrupt(rcvpkt) &&has seq0(rcvpkt)sndpkt make pkt(ACK, chksum)udt send(sndpkt)
rdt2.1: discussionSender: seq # added to pkt two seq. #’s (0,1) willsuffice. Why? must check if receivedACK/NAK corrupted twice as many states state must “remember”whether “current” pkthas 0 or 1 seq. #Receiver: must check if receivedpacket is duplicate state indicates whether0 or 1 is expected pktseq #notknow if its last ACK/NAK received OK atsender note: receiver can
rdt2.2: a NAK-free protocol same functionality as rdt2.1, using ACKs only instead of NAK, receiver sends ACK for last pktreceived OK receiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action asNAK: retransmit current pkt
rdt2.2: sender, receiver fragmentsrdt send(data)sndpkt make pkt(0, data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&( corrupt(rcvpkt) Wait forWait forisACK(rcvpkt,1) )ACKcall 0 from0udt send(sndpkt)abovesender FSMfragmentrdt rcv(rcvpkt) &&(corrupt(rcvpkt) has seq1(rcvpkt))udt send(sndpkt)Wait for0 frombelowrdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)receiver FSMfragmentrdt rcv(rcvpkt) && notcorrupt(rcvpkt)&& has seq1(rcvpkt)extract(rcvpkt,data)deliver data(data)sndpkt make pkt(ACK1, chksum)udt send(sndpkt)Λ
rdt3.0: channels with errors and lossNew assumption:underlying channel canalso lose packets (dataor ACKs) checksum, seq. #, ACKs,retransmissions will beof help, but not enoughApproach: sender waits“reasonable” amount oftime for ACK retransmits if no ACKreceived in this time if pkt (or ACK) just delayed(not lost): retransmission will beduplicate, but use of seq.#’s already handles this receiver must specify seq# of pkt being ACKed requires countdown timer
rdt3.0 senderrdt send(data)sndpkt make pkt(0, data, checksum)udt send(sndpkt)start timerrdt rcv(rcvpkt)Λrdt rcv(rcvpkt) &&( corrupt(rcvpkt) isACK(rcvpkt,1) )ΛWaitforACK0Wait forcall 0fromaboverdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,1)timeoutudt send(sndpkt)start timerrdt rcv(rcvpkt)&& notcorrupt(rcvpkt)&& isACK(rcvpkt,0)stop timerstop timertimeoutudt send(sndpkt)start timerrdt rcv(rcvpkt) &&( corrupt(rcvpkt) isACK(rcvpkt,0) )ΛWaitforACK1Wait forcall 1 fromaboverdt send(data)sndpkt make pkt(1, data, checksum)udt send(sndpkt)start timerrdt rcv(rcvpkt)Λ
rdt3.0 in action
rdt3.0 in action
Performance of rdt3.0 rdt3.0 works, but performance stinks ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:dtrans U sender: utilization – fraction of time sender busy sendingU L 8000bits 8 microseconds9R 10 bpssender L/RRTT L / R .00830.008 0.00027microseconds1KB pkt every 30 msec - 33kB/sec thruput over 1 Gbps linknetwork protocol limits use of physical resources!
rdt3.0: stop-and-wait operationsenderreceiverfirst packet bit transmitted, t 0last packet bit transmitted, t L / Rfirst packet bit arriveslast packet bit arrives, send ACKRTTACK arrives, send nextpacket, t RTT L / RU senderL/RRTT L / R .00830.008 0.00027microseconds
Pipelined protocolsPipelining: sender allows multiple, “in-flight”, yetto-be-acknowledged pkts range of sequence numbers must be increasedbuffering at sender and/or receiver Two generic forms of pipelined protocols:selective repeatgo-Back-N,
Pipelining: increased utilizationsenderreceiverfirst packet bit transmitted, t 0last bit transmitted, t L / Rfirst packet bit arriveslast packet bit arrives, send ACKlast bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACKRTTACK arrives, send nextpacket, t RTT L / RIncrease utilizationby a factor of 3!Usender 3*L/RRTT L / R .02430.008 0.0008microseconds
Pipelining ProtocolsGo-back-N: big picture: Sender can have up toN unacked packets inpipeline Rcvr only sendscumulative acks Doesn’t ack packet ifthere’s a gap in packetreception (missing) Sender has timer foroldest unacked packet If timer expires,retransmit all unackedpacketsSelective Repeat: big pic Sender can have up toN unacked packets inpipeline Rcvr acks individualpackets Sender maintainstimer for eachunacked packet When timer expires,retransmit only unackpacket
Selective repeat: big picture Sender can have up to N unacked packetsin pipeline Rcvr acks individual packets Sender maintains timer for each unackedpacket When timer expires, retransmit only unackpacket
Go-Back-NSender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”may receive duplicate ACKs (see receiver) timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window
Go-Back-N contdACK-only: always send ACK for correctly-received pktwith highest in-order seq # may generate duplicate ACKsneed only remember expectedseqnum out-of-order pkt: discard (don’t buffer) - no receiver buffering! Re-ACK pkt with highest in-order seq #
GBN: sender extended FSMrdt send(data)Λbase 1nextseqnum 1rdt rcv(rcvpkt)&& corrupt(rcvpkt)if (nextseqnum base N) {sndpkt[nextseqnum] make pkt(nextseqnum,data,chksum)udt send(sndpkt[nextseqnum])if (base nextseqnum)start timernextseqnum }elserefuse data(data)timeoutstart timerWaitudt send(sndpkt[base])udt send(sndpkt[base 1]) udt send(sndpkt[nextseqnum-1])rdt rcv(rcvpkt) &¬corrupt(rcvpkt)base getacknum(rcvpkt) 1If (base nextseqnum)stop timerelsestart timer
GBN: receiver extended FSMdefaultudt send(sndpkt)ΛWaitexpectedseqnum 1sndpkt make pkt(expectedseqnum,ACK,chksum)rdt rcv(rcvpkt)&& notcurrupt(rcvpkt)&& a)deliver data(data)sndpkt make pkt(expectedseqnum,ACK,chksum)udt send(sndpkt)expectedseqnum ACK-only: always send ACK for correctly-received pktwith highest in-order seq # may generate duplicate ACKsneed only remember expectedseqnum out-of-order pkt: discard (don’t buffer) - no receiver buffering! Re-ACK pkt with highest in-order seq #
GBN inaction
Selective Repeatindividually acknowledges all correctlyreceived pkts receiver buffers pkts, as needed, for eventual in-order deliveryto upper layer sender only resends pkts for which ACK notreceived sender timer for each unACKed pkt sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts
Selective repeat: sender, receiver windows
Selective repeatsenderdata from above :receiverpkt n in [rcvbase, rcvbase N-1] if next available seq # in send ACK(n)timeout(n): in-order: deliver (alsowindow, send pkt resend pkt n, restart timerACK(n) in [sendbase,sendbase N]: mark pkt n as received if n smallest unACKed pkt,advance window base tonext unACKed seq # out-of-order: bufferdeliver buffered, in-orderpkts), advance window tonext not-yet-received pktpkt n in [rcvbase-N,rcvbase-1] ACK(n)otherwise: ignore
Selective repeat in action
Selective repeat:dilemmaExample: seq #’s: 0, 1, 2, 3 window size 3 receiver sees nodifference in twoscenarios! incorrectly passesduplicate data as newin (a)Q: what relationshipbetween seq # sizeand window size?
Chapter 4 outline 4.1 Transport-layerservices 4.2 Multiplexing anddemultiplexing 4.3 Connectionlesstransport: UDP 4.4 Principles ofreliable data transfer(rdt) 4.5 Connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management 4.6 Principles ofcongestion control 4.7 TCP congestioncontrol
TCP: Overview point-to-point: one sender, one receiver reliable, in-ordersteam: byteno “message boundaries” pipelined: TCP congestion and flowcontrol set window size socketdoorsend & receive buffersapplicationwrites dataapplicationreads dataTCPsend bufferTCPreceive buffersegmentRFCs: 793, 1122, 1323, 2018, 2581 full duplex data: bi-directional data flowin same connection MSS: maximum segmentsize connection-oriented: handshaking (exchangeof control msgs) init’ssender, receiver statebefore data exchange flow controlled: sender will notsocketdooroverwhelm receiver
TCP segment structure32 bitsURG: urgent data(generally not used)ACK: ACK #validPSH: push data now(generally not used)RST,
Chapter 4 outline 4.1 Transport-layer services 4.2 Multiplexing and demultiplexing 4.3 Connectionless transport: UDP 4.4 Principles of reliable data transfer 4.5 Connection-oriented transport: TCP segment structure reliable data tran
Part One: Heir of Ash Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 Chapter 24 Chapter 25 Chapter 26 Chapter 27 Chapter 28 Chapter 29 Chapter 30 .
TO KILL A MOCKINGBIRD. Contents Dedication Epigraph Part One Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Part Two Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18. Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 Chapter 24 Chapter 25 Chapter 26
DEDICATION PART ONE Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 PART TWO Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 Chapter 21 Chapter 22 Chapter 23 .
9. Build a sugar-cube pyramid as follows: First make a 5 5 1 bottom layer. Then center a 4 4 1 layer on the rst layer, center a 3 3 1 layer on the second layer, and center a 2 2 1 layer on the third layer. The fth layer is a single 1 1 1 cube. Express the volume of this pyramid as a percentage of the volume of a 5 5 5 cube. 10.
C. Rockwell hardness test LAMINATES RHN LAYER 1 95 LAYER 2 96 LAYER 3 97 LAYER 4 98 Table 4.2 Hardness number RHN rockwell hardness number D. Impact test LAMINATES ENERGY (J) DEGREE (ang) LAYER 1 1.505 105 B. LAYER 2 2.75 114 LAYER 3 3.50 124 LAYER 4 4.005 132 Table 4.3 Impact Test data E.
Office IP Phones Access Layer Distribution Layer Main Distribution Facility Core Switch Server Farm Call Servers Data Center Data/Voice/Video Pipe IDF / Wiring Closet VoIP and IP Telephony Layer 1 - Physical Layer IP Phones, Wi-Fi Access Points Layer 1 - Physical Layer IP Phones, W i-F Access Points Layer 2 - Distribution Layer Catalyst 1950 .
Transport Layer 3-3 3. Transport Layer: Outline 3.1 transport-layer services 3.2 multiple
Transport Management System of Nepal Nepalese transport management is affected by existing topographical condition of the country. Due to this only means of transport used in the country are road transport and air transport. In this paper only road transport is discussed. During the Tenth Plan period, the vehicle transport management
