University of Roma Sapienza Telecomunicazioni Docente: Andrea Baiocchi DIET - Stanza 107, 1 piano palazzina P. Piga Sede: Via Eudossiana 18 E-mail: andrea.baiocchi@uniroma1.it Corso di Laurea in Ingegneria Gestionale A.A. 2014/2015 About errors Delay is preferable to error. [Thomas Jefferson] E' men male l'agitarsi nel dubbio, che il riposar nell'errore. [Alessandro Manzoni] There are no errors in these slides, except this one. [anonymous joke]
Programma 1. SERVIZI E RETI DI TELECOMUNICAZIONE 2. ARCHITETTURE DI COMUNICAZIONE E MODI DI TRASFERIMENTO 3. FONDAMENTI DI COMUNICAZIONI 4. MULTIPLAZIONE E ACCESSO MULTIPLO 5. LO STRATO DI COLLEGAMENTO 6. LO STRATO DI RETE IN INTERNET 7. LO STRATO DI TRASPORTO IN INTERNET Strato di collegamento! Introduzione, servizio offerto e funzioni! Delimitazione delle trame! Recupero degli errori! Esempio di protocollo di data link! Point-topoint protocol (PPP)
DL (Data Link): servizio! I canali di comunicazione che collegano nodi adiacenti lungo un cammino sono i collegamenti (link)! collegamenti cablati! collegamenti wireless! Le unità di dati scambiate dai protocolli a livello di link sono chiamate trame (frame).! I protocolli a livello di strato di collegamento si occupano del trasporto di trame lungo un singolo canale di comunicazione. DL: modo di funzionamento! Il servizio può essere fornito con connessione:! utilizzazione del servizio articolata in tre fasi (instaurazione, trasferimento, abbattimento)! legame logico tra le PDU scambiate (possibilità di controllo di flusso e di sequenzialità) senza connessione:! modalità con riscontro (acknowledged)! modalità senza riscontro (unacknowledged)
DL: architettura! Ogni link utilizza un proprio protocollo di DL! La trame sono create e terminate dalle entità alle due estremità del link IP IP link1 link1 link2 link2 phy1 phy1 phy2 phy2 IP Dovè il DL? 8 Tanenbaum, Wetherall, Reti di calcolatori Pearson 2012
Funzioni del DL-Servizio! Le funzioni di un protocollo di strato di collegamento sono:! la delimitazione delle PDU (trame)! la rivelazione degli errori binari e di sequenza dei dati! il recupero degli errori (corretto trasferimento delle trame)! il controllo di flusso! la gestione (instaurazione, abbattimento e reinizializzazione) della connessione di strato di collegamento! l accesso multiplo, nei mezzi multi-accesso (MAC)! l indirizzamento delle trame (accesso multiplo) Strato di collegamento! Introduzione, servizio offerto e funzioni! Delimitazione delle trame! Recupero degli errori! Esempio di protocollo di data link! Point-topoint protocol (PPP)
Un flusso di byte: (a) senza errori, (b) con un errore. 11 Tanenbaum, Wetherall, Reti di calcolatori Pearson 2012 Delimitazione e stuffing nei protocolli orientati al byte 12 Tanenbaum, Wetherall, Reti di calcolatori Pearson 2012
Delimitazione e stuffing nei protocolli orientati al bit! Flag = 01111110! Per evitare che una sequenza di dati nel corpo della trama coincida con un Flag, rendendo così impossibile la delimitazione della trama, si opera con la tecnica del bit stuffing in emissione e del bit destuffing in ricezione Flag Contenuto della trama Flag Regola di stuffing! In emissione, si aggiunge uno 0 dopo ogni sequenza di cinque 1 consecutivi entro il corpo della trama (bit stuffing), indipendentemente da quale sia la cifra seguente! In ricezione si contano le cifre 1 consecutive: se se ne incontrano cinque, si esamina la cifra successiva; se questa è un 1, la sequenza di cifre binarie è un Flag ; in caso contrario, lo 0 che si incontra è necessariamente di riempimento e deve quindi essere eliminato.! sequenza originaria di cifre binarie 1 0 1 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0! sequenza dopo l'operazione di riempimento 1 0 1 1 1 1 1 0 1 1 1 1 1 0 1 0 1 1 0 1 1 1 1 1 0 0 0 1 1 1 1 1 0 1 0 0
Regola di stuffing! In emissione, si aggiunge uno 0 dopo ogni sequenza di cinque 1 consecutivi entro il corpo della trama (bit stuffing) indipendentemente da quale sia la cifra seguente! In ricezione si contano le cifre 1 consecutive: se se ne incontrano cinque, si esamina la cifra successiva; se questa è un 1, la sequenza di cifre binarie è un Flag ; in caso contrario, lo 0 che si incontra è necessariamente di riempimento e deve quindi essere eliminato.! sequenza originaria di cifre binarie 1 0 1 1 1 1 1 1 1 1 1 1 1 0 1 1 0 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0! sequenza dopo l'operazione di riempimento 1 0 1 1 1 1 1 0 1 1 1 1 1 0 1 0 1 1 0 1 1 1 1 1 0 0 0 1 1 1 1 1 0 1 0 0 Strato di collegamento! Introduzione, servizio offerto e funzioni! Delimitazione delle trame! Recupero degli errori! Esempio di protocollo di data link! Point-topoint protocol (PPP)
Principles of Reliable data transfer! important in app., transport, link layers! top-10 list of important networking topics!! characteristics of unreliable channel will determine complexity 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 determine complexity 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 determine complexity of reliable data transfer protocol (rdt) Reliable data transfer: getting started rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data(): called by rdt to deliver data to upper send side receive side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel
Reliable data transfer: getting started We ll:! incrementally develop sender, receiver sides of reliable data transfer protocol (rdt)! consider only unidirectional data transfer! but control info will flow on both directions!! use finite state machines (FSM) to specify sender, receiver state: when in this state next state uniquely determined by next event state 1 event causing state transition actions taken on state transition event actions state 2 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 channel call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) sender 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 sender that pkt received OK! negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors! sender 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 specification rdt_send(data) sndpkt = make_pkt(data, checksum) call from above rdt_rcv(rcvpkt) && isack(rcvpkt)! sender ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) call from below rdt_rcv(rcvpkt) && notcorrupt(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 what happened at receiver!! can t just retransmit: possible duplicate Handling duplicates:! sender retransmits current pkt if ACK/NAK garbled! sender adds sequence number to each pkt! receiver discards (doesn t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response rdt2.1: sender, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt)! rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(0, data, checksum) call 0 from above ACK or NAK 1 rdt_send(data) ACK or NAK 0 call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum)!
rdt2.1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) 0 from below 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) rdt2.1: discussion Sender:! seq # added to pkt! two seq. # s (0,1) will suffice. Why?! must check if received ACK/NAK corrupted! twice as many states! state must remember whether current pkt has 0 or 1 seq. # Receiver:! must check if received packet is duplicate! state indicates whether 0 or 1 is expected pkt seq #! note: receiver can not know if its last ACK/NAK received OK at sender
rdt2.2: a NAK-free protocol! same functionality as rdt2.1, using ACKs only! instead of NAK, receiver sends ACK for last pkt received OK! receiver must explicitly include seq # of pkt being ACKed! duplicate ACK at sender results in same action as NAK: retransmit current pkt rdt2.2: sender FSM call 0 from rdt_rcv(rcvpkt) above && notcorrupt(rcvpkt) && isack(rcvpkt,1)! rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) rdt_send(data) sndpkt = make_pkt(0, data, checksum) ACK 1 rdt_send(data) ACK 0 call 1 from above sndpkt = make_pkt(1, data, checksum) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0)! Error channel No packet erasure
rdt2.2: receiver FSM rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) 0 from below extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack0, chksum) 1 from below rdt_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq0(rcvpkt)) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) Error channel No packet erasure rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs)! checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits reasonable amount of time for ACK! retransmits if no ACK received in this time! if pkt (or ACK) just delayed (not lost):! retransmission will be duplicate, but use of seq. # s already handles this! receiver must specify seq # of pkt being ACKed! requires countdown timer
rdt3.0 sender rdt_rcv(rcvpkt)! call 0from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) )! Wait for ACK1 rdt_send(data) sndpkt = make_pkt(0, data, checksum) start_timer rdt_send(data) Wait for ACK0 call 1 from above sndpkt = make_pkt(1, data, checksum) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) )! timeout start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt)! rdt3.0 in action
rdt3.0 in action rdt performance! Main issue: throughput! C = unreliable capacity (bit/s)!! = net (average) capacity offered by rdt to upper layer entities! It must be! < C: utilization U =!/C.! The value of U depends on two facts:! Upper layer offered traffic can be low! Intrinsic rdt limitations! Assumption: saturation traffic, i.e. upper layer entity always have packets to send! Upper bound on rdt utilization performance
ARQ protocols! Protocols for reliable data transfer are generally referred to as Automatic Repeat request (ARQ) protocols in the technical literature! Three paradigms:! STOP & WAIT! GO-BACK-N! SELECTIVE REPEAT! ARQ paradigms are listed in order of increasing efficiency and complexity! Rdt 3.0 is the stop&wait case stop-and-wait operation first packet bit transmitted, t = 0 last packet bit transmitted, t = L / C sender RTT receiver first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L/C
Performance of stop&wait! rdt3.0 works, but performance stinks! ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: d trans = L C = 8000bits 10 9 bps = 8microseconds U sender : utilization fraction of time sender busy sending! 1 kbyte pkt every 30 msec -> 33 kbyte/s throughput over 1 Gbps link! rdt protocol limits use of physical resources! Pipelined protocols! Pipelining: sender allows multiple, in-flight, yet-to-beacknowledged pkts! range of sequence numbers must be increased! buffering at sender and/or receiver Two generic forms of pipelined protocols:! go-back-n! selective repeat
Pipelining Protocols Go-back-N: big picture:! Sender can have up to N unacked packets in pipeline! Rcvr only sends cumulative acks! Doesn t ack packet if there s a gap! Sender has timer for oldest unacked packet! If timer expires, retransmit all unacked packets Selective Repeat: big pic! Sender can have up to N unacked packets in pipeline! Rcvr acks individual packets! Sender maintains timer for each unacked packet! When timer expires, retransmit only unack packet Go-Back-N Sender:! 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 Receiver:! ACK-only: always send ACK for correctly-received pkt with highest in-order seq #! may generate duplicate ACKs! need only remember expectedseqnum! out-of-order pkt:! discard (don t buffer) -> no receiver buffering!! Re-ACK pkt with highest in-order seq # GBN in action
One more example of GBN 45 Tanenbaum, Wetherall, Reti di calcolatori Pearson 2012 Pipelining: increased utilization first packet bit transmitted, t = 0 last bit transmitted, t = L / C sender receiver RTT ACK arrives, send next packet, t = RTT + L / C first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Increase utilization by a factor of 3! W
Window size and utilization! In general, with a static window size of W the average utilization is! There is a critical window size, namely the minimum value of W that attains maximum utilization! It depends on the Bandwidth Delay Product (BDP) Selective Repeat! receiver individually acknowledges all correctly received pkts! buffers pkts, as needed, for eventual in-order delivery to upper layer! sender only resends pkts for which ACK not received! sender timer for each unacked pkt! sender window! N consecutive seq # s! again limits seq #s of sent, unacked pkts
Selective repeat: sender and receiver windows Selective repeat sender data from above :! if next available seq # in window, send pkt timeout(n):! resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n 1]:! mark pkt n as received! if n smallest unacked pkt, advance window base to next unacked seq # receiver pkt n in [rcvbase, rcvbase+n-1]! send ACK(n)! out-of-order: buffer! in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-n,rcvbase-1]! ACK(n) otherwise:! ignore
Selective repeat in action Sequence numbers and window size Example:! seq # s: 0, 1, 2, 3! window size=3! receiver sees no difference in two scenarios!! incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size?
Strato di collegamento! Introduzione, servizio offerto e funzioni! Delimitazione delle trame! Recupero degli errori! Esempio di protocollo di data link! Point-topoint protocol (PPP) Point to Point Data Link Control! one sender, one receiver, one link: easier than broadcast link:! no Media Access Control! no need for explicit MAC addressing! e.g., dialup link, ISDN line! popular point-to-point DLC protocols:! PPP (point-to-point protocol)! HDLC: High level data link control (Data link used to be considered high layer in protocol stack!! PPP is specified in RFC 1661.
PPP Design Requirements [RFC 1557]! packet framing: encapsulation of network-layer datagram in data link frame! carry network layer data of any network layer protocol (not just IP) at same time! ability to demultiplex upwards! bit transparency: must carry any bit pattern in the data field! error detection (no correction)! connection liveness: detect, signal link failure to network layer! network layer address negotiation: endpoint can learn/configure each other s network address PPP non-requirements! no error correction/recovery! no flow control! out of order delivery OK! no need to support multipoint links (e.g., polling) Error recovery, flow control, data re-ordering all relegated to higher layers!
PPP Data Frame! Flag: delimiter (framing)! Address: does nothing (only one option)! Control: does nothing; in the future possible multiple control fields! Protocol: upper layer protocol to which frame delivered (eg, PPP-LCP, IP, IPCP, etc)! info: upper layer data being carried! check: cyclic redundancy check for error detection Framing and byte Stuffing! data transparency requirement: data field must be allowed to include flag pattern <01111110>! The DLE character is used to stuff both flag and DLE characters occurring within the frame boundaries.! Receiver:! When searching for a starting flag, two consecutive flag characters are silemtly discarded.! After having found a single flag (start flag), drop every DLE and keep the subsequent character, until a new flag with no preceding DLE is found.! Two consecutive PPP frame can be separated by a single flag character.! Specs in RFC 1662.
PPP Data Control Protocol Before exchanging networklayer data, data link peers must! configure PPP link (max. frame length, authentication)! learn/configure network layer information! for IP: carry IP Control Protocol (IPCP) msgs (protocol field: 8021) to configure/learn IP address