40 likes | 145 Vues
This document delves into the architecture of Robust Header Compression (RFC 3095), focusing on the key concepts such as channel-based header compression and multiplexing of multiple compression contexts via Compression Context IDs (CIDs). It highlights the implications of handover scenarios, including the need for negotiation, changes to context fields, and potential race conditions. Additionally, it raises questions regarding how Mobile Nodes (MNs) can ascertain the completion of context transfer (CT) and what parameters were utilized, emphasizing the importance of HC profiles in these operations.
E N D
ROHC CT issues Carsten Bormann, 2003-07-17 cabo@tzi.org
The RFC 3095 architecture • Header compression is on a channel • Multiple compression contexts are multiplexed via a CID (compression context ID) • HC state is L2 state • In a bridged system, lives on AP, not AR • There are multiple profiles (RTP, TCP, …) • Some even have special state at L2 (LLA) cabo@tzi.org
Implications (1) • Handover creates a new channel • Normally, negotiation required! • Some context fields may need to change (e.g., IP address) • These are profile specific • Context was active before transfer • Race conditions possible! cabo@tzi.org
Implications (2) • How does MN know that CT was done? • And what CT parameters were used, if any? • What is the CID mapping on nAR? • Any other interesting channel parameters? • CT operation must be part of HC profile • Quite similar to ROHC context replication:draft-ietf-rohc-context-replication-00.txt cabo@tzi.org