From wcang at nav6.org Fri Oct 17 08:02:57 2008 From: wcang at nav6.org (=?UTF-8?B?IkFuZyBXYXkgQ2h1YW5nIDzmtKrkvJ/lo64+Ig==?=) Date: Fri, 17 Oct 2008 16:02:57 +0900 Subject: New I-D has been submitted for draft-wan-ipdvb-rohc Message-ID: <48F838A1.5000406@nav6.org> Hi all, I've just submitted the latest draft to IETF. The URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=9771 The following is a summary of changes that went into this draft: - Introduce a field called RefID (reference ID) in RCPNP message that used to ack/nack another message with the same ID. - Reorganize the content so all causes of negative acknowledgement are now put under Negative acknowlegement section. - Introduce heartbeat message in RCPNP that will be sent periodically when ROHC channel is idle. This is used to detect cases where compressor/decompressor terminates abnormally. - In the section where interaction of RCPNP is shown, how RefID and ID are used was added. In addition, a case where abnormal termination is also shown. Any comment on the latest draft? In addition, we would like to discuss and possibly include the following ideas for the next revision: 1. Network with only 2 nodes may avoid the steps involve in the learning of network topology. Broadcast/multicast traffic can be compressed in this case. My guess is that this can achieved by gateway machine by detecting how many receiver frontend. If there is only one receiver frontend, then it is safe to assume the network only consists of 2 nodes. Our definition of node is limited to receive capable feed. Of course, I am likely to be wrong. 2. How to enable compression of broadcast/multicast traffic if the network has more than 2 nodes? One idea is to have compressor gateway send a beacon signal about parameters of ROHC channel for broadcast/multicast traffic through uncompressed channel periodically There are several challenges that must be handled for this case. - Firstly, if one of the receiver gateway can't accept the ROHC channel parameter (e.g doesn't support certain profile or doesn't ROHC decompression), then compression of broadcast/multicast can't proceed. - There may be cases where receiver gateway joins the network after compressor gateway has started transmission of compressed packet. In this situation, the receiver gateway won't be able to decompress the packet until it receives the beacon and until the compressor's context falls back to IR state. Thus, context of compressor must periodically fall back to IR state after certain time (this may consumes more bandwidth than having uncompressed packet for certain cases depending on how frequent it falls back to IR state). 3. Only decompressor gateway can initiate the negotiation of ROHC channel in current draft. I think it is sufficient, so is there a need to specify a way to let compressor gateway to initiate the negotiation of ROHC channel? Anyway, I had a quick glance at the drafts related to security extension mentioned in the last IETF meeting, but I have no idea how it can be used to overcome the problem of address spoofing vulnerability mentioned in our draft. Thanks for reading this lengthy email. Regards, Ang Way Chuang From gorry at erg.abdn.ac.uk Mon Oct 27 14:12:31 2008 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 27 Oct 2008 14:12:31 +0000 Subject: IPDVB Working Group Status for IETF-73 Message-ID: <4905CC4F.2030807@erg.abdn.ac.uk> Dear all The current IPDVB status is at: http://tools.ietf.org/wg/ipdvb/ The following drafts have now been sent to our AD, with a request for publication: draft-ietf-ipdvb-sec-req-09 WG: 2008-08-23 draft-combes-ipdvb-mib-rcs-04 AD-Sponsored Submission. Please let me know if you have any items you feel should be discussed, or brought to AD's attention at the next IETF meeting. Currently, no official meeting has been scheduled, since there are no WG work items within the group - However, there ARE individual submissions that are progressing (see page). Even if no official meeting is scheduled, there will be plenty of opportunity for discussion either face-to-face or via email. Please let me know if you have issues or topics you'd like to discuss. Best wishes, Gorry Fairhurst