1 / 56

RObust Header Compression

RObust Header Compression. IETF 66th - RoHC Working Group meeting. Author: Ghyslain Pelletier ghyslain.pelletier@ericsson.com. Presentation Outline. Corrections and Clarifications to RFC 3095 10 mins RoHC framework 10 mins Updated RoHC profiles (RoHCv2) 40 mins

jules
Download Presentation

RObust Header Compression

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. RObust Header Compression IETF 66th - RoHC Working Group meeting Author: Ghyslain Pelletier ghyslain.pelletier@ericsson.com

  2. Presentation Outline • Corrections and Clarifications to RFC 3095 10 mins • RoHC framework 10 mins • Updated RoHC profiles (RoHCv2) 40 mins • RoHC Formal Notation (RoHC-FN) 5 mins • Compression profile for TCP/IP (RoHC-TCP) 5 mins

  3. Corrections and Clarifications to RFC 3095 Purpose of draft-ietf-rohc-rtp-impl-guide Recent changes (-18 to -19) Next steps

  4. RFC 4019 UDP-Lite RTP Profile, 0x0007 UDP-Lite Profile, 0x0008 RFC 3843 IP-only Profile, 0x0004 Includes: - Corrections (normative) - Clarifications - Guidelines No changes to profile versions, this update is required ! Purpose of draft-ietf-rohc-rtp-impl-guide RFC 3095 RoHC Framework Uncompressed, 0x0000 UDP RTP Profile, 0x0001 UDP Profile, 0x0002 ESP/IP Profile, 0x0003 draft-ietf-rohc-rtp-impl-guide RFC 3095 Update

  5. Editorial changes: • New title: RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 • Complete review and re-write by the authors • ”corrigendum” approach to formatting wherever appropriate • Duplicate text and redundancies have been purged out • Restructuring of the document Mostly editorial changes • Document aims at a publication as Proposed Standard • Normatively updates RFC3095 (as well as 3241, 3843, 4019, 4362) Technical changes • Fixed some errors: TS Wraparound algorithm, R-P field and RTP X bit in extension 3, translation table and multiple occurances of the same item, etc. Recent changes (-18 to -19) (1/2)

  6. Recent changes (-18 to -19) (2/2) EXAMPLE: INCORRECT RFC 3095 TEXT (section 4.5.3): "Tsc: Tsc = 0 indicates that TS is not scaled; Tsc = 1 indicates that TS is scaled according to section 4.5.3, using value(TS_STRIDE). Context(Tsc) is always 1. If scaling is not desired, the compressor will establish TS_STRIDE = 1." CORRECTED TEXT: "Tsc: Tsc = 0 indicates that TS is not scaled; Tsc = 1 indicates that TS is scaled according to section 4.5.3, using context(TS_STRIDE). Context(Tsc) is always 1. If scaling is not desired, the compressor will establish TS_STRIDE = 1. If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is present in the extension), field(TS_STRIDE) MUST be ignored and discarded."

  7. Next steps ... • Please read, review and comment. You’ll need this document as much as RFC3095! • Some more fixes -> one more update in August: • Context repairs, TS_STRIDE and TIME_STRIDE (mail 060614) • Updating properties of EXT-3 with UO-1ID (mail 060628) • Re-write section 3.3 to make it clearer and more accurate. • Resubmit to committed reviewers, then slowly proceed to WG last call • Aim to send to IESG for review by end of September?

  8. The RoHC Framework Purpose of draft-ietf-rohc-rfc3095bis-framework Overview of the RoHC Framework Recent changes (-00 to -01) Next steps

  9. Clear separation between framework and profiles: • what is needed to support a ROHC profile • what is common to all profiles • definition of the ROHC channel ”Backward” compatible with framework part of RFC3095 • although RFC3095 is not clear about what is the framework part! • no technical changes, possibly optional additions • editorial improvements, (hopefully) clear definitions Purpose of draft-ietf-rohc-rfc3095bis-framework

  10. RoHC Profiles Packet Formats Context Management Overview of the ROHC Framework ROHC Framework draft-ietf-rohc-3095bis-framework RoHC Channel Multiplexing (CIDs) Initialization of new contexts Padding Feedback Segmentation

  11. Editorial changes: • removed some unused definitions (RTT) • reformatted section 5.2.1 • removed note in 5.2.3.1 Mostly editorial changes • definition of a ”new context” • definition of robustness includes both against losses and ooo delivery • definition of the static and dynamic parts of a context • description of ”payload” field in general packet format definition • operational characteristics common to any RoHC profile Somewhat technical changes • definition of Master Sequence Number (MSN) • packet type identifiers unused by the framework • s/ ”MUST be discarded” / ”MUST NOT be delivered to upper layers” / Recent changes (-00 to -01) (1/2)

  12. Technical changes • UNCOMPRESSED profile 0x0000 • new channel parameter, MAX_R_DEPTH • indicates an estimate of the ooo depth for the channel • optional to negotiate • MAY be used by implementations (e.g. OA approach, decompression and/or context update logic, mode selection, other logic as per RFC4224) • MAY be used by profile definition, for profiles that aim to include some robustness against reordering (e.g. RoHCv2 profiles) Recent changes (-00 to -01) (2/2)

  13. The RoHC context ... The following are conceptual definitions added to help understanding: New context • CID is associated for the first time with a profile in channel lifetime • CID is associated with a different profile than the one in the contet for that CID, using IR (not IR-DYN ! ) Static part of a context • Conceptually, it is the entire state information maintained by an implementation for fields whose change behavior is classified as STATIC, STATIC-KNOWN or STATIC-DEF. Dynamic part of a context • Conceptually, it is the entire state information maintained by an implementation for fields whose change behavior is classified as CHANGING, i.e. any information that is not part of the static context.

  14. RoHC CRCs and their purpose ... • CRC-3 (3-bit CRC) over original, uncompressed header • ”individually” weak • not really suitable to verify decompression when part of the context is assumed damaged • not really suitable to verify a context repair using a single header • BUT provide means to detect context damage from multiple failures • CRC-7 (7-bit CRC) over original, uncompressed header • Provide means to verify both correctness of decompression attempt and decompressor context • CRC-8 (8-bit CRC) over some or all of the IR information • does not cover the original uncompressed header • does not verify correctness of decompression attempt • does not verify correctness of decompressor context • BUT provides enough robustness for a decompressor to update its context with the information covered by the CRC-8 Purpose: Damage Detection and Context Verification, using multiple consecutive headers Purpose: Damage Detection and Context Verification Purpose: Protect transmitted information, such as - ”Channel” Information e.g. CID/profile - uncompressed value of fields, incl. ctrl fields

  15. RoHC feedback and semantics ... The framework draft clarifies the semantics of the feedback messages: (in RFC3095 these may be understood as requests from decompressor) Acknowledgement (ACK) • means ”decompressor believes that its context is valid up to packet with this MSN” Negative ACK (NACK) • means ”decompressor believes that some or all of the dynamic part of the context is invalid” STATIC-NACK • means ”decompressor believes that its entire (static) context is not valid, or it has not been established” ... and means nothing more!!!

  16. Next steps ... • Please read, review and comment! • Freeze document, focus on RoHCv2 profiles • Find 2 committed reviewers and then proceed to WG last call ANY VOLUNTEERS ??? • Aim to WGLC in October 2006 • Aim to submit to IESG for review by November

  17. Short Summary of Impactsof Reordering on RoHC ... for RoHC Profiles based on RFC 3095

  18. RFC 3095-based profiles and reordering The design of 3095 inherently assumes ... no reordering between compressor and decompressor Only robustness against packet losses and small amount of reordering BEFORE the compression point considered when compressing sequentially changing fields Two different robustness algorithms: U/O-mode: uses CRC in every compressed header, and repeats updates L times (optimistic approach) R-mode: uses a reference that must be acknowledged before it is used - cumulative updates with acks, more vulnerable to reordering

  19. Robustness Properties of W-LSB Encoding lsb interpretation interval (size is 2k) Robustness to reordering max delta(SN) = p Robustness to consecutive losses max delta(SN) = (2k-1) - p v_ref upper bound (ref_max) lower bound (ref_min) The robustness to reordering and the robustness to consecutive packet losses for the W-LSB encoding are bound to the same factors: • number of LSB-encoded SN bits(k) in the compressed header format (varies between different header formats in 3095) • offset p of the interpretation interval(differs between profiles) • optimistic approach in U/O-mode (repetition of updates), and • ack:ed reference principle in R-mode (cumulative updates w/ ACKs)

  20. Robustness Properties of RoHC Profiles based on the properties of W-LSB encoding Profile # Profile Name Max Reordering Max Consecutive Losses Specification 0x0000 Uncompressed not sensitive not sensitive RFC 3095 0x0001 RoHC RTP 1 14 RFC 3095 0x0002 RoHC UDP 0 15 RFC 3095 0x0003 RoHC ESP 1 14 RFC 3095 0 15 RFC 3843 0x0004 RoHC IP-Only 0x0X05 RoHC LLA not allowed 14 RFC 3095 0x0006 RoHC-TCP 4 11 Not yet published RFC 4019 0x0007 RoHC RTP/UDP-Lite 1 14 RoHC UDP-Lite RFC 4019 0x0008 0 15 Reference: RFC 4224, section 5.1.1 - http://www.ietf.org/rfc/rfc4224.txt Note: the figures for reordering in the table are limits for a packet to be successfully decompressible, when packets are compressed with maximum possible ratio. Anything outside these range will lead to: - U/O-mode: the packet is discarded; the risk of damage propagation is low - R-mode : the packet is erroneous and may be forwarded to upper layers undetected; the risk of damage propagation is high

  21. Huuum... but W-LSB is NOT the entire story!!! RFC4224 tells us that there is more than the W-LSB encoding that isn’t robust to OOO for RFC3095-based profiles ... • Don’t use R-mode when reordering may occur (masked reference, loss of transparency, lack of CRC verification for all packets) • Do use U/O-mode when reordering may occur • Don’t use ROHC Segmentation • Don’t use reference-based list compression • Do use list compression type 0 • Avoid mode transitions, especially U/O- to R-mode is sensitive RFC4224’s description of the OOO problem is incomplete, but the following was caught anyhow by the proposed implementation solutions (we’ve unfortunately focused on W-LSB mainly, but we missed some more) • longer Optimistic Approach for significant updates (efficiency tradeoff) • control fields (aka TIME_STRIDE, TS_STRIDE, TS_OFFSET and extension 3 with UOR-2) are not verified when updated! • IRs may update Translation Table and control fields without verifying them • ... and there’s plenty of other stuff we probably don’t know ... Things we’ve identified in RFC4224 ... ... and some more we’ve identified later!!!

  22. Recommended Reading – RFC 4224 It contains the basis of what there is to know about RoHC and reordering ( ... that we could think of at the time... ) • Robustness principles of RoHC (as backgroung info) • Consequences of Reordering • How to mitigate the impacts of reordering for RFC-3095 based profile implementations http://www.ietf.org/rfc/rfc4224.txt

  23. Revisiting the Robustness Principles Challenges of header compression, updated Robustness against Packet Losses AND Out-of-Order delivery

  24. Challenges for Header Compression, updated • Compression efficiency • Minimize average header size, “it’s never small enough” • Minimize header size variation • Robustness • before the compressor: • efficiently handle packet losses • efficiently handle re-ordering of packets • between compressor and decompressor: • packet losses shall not be increased from the use of header compression • decompression should be robust to moderate reordering • Compression reliability • Ensure transparency of header compression. Decompressed header must be identical as before compression. • Robust algorithm, e.g., against residual bit errors in headers

  25. Robustness to losses and to OOO delivery Seldom changing fields and reordering • Optimistic Approach (OA) provides upper bound for reordering depth that can safely be handled Dynamically changing fields, encoded using W-LSB, and reordering • Interpretation interval offset sets the upper bound for the reordering depth for which the value of a W-LSB encoded field can possibly be recovered Control fields and reordering • The capacity to verify a control field when updating its value in the context helps to prevent hard-to-detect context damage Robustness to reordering is a tradeoff with robustness against losses

  26. Updated RoHC Profiles RoHCv2 draft-ietf-rohc-rfc3095bis-improvements-02.txt draft-pelletier-rohc-rohcv2-profiles-00.txt Overview of proposal for updated profiles Other issues, and relationship to RFC4224 Next steps

  27. draft-ietf-rohc-rfc3095bis-framework RoHC Framework Uncompressed, 0x0000 draft-pelletier-rohc-rohcv2 UDP RTP Profile, 0x0101 UDP Profile, 0x0102 ESP/IP Profile, 0x0103 IP-Only Profile, 0x0104 UDP-Lite RTP Profile, 0x0107 UDP-Lite Profile, 0x0108 Formal Notation RoHC-TCP Profile, 0x0006 ROHCv2 profiles RFC 3095 RoHC Framework Uncompressed, 0x0000 UDP RTP Profile, 0x0001 UDP Profile, 0x0002 ESP/IP Profile, 0x0003 RFC 3843 IP-only Profile, 0x0004 RFC 4019 UDP-Lite RTP Profile, 0x0007 UDP-Lite Profile, 0x0008

  28. Approach to the update of RoHC profiles (1/2) ... Simpler to implement draft-ietf-rohc-rfc3095bis-improvements: • Strive for simplicity: • no list compression for extension headers • list compression type 0 only • avoid multi-mode, base operation on RoHC-TCP • Don’t overspecify, make a clear specification easily implementable • don’t specify non-protocol features not affecting interoperability (i.e. implementation, e.g. reverse decompression, implementation parameters + signals) • don’t mix pedagogical and conceptual logic with protocol specification (e.g. compressor state mixed with packet type selection, framework VS profile, etc) • Add some known useful features • multiple level of IP headers • constant IP-ID • CONTEXT MEMORY feedback option • Add some new features, e.g. • Improve robustness against out-of-order (ooo) delivery • (Lessons learned since publication of RFC3095) • Blend in RFC4224, Corr. and clarifications + good ideas from other profiles, e.g. RoHC-TCP ... Clarity and Conciseness ... Update with known features ... Add new features e.g. robustness to reordering ... Fix errors and avoid previous ”mistakes”

  29. Approach to the update of RoHC profiles (2/2) Refer to agreed ”improvements” wg draft • What the RoHCv2 work item is: • simplest possible RoHC (features with proven gain only) • maintain equal or similar compression efficiency as RFC3095 under similar operating conditions (e.g. ooo depth and loss rate) • improve interoperability • incorporate lessons learned in the last years since publication • add robustness support against ooo, as one feature among others • What it is not meant to be: • a quick fix for one specific issue • a fix to improve robustness against ooo • What RFC4224 and draft-pelletier-rohc-rohcv2-profiles shows: • a ”quickfix” for ooo, properly done, will look very much like our proposal! (in other words, you can’t get around the problem) • the proposal meets draft-ietf-rohc-3095bis-improvements If you need a quick fix and believe that failure cases not related to the Optimistic Approach and/or to the W-LSB encoding will not be an issue, then implement RFC4224 recommendations instead! ... a remake of past RoHC WG history ... nothing comes for free, but it can be done ...

  30. High-level design choices for RoHCv2 ROHC Profile Packet formats Context management Formal Notation RoHC-TCP SM ++ (robustness ++) Bits-on-the-wire State machines and transition logic Field encodings No Change Feedback Verifying successful decompression Better Usage of CRCs All PT = CRCs, All PT = Updating Which formats update the context

  31. Overview of Proposal for Updated Profiles (1/9) • The robustness requirements have changed. • Both robustness against losses AND against ooo inherent within the design of the solution(s) • Improved robustness to meet new challenge: • decompressor state machine • flexible setting of interpretation interval ratio reordering / losses • control_crc3 covers control fields reorder_ratio and TS_STRIDE in co_common

  32. Overview of Proposal for Updated Profiles (2/9)Header formats RoHCv2 Header formats are different from RFC3095 formats. The RoHCv2 profiles define 7 packet types: • 4 different compressed (CO) formats (PT-0, PT-1, PT-2, co_common) • IR header • IR-DYN header • IR header without payload (IR-PD) Each CO format differ based on control field ip_id_behavior. Format are structured using the concept of chaining.

  33. Overview of Proposal for Updated Profiles (3/9)IR, IR-DYN and IR-PD header formats IR/IR-DYN: • Very similar to IR formats in RFC3095 • some additional control fields • more efficient compression of some fields (such as IP version field) IR-PD: • IR D-bit redefined, for simplicity • IR-PD allows a header type for which the payload has been explicitely dropped • also allows the compression of payload-less packets with the RTP profile 0x0101, which removes some of the many IR-specific options.

  34. general format Add-CID octet first octet of base header 1, 2 or 3 octets of CID first octet of base header Irregular chain ipv4_innermost_irregular udp_with_checksum_irregular rtp_irregular Overview of Proposal for Updated Profiles (4/9)CO header formats PT-0, PT-1, PT-2, co_common irregular chain (example) ip_id (lsb) [ 0, 16 ] udp_checksum [ 16 ] {empty}

  35. pt_0_crc3 0 msn (lsb) CRC-3 pt_1_seq_ts pt_1_seq_id 1 0 1 1 M CRC-3 1 0 1 0 CRC-3 ... ... msn (lsb) ts_scaled ... msn (lsb) ip_id pt_1_rnd 1 0 1 msn (lsb) ... pt_0_crc7 M ts_scaled CRC-3 1 0 0 msn (lsb) ... ... CRC-7 Overview of Proposal for Updated Profiles (5/9)CO base header formats PT-0: • pt_0_crc3, MSN-only packet w/ 3-bit CRC (identical to 3095 UO-0) • pt_0_crc7, MSN-only packet w/ 7-bit CRC PT-1 (CRC-3): Carries one LSB-coded field other than MSN (either TS or IP-ID) • pt_1_rnd, used for non-sequential IP-ID (replaces UO-1 from 3095) • pt_1_seq_id, used for sequential IP-ID (replaces UO-1-ID from 3095) • pt_1_seq_ts (only UDP/RTP and UDP-Lite/RTP profiles) (replaces UO-1-TS from 3095)

  36. pt_2_rnd pt_2_seq_ts pt_2_seq_id 1 1 0 msn (lsb) ... 1 1 0 1 msn (lsb) ... 1 1 0 0 msn (lsb) ... ... ts_scaled ... ts_scaled ... ip_id ... M CRC-7 M CRC-7 ... CRC-7 Overview of Proposal for Updated Profiles (6/9)CO base header formats PT-2 (CRC-7): - Carries one LSB-coded field other than MSN (either TS or IP-ID) - Also carries the M-bit (only UDP/RTP and UDP-Lite/RTP profiles) • pt_2_rnd, used for non-sequential IP-ID, (replaces UOR-2 from 3095) • pt_2_seq_id, used for sequential IP-ID (replaces UOR-2-ID from 3095) • pt_2_seq_ts (only UDP/RTP and UDP-Lite/RTP profiles) (replaces UOR-2-TS from 3095)

  37. co_common 1 1 1 1 1 0 1 M CRC-7 ii ipid_b reor_r df CRC-3 ttf ttp tof top tsi tss ptp lip pad ext reserved ip_id (lsb) [ 0, 8, 16 ] tos_tc [ 0, 8 ] msn (sdvl) [ 8, 16 ] ts_scaled [ variable ] payload_type [ 0, 8 ] ts_stride [ variable ] csrc_list [ variable ] Overview of Proposal for Updated Profiles (7/9)CO base header formats (0x0101) CO_COMMON (CRC-7): • Replaces "UOR-2-with-extension-3“ from 3095 • Can carry practically everything from the dynamic chain of innermost IP header and "endpoint headers". • Can also carry TOS/TC and TTL/HopLimit of outer IP headers. • Carries an additional CRC3 • covers some of the control fields • means to avoid having the decompressor sending ACKs on packets that contained a “bad” control field which was not used during the decompression.

  38. lsb interpretation interval (size is 2k) REORDERING_NONE 0 0 REORDERING_QUARTER 0 1 REORDERING_HALF 1 0 Repeat same type of information until confidence is achieved REORDERING_THREEQUARTERS 1 1 v_ref upper bound (ref_max) lower bound (ref_min) For fields using other encoding(s): Optimistic Approach (OA) can be based on • Estimation of reordering depth (e.g. feedback) • Optional channel parameter: MAX_R_DEPTH SN MAX_R_DEPTH Overview of Proposal for Updated Profiles (8/9)Robust and efficient support against reordering For fields that are LSB encoded: • control field, ”reorder_ratio [2 bits]” • coding method, ”reorder_ratio_choice()”

  39. Packet Type not allowed: The decompressor’s current view of the state of its context does not allow it to attempt decompression of the packet received, as it does not have enough valid information to process it properly. Static Context Damaged Detected (implementation-specific algorithm) The decompressor algorithm has detected a severe problem, possibly following one or more failure to verify a CRC (or some other reason). This is the highest ”severity level” when assuming context damage. The decompressor thus chose not to decompress anything else than IR and IR-DYN packets types Context Damaged Detected (implementation-specific algorithm) The decompressor algorithm has detected a problem, possibly following one or more failure to verify CRC-3 (or some other reason). This is the first ”severity level” when assuming context damage. The decompressor thus chose not to decompress packet types that carry only a small CRC-3. Overview of Proposal for Updated Profiles (9/9) Decompressor State Machine revisited CRC-8 (IR) Failure CRC-8 (IR) Validation CRC-8 (IR) or CRC-8 (IR-DYN) Validation CRC-7 (CO) Verification CRC-8 (IR) or CRC-8 (IR-DYN) Validation CRC-3 (CO) or CRC-7 (CO) Verification No Context Initial Context Full Context Static Context Damage Detected CRC-7 (CO) Failure or Packet Type not allowed Context Damage Detected

  40. PROs CONs • Encoding not too sensitive to reordering [RFC4224] • Usage can be optional: decompressor feeds back it wants it, compressor has final word on using it or not • Possibly saves 1-2 octets but very unfrequently (e.g. at the beginning of a talk spurt for VoIP, or start of silence) Complexity: • Implementation • Interoperability Compression efficiency gain: • Very marginal, if any • Requires additional signalling of control fields and feedback • Would increase the size of pt-1-seq-ts (replaces the UO_1_TS) • Limited number of packet format may hinder timer-based gains (HC sends larger type anyway) The case for Timer-based RTP TS compression Based on the Pros and Cons above, we made a concious choice not to have it in our proposal. There is no real technical issue to add support for it, if the WG has consensus that this is something to include for profile 0x0101.

  41. Relationship to, backward compatibility with RFC3095? New robustness requirements and lessons learned speak for some distance from some aspects of RFC3095 ... • Backward compatibility with RFC3095 and derivative profiles is NOT an aspect that should be considered: • design assumptions and objectives are significantly different • not possible to meet objectives while being closely similar to RFC3095 • no requirements to do so, see improvements draft • Note however that • Most encoding methods are similar • Optimistic Approach and unidirectional operation • Much in common with RoHC-TCP • Much simpler than RFC3095 to implement • Finally, note that • The WG has no requirement whatsoever with respect to compatibility with RFC-3095, rather the opposite. • Use RFC4224 to this end if ooo is your concern (but beware, RFC4224 is not the entire story with respect to reordering). • RFC3095 does have flaws, even without having to support reordering. • There seems to be an agreement in the comments received that the proposed changes make ROHCv2 more robust to both losses and ooo than RoHC -> this is thus the right track imho ... yet the encoding methods, now the only ”complex” part of the RoHCv2 profiles, have a lot in common ... We do not believe or support a solution to the reordering problematic based on small changes to RFC3095, other than implementation guidelines of RFC4224 Should we make this draft a working group document?

  42. Minimal changes to 3095 to support OOO (1/2) Make the following reflexion, in order to ”quickfix” RFC3095 to support robustness against ooo [RFC4224] : • Take RFC3095, first remove R-mode (including mode transitions, mode bits in EXT-3 and in FEEDBACK-2, and related logic) • Disable RoHC segmentation • Change interpretation interval offset P in W-LSB (the robustness to losses is now skewed, some packet types e.g. PT-0 will need more bits most of the time) • Make P configurable (how? new bits in packet format?) • Increase OA to paliate for ooo effects for non-SN based fields

  43. Minimal changes to 3095 to support OOO (2/2) • Hack compressor implementation to become aware of corner cases related to ooo (e.g. control fields updating) • Hack decompressor implementation to become aware of corner cases related to ooo (e.g. control fields updating) • etc ... Make this interoperable, i.e. someone (IETF, 3GPP2 and/or 3GPP) has to back this up with a specification. How simple is this really? Consider that the above only tackles a subset of the problem, and shows that some packet types need anyway to be modified?

  44. Next steps ... • Get consensus to make draft-pelletier-rohc-rohcv2-profiles the working group document for this work item (today?) • Please read, review and comment - contribute to the list if you can • Aim to WGLC in November 2006 • Aim to submit to IESG for review by December 2006

  45. The RoHC Formal Notation Purpose of draft-ietf-rohc-formal-notation Overview of RoHC-FN Recent changes (-09 to -10) Next steps

  46. What is the Formal Notation? • It is purely a documentation tool • Means to be formal, and avoid interpretation ambiguities • Can be used to specify packet formats, i.e • ”bits on the wire” and • encodings for each field ROHC Profile Packet formats Context management Bits-on-the-wire State machines and transition logic Field encodings Verifying successful decompression Feedback Which formats update the context

  47. Elements of the Formal Notation Scoping mechanism {}, ENFORCE() Reversible bindings =:= Control Fields e.g. MSN Fields and Attributes field_x.UVALUE, ULENGTH, UPOSITION field_x.CVALUE, CLENGTH, CPOSITION Encoding Methods encoding(parameter) Structure UNCOMPRESSED, CONTROL, DEFAULT, COMPRESSED Library of common methods static(), irregular(), lsb(), crc() uncompressed_value(), compressed_value() Expressionsand common operator arithmetics

  48. Structure of the Formal Notation • encoding_0 (parameter) { • UNCOMPRESSED { // Defines the ”layout” used for the original header • field_x; • field_y • } • CONTROL { // Defines additional field needed for compression • } • DEFAULT { // Defines default encodings to apply if nothing else • field_y =:= encoding_1(); // Binds a fields parameter to an encoding • field_x =:= encoding_2(); • } • COMPRESSED { // Defines the ”layout” used for compressed format • field_x =:= encoding_3 { • field_x =:= encoding_4(); • ENFORCE(parameter) // Tests a condition, fails the scope if FALSE • } • } • }

  49. Recent changes (-09 to -10) (1/2) Many changes based on last wglc comments received Many changes based on improvements to TCP and RoHCv2 formats • Editorial changes: • Mostly editorial changes • replaced ”structures” with ”encoding methods” • ::= became =:= • Keywords capitalized • new keywords: UNCOMPRESSED, CONTROL, DEFAULT, COMPRESSED • Somewhat technical changes • Technical changes • Many changes based on last wglc comments received • ENFORCE (instead of let) • Diff: http://tools.ietf.org/wg/rohc/draft-ietf-rohc-formal-notation/draft-ietf-rohc-formal-notation-10-from-09.diff.html

  50. Next steps ... • Please read, review and comment! • Freeze document, focus on RoHC-TCP packet formats • ReSubmit to committed reviewers and then proceed to WG last call ANY MORE VOLUNTEERS ??? • Aim to WGLC in August 2006 • Aim to submit to IESG for review by September 2006

More Related