Robust Header Compression (ROHC)‏ An introduction Jonathan Shufelt

Slides:



Advertisements
Similar presentations
IP Header compression in UMTS network Thesis Work Presentation Author: Jukka Raunio Supervisor: Prof. Raimo Kantola Instructor: M. Sc. Antti.
Advertisements

William Stallings Data and Computer Communications 7th Edition
CCNA – Network Fundamentals
1 Chapter 3 TCP and IP. Chapter 3 TCP and IP 2 Introduction Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) User Datagram Protocol.
Chapter 20 Network Layer: Internet Protocol Stephen Kim 20.1.
Data and Computer Communications Updated: 2/9/2009.
1 TCP CSE May TCP Services Flow control Connection establishment and termination Congestion control 2.
EEC-484/584 Computer Networks Lecture 12 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer.
Zero byte ROHC RTP1Lars-Erik Jonsson, Zero-byte ROHC RTP Background, requirements, current status and proposed way forward Lars-Erik Jonsson.
SvanbroLower Layer Guidelines for ROHC 1 Lower Layer Guidelines for Robust Header Compression Krister Svanbro
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 OSI Transport Layer Network Fundamentals – Chapter 4.
EEC-484/584 Computer Networks Lecture 14 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer.
EEC-484/584 Computer Networks Lecture 12 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #2 Header Compression.
MOBILITY SUPPORT IN IPv6
1 Chapter Six - Errors, Error Detection, and Error Control Chapter Six.
EEC-484/584 Computer Networks Lecture 14 Wenbing Zhao (Part of the slides are based on Drs. Kurose & Ross ’ s slides for their Computer.
1 Enhancements to CRTP draft-koren-avt-crtp-enhance-01.txt T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweedly, D. Wing Cisco Systems John Geevarghese.
Header Compression Schemes. Center for TeleInFrastructure 2 Different Header Compression schemes  Compressed TCP – Van Jacobsen RFC 1144  only for TCP/IP.
1 Internet Networking Spring 2006 Tutorial 14 Header Compression.
1 © NOKIA ace ppt/ Marchr, 2000 / KL ACE: A Robust and Efficient IP/UDP/RTP Header Compression Scheme March 31, 2000 Khiem Le, Christopher Clanton,
Department of Electronic Engineering City University of Hong Kong EE3900 Computer Networks Transport Protocols Slide 1 Transport Protocols.
WXES2106 Network Technology Semester /2005 Chapter 8 Intermediate TCP CCNA2: Module 10.
Networking. Protocol Stack Generally speaking, sending an message is equivalent to copying a file from sender to receiver.
SO headers based on CRC Functionality and comparisons to a Keyword approach Lars-Erik Jonsson (Ericsson) ROHC IETF
Error Checking continued. Network Layers in Action Each layer in the OSI Model will add header information that pertains to that specific protocol. On.
Gursharan Singh Tatla Transport Layer 16-May
1 CMPT 471 Networking II ICMP © Janice Regan, 2012.
ICMP (Internet Control Message Protocol) Computer Networks By: Saeedeh Zahmatkesh spring.
© Janice Regan, CMPT 128, CMPT 371 Data Communications and Networking Network Layer ICMP and fragmentation.
Protocol Layering Chapter 10. Looked at: Architectural foundations of internetworking Architectural foundations of internetworking Forwarding of datagrams.
1 Semester 2 Module 10 Intermediate TCP/IP Yuda college of business James Chen
Data Link Control Protocols Dr. Muazzam A. Khan. Flow Control Ensuring the sending entity does not overwhelm the receiving entity —Preventing buffer overflow.
TCP1 Transmission Control Protocol (TCP). TCP2 Outline Transmission Control Protocol.
(Business) Process Centric Exchanges
Chi-Cheng Lin, Winona State University CS 313 Introduction to Computer Networking & Telecommunication Data Link Layer Part I – Designing Issues and Elementary.
Chapter 5 Peer-to-Peer Protocols and Data Link Layer PART I: Peer-to-Peer Protocols ARQ Protocols and Reliable Data Transfer Flow Control.
Data and Computer Communications Chapter 6 – Digital Data Communications Techniques.
Header Compression over Cellular LinksLars-Erik Jonsson, Header Compression for IP-Telephony over Cellular Links Lars-Erik Jonsson (Ericsson.
Overview of ROHC framework
CSC 600 Internetworking with TCP/IP Unit 5: IP, IP Routing, and ICMP (ch. 7, ch. 8, ch. 9, ch. 10) Dr. Cheer-Sun Yang Spring 2001.
Prepared by Engr.Jawad Ali BSc(Hons)Computer Systems Engineering University of Engineering and Technology Peshawar.
ICMPv6 Error Message Types Informational Message Types.
TCP OVER ADHOC NETWORK. TCP Basics TCP (Transmission Control Protocol) was designed to provide reliable end-to-end delivery of data over unreliable networks.
1 © NOKIA 3GPP2-TSGC-SWG1.2/ / BKM RTP Header Compression using RObust Header Compression (ROHC) Keith Miller Nokia Inc.
Video Quality Evaluation for Wireless Transmission with Robust Header Compression Fourth International Conference on Information, Communications & Signal.
© Janice Regan, CMPT 128, CMPT 371 Data Communications and Networking Principles of reliable data transfer 0.
Chi-Cheng Lin, Winona State University CS412 Introduction to Computer Networking & Telecommunication Data Link Layer Part II – Sliding Window Protocols.
TCP/IP1 Address Resolution Protocol Internet uses IP address to recognize a computer. But IP address needs to be translated to physical address (NIC).
DATA LINK CONTROL. DATA LINK LAYER RESPONSIBILTIES  FRAMING  ERROR CONTROL  FLOW CONTROL.
1 Transmission Control Protocol (TCP) RFC: Introduction The TCP is intended to provide a reliable process-to-process communication service in a.
PROTOCOL BASICS. 2 Introduction In chapter 3: Circuits and techniques can be employed to transmit a frame of information between 2 DTEs Error detection.
Powerpoint Templates Data Communication Muhammad Waseem Iqbal Lec # 15.
Chapter 9: Transport Layer
Reliable Transmission
Instructor Materials Chapter 9: Transport Layer
IP Header compression in UMTS network
Data link layer (LLC).
CMPT 371 Data Communications and Networking
Data Link Layer What does it do?
Introduction of Transport Protocols
Transport Layer Unit 5.
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Chapter 5 Peer-to-Peer Protocols and Data Link Layer
IETF 50, Minneapolis Zero-byte ROHC RTP Background, requirements, current status and proposed way forward Lars-Erik Jonsson Ericsson Research, Luleå.
Advanced Computer Networks
Burst Transmission and Acknowledgment
Chapter 5 Peer-to-Peer Protocols and Data Link Layer
Lecture 4 Peer-to-Peer Protocols and Data Link Layer
Presentation transcript:

Robust Header Compression (ROHC)‏ An introduction Jonathan Shufelt

What is Robust Header Compression? First specified in RFC 3095, updated by RFCs 4815 and 3759 created by the ROHC charter. Utilizes the significant redundancy between header fields in consecutive packets from a packet stream. Static field information is only sent initially. Predictability of other fields is used to reduce header size.

What is Robust Header Compression? Relevant information from past packets in the stream is used to maintain a context. This context information is used to compress and decompress subsequent packets. Certain events will cause the context to be updated. Impairments may cause loss of context, or Context Damage. Context Damage leads to incorrect decompression. Provides mechanisms to avoid and recover from Context Damage.

ROHC Terminology Channel – Logical link over which the ROHC header-compressed packets flow. Context Identifiers (CID) – Uniquely identify a stream, useful when a channel is transporting more than one stream simultaneously. Context Damage – Situation where decompressor is unable to decompress headers without error.

ROHC – how is it negotiated? The use of ROHC can be manually configured, or negotiated at the time of the channel’s establishment. State information and compression profiles available can be established at the time the channel is established, or may be predefined. Per context parameters are initialized with IR packets, updated with IR-DYN packets.

Compression and Decompression states ROHC can be characterized as an interaction between two state machines, compressor and decompressor. State machine pairs are associated with a context identifier (CID). The compressor and decompressor each have 3 possible states of operation. The compressor and decompressor states are related to each other. Both machines start in the lowest compression state.

Compression and Decompression states State transitions occur in both the compressor and decompressor. State transitions are not necessarily synchronized. In normal operation, the compressor will temporarily transition to a lower state. The decompressor will only transition to a lower state when context damage is detected.

Compressor States Initialization and Refresh (IR) – Compressor will start here and transition to higher compression states such as FO and SO. First Order (FO) – Efficiently communicates irregularities in the packet stream. Second Order (SO) – Optimized compression is used and only minimal header information is sent in each packet.

Compressor States

Compressor States: Initialization and Refresh (IR) Used to initialize static parts of context at decompresser, or to recover after failure. Complete header information, static and non-static fields, is sent from the compressor in this state. Compressor will remain in this state until it is fairly confident that the decompresser has correctly received the static information.

Compressor States: First Order (FO)‏ Provides efficient communication of irregularities of packet stream. Information about dynamic fields is rarely sent in this state. Sent information in this state is usually partially compressed. Only a few static fields can be updated in this state. Compressor may enter this state from IR or SO states. Transition to FO from IR is a normal step in the state machine transition.

Compressor States: First Order (FO)‏ Transition to FO from SO will occur when a pattern change is present in the packet stream headers. Compressor will remain in FO state until it is confident that decompresser has acquired all parameters of packet stream headers. Changes in fields that are always irregular are communicated in all packets. Some or all packets sent carry context updating information. Detection of corruption of FO state packets is very important to avoid erroneous updates and context inconsistencies.

Compressor States: Second Order (SO)‏ State of optimal compression. Compressor enters this state when header is completely predictable given the sequence number (SN), and confidence that the decompressor has acquired the functions of SN to other fields. Correct decompression of the SN is required to prevent Context Damage. Compressor will transition to lower states when the header no longer conforms to uniform pattern established upon previous context information.

Decompressor States No Context – Initial and lowest compression state. Used for initializing and refreshing context. Static Context – Intermediate compression state. Used when some header fields are still dynamic in nature. Full Context – Highest compression state. Used when all header fields are known from previous packets, or can be predicted from the SN.

Modes of Operation Unidirectional – U-mode Bidirectional Optimistic – O-mode Bidirectional Reliable – R-mode States and Modes abstractions are orthogonal to each other. State abstraction is the same for all modes. Mode controls the logic of state transitions and what actions to perform in each state. The optimal mode of operation will depend on environmental characteristics of the compression protocol. These include feedback abilities, error probabilities and distributions, and effects of header size and variation.

Unidirectional mode – U-mode Packets are sent in one direction only, from compressor to decompressor. Useful in situations where the return path over communications link is unavailable or undesirable. Transitions between compressor states result from periodic timeouts or irregularities in the header field change patterns of the packet stream. Least efficient mode due to periodic refreshes and lack of feedback. Slightly higher probability of loss propagation as compared to bidirectional modes (O-mode and R-mode) of operation. U-mode must be used to start compression. Transition to bidirectional modes will occur when feedback packet indicating a desire for transition is received from decompressor.

Bidirectional Optimistic mode – O-mode Utilizes a feedback channel from decompressor to compressor. Feedback channel is used to send error recovery requests and optionally acknowledgements of significant context updates. Periodic refreshes are not used in O-mode. Maximizes compression while minimizing usage of the feedback channel. Reduces number of damaged headers delivered to upper layers due to residual errors or context invalidation. Frequency of context invalidation may be higher than in R-mode. Prone to context invalidation when long loss or burst errors are present on link.

Bidirectional Reliable mode – R-mode More intensive use of feedback channel when compared to U-mode and O-mode. Stricter logic at compressor and decompressor prevents loss of context except in the case of very high residual Bit Error Rate (BER) conditions. Feedback is sent to acknowledge all context updates, including SN updates. Not every feedback packet is sent to update context in R-mode.

Encoding Methods Least Significant Bits (LSB) – Used for header fields whose values are subject to small value changes. Window-based LSB (W-LSB) – Adds robustness to the LSB encoding algorithm by the compressor using a sliding window reference approach based upon feedback from decompressor. Scaled RTP Timestamp (TS) – Scaled counter method that minimizes the encoding field size. Applied to frame-based codecs. Offset IP-ID – In the case of IPv4 the compressor will compress the offset of the IP-ID value subtracted from the RTP SN instead of the IP-ID value itself.

Encoding Methods Timer-based compression of RTP Timestamp – Utilizes fixed sampling intervals, constant sampling rate, and the fact that packets are generated lock- step with sampling to make use of a linear time-of- day relationship and decompressor’s local clock to approximate the scaled TS in the header. Self-describing variable-length values – Compressor examines the values of up to the first 3 bits, and chooses the number of octets to use based upon their values. Encoded values across several fields in compressed headers – Compressor examines for extension headers, compares the bits available to the bits in the value, and chooses the appropriate packet type.

Residual Errors Packets may become damaged in transit between compressor and decompressor. CRC values calculated by compressor and included in packet are used by decompressor to detect damaged packets. Damage to packets may cause misinterpretation of packet content. Undetected damaged packets may be passed to upper layers.

Impairment Considerations Impairments can cause loss or damage to individual headers, context invalidation, loss propagation, and damage propagation. Impairments to headers can be classified as follows: –Lower layer decoding failure, and subsequent discarding of packet. –Lower layer error detection, and subsequent discarding of packet. –ROHC error detection, and subsequent discarding of packet. –ROHC error detection failure, and subsequent passing of packet to upper layers.

Per-context parameters, profiles Established with IR headers, which contain a profile identifier. Profile identifiers determine the syntax and semantics of the packet type identifiers, and the packet types used in conjunction with the specific context. Profiles: 0x0000 – Uncompressed IP 0x0001 – RTP/UDP/IP 0x0002 – UDP/IP 0x0003 – ESP/IP 0x0004 – IP 0x0005 – Link Layer Assisted 0x0006 – TCP/IP 0x0007 – RTP/UDP-Lite/IP 0x0008 – UDP-Lite/IP

Contexts and context identifiers A context is: - associated with each compressed flow. - used by compressor and decompressor to compress and decompress headers of a packet stream. - identified by Context Identifier (CID). CIDs are sent along with compressed headers and feedback information. CID space, size, for each channel direction may be distinct. CID parameters are negotiated during channel establishment.

ROHC packets and packet types Packet type design constraints: - must be possible to use limited number of packet sizes. - must be possible to send feedback information in separate ROHC packets as well as piggybacked on forward packets. - desirable to allow elimination of CID for one packet stream when few packet streams share a channel. - anticipated that some packets with large headers may be larger than the MTU of very constrained lower layers. Packet design includes: - optional padding - a feedback packet type - optional Add-CID octet - simple segmentation and reassembly mechanism

ROHC feedback Carries feedback from decompressor to compressor. Principal kinds of feedback: ACK – acknowledges successful decompression. NACK – indicates that the dynamic context of the decompressor is out of sync. STATIC-NACK – indicates that the static context of the decompressor is not valid or has not been established. Feedback for ROHC can be realized in many ways such as: –Lower layer specific mechanisms –Dedicated feedback-only channel (i.e. lower layer based, or timing based)‏ –Interspersed among normal compressed packets traveling in same direction –Piggybacking of feedback information in compressed packets traveling in same direction

Unidirectional Mode (U-mode) – compressor state machine Transition logic for compression states in Unidirectional mode based upon three principles: - optimistic approach principle - timeouts - the need for updates Feedback channels may or may not be available. Mode is designed to operate in the absence of a feedback channel.

Unidirectional Mode (U-mode) – compressor state machine Optimistic approach, upwards transition – compressor will transit to a higher compression state when it is fairly confident that the decompressor has received enough information to decompress packets. Timeouts/Updates, downwards transition – compressor must periodically transition to lower compression states (FO and IR) to ensure that the decompressor has the required information for successful decompression of packets. Compression logic and packets used – Compressor will choose the smallest packet that can communicate the desired changes, and has the required number of bits for W-LSB encoding. Feedback – If available, decompressor may send acknowledgements of successful decompression to the compressor. The compressor may then disable, or increase the interval, between periodic IR refreshes.

Unidirectional Mode (U-mode) – decompressor state machine Successful decompression will always move the decompressor to the Full Context state. Repeated failures will force the decompressor to transit to a lower state (Static Context (SC) or No Context (NC) ). The decompressor does not attempt decompression in the lower states without sufficient context information present in received packets. If feedback is present and used by the decompressor, acknowledgements may be used to control compressor state.

Unidirectional Mode (U-mode) – decompressor state machine Decompression is carried out by following these steps: - Decide whether decompression is allowed. - Reconstruct and verify the header. - If header verifies correctly, remain in current state. - If header fails verification, attempt recovery, transitioning to lower state upon recovery failure. Feedback – If available, the decompressor may send acknowledgement packets reducing the frequency of IR packets from the compressor. The decompressor may send repeated acknowledgement packets, but should not do so continuously.

Bidirectional Optimistic Mode (O-mode) – compressor state machine Transition logic for compression states in Bidirectional Optimistic mode is based upon these principles: - optimistic approach principle - feedback - the need for updates Feedback channel is available, and always used.

Bidirectional Optimistic Mode (O-mode) – compressor state machine State transition logic has much in common with Unidirectional mode, but does not use timeouts. Feedback from decompressor to compressor causes transitions to lower compression states, and may optionally be used to cause transitions to higher compression states. Negative acknowledgements (NACKs), downward transition: - NACKs are also known as context requests. - NACKs transitions the compressor to the FO state, and prompts the compressor to send updates (IR-DYN, UOR-2, IR) to the decompressor. - Reception of a STATIC-NACK from decompressor will cause the compressor to transition to the IR state. Optional acknowledgements, upwards transition – positive feedback (ACKs) may be used to transition the compressor to a higher state. Compression logic and packets used – same as those used for the Unidirectional mode.

Bidirectional Optimistic Mode (O-mode) – decompressor state machine Same decompression states and state logic as the Unidirectional case, with different decompression and feedback logic. Decompression logic, timer-based timestamp decompression – May be used to improve compression efficiency when RTP timestamp values are proportional to wall clock time. Feedback logic (O-mode): Decompressor - Three principal kinds of feedback: ACK, NACK, and STATIC-NACK. Use of optional feedback requires decompressor to send optional feedback for the lifetime of the stream. Compressor – IR, IR-DYN, UOR-2, UO-1, and U0-0 may be sent to the decompressor depending on context conditions and state. Decompressor State Actions – Are defined for NC, SC, and FC states and received packet types.

Bidirectional Reliable Mode (R-mode) – compressor state machine Transition logic for compression states in Bidirectional Reliable Mode is based on three principles: - the secure reference principle - the need for updates - negative acknowledgements Feedback logic is available, though more sparsely used.

Bidirectional Reliable Mode (R-mode) – compressor state machine Upwards transition – Determined by secure reference principle. The secure reference principle uses acknowledgements from the decompressor to ensure that context is not lost due to packet losses. Downward transition – Triggered by the need for context updates, or by NACK or STATIC-NACK packets received from the decompressor. Compression logic and packets used – Compression logic starts in the IR state and makes a direct transition to the FO state upon receipt of a valid ACK from the decompressor. Transition to the SO state is dependent upon the presence of a string. The string contains information about the slope and offset values used in compression of packets. Decompressor states and logic – State and state transition logic are the same as in the Unidirectional mode, but not the decompression and feedback logic. Decompression logic – Rules for when decompression is allowed are the same as for U-mode. ACKing scheme in R-mode guarantees that non-decompress able packets are never sent by compressor. Residual errors may cause delivery of unexpected packets for which decompression will not be attempted. CRCs are only carried by update packets from the compressor. Feedback logic – Rules: - Updating packets correctly decompressed cause ACK packets to be sent to compressor. - Upon detection of context damage, send NACK if in FC state, or send STATIC-NACK if in SC state. - Upon receipt of a non-IR packet in NC state, send a STATIC-NACK unless the CRC fails. - Feedback is never sent for packets not updating the context.

ROHC – mode transitions The decision to move from one compression mode to another is taken by the decompressor

ROHC – mode transitions For each context, the compressor and decompressor maintain a variable whose value is the current compression mode for that context. The value of the variable controls, for the context in question, parameters such as; which packet types to use, which actions to be taken, etc. CRCs must be used during all mode transitions as a safeguard. Mode initiations must not be initiated by feedback that is not protected by a CRC. Each compression mode has corresponding mode variables. The behavior of the compressor and decompressor must be restricted during mode transition phases by exception parameters. Exception parameters names and values are all explicitly defined for each case of mode transition.