atenkommunikation 84.8-9 atenkommunikation 84.8-9 Line Protocols Protocol Principles Layering, CL versus CO ervice, ARQ Techniques, equence umbers, Windowing, Flow Control line protocols regulate and control between two devices over pointto-point line basic elements frame synchronization frame protection error detection usually implemented in hardware optional elements connection and line management error recovery flow control usually implemented in Protocol Principles, v4.8 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 Two Important Principles for ata Communication Layering tructuring the complex task of data into smaller pieces by usage of layers A layer is built by the resources of the corresponding protocol peer entities and by the protocol procedures performed between them protocol standards define fields of the control field of a frame (bits seen on the wire) and the behavior of the peers receiving and sending frames A layer is using the services of the lower layers to provide a enhanced service to the upper layer The application layer can access the lower layer (the protocol stack) via API (application programming interface) The layer can access the lower layer via network-card driver Connectionless versus connection-oriented service 9,.I. Lindner /.I. Protocol Principles, v4.8 4 Page - Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Layer Model Cooperation of oftware Layers O Computer A application hardware Tmt_A Rcv_A line protocol signal reference Rcv_B Tmt_B O Computer B application hardware if information has to be transmitted from A to B the application W of device A forwards some data blocks to the W the W transmits the data using the hardware and the line protocol the W of device B receives the data and forwards it to the application W that means, the W provides a service for the application W this service can be connection-less or connection-oriented Protocol Principles, v4.8 5 Protocol Principles, v4.8 7 oftware Aspects Connectionless ervice application uses the (normally part of an operating system, O) in order to exchange data mailbox and queueing techniques allow cooperation of application and within a computer system the uses a line protocol for peer to peer virtual relationship on a given layer hides the details of line protocols and other related tasks from the application procedural approach tation A like packet or telegram service of a PTT atagram's atagram's no error recovery of corrupted frames tation B transmission of data Protocol Principles, v4.8 6 Protocol Principles, v4.8 8 Page - Page - 4
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Line Protocol ervices - CL Connection-Less (CL) - type of service W uses only basic elements (frame synchronization, frame protection, error detection) to transmit data blocks transmission errors causes receiver to discard data blocks best effort service no special frame types are necessary to implement this protocol strategy low implementation requirements for W but error recovery (correction of errors) must be done by application Line Protocol ervices - CO Connection-Oriented (CO) - type of service a channel must be established before data blocks can be transmitted logical connection transmission errors will be detected and corrected by the W using feedback error control retransmission of corrupted data blocks Automatic Repeat request (ARQ) method reliable transmission service for application W error recovery done by W special frame types are necessary (connect, disconnect) more sophisticated W is necessary in order to implement ARQ strategy Protocol Principles, v4.8 9 Protocol Principles, v4.8 Phases with Connection-Oriented ervice Agenda tation A like telephone call of Telecom Connection Request Connection Acknowledgement ATA isconnection Request isconnected Acknowledgment error recovery of corrupted frames is possible by usage of ARQ techniques tation B connection establishment transmission of data clearing of connection Protocol Principles, v4.8 Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 Page - 5 Page - 6
atenkommunikation 84.8-9 atenkommunikation 84.8-9 ARQ Techniques Overview ARQ Variants Connection-oriented service allows error recovery by usage of feedback error control ARQ (Automatic Repeat Request) techniques Receiver acknowledges correct receipt of data frame Idle-RQ Easy to implement (few resources necessary) but inefficient concerning usage of bandwidth in case of full-duplex line Continous-RQ everal methods» elective ACK (e.g. TCP optional ACK procedure)» GoBack (e.g. HLC basic REJ procedure)» Positive Acknowledgement (e.g. TCP basic procedure)» elective Reject (HLC optional REJ procedure) More complex to implement (much more resources necessary), more efficient concerning usage of bandwidth in case of full-duplex line Idle-RQ Continuous-RQ elective ACK (ACK) GoBack Positive ACK elective Reject (REJ) Protocol Principles, v4.8 Protocol Principles, v4.8 5 Idle-RQ versus Continuous-RQ ARQ Principle ata Ack ata Ack ata Ack half duplex protocol Idle-RQ ata Acks full duplex protocol Continuous-RQ ata and Acks are sent continuously!! correct receipt of each transmitted data frame is acknowledged by the receiver special control message (ACK) in opposite direction each data frame transmitted is stored in a retransmission buffer until receipt of corresponding acknowledgement if acknowledgement is not received, data frame will be retransmitted after a out identifiers (, +,...) are necessary to mark the sequence of data frames and to recognize duplicate frames Protocol Principles, v4.8 4 Protocol Principles, v4.8 6 Page - 7 Page - 8
atenkommunikation 84.8-9 atenkommunikation 84.8-9 ecessary Resources for Com-W Layer Generic Frame Format O Computer A application Protocol tate Machine Retransmission List Receive List Timers Control Variables Queues / Mailboxes for operating API O Computer B application YC Control control information = line protocol header frame header payload ATA frame trailer FC E checksum hardware Tmt_A Rcv_A signal reference Rcv_B Tmt_B hardware Frame Type Field: Connect Request, I, ACK, ACK, Identifier Field:, +, Protocol Principles, v4.8 7 Protocol Principles, v4.8 9 ecessary Resources for Com-W Layer (cont.) O Computer A application hardware Frame Types: Connect request / ack isconnect request / ack I, ACK, ACK, REJ Identifiers Tmt_A Rcv_A line protocol signal reference Rcv_B Tmt_B application hardware Protocol Principles, v4.8 8 O Computer B Idle-RQ and Continuous-RQ Facts Idle-RQ old and slow method but small code and only little resources necessary even today used e.g. TFTP (Trivial File Transfer Protocol) half duplex protocol Continuous-RQ requires dramatically more resources than Idle-RQ or connectionless protocols!!! Retransmission Timers Retransmission Buffers Receive Buffers might result in high CPU loads!!! full duplex protocol Protocol Principles, v4.8 Page - 9 Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 Basic equence of Idle-RQ ource of I () estination I () response + I () ACK () I (+) ACK (+) + receive buffer retransmission buffer I () Information Frame containing ata ACK () Acknowledgment Frame Protocol Principles, v4.8 Idle-RQ Idle-RQ Retransmission simple ARQ implementation stop & wait protocol device waits for the acknowledgement (ACK) before sending the next data frame basic method can be improved by ACK two identifiers are necessary (, ) distinction between new data frame or duplicate frame numbering of data frames modulo half duplex protocol full duplex lines can not be efficiently used I () out o Ack? Retransmission! I () ACK () Protocol Principles, v4.8 Protocol Principles, v4.8 4 Page - Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Idle-RQ Retransmission Agenda out I () ACK () o Ack? Retransmission! I () ACK () recognition of duplicate frame Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 5 Protocol Principles, v4.8 7 Idle-RQ Retransmission with optional ACK I () ACK () I () ACK () Protocol Principles, v4.8 6 ACK () ot Acknowledgment Frame Continuous-RQ in order to use full duplex lines more efficiently, device does not wait for acknowledgements for frames already sent Continuous Repeat request (C-RQ) protocols full duplex protocol until receipt of acknowledgments, data frames are buffered in a retransmission list each incoming acknowledgment removes the corresponding data frame from that list receiver stores data frames in receive list to detect duplicates to reorder the sequence Protocol Principles, v4.8 8 Page - Page - 4
atenkommunikation 84.8-9 atenkommunikation 84.8-9 equence of Continuous-RQ Error Control Variants with Continuous-RQ I () + I (+) + + I (+) + + + I (+) + + + + + + + + + ACK () ACK (+) receive list (FIFO) + + + ACK (+) ACK (+) retransmission list (FIFO) ource of I () estination I () several methods for error control (cont.) based on out and positive acknowledgement order of frames is not maintained by the procedure e.g. TCP s original procedure (early TCP) note: today's TCP uses additionally duplicate ACK s to signal the rate of frames leaving the network to the sender based on selective reject selective retransmission done explicitly order of frames is not maintained by the procedure e.g. HLC s REJ option Protocol Principles, v4.8 9 Protocol Principles, v4.8 Error Control Variants with Continuous-RQ several methods for error control based on selective acknowledgement selective retransmission done implicitly order of frames is not maintained by the procedure e.g. TCP (Transmission Control Protocol) ACK option based on multiple and negative acknowledgement also known as GoBack order of frames is maintained by the procedure e.g. HLC (High Level ata Link Control) check pointing technique and REJ option e.g. CMP (igital ata Link Control Management Protocol) Protocol Principles, v4.8 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 Page - 5 Page - 6
atenkommunikation 84.8-9 atenkommunikation 84.8-9 elective Acknowledgement principle every data frame is exclusively confirmed if acknowledgment is not received, corresponding data frame will be sent again and stored at the end of the retransmission list in case of retransmission data frames may not remain in sequence (scenario ) receiver must recognize duplicate frames and discard them (scenario ) each transmitted data frame starts an individual r which will be reset, if acknowledgement is received if out occurs data frame is sent once again (scenario ) elective Acknowledgement I () + I (+) + + I (+) + + + I (+) + + + ACK () + + + ACK (+) triggers implicitly retransmission of I (+) at + + + ACK (+) ACK (+) ACK (+) + + + I (+) + + + ACK (+) recognition of duplicate frames Protocol Principles, v4.8 Protocol Principles, v4.8 5 elective Acknowledgement I () + I (+) + + I (+) + + + I (+) ACK () + + + ACK (+) triggers implicitly retransmission of I (+) at + + + ACK (+) ACK (+) + + + I (+) + + + ACK (+) reordering of frames necessary elective Acknowledgement I () +.. + + I (+) out for frame + ACK () ACK (+) + + I (+) ACK (+) recognition of duplicate frames Protocol Principles, v4.8 4 Protocol Principles, v4.8 6 Page - 7 Page - 8
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 7 GoBack I () + I (+) + + I (+) + + + I (+) + + + ACK () + + + ACK (+) I(+) and I(+) are + + + skipped at!!! + ACK (+) Protocol Principles, v4.8 9 I (+) I (+)... reordering of frames not necessary GoBack principle in case of errors, all data frames since will be requested again by ACK() (egative Ack.) all following frames are discarded by receiver until frame with correct sequence number arrives reordering is not necessary in this case W at receiver could be kept more simple a single acknowledgments could confirm multiple data frames (multiple acknowledgement) often use to spare number of Ack s in opposite direction each transmitted data frame starts an individual r which will be reset, if acknowledgement is received if out occurs data frame is sent once again (scenario ) GoBack I () + I (+) + + I (+) + + + I (+) + + + ACK () ACK (+) acknowledges all frames up to I (+) at -> multiple acknowledgment + + + + + + + ACK (+) ACK (+) ACK (+) Protocol Principles, v4.8 8 Protocol Principles, v4.8 4 Page - 9 Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 GoBack I () +.. + + I ( +) out for frame + ACK () I ( +) + ACK (+) Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 4 Protocol Principles, v4.8 4 GoBack 4 Positive Acknowledgement I () + I (+) out for frame ACK () I(+) is skipped at!!! + I () + I (+)... ACK () principle data frames will be confirmed as long as frames arrives in sequence multiple acknowledgement can be used by receiver if data frames get out of sequence, confirmation is stopped nevertheless, all following data frames will be stored each transmitted data frame starts an individual r which will be reset, if acknowledgement is received if out occurs data frame is sent once again (scenario ) data frames which are already stored in the receiver can be confirmed with multiple acknowledgements when missing data frame arrives (scenario ) Protocol Principles, v4.8 4 Protocol Principles, v4.8 44 Page - Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Positive Acknowledgement Agenda I () + I (+) + + I (+) out for frame + + + + I (+) ACK () + + + + + + + + + I (+) + + + + + + reordering of frames necessary ACK (+) Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 45 Protocol Principles, v4.8 47 Positive Acknowledgement elective Reject I () + I (+) + + I (+) + + + I (+) + + + ACK () ACK (+) acknowledges all frames up to I (+) at -> multiple acknowledgment + + + + + + + ACK (+) ACK (+) ACK (+) principle data frames will be confirmed as long as frames arrives in sequence multiple acknowledgement can be used by receiver in case of an error, only the data frame causing the error will be requested explicitly through REJ() by the receiver in case of retransmission data frames may not remain in sequence (scenario ) each transmitted data frame starts an individual r which will be reset, if acknowledgement is received if out occurs data frame is sent once again (scenario ) Protocol Principles, v4.8 46 Protocol Principles, v4.8 48 Page - Page - 4
atenkommunikation 84.8-9 atenkommunikation 84.8-9 elective Reject elective Reject I () + I (+) + + I (+) + + + I (+) REJ (+) triggers explicitly retransmission of I (+) at, ACK (+) acknowledges all frames up to I (+) at -> multiple acknowledgment ACK () + + + REJ (+) + + + I (+) ACK (+) I () +.. + + I (+) out for frame + ACK () ACK (+) I (+) ACK (+) + + + + + + reordering of frames necessary + + recognition of duplicate frames Protocol Principles, v4.8 49 Protocol Principles, v4.8 5 elective Reject I () + I (+) + + I (+) + + + I (+) + + + ACK () ACK (+) acknowledges all frames up to I (+) at -> multiple acknowledgment + + + + + + + ACK (+) ACK (+) ACK (+) Protocol Principles, v4.8 5 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 5 Page - 5 Page - 6
atenkommunikation 84.8-9 atenkommunikation 84.8-9 equence umber identifiers of data frames are implemented by increasing numbers sequence numbers the number used in I-frames send sequence number () the number used in ACK/ACK/REJ-frames receive sequence number (R) register variables are necessary V(), V(R) must be initialized (set to ) by connection setup handling of V(), V(R), (), and (R) will be explained in next slides for GoBack V(), V(R) with GoBack receiver only accepts I-frames with () = V(R) after successful receipt of a frame V(R) will first be increased by one and then acknowledgment with (R) = V(R) will be sent therefore receipt of ACK with (R) = x means that all I-frames until x- are confirmed Protocol Principles, v4.8 5 Protocol Principles, v4.8 55 V(), V(R) with GoBack V() indicates the sequence number of the next I-frame that will be sent V(R) indicates the expected sequence number of the next in-sequence I-frame to be received this value will be seen in (R) prior to sending an I-frame, the value of () is set to the value of V() afterwards V() is increased by one GoBack V (): 4 V (R): I () I () I () I () () receive buffer 4 ACK () ACK () ACK () ACK (4) (R) Protocol Principles, v4.8 54 Protocol Principles, v4.8 56 Page - 7 Page - 8
atenkommunikation 84.8-9 atenkommunikation 84.8-9 GoBack V (): 4 I () I () I () I () ACK () Protocol Principles, v4.8 57 ACK () I () I () V (R): ACK () Initializing / Transmission Pause connection establishment initializes V() and V(R) after connection establishment connection is maintained by keepalive messages during transmission pauses example for keepalive technique exchange of HELLO (request / poll) and ACK (response) ACK is used for acknowledgment as well as for connection maintenance because of this an ACK() only confirms all frames up to - and not up to sender can distinguish between a keepalive response and acknowledgement of a new data frame Protocol Principles, v4.8 59 GoBack Initializing / Keepalive V (): 4 I () I () I () I () ACK () ACK () ACK () ACK (4) multiple acknowledgement V (): x x connect request receive buffer connect confirm.. hello I () ACK () ACK () V (R): 4 V (R): x Protocol Principles, v4.8 58 Protocol Principles, v4.8 6 Page - 9 Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Keepalive Piggyback Acknowledgement V (): 4 4 4 5 5 5 4 4 4 I () hello I (4) ACK (4).. ACK (4) ACK (5) 4 V (R): 4 4 4 5 retrans. list A > B v (r) V () A V (R) v (s) 4 4 5 I (,) I (,) I (,) I (,) () n (r) receive buffer B I (,) I (,) I (,) 4 5 4 I (4,) I (5,) 5 4 4 5 4 5 6 4 4 4 5 4 I (,4) n (s) (R) retrans list B -> A receive buffer Protocol Principles, v4.8 6 Protocol Principles, v4.8 6 Piggyback Acknowledgement confirmation of every data frame is only appropriate for data flow in one direction acknowledgment frames produce unnecessary overhead with full duplex data traffic acknowledgments contained in data frames in opposite direction can avoid that overhead piggyback acknowledgement if no backward data frame is waiting for transmission ACK frame will be sent still Protocol Principles, v4.8 6 ata Flow in both irections data frames contain both send sequence number and receive sequence number of backward direction now I-frames and ACK/ACK-frames can arise in both directions devices must contain both V()- and V(R)-registers, retransmission and receive lists (), (R), V() und V(R) control data transfer from A to B n(s), n(r), v(s) und v(r) control data transfer from B to A Protocol Principles, v4.8 64 Page - Page -
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Windowing without a restriction of the number of unconfirmed data frames, continuos-rq would require infinite number of identifiers and buffer memory for that reason, the amount W of data frames stored for retransmission must be limited W = send window if limit is reached, sending of additional data frames is stopped until receipt of acknowledgement indicates that window is opened again windowing liding Windowing 4 5 6 7 8 9 ent and already acknowledged Event t: Ack = 6 Window W = 5 Usable window... can't send until window moves Protocol Principles, v4.8 65 Protocol Principles, v4.8 67 Principle of Windowing Consequences of Windowing Event t: Window W = 5 4 5 6 7 8 9 ent and already acknowledged Ack = 4 ent but not yet acknowledged Will send as soon as possible Usable window can't send until window moves... windowing reduces the buffer memory for retransmission buffer and receive-list buffer size of retransmission buffer = W * maximum frame size windowing reduces the number of identifiers numbering of data frames can be done by a modulo operation e.g. GoBack with send window = W needs W+ identifiers because of worst case scenario next slide data frames can be numbered modulo W+ e.g. elective Acknowledgement with send window = W needs W identifiers because of worst case scenario data frames can be numbered modulo W Protocol Principles, v4.8 66 Protocol Principles, v4.8 68 Page - Page - 4
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Windowing with umbering Modulo W+ Time to Transmit a given umber of Bytes GoBack and send-window W means W+ Identifier and numbering with modulo W+ erialization elay (in ms) = [ ( umber of Bytes * 8 ) / ( Bitrate in sec ) ] * Window W = 5 4 5 4 5 ent and already acknowledged ent but not yet acknowledged Will send as soon as possible Usable window can't send until window moves... Bitrate 9,6 kbit/s 48 kbit/s 8 kbit/s,48 Mbit/s Mbit/s Mbit/s 55 Mbit/s 6 Mbit/s Gigabit/s umber of Byte elay in msec ( - ) elay in msec ( - ) elay in msec ( - ) elay in elay in elay in msec ( - ) msec ( - ) msec ( - ) elay in msec ( - ) elay in msec ( - ) elay in msec ( - ) Bit,5,467,8,78,488,,,6,, Byte,8,66667,65,96,8,8,5,,8 PCM- 6,666667 5,,,5,56,56,65,4,56 ATM cell 5 44,66667 8,8,5,7,44,44,75,68,44 Ethernet 64 5,,666667 4,,5,5,5,,8,5 X.5 56, 4,666667 6,,,48,48,,9,48 IP 576 48, 96, 6,,5,468,468,979,748,468 Ethernet.58.65, 5, 94,875 5,99688,44,44,7848,954,44 FR 8.9 6.86,666667.65, 5,, 6,556,6556,48,56,6556 TCP 65.54 54.6,666667.9, 4.95,875 55,9988 5,47 5,47,84,8488,547 kbit/s = bit/s!!! KByte = 4 Byte!!! Protocol Principles, v4.8 69 Protocol Principles, v4.8 7 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Propagation (ignal) elay Tp = Propagation elay (in ms) = [ ( istance in m ) / ( velocity in m/sec ) ] * istance v=.km/s elay in msec ( - ) v=.km/s elay in msec ( - ) CPU Bus cm,5, m,5, R, V4/V.8 5 m,75,5 LA, Copper, RJ45 m,5, LA, FO, X./V.-V. km,5, Local ubscriber Line,5 km,5,8 WA Link Repeater km,5, WA Link Repeater km,5, WA FO Link Repeater. km 5,, WA FO Link Repeater. km 5,, atellite Link 4. km,, atellite Link 5. km 5, 66,6666667. km 5,,. km 5,, Total elay = erialization elay + Propagation elay + (witching elay) Protocol Principles, v4.8 7 Protocol Principles, v4.8 7 Page - 5 Page - 6
atenkommunikation 84.8-9 atenkommunikation 84.8-9 How Long is a Bit? Length (in m) = [ ( / ( bitrate per sec) ] * [ ( velocity in m/sec ) ] Bitrate Bit Length in meter Bit Length in meter Analogue Modem 9,6 kbit/s 8, 5, Analogue Modem 48 kbit/s 466,67 65, 64 kbit/s 5, 4687,5 I (B) 8 kbit/s 56,5 4,75 PCM-, E,48 Mbit/s 97,66 46,48 Token Ring 4 4 Mbit/s 5, 75, Ethernet Mbit/s,, Token Ring6 6 Mbit/s,5 8,75 Fast Ethernet, FI Mbit/s,, ATM TM, OC- 55 Mbit/s,9,94 ATM TM4, OC- 6 Mbit/s,,48 Gigabit Ethernet Gigabit/s,, OC-48,5 Gigabit/s,8, Gigabit Ethernet Gigabit/s,, Copper LWL - Free pace. km /sec. km / sec Protocol Principles, v4.8 7 How Large should be the Window ize? choice of window size is determined by response ( = round trip RTT) x (propagation + serialization) delay plus response delay of partner bandwidth (bit rate) of channel [available buffer size transmitter/receiver] principle to achieve the optimum: the sender s window must be big enough so that the sender can fully utilize the channel volume the channel volume can be expressed by the elay-bandwidth Product window size W in bytes = RTT x BW Protocol Principles, v4.8 75 Propagation elay and umber of Bits on a given Link early Empty Pipe with Idle-RQ and W = ource km Tp =,5ms,5 bits estination kbit/s W = Vienna t = s KB ata Tokyo.5 Mbit/s 5 bits Mbit/s ource km Tp = ms bit estination kbit/s Ack This pipe allows storing of.5 Mbit/s 5 ms = 55, bit 64 KB of data. ource 5 km Tp = 67ms. bits Mbit/s estination t = 5 ms Idle-RQ only allows one frame to be outstanding. That means W =!!! 67 bits.67. bits kbit/s Mbit/s Assume KByte (4 byte) maximum frame size, then the maximal achievable rate is (4 8) bit /.5 s kbit/s Protocol Principles, v4.8 74 Protocol Principles, v4.8 76 Page - 7 Page - 8
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Full Pipe with Continous-RQ and W = 64 W = 64 Vienna t = s t = 5 ms KB ata I (6)... I() Ack()... Ack (64) Tokyo.5 Mbit/s This pipe allows.5 Mbit/s 5 ms = 55, bit 64 KB of data. This situation corresponds with a true sliding window Continous-RQ (C-RQ) allows several frames to be outstanding. With KByte maximum Frame ize optimum would be W = 64!!! Protocol Principles, v4.8 77 Optimal Window ize - liding Window optimal window size (Continuous-RQ) acknowledgments arrive just in to keep the window always open sliding window requirement for optimum window size W in bytes in minimum equal to RTT x BW if window size is smaller than RTT x BW transmission will be stopped until acknowledgments arrive jumping window Idle RQ behaviour in worst case with W = if window size is too large in case of errors many good frames must be retransmitted (see Go Back ) Protocol Principles, v4.8 79 Only Half Pipe Used with C-RQ and W = W = Vienna t = s t = 5 ms capacity unused Ack()... Ack () KB ata I ()... I() Tokyo.5 Mbit/s With KByte maximum Frame ize and W = the pipe could be used only half the!!! This pipe allows.5 Mbit/s 5 ms = 55, bit 64 KB of data. This situation corresponds with a true jumping window Protocol Principles, v4.8 78 Timers - Retransmission Timeout the value for retransmission outs with line protocols can be easily calculated using the following parameters bitrate maximum data frame size worst case at receiver to generate an acknowledgment size of acknowledgment frame calculation for network protocols with varying transmission delays is more complex adaptive process is necessary Protocol Principles, v4.8 8 Page - 9 Page - 4
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Agenda Flow Control Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview O Host A application hardware Tmt_A Rcv_A flow control indicating congestion signal reference Rcv_B Tmt_B O Host B application hardware Protocol Principles, v4.8 8 Protocol Principles, v4.8 8 Flow Control if data frames arrive faster than application is able to process, receiver runs out of available buffer storage and good frames must be discarded by the receiver discarded data frames will cause retransmission but they will be still discarded because of lack of buffers therefore receiver should control the rate of transmission of data frames flow control overload/congestion situation indicated to the sender using flow control messages sender stops and waits until receiver is able to process frames again Flow Control windowing could be used to implement flow control receiver does not generate acknowledgements in case of congestion sender will stop transmission if send window is closed problem with windowing after out unconfirmed frames will be retransmitted after a defined amount of unsuccessful retransmissions, the connection is considered to be broken therefore flow control is based on separate flow control frames and windowing Protocol Principles, v4.8 8 Protocol Principles, v4.8 84 Page - 4 Page - 4
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Flow Control typically used flow control messages TOP, e.g. HLC s Receiver ot Ready (RR) GO, e.g. HLC s Receiver Ready (RR) in case of congestion receiver signals TOP on receipt of TOP sender will suspend transmitting in the worst case, sender will use the send window before stopping transmission receiver signals GO when data flow can resume TOP and GO may contain (R) and hence be used for acknowledgement Flow Control / Keepalive in case of full duplex data TOP and GO control frames are used for flow control in both directions in some cases TOP and GO frames are further used for connection management keepalive procedure if no data frames are waiting for transmission a GO frame can signal keepalive to the partner if traffic was suspended by TOP a periodic repetition of TOP can signal keepalive to the partner in both cases keepalives maintain the connection Protocol Principles, v4.8 85 Protocol Principles, v4.8 87 Flow Control Flow Control / Adaptive Windowing I () I () I () I () ACK()+TOP ACK()+TOP Protocol Principles, v4.8 86 ACK()+TOP... ACK()+GO ACK(4)+GO W = 6 window size could be constant or dynamic during life of a connection constant window size is used e.g. by HLC, X.5 if window size is dynamic a start value is negotiated during connection establishment actual window size will be dynamically adjusted to an optimal value receiver continuously advertises optimal value (e.g. based on availability free buffer memory) advertised window size = -> TOP advertised window size > -> GO adaptive windowing e.g used by TCP Protocol Principles, v4.8 88 Page - 4 Page - 44
atenkommunikation 84.8-9 atenkommunikation 84.8-9 Agenda Introduction Layer Model and ervice Types ARQ Techniques Introduction Idle RQ Continuous RQ elective Acknowledgement GoBack Positive Acknowledgement elective Reject equence umbers and Windowing elay Bandwidth Product Flow Control HLC Overview Protocol Principles, v4.8 89 HLC Frame Format hex7e Flag (F) Address (A) Control (C) Information (I) FC Flag (F) 8-6 bits 8-6 bits 6 or bits end equence umber () upervisory Code Code P/F P/F P/F Receive equence umber (R) Receive sequence number (R) hex7e Protocol Principles, v4.8 9 Code 4 5 6 7 P / F = Poll / Final Bit Information Frame, I-Frame upervisory Frame, -Frame Unnumbered Frame, U-Frame HLC upervisory Frames High-level ata Link Control most widely used data link control protocol based on building elements synchronous transmission bit-oriented line protocol using bitstuffing Continuous RQ with GoBack, piggybacked ACK P/F procedure (see appendix chapter for details) provides many options half-duplex and full-duplex transmission (see appendix chapter for details) point-to-point and multipoint configuration (see appendix chapter for details) switched or non-switched channels upervisory Code P/F Receive equence umber (R) RR (Receiver Ready) = meaning of ACK plus GO REJ (Reject) = meaning of ACK RR (Receiver ot Ready) = meaning ACK plus TOP REJ (elective Reject) Protocol Principles, v4.8 9 Protocol Principles, v4.8 9 Page - 45 Page - 46
atenkommunikation 84.8-9 atenkommunikation 84.8-9 HLC ata Link ervices Unnumbered Frames HLC can provide connection-oriented service setup of connection done by U-frames RM, ARM, ABM, UA I-frames and -frame can be used only after connection setup I, RR, RR, REJ, REJ clearing of a connection done by U-frames IC, UA HLC can provide connectionless service only U-frames can be used UI for data transport Code P/F Code Command UI RM IC UP R R R R IM ARM RET ARME RME ABM XI ABME Response UI R UA R R R R RIM FRMR M XI Protocol Principles, v4.8 9 Protocol Principles, v4.8 95 Frame-Types HLC Example: Initializing / Keepalive / First ata Frame A -> B Connection-Oriented I Information RR Receiver Ready REJ Reject RR Receiver ot Ready REJ elective Reject RM et ormal Response Mode ABM et Async Balanced Mode ARM et Async Response Mode RME et RM Extended Mode ABME et ABM Extended Mode ARME et ARM Extended Mode IC isconnect UA Unnumbered Acknowledge RET Reset FRMR Frame Reject Connection-Less UI Unnumbered Information Miscellaneous XI Exchange Identification UP Unnumbered Poll IM et Initialization Mode RIM Request Initialization Mode R- on-reserved V (): A B receive buffer ABM UA.. RR () hello RR () hello ack I (,) first data frame A->B RR () acknowledgement of first data frame R M Request isconnect isconnect Mode V (R): Protocol Principles, v4.8 94 Protocol Principles, v4.8 96 Page - 47 Page - 48
atenkommunikation 84.8-9 atenkommunikation 84.8-9 HLC Example: ata Frames A->B, B->A with piggyback ACK HLC Example: Flow Control V (): 4 4 4 4 A W = 6 I (, ) I (, 4) I (, 5) I (.) I (,) I (,) I (,) B receive buffer I (, ).. I( 4, ) RR (4) B has nothing to transmit therefore no piggyback acknowledgement RR() TOP RR() RR()... RR() GO RR(4) V (R): 4 Protocol Principles, v4.8 97 Protocol Principles, v4.8 99 HLC Example: Keepalive HLC Family V (): 4 4 4 5 5 5 5 4 4 4 I (, ) RR (4).. RR () hello RR (4) hello ack I (4, ) 4 RR (5) LAPB - Link Access Procedure Balanced link layer protocol for X.5 LAP - Link Access Procedure -Channel I V. - used on I terminal adapters for multiplexing HLC LAPM - Link Access Procedure for Modems PPP - Point-to-Point Protocol encapsulates network PUs and identifies protocol type LC - ynchronous ata Link Control (IBM) V (R): 4 4 5 LAPB (X.5) LAP (I) V. (I) LLC (LAs) LAPM (V.4) Frame Relay PPP LC (A) Protocol Principles, v4.8 98 Protocol Principles, v4.8 Page - 49 Page - 5