Point-to-Point Links: Framing Section 2.3

Framing Demarcates (Separates) units of transfer Goal Challenge Enable nodes to exchange blocks of data Challenge How can we determine exactly what set of bits constitute a frame? How do we determine the beginning and end of a frame?

Why Framing? Synchronization recovery Link multiplexing Breaks up continuous streams of unframed bytes Link multiplexing Multiple hosts on shared medium Simplifies multiplexing of logical channels Efficient error detection Per-frame error checking and recovery

Framing Approaches Characteristics Sentinel Length-based Clock based Bit- or byte-oriented Fixed or variable length Data-dependent or data-independent length

Framing: Bit Oriented Protocols/ Sentinel-based Beginning and End of Frame Marked with a special bit pattern: 0111 1110 Frame length is data-dependent Problem: what if the special pattern 0111 1110 occurs within frame? Solution: escaping the special characters E.g., sender always inserts a 0 after five 1s … and receiver always removes a 0 appearing after five 1s 01111110 Frame contents

Bit Oriented Protocols/ Sentinel-based: bit stuffing After receiving 5 1s next bit 0 >> stuffed bit >> removed Example bits received 0111 1101 010; bits retained (data): 0111 1110 10 bits received 0111 1100 010; bits retained (data): 0111 1100 10 1 >> bits received 0111 1110 or 0111 1111 0 END of Frame marker 1 Error , frame is discarded; receiver waits for next 0111 1110 to start receiving next frame

Example Bit Oriented Protocol ISO High-Level Data Link Control, HDLC protocol Cyclic Redundancy Check (CRC) field: used to detect transmission errors (Section 2.4)

Framing: Byte Oriented Protocols/ Sentinel-based e.g. Point-to-Point, PPP protocol is similar in concepts as “Bit Oriented/ Sentinel-based” ( p. 84)

Framing: Byte Oriented Protocols/ Counter-based include payload length in header COUNT: specifies how many bytes are contained in the frame’s body e.g. Digital Data Communication Message Protocol, DDCMP Problem: what if the count field gets corrupted? Causes receiver to think the frame ends at a different place Solution: catch when CRC fails Receiver accumulates bytes numbered by bad COUNT field Recognizes that frame is bad using the error detection field And wait for the next sentinel (SYN) for the start of a new frame The beginning of a frame is denoted by sending a special SYN (synchronization) character.

Clock-Based Framing Continuous stream of fixed “time-length” frames Example: Synchronous Optical Network (SONET) Dominant for long-distance transmission over optical networks STS-1: lowest-speed SONET link (51.84 Mbps) STS-1 frames - 125 µsec long All SONET frames are 125 125 µsec long Problems: Frame synchronization Clock synchronization

SONET Frame synchronization Clock synchronization … 2-byte synchronization pattern starts each frame (unlikely to occur in data) Wait until pattern appears in same place repeatedly; once every 810 bytes Clock synchronization NRZ encoding, payload scrambled (XOR’d) with well-known 127-bit pattern Ensures that there are plenty of transitions to allow the receiver to recover the sender’s clock Frame is arranged as 9 rows of 90 bytes each First 3 bytes of each row are overhead. First two bytes of the frame: special bit pattern, used to determine start of frame. Receiver hope pattern appears once every 810 bytes, since each frame is 9 X 90 = 810 bytes long. special pattern appears in the right place enough times >> sync , receiver interprets frame correctly The overhead bytes of a SONET frame are encoded using NRZ, the simple encoding described in the previous section where 1s are high and 0s are low. However, to ensure that there are plenty of transitions to allow the receiver to recover the sender’s clock, the payload bytes are scrambled. This is done by calculating the exclusive-OR (XOR) of the data to be transmitted and by the use of a well-known bit pattern. The bit pattern, which is 127 bits long, has plenty of transitions from 1 to 0, so that XORing it with the transmitted data is likely to yield a signal with enough transitions to enable clock recovery. … Overhead Payload 9 rows 90 columns STS-1 frame

SONET Multiplexing STS-n Since each frame is 125µs long STS-1: lowest speed SONET, runs at 51.84 Mbps STS-N viewed as N STS-1 sharing a fiber STS-48 runs at 2488.32 Mbps…you can go faster Since each frame is 125µs long STS-1 frame is 810 bytes STS-3 frame is 2430 bytes Payload from N STS-1 frames can be linked to form a larger STS-N payload. This is called an STS-Nc link

SONET Multiplexing (continued) A single SONET frame can contain subframes for lower-rate channels STS-N signal can be used to multiplex the bytes of N STS-1 frames STS-3 thought of as consisting of 3 51.84 Mbps links sharing a fiber (bytes interleaved; STS-1 merged byte wise round-robin into STS-3) OR Unmerged (single-source) Payload from N STS-1 frames can be linked to form a larger STS-N payload. The link is called an STS-Nc {concatenated} link (e.g. STS-3c is viewed as a single 155.52 Mbps pipe) HDR STS-1 STS-3