We would like to give our comment regarding rfc2507 – IP Header compression to fulfill our requirement of our minor assignment. Please feel free to give any comment. Thank you very much.
If you're interested, it is also available at the following URL: http://www.geocities.com/ipv6group/index.html Group 4 & 5 University Science Malaysia Suggestions On RFC2507 – IP Header Compression After reading the RFC2507 – IP Header Compression and other related RFC (RFC1144, RFC2508, RFC2509 and RFC3096), we would like to express our opinion on IP Header Compression. As a simple introduction, packet compression can be performed by taking advantages of the constant field, field change infrequently or field that its value can be predicted (For a complete list of these fields, please refer to RFC1144). >From our understanding, the way packet compression work is that, the sender will send >a full header, which is an uncompressed packet with Context Identifier (CID). The >information in the full header is used to create/refresh the context, which have the >information to uncompressed compressed packet. Compressed packet can be decompressed >using the context information that had been established, using the CID as the key. If >CID can be found, the packet will be uncompressed. But if it can’t be found then it >will either be stored for future processing (when full header arrive later) or be >discarded. >From RFC2507, we can’t find any information that discusses on the number of contexts >to be kept by the compressor. In situation where there are a lot of compressor and >only one decompressor, there is a possibility that memory limitation limit the number >of contexts that can be kept at a time. The issue is how to handle such a case if it >happened. Below, we give our suggestion to overcome this problem. We suggest that we associate a time field to each context at the decompressor. From time to time, compressor will let decompressor knows that it is still using that context by updating it. This can be done either using a different type of packet or the information can be attached when packets are grouped together. Compressor will from time to time check the time associate with every context, and record down any contexts that are expired. The expired context can then be reclaimed, and use by others. In situation when there are a lot of compressors and there is not enough memory to keep the new context, the sender will have to send in original uncompress packets. Compressor can be notified either implicitly or explicitly. Decompressor can explicitly send a special packet to notify compressor, when decompressor receives the new full header. Decompressor can also just perform a discard on the full header if situation not allow it to send a packet to compressor. Compressor that f! ails to send compressed packet will then switch to normal packet and resend them. We would also like to give our suggestion on how to implement the system in a wide area network, which involves more than one hop. We suggest that at every decompressor, decompressor will mapped and every compressors’ CID to a unique CID and send them to the next node. The reason for mapping the CID is to make sure packet from different source has a unique CID. The same operation is performed from source until destination. If in the process, there is some node that unable to perform the compression, then the node before it will uncompressed them and send them as normal packet (uncompressed packet). -- __________________________________________________ Get FREE 50 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
