1 / 24

CSS432 Point-to-Point Links Textbook Ch2.1 – 2.5

CSS432 Point-to-Point Links Textbook Ch2.1 – 2.5. Professor: Munehiro Fukuda. Basic Knowledge about Links. Full-duplex versus Half-duplex Full Half Local cable types Category 5 twisted pair Coax Multimode fiber LED-based, 2km

giannini
Télécharger la présentation

CSS432 Point-to-Point Links Textbook Ch2.1 – 2.5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSS432 Point-to-Point LinksTextbook Ch2.1 – 2.5 Professor: Munehiro Fukuda CSS 432

  2. Basic Knowledge about Links • Full-duplex versus Half-duplex • Full • Half • Local cable types • Category 5 twisted pair • Coax • Multimode fiber LED-based, 2km • Single-mode fiber laser-diode-based, 40km • Carrier-supported cables/fibers • DS1 (T1): 1.544Mbps, 24-digital voice circuits of 64 Kbps each • DS3 (T3): 44.736Mbps, 28 DS1 links • STS-1 (OC-1): Synchronous Transport signal, the base link speed= 51.840Mbps • STS-3, 12, 48, 192 (OC-3, OC-12, OC-48, OC-192) at time t at time u CSS 432

  3. Basic Knowledge (Cont’d) Voice line 28.8~56Kbps • Last-Mile Links • POTS: Plain Old Telephone Service • ISDN: Integrated Services Digital Network • ADSL: Asynchronous Digital Subscriber Line • VDSL: Very high data rate Digital Subscriber Line • Wireless Links • AMPS, PCS, GSM: Wide-area analog/digital-based mobile phone services • IEEE 802.11: wireless LAN with up to 54Mbps transfer rate • BlueTooth radio interface: 1Mpbs piconet in 10m CODEC Digital line 64-128Kbps 1.554-8.448Mbps 16-640Kbps 12.96~ 55.2Mbps STS-N CSS 432

  4. Focusing on ADSL Long distance Residence B Residence A To telephone switch 255 frequencies for downstream 31 use for upsreams 2 taken for control • Preparing 286 frequencies and agreeing at the available frequencies between two modems • Fitting to most usages where a user tends to retrieve Internet information. CSS 432

  5. Bits 0 0 1 0 1 1 1 1 0 1 0 0 0 0 1 0 NRZ Encoding • Signals propagate over a physical medium • modulate electromagnetic waves • e.g., vary voltage • Encode binary data onto signals • e.g., 0 as low signal and 1 as high signal • known as Non-Return to zero (NRZ) • Consecutive 1s and 0s • Baseline wander: if the receiver averages signals to decide a threshold • Clock recovery: both sides must be strictly synchronized CSS 432

  6. Alternative Encodings • Non-return to Zero Inverted (NRZI) • Encode 1: make a transition from current signal • Encode 0: stay at current signal to encode a zero • solves the problem of consecutive 1s • Signal flips every 1 is encountered. • Manchester • Transmit XOR of the NRZ encoded data and the clock • Only 50% efficient. • Used by Ethernet/Token Ring 0 1 CSS 432

  7. 4B/5B Encoding • Every 4 bits of data encoded in a 5-bit code • 5-bit codes selected to have • no more than one leading 0 • no more than two trailing 0s • See textbook Table 2.4 on page 79 • Thus, never get more than three consecutive 0s • Resulting 5-bit codes are transmitted using NRZI • Achieves 80% efficiency • Because 5th bit is redundant. • Used by FDDI 01??? but not 001?? ??100 but not ?1000 CSS 432

  8. Bits 0 0 1 0 1 1 1 1 0 1 0 0 0 0 1 0 NRZ Clock Manchester NRZI Encoding Example CSS 432

  9. Framing • Break sequence of bits into a frame • Typically implemented by a network adaptor Bits Node A Adaptor Adaptor Node B Frame CSS 432

  10. Frame error 8 16 16 8 Frame error Beginning Ending Header Body CRC sequence sequence Approaches • Sentinel-based • delineate frame with special pattern: 01111110 • e.g., HDLC, SDLC, PPP • problem: ending sequence appears in the payload • solution: bit stuffing • sender: insert 0 after five consecutive 1s • receiver: delete 0 that follows five consecutive 1s • Counter-based • include payload length in header • e.g., DDCMP • problem: count field corrupted (frame error) • solution: • Wait for the next beginning sequence • Catch when CRC fails CSS 432

  11. Approaches (cont) • Clock-based • each frame is 125us long • e.g., SONET: Synchronous Optical Network • STS-n (STS-1 = 51.84 Mbps) Interleaved every byte: keep 51Mbps for each STS-1 CSS 432

  12. Error Detections • Add k bits of redundant data to an n-bit message • want k << n (i.e. k is extremely small as compared to n) • e.g., k = 32 and n = 12,000 (1500 bytes) in CRC-32 • Parity Bit • Internet Checksum Algorithm • Cyclic Redundancy Check CSS 432

  13. 1 0 1 1 0 1 0101001 1101001 1011110 0110100 1011111 0001110 0 1111011 Parity Parity bits • Odd parity • Even parity • Two-dimensional parity Data Parity byte CSS 432

  14. Internet Checksum Algorithm • View message as a sequence of 16-bit integers; • Convert each 16-bit integer into a ones-complement arithmetic • Sum up each integer • Increment the result upon a carryout • Example: Ones-complement message u_short cksum(u_short *buf, int count) { register u_long sum = 0; while (count--) { sum += *buf++; if (sum & 0xFFFF0000) { // carry occurred, so wrap around sum &= 0xFFFF; sum++; } } return ~(sum & 0xFFFF); } 5: 0 00000000 00000101 3: 0 00000000 00000011 -5: 0 11111111 11111010 -3: 0 11111111 11111100 -5 + (-3): 1 11111111 11110110 w/ carry: 0 11111111 11110111 This corresponds to -8 What if 5 and 3 were changed In 6 and 2 ? CSS 432

  15. Cyclic Redundancy Check • Represent n-bit message as n-1 degree polynomial • e.g., MSG=10011010 as M(x) = x7 + x4 + x3 + x1 • Let k be the degree of some divisor polynomial • e.g., C(x) = x3 + x2 + 1 receiver sender M(x)2k – M(x) 2k % C(x) = C(x)-divisible message: P(x) If P(x) % C(x) == 0 P(x) was sent successfully CSS 432

  16. 10011010000 eor 1101 1001 eor 1101 1000 eor 1101 1011 eor 1101 1100 eor 1101 1000 eor 1101 101 Just appended CRC (cont) • Sender polynomial M(x) • M(x) = 10011010, C(x) = 1101, thus k = 3 • M(x)23 = 10011010000 (<< 3) • M(x)23 % C(x) = 101 • M(x)23– M(x)23 % C(x) = 10011010101 = P(x) • Noise polynomial E(x) • Receiver polynomial P(x) + E(x) • E(x) = 0 implies no errors • (P(x) + E(x)) % C(x) == 0 if: • E(x) was zero (no error), or • E(x) is exactly divisible by C(x) • To retrieve M(x): P(x)/ 23, (truncate the last 3 bits) CSS 432

  17. 1 0 0 1 x2 1 1 x2 1 0 0 1 1 0 0 x1 x1 0 0 0 1 0 0 1 0 0 0 1 0 0 x0 x0 0 1 1 0 0 0 1 0 0 1 CRC Calculation Using Shift Register sender receiver C(x) = 1101 M(x) M(x) CRC + M(x) CRC CRC’ If CRC == CRC’, no errors Example: M(x) = 10011010 0 000 010 000 01011001 000 01 000 0101100 000 0 000 010110 101 will be transferred. 000 000 01011 00 000 0101 CSS 432

  18. Frame Transfer Algorithms Sender Receiver Frame 0 Ack 0 Frame 1 Ack 1 Frame 0 Ack 0 Sender Receiver … Time … • Stop and wait • Stop a transmission and wait for ack to return or timeout • Add 1-bit sequence number to detect a duplication of the same frame • Sliding window • Allow multiple outstanding (un-ACKed) frames • Upper bound on un-ACKed frames, called window CSS 432

  19. Stop and Wait timeout // Test 2: client stop-and-wait message send ---------------------------------- int clientStopWait( UdpSocket &sock, const int max, int message[] ) { int retransmits = 0; // # retransmits int ack; // prepare a space to receive ack // transfer message[] max times for ( int sequence = 0; sequence < max; ) { message[0] = sequence; // message[0] has a sequence number sock.sendTo( (char *)message, MSGSIZE ); // udp message send // until a timeout (1500msecs) occurs // keep calling sock.poolRecvFrom( ) // if an ack came, exame if its ack sequence is the same as my sequence // if so, increment my sequence and go back to the loop top // if a timeout occurs, resend the same sequence and increment retransmits } return retransmits; } 2 0 1 1 seq=1 seq=1 tardy ack=1 ack=0 seq=0 // Test 2: server reliable message receive ------------------------------------ void serverReliable( UdpSocket &sock, const int max, int message[] ) { int ack; // an ack message // receive message[] max times for ( int sequence = 0; sequence < max; ) { sock.recvFrom( (char *)message, MSGSIZE ); // udp message receive // check if this is a message expected to receive // if so, send back an ack with this sequence number and increment sequence } } 2 1 0 2 discarded CSS 432

  20. Stop and Wait • Problem: Can’t utilize the link’s capacity • Example 1 • 1.5Mbps link x 45ms RTT = 67.5Kb (8KB) • If the frame size is 1KB and the sender waits for 45ms RTT • 1KB for 45ms RTT • 1/8th link utilization • Example 2 • Ping from uw1-320-21 to uw1-320-22: 0.200msec = 2 x 10-4sec • 1Gbps x (2 x 10-4) = 109 x 2 x 10-4 = 2 x 105 = 200Kbits = 25KB • Unless you send 25KB for every 0.2msec, you make the network idle • Or, you should send 25KB ÷ 1.5KB/packet = 16.7 packets consecutively. CSS 432

  21. Sliding Window // Test 3: client sliding window + early-retransmission ----------------------- int clientSlidingWindow( UdpSocket &sock, const int max, int message[], const int windowSize ){ int retransmits = 0; // # retransmits int ack; // prepare a space to receive ack int ackSeq = 0; // the ack sequence expected to receive // transfer message[] max times for ( int sequence = 0; sequence < max || ackSeq < max; ) { if ( ackSeq + windowSize > sequence && sequence < max ) { // within the sliding window message[0] = i; // message[0] has a sequence number sock.sendTo( (char *)message, MSGSIZE ); // udp message send // check if ack arrived and if ack is the same as ackSeq, increment ackSeq // increment sequence } else { // the slinding window is full! // until a timeout (1500msecs) occurs // keep calling sock.poolRecvFrom( ) // if an ack came, exame if ack >= ackSeq // if so, ackSeq = ack + 1 // else resend the message with this ack number and increment retransmits // if a timeout occurs, resend the same ackSeq and increment retransmits } } return retransmits; } window max = 5 3 7 6 3 5 3 3 8 2 4 1 0 3 lost lost // Test 3: server early retransmission ---------------------------------------- void serverEarlyRetrans(UdpSocket &sock, const int max, int message[], const int windowSize ){ int ack[3]; // an ack message bool array[max]; // indicates the arrival of message[i] for ( int j = 0; j < max; j++ ) array[j] = false; // no message has arrived yet // receive message[] max times for ( int sequence = 0; sequence < max; ) { sock.recvFrom( (char *)message, MSGSIZE ); // receive a UDP message // if message[0] is the same as sequence. // mark array[sequence], and scan array[sequence] through to array[max] // advance sequence to the last consecutive true element’s index +1. // else // mark arrray[message[0]]. // send back the ack for a series of messages I received so far, ack[0] = sequence } } 3 sequence 7 3 7 8 0 3 3 2 7 1 CSS 432

  22. Sliding Window CSS 432

  23. Sequence Number Space • SeqNum field is finite; sequence numbers wrap around • MaxSeqNum: Sequence number space must be larger than # outstanding frames • SWS: Sender’s Window Size • RWS: Receiver’s Window Size • SWS <= MaxSeqNum-1 is not sufficient • suppose 3-bit SeqNum field (0..7) • SWS=RWS=7 • sender transmit frames 0..6 • arrive successfully, but ACKs lost • sender retransmits 0..6 • receiver expecting 7, 0..5, but receives second incarnation of 0..5 • SWS < (MaxSeqNum+1)/2 or 2 x SWS – 1 < MaxSeqNum CSS 432

  24. Reviews • Encoding (NRZ, NRZI, Manchester, and 4B/5B) • Framing (Sentinel and counter-based) • Error Detections (Parity, Internet checksum, and CRC) • Stop-and-wait • Sliding window • Exercises in Chapter 2 • Ex. 2 and 5 (4B/5B, NRZI, and bit stuffing) • Ex. 16 (Internet Checksum) • Ex. 18 (CRC) • Ex. 24 (Sliding Window) CSS 432

More Related