From owner-ipdvb@erg.abdn.ac.uk Mon Mar 3 00:04:35 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785303A6E56 for ; Mon, 3 Mar 2008 00:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=3.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RujkLgBGrRb6 for ; Mon, 3 Mar 2008 00:04:29 -0800 (PST) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 3D6993A680A for ; Mon, 3 Mar 2008 00:04:28 -0800 (PST) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m237XwDk002721 for ; Mon, 3 Mar 2008 07:33:58 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m237Xwo9002719 for ipdvb-subscribed-users; Mon, 3 Mar 2008 07:33:58 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mailhub1.abdn.ac.uk (mailhub1.abdn.ac.uk [139.133.7.28]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m237Xd7q002678 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 3 Mar 2008 07:33:44 GMT Received: from [219.93.2.104] (helo=nav6.org) by mailhub1.abdn.ac.uk with esmtp (Exim 4.52) id 1JVj3S-0008Ax-8X for ipdvb@erg.abdn.ac.uk; Sun, 02 Mar 2008 07:56:27 +0000 Received: from [10.207.160.229] (unknown [10.207.160.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nav6.org (Postfix) with ESMTP id 9EB581D600DD for ; Sun, 2 Mar 2008 15:51:50 +0800 (MYT) Message-ID: <47CA5D7B.1000609@nav6.org> Date: Sun, 02 Mar 2008 15:55:39 +0800 From: Ang Way Chuang User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Draft for ROHC over DVB - comments on your text. References: <47B82AF0.7080605@nav6.org> <47B8982A.2020007@erg.abdn.ac.uk> <47B8EE6F.4050005@nav6.org> <47B94AFB.5060909@erg.abdn.ac.uk> <47B95983.4070600@nav6.org> <47B95D6D.3020500@erg.abdn.ac.uk> <47BE9B0F.3020100@nav6.org> <47C0663E.20100@erg.abdn.ac.uk> In-Reply-To: <47C0663E.20100@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Dear Dr. Gorry Fairhurst, Sorry for the late reply. I hope you are okay with the inlined reply. Gorry Fairhurst wrote: > > I have a few questions about the draft from the ULE perspective, please > see below. > > Gorry > > > --------------------------------------------------------------------- > > 1) ULE Type > > There are two ways the Type field could be used, and I am not clear > which you are proposing. > > a) You could use a ULE Mandatory Extension Header. The value for this > could be allocated by the IETF, if this were approved as an IETF RFC and > that would certainly be one way to proceed that would allow you to embed > ROHC functionality in the ULE/GSE Gateway and Receivers. > > b) You could apply to the IEEE for an EtherType value from the IEEE > Registry that would be applicable to all IEEE technologies (WiFi, > wired-ethernet, etc) and which naturally could be used with ULE/GSE > also, although you would still need to define how this was implemented, > and how this interacted with ULE if you wanted to embed the compression > and decompression in the ULE end-points rather than in the connected end > host Ethernet drivers. > > (it's a little wrong to speak of a "IANA assigned EtherType number" - > since this mixes the two possibilities). Oh I see. What are the financial implications for approach a and b? I assume that b is harder and may take longer to get approval. 1) I think b is more desirable since it applicable for ULE/GSE and UDLR. 2) If getting a EtherType from IEEE is not feasible, then we may need to resort to change the format of the ULE payload to accommodate the source address if necessary. > > Comments and questions relating to this: > > --- > In section 3.1.2: > > I don't understand the header format. The base-header has the type > Ethernet - this means the encapsulated PDU must be an Ethernet Frame (as > per RFC4326). A receiver should attempt to forward the PDU to the > bridged LAN interface. > > If you wanted a compressed ROHC payload in bridged mode, you'd probably > need to define a new ULE-Type that denotes you are carrying a bridged > ROHC PDU that needs to be decompressed prior to Receiver bridge > processing - you probably also need to describe how this would work. 3) Yes, the ideal case is to get IEEE EtherType for ROHC, so that it can be used for Bridged Frame (Type = 0x0001). > > --- > > In Section 4.1: > > "Since new EtherType is allocated, this > protocol can be extended to asymmetrical link via Link-Layer > Tunneling Mechanism [RFC3077]" > > - UDLR uses IEEE EtherTypes, whereas ULE uses these, but includes its > own extension formats. So this is only so, if you request an > IEEE-allocated Ethertype, rather than a ULE-Type value from the IANA > extensions registry. 4) Yeap, so it can't get work without IEEE EtherType. > > --------------------------------------------------------------------- > 2) In Section 3.1.1: > > "In the absence of multiple receivers, a transmitter can send an SNDU"... > > I think this is only partially true, it may be safer to refer this to > RFC4326, since this is also dependent on the way in which the ULE Stream > is used. 5) I'm not sure whether I get your point correctly. Referring to section 4.5, there is no point of using ROHC in multicast and broadcast. So it only make sense in unicast. But since the IPv4/IPv6 header is compressed, the receiver needs to distinguish its packet from others by looking at the Destination Address in the case where multiple receivers share the link. Is that your concern? > > --------------------------------------------------------------------- > 3) In section 3.2 (ROHC over MPEG2-TS): > > - This format isn't clear to me, it seems you are trying to define a new > types of Stream, which I guess is possible, but that would imply > defining integrity checks, length, NPAs, etc - in much the same way as > ULE was developed. This would perhaps at most save 2 bytes, but would be > incompatible with the ULE framework. I'm not sure I understand the > motivation here. 6) Yes, you are right. The idea is to save 2 - 3 bytes for each ROHC compressed packet. But if the amount of effort involved does not worth it, we can drop this. The whole idea is that is to let compressor site selects a PID as a unique channel between itself and a particular receiver. Of course, the advantage is more obvious if source and destination L2 addresses need to be included. By mapping a PID to a pair of source and destination address, 12 bytes can saved per ROHC compressed packet. But ROHC over ULE can also work in this manner. > > --------------------------------------------------------------------- > 4) In Section 4: > > With the exclusion of section 3.2, this seems to apply to any ULE Stream > (and probably a GSE stream) - independent of the physical layer (DVB, > ATSC, or whatever). > > In Section 4.1: > > Again, with the exclusion of section 3.2, this could be applicable to GSE. > --------------------------------------------------------------------- > Okay. > Best wishes, > > Gorry > > > I also have a few minor editorial comments (which may be helpful if you > decide to prepare an updated draft): > > --- > Change > /ULE stream/ > to > /ULE Stream > --- > > It would seem worthwhile drawing the diagrams in the same representation > as other ULE Extensions, using the 32-bit wide format of: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |D| Length (15b) | Type = 0x???? | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > --- > > I'd suggest creating a two reference subsections, one > "Normative References" > and one > "Informative References" > > I'd suggest replacing GSE with the ETSI Specification reference: > > [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream > Encapsulation (GSE) Protocol, "European Telecommunication Standards, > Institute (ETSI), 2007. > > I'd suggesting a normative reference to: > > [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional > Lightweight Encapsulation (ULE) for transmission of IP datagrams > over an MPEG-2 Transport Stream", RFC 4326, December 2005. > > I'd suggest placing the following as Informative references : > > [DIX] > [ISO-MPEG2] > [ITU-H222] > [RFC3077] > > You may like to provide an informational reference to the following for > terminology and architecture: > > [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- > Nocker, B., and H. Linder, "A Framework for Transmission of IP > Datagrams over MPEG-2 Networks", RFC 4259, November 2006. > > > > > Okay, noted. Thank you very much for your feedback. I shall try to send an updated draft within this 2 weeks. Regards, Ang Way Chuang From gefescuelamaristazoj@escuelamarista.com Wed Mar 12 08:34:15 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3587A28C681; Wed, 12 Mar 2008 08:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.321 X-Spam-Level: ** X-Spam-Status: No, score=2.321 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al9VJqQCm2Yt; Wed, 12 Mar 2008 08:34:10 -0700 (PDT) Received: from static-ip-cr200715061.cable.net.co (unknown [200.71.50.61]) by core3.amsl.com (Postfix) with ESMTP id 6045728C86C; Wed, 12 Mar 2008 08:32:07 -0700 (PDT) Received: from [200.71.50.61] by ALT1.ASPMX.L.GOOGLE.com; Wed, 12 Mar 2008 10:29:47 -0500 Date: Wed, 12 Mar 2008 10:29:47 -0500 From: "Liz Nava" X-Mailer: The Bat! (v3.0.0.15) Home Reply-To: gefescuelamaristazoj@escuelamarista.com X-Priority: 3 (Normal) Message-ID: <107268388.12463833151308@escuelamarista.com> To: imrg-web-archive@megatron.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------44B80CCC513DA29" ------------44B80CCC513DA29 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Our main purpose is to assure low price PC and Mac legal software and computer solutions to give the best fit to any budget. Whether you're a corporate purchaser, a proprietor of small enterprise, or go shopping for your own home PC, we believe we can help you. HERE IS A LIST OF OUR SOFTWARE http://hgrsagfsk78.blogspot.com Most popular products in sight are: *Adobe Photoshop Elements 3.0 for Mac: Retail price today - $89.99; Our today only - $39.95 *Symantec pcAnywhere V 11.0 Host & Remote: Retail price this day - $210.00; Our only - $29.95 *Virtual PC 7.0 for Mac: Retail price for today - $249.99; Our for today only - $49.95 *Macromedia Dreamweaver 8: Retail price now - $399.99; Our just - $49.95 *Microsoft Plus! for Windows XP: Retail price now - $29.95; Our just - $10.95 *Microsoft Visual FoxPro 8.0: Retail price this day - $335.00; Our only - $29.95 *Corel Print House 6: Retail price for now - $270.00; Our only - $29.95 *Adobe Audition 1.5: Retail price this time - $299.00; Our for now just - $49.95 COME TO US JUST NOW! http://hgrsagfsk78.blogspot.com ------------44B80CCC513DA29 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Our main purpose is to assure low price PC and Mac legal software and computer solutions to give the best fit to any budget.
Whether you're a corporate purchaser, a proprietor of small enterprise,
or go shopping for your own home PC, we believe we can help you.
HERE IS A LIST OF OUR SOFTWARE
http://hgrsagfsk78.blogspot.com
Most popular products in sight are:
*Adobe Photoshop Elements 3.0 for Mac: Retail price today - $89.99; Our today only - $39.95
*Symantec pcAnywhere V 11.0 Host & Remote: Retail price this day - $210.00; Our only - $29.95
*Virtual PC 7.0 for Mac: Retail price for today - $249.99; Our for today only - $49.95
*Macromedia Dreamweaver 8: Retail price now - $399.99; Our just - $49.95
*Microsoft Plus! for Windows XP: Retail price now - $29.95; Our just - $10.95
*Microsoft Visual FoxPro 8.0: Retail price this day - $335.00; Our only - $29.95
*Corel Print House 6: Retail price for now - $270.00; Our only - $29.95
*Adobe Audition 1.5: Retail price this time - $299.00; Our for now just - $49.95
COME TO US JUST NOW!
http://hgrsagfsk78.blogspot.com ------------44B80CCC513DA29-- From owner-ipdvb@erg.abdn.ac.uk Thu Mar 13 11:20:11 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41E928C137 for ; Thu, 13 Mar 2008 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZMPVQVtge+Q for ; Thu, 13 Mar 2008 11:20:09 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 9733928C83E for ; Thu, 13 Mar 2008 11:16:59 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2DHQUx4010312 for ; Thu, 13 Mar 2008 17:26:30 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2DHQUBH010311 for ipdvb-subscribed-users; Thu, 13 Mar 2008 17:26:30 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2DHQLo8010301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2008 17:26:22 GMT Message-ID: <47D963BB.7030804@erg.abdn.ac.uk> Date: Thu, 13 Mar 2008 13:26:19 -0400 From: Gorry Fairhurst Organization: School of Engineering, University of Aberdeen, Scotland User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: Martin Stiemerling Subject: Re: opsdir review of draft-ietf-ipdvb-ule-ext-07] - Proposed changes. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk A late OPSDIR review flagged some places where the guidance could be tightened (a few paragraphs of rewording and one minor change to the spec - require padding of unused low-order time stamp bits with zero's in section 3.3). I've spoken to Bernhard (co-author) and Martin (as Shepherd) and we think two changes are appropriate. If anyone on this list has concerns about the proposed changes please *DO* tell us. All issues need to be received by Thursday 20th March 2008. Best wishes, Gorry Fairhurst (as WG Chair) ----------- Proposed Change note ---------- Section 3.1: OLD: "This document does not specify how TS Packets are to be handled at the Receiver, however it notes that a poorly configured Encapsulator could lead to a Multiplex carrying multiple (possibly conflicting) sets of TS Logical Channels and SI information encapsulated at different levels or with different NPA addresses. The need for consistency in the use of PIDs and the related SI information is described in section 4.2 of [RFC4947]." NEW: "This document does not specify how TS Packets are to be handled at the Receiver. However, it notes: * A Receiver needs to consistently associate all TS Packets in a Stream with one TS Logical Channel (Stream). If an Encapsulator transmits more than one Stream of TS Packets each encapsulated at a different level or with a different NPA address, a Receiver needs to ensure that each is independently demultiplexed as a separate Stream (Section 3.2 [RFC4259]). * If an Encapsulator transmits service information encapsulated at different levels or with different NPA addresses, the Receivers need to ensure each Stream is related to the corresponding SI table information (if any). A RECOMMENDED way to reduce signaling interactions is to ensure each PID value uniquely identifies a Stream within a TS Multiplex carrying ULE and also any TS Packets encapsulated by a ULE/GSE Stream. The need for consistency in the use of PIDs and the related service information is described in section 4.2 of [RFC4947]." --- In Section 3.3 OLD: "may use an arbitrary (and varying) value to pad the unused least-significant bits." NEW: "MUST pad the unused least-significant bits with a value of zero." --- end of change note -------------------------------- The following text contains the detailed comments and responses from the authors. This is provided for information and completeness since the document has already been approved for publication. > David Harrington wrote: > > I have reviewed this document as part of the operations > directorate's > > ongoing effort to review IETF documents being submitted to > the IESG. > > These comments were written primarily for the benefit of > the OPS area > > directors. Document editors and WG chairs should treat > these comments > > just like any other last call comments. > > > > draft-ietf-ipdvb-ule-ext defines multiple extensions for > ULE and GSE > > encapsulations of IPDVB traffic. > > > > This is an area in which I have no expertise. > > > Your comments are still appreciated! > > > I have a few concerns about the document. > --------------------------------------------------------------- > > In section 3.1, there is a paragraph that mentions the need to > > update/modify the timing information, and says "these > issues are not > > considered here". That makes me concerned that they may not be > > considered anywhere. > > > These issues are expected to be addressed in the Guidelines > to GSE, to be published as an ETSI Technical Report > (equivalent to an IETF INFO RFC). It is normal to start a > Guidelines TR, once operational experience has been obtained > from implementation. Clock references impact the physical > layer and native video (rather than IP). Our thoughts were > that DVB-specific details should be handled by DVB via ETSI. > > - We think no change needed. > --------------------------------------------------------------- > > section 3.1 also "notes that a poorly configured Encapsulator could > > lead to a Multiplex carrying multiple (possibly > conflicting) sets of > > TS Logical Channels ..." I am not sure that the pointer to > [RFC4947] > > adequately addresses the issue. > > > I'd be happy for it to say more, but as I see it the whole of > the TS Multiplex transmission network requires consistent > configuration, and this adds just one more thing that needs > to be done consistently. I think it is hard to be > perscriptive here, given the wide range of networks that use > this technology. Is the following better? > > - Suggested change. > --------------------------------------------------------------- > > In section 3.2, the Packing Threshold SHOULD be configurable in the > > Encapsulator. I wonder why this is not a MUST be configurable? > > > This follows the practice RFC 4236 for the ULE Packing > Threshold. This was deemed a "SHOULD" since it does not > impact interoperability between the sender and receiver (all > values result in "correct" operation - the value is a > performance-tuning parameter that operators will likely wish > to use to control Jitter and efficiency). > > - We think no change is needed. > --------------------------------------------------------------- > > In section 3.3, "Systems unable to insert timestamps at the > specified > > resolution may use an arbitrary (and varying) value to pad > the unused > > least-significant bits." I wonder why this isn't simply padded with > > 0-bits. Is there a reason why the padding is arbitrary and varying? > > > Thanks! The reason is that some people suggested use of the > TimeStamp for also transferring a reference clock (inspired > by RFC4340). I think we reached consensus that this was not > the primary function, and therefore it is better if the > TimeStamp value ONLY increased. > We agree with your proposed correction. > > - Suggested change. > --------------------------------------------------------------- > > section 3.3 also says "Receivers MAY process the timestamp when the > > PDU encapsulation is removed. Recievers that do not > implement, or do > > not wish to process, the TimeStamp Extsnsion MAY skip this > extension > > header." I always get concerned when a "standard" is allowed to be > > ignored at the implemeter's whim, and such behavior still > somehow gets > > classified as being standard-compliant. Either they should > be required > > to process the fields, or they should not be allowed to declare > > compliance to the standard. > > > - We do not intend to obsolete/update RFC4326 as deployed. > We could say "Receivers SHOULD process", but then we'd still > need to allow RFC4326 Receivers to ignore this unknown extension. > - We thing this is correct. > --------------------------------------------------------------- > > Idnits complains about the [GSE] normative reference, which > is an ETSI > > document, and about the reference to sec-req-04 being outdated. > > > Correct, draft-ietf-ipdvb-sec-req was revised to rev -05. > - This could be corrected next rev. > The ETSI GSE Technical Specification (TS) is indeed a > normative reference on the framing structure, and this TS > cites this document as Normative too on the extension format. > - This seems correct to us, no change needed. > --------------------------------------------------------------- > > It is recommended practice to place the Intellectual property > > statement at the end of the file. This document places the Appendix > > after the Intellectual property statement. > > > - Noted, this will be corrected. > --------------------------------------------------------------- > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > From nirgatewaywrestlingjyl@gatewaywrestling.com Mon Mar 17 07:12:29 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9D928C34D; Mon, 17 Mar 2008 07:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.105 X-Spam-Level: **** X-Spam-Status: No, score=4.105 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKGO3+izT5U2; Mon, 17 Mar 2008 07:12:23 -0700 (PDT) Received: from wan.sec-rb.iasl.com (unknown [206.210.97.88]) by core3.amsl.com (Postfix) with ESMTP id 2972C3A67DA; Mon, 17 Mar 2008 07:12:22 -0700 (PDT) Received: from [206.210.97.88] by smtp.secureserver.net; Mon, 17 Mar 2008 09:10:07 -0500 Date: Mon, 17 Mar 2008 09:10:07 -0500 From: "Jose Calderon" X-Mailer: The Bat! (v2.00.3) Educational Reply-To: nirgatewaywrestlingjyl@gatewaywrestling.com X-Priority: 3 (Normal) Message-ID: <340036066.95792071454465@gatewaywrestling.com> To: imrg-web-archive@megatron.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------4BF6EBF6EB829AD" ------------4BF6EBF6EB829AD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit In search for the best value in software discounts? Now you will find the chance to have the softwares you dream of from long time ago. And the best thing is, all softwares are dirt cheap. Check up by yourself and get the softwares for cheap rates! http://inacrankgx197.blogspot.com ------------4BF6EBF6EB829AD Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
In search for the best value in software discounts?
Now you will find the chance to have the softwares you dream of from long time ago.
And the best thing is, all softwares are dirt cheap.
Check up by yourself and get the softwares for cheap rates!
http://inacrankgx197.blogspot.com ------------4BF6EBF6EB829AD-- From zifglendasflowerscop@glendasflowers.com Tue Mar 18 07:48:52 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2F53A6F24; Tue, 18 Mar 2008 07:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2bHVvukSzaX; Tue, 18 Mar 2008 07:48:45 -0700 (PDT) Received: from NICOLE.dedicado.com.uy (78-30.dedicado.com.uy [201.221.30.78]) by core3.amsl.com (Postfix) with ESMTP id 10C143A6F07; Tue, 18 Mar 2008 07:48:26 -0700 (PDT) Received: from [201.221.30.78] by mail.florists.ftd.com; Tue, 18 Mar 2008 11:46:01 -0300 Date: Tue, 18 Mar 2008 11:46:01 -0300 From: "Tammi Mcclellan" X-Mailer: The Bat! (v2.12.00) Personal Reply-To: zifglendasflowerscop@glendasflowers.com X-Priority: 3 (Normal) Message-ID: <923063025.02675652763322@glendasflowers.com> To: imrg-web-archive@megatron.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------780C930C932178" ------------780C930C932178 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Our aim is to guarantee PC and Mac legal soft and computer solutions of low price for anyone. Whether you're a corporate customer, a small-scale enterprise holder, or go shopping for your home personal computer, we guess we will assist you. TAKE A LOOK AT ALL PRODUCTS! http://janisroleype145.blogspot.com ------------780C930C932178 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Our aim is to guarantee PC and Mac legal soft and computer solutions of low price for anyone.
Whether you're a corporate customer, a small-scale enterprise holder,
or go shopping for your home personal computer, we guess we will assist you.
TAKE A LOOK AT ALL PRODUCTS!
http://janisroleype145.blogspot.com
------------780C930C932178-- From snetseuk@APPLE.COM Tue Mar 18 17:01:19 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF733A67E1 for ; Tue, 18 Mar 2008 17:01:19 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char 92 hex): Subject: How to fulfill your girl\222s expectations\n X-Spam-Flag: NO X-Spam-Score: -30.954 X-Spam-Level: X-Spam-Status: No, score=-30.954 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_ADD_INCHES=2.131, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7OA6+KTar-c for ; Tue, 18 Mar 2008 17:01:19 -0700 (PDT) Received: from 201-94-168-73.botucatu.flash.tv.br (201-94-168-73.botucatu.flash.tv.br [201.94.168.73]) by core3.amsl.com (Postfix) with ESMTP id 78A983A67E9 for ; Tue, 18 Mar 2008 17:01:18 -0700 (PDT) Message-ID: <000f01c88954$09a84520$49a85ec9@user3f11e76b73> From: "Amol nicolas" To: ipdvb-archive@ietf.org Subject: How to fulfill your girl’s expectations Date: Tue, 18 Mar 2008 20:59:01 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C8893A.E45B0D20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C8893A.E45B0D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Add inches permanently to the only place that matters. http://www.daadhorse.com/ Revolutionary, proven enlargement supplement ----------=_NextPart_000_000B_01C8893A.E45B0D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Add inches permanently to the only = place that=20 matters.
 
 
http://www.daadhorse.com/
Revolutionary, proven enlargement=20 supplement
----------=_NextPart_000_000B_01C8893A.E45B0D20-- From Jarret-snerafir@APPLE.COM Tue Mar 18 17:02:12 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F703A67E9 for ; Tue, 18 Mar 2008 17:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM2KntEScgTS for ; Tue, 18 Mar 2008 17:02:11 -0700 (PDT) Received: from 201-94-168-73.botucatu.flash.tv.br (201-94-168-73.botucatu.flash.tv.br [201.94.168.73]) by core3.amsl.com (Postfix) with ESMTP id 92EBD3A67E1 for ; Tue, 18 Mar 2008 17:02:10 -0700 (PDT) Message-ID: <000601c88954$28b9e9f0$49a85ec9@user3f11e76b73> From: "Jarret paananen" To: ipdvb-archive@megatron.ietf.org Subject: Massive, throbbing rod Date: Tue, 18 Mar 2008 20:59:53 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0002_01C8893B.036CB1F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0002_01C8893B.036CB1F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Penetrate her with your large manhood like never before. http://www.ikluj.com/ Massive gains in length and girth ----------=_NextPart_000_0002_01C8893B.036CB1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Penetrate her with your large manhood = like never=20 before.
 
 
http://www.ikluj.com/
Massive gains in length and=20 girth
----------=_NextPart_000_0002_01C8893B.036CB1F0-- From woxgtactivegir@gtactive.com Wed Mar 19 17:49:21 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2963A67B7; Wed, 19 Mar 2008 17:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.011 X-Spam-Level: *** X-Spam-Status: No, score=3.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+GKUJcqqSrX; Wed, 19 Mar 2008 17:49:20 -0700 (PDT) Received: from mx-ll-58.147.53-203.tttmaxnet.com (unknown [58.147.53.203]) by core3.amsl.com (Postfix) with ESMTP id 2BF6128C106; Wed, 19 Mar 2008 17:48:47 -0700 (PDT) Received: from [58.147.53.203] by mail.gtactive.com; Wed, 19 Mar 2008 16:46:33 -0800 Date: Wed, 19 Mar 2008 16:46:33 -0800 From: "Terrance Reagan" X-Mailer: The Bat! (v2.10) Business Reply-To: woxgtactivegir@gtactive.com X-Priority: 3 (Normal) Message-ID: <193912215.27540638374188@gtactive.com> To: imrg-web-archive@megatron.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------34867299915AF21C" ------------34867299915AF21C Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Searching for the best price in software discounts? Now you'll catch the opportunity to use the software environment you wanted for a very long time. And the best matter is, all softs are dirt cheap. Check up by yourself and have the softwares for cheap rates ever seen! http://shannaleibowitzng189.blogspot.com ------------34867299915AF21C Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
Searching for the best price in software discounts?
Now you'll catch the opportunity to use the software environment you wanted for a very long time.
And the best matter is, all softs are dirt cheap.
Check up by yourself and have the softwares for cheap rates ever seen!
http://shannaleibowitzng189.blogspot.com ------------34867299915AF21C-- From owner-ipdvb@erg.abdn.ac.uk Fri Mar 21 06:21:20 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B9228C1EA for ; Fri, 21 Mar 2008 06:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIO8JQ9TS+sl for ; Fri, 21 Mar 2008 06:21:20 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 9862428C0E2 for ; Fri, 21 Mar 2008 06:21:19 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2LCipwN015534 for ; Fri, 21 Mar 2008 12:44:51 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2LCipZe015533 for ipdvb-subscribed-users; Fri, 21 Mar 2008 12:44:51 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2LCinai015524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 21 Mar 2008 12:44:49 GMT Message-ID: <47E3ADC2.80108@erg.abdn.ac.uk> Date: Fri, 21 Mar 2008 12:44:50 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "ipdvb@erg.abdn.ac.uk" Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Here is a copy of the I-D previously circulated on the list. This has been published in the IETF I-D database. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt Comments and discussion is invited on this list. AUTHORS: Please note the name of the file. If you wish to submit an updated revision the new version should be: draft-wan-ipdvb-rohc-01.txt Best wishes, Gorry Fairhurst (ipdvb WG Chair) --- To: i-d-announce at ietf.org Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt From: Internet-Drafts at ietf.org Date: Wed, 19 Mar 2008 11:00:01 -0700 (PDT) Cc: Delivered-to: ietfarch-i-d-announce-web-archive at core3.amsl.com Delivered-to: i-d-announce at core3.amsl.com List-archive: List-help: List-id: Internet Draft Announcements List-post: List-subscribe: , List-unsubscribe: , Reply-to: internet-drafts at ietf.org Sender: i-d-announce-bounces at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames Author(s) : T. Wan, W. Ang, C. Teh Filename : draft-wan-ipdvb-rohc-00.txt Pages : 26 Date : 2008-3-19 This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS frames. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipdvb@erg.abdn.ac.uk Mon Mar 24 00:56:25 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE953A6C14 for ; Mon, 24 Mar 2008 00:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQn-4ox1aRe7 for ; Mon, 24 Mar 2008 00:56:22 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 1FE8828C10C for ; Mon, 24 Mar 2008 00:56:21 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2O70sPf016418 for ; Mon, 24 Mar 2008 07:00:54 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2O70stc016417 for ipdvb-subscribed-users; Mon, 24 Mar 2008 07:00:54 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nav6.org (mail.nrg.cs.usm.my [219.93.2.104] (may be forged)) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2O703NM016330 for ; Mon, 24 Mar 2008 07:00:15 GMT Received: from [10.207.160.229] (unknown [10.207.160.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nav6.org (Postfix) with ESMTP id 394521D6015A; Mon, 24 Mar 2008 15:08:07 +0800 (MYT) Message-ID: <47E7516A.8080902@nav6.org> Date: Mon, 24 Mar 2008 14:59:54 +0800 From: Ang Way Chuang User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: TC Wan Subject: Re: I-D ACTION:draft-wan-ipdvb-rohc-00.txt References: <47E3ADC2.80108@erg.abdn.ac.uk> In-Reply-To: <47E3ADC2.80108@erg.abdn.ac.uk> Content-Type: multipart/mixed; boundary="------------090706090407040105040409" X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------090706090407040105040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Dr. Fairhurst, Here is updated version according your previous feedback, but still incomplete. I removed the section that carries ROHC compressed packet directly over MPEG2-TS. So, what works for ULE should also work for GSE except for section 4.1.4.1.1 which relies on MPEG2-TS. In addition to 2 new ULE type, we also need to have a new EtherType for section 3.1.2. If getting new EtherType is hard, we may need to redefine the packet format. As for your previous comment: > 2) In Section 3.1.1: > > "In the absence of multiple receivers, a transmitter can send an > SNDU"... > > I think this is only partially true, it may be safer to refer this to > RFC4326, since this is also dependent on the way in which the ULE > Stream is used. I'm not sure what you meant exactly. I refer to figure 11 of RFC4326 and the Receiver Destination NPA address field seems redundant since MAC destination address is there. Any practical scenario where Receiver Destination needs to be different from MAC destination address? Diagrams has been changed to conform with the style used by RFC4326, but style of diagram 4, 5, 6 and 7 is left untouched since it is difficult to represent variable format imposed by medium information using the former style. Thank you. Regards, Ang Way Chuang Gorry Fairhurst wrote: > > Here is a copy of the I-D previously circulated on the list. This has > been published in the IETF I-D database. A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt > > Comments and discussion is invited on this list. > > AUTHORS: Please note the name of the file. If you wish to submit an > updated revision the new version should be: draft-wan-ipdvb-rohc-01.txt > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > > --- > > To: i-d-announce at ietf.org > Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt > From: Internet-Drafts at ietf.org > Date: Wed, 19 Mar 2008 11:00:01 -0700 (PDT) > Cc: > Delivered-to: ietfarch-i-d-announce-web-archive at core3.amsl.com > Delivered-to: i-d-announce at core3.amsl.com > List-archive: > List-help: > List-id: Internet Draft Announcements > List-post: > List-subscribe: , > > List-unsubscribe: , > > Reply-to: internet-drafts at ietf.org > Sender: i-d-announce-bounces at ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Robust Header Compression over Unidirectional > Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames > Author(s) : T. Wan, W. Ang, C. Teh > Filename : draft-wan-ipdvb-rohc-00.txtNPA > Pages : 26 > Date : 2008-3-19 > > This paper introduces approach to carry ROHC packets over ULE and > MPEG2-TS frames. For completeness, ROHC Channel Parameters > Negotiation Protocol (RCPNP) is also presented. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wan-ipdvb-rohc-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --------------090706090407040105040409 Content-Type: text/plain; name="draft-wan-ipdvb-rohc-01-pre.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-wan-ipdvb-rohc-01-pre.txt" Network Working Group Tat-Chee. Wan Internet-Draft Way-Chuang. Ang Intended status: Standards Track Chee-Hong. Teh Expires: September 25, 2008 Universiti Sains Malaysia March 24, 2008 Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) packets draft-wan-ipdvb-rohc-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Wan, et al. Expires September 25, 2008 [Page 1] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Abstract This document introduces approach to carry ROHC packets over ULE packets. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Packet Format of ROHC Packet . . . . . . . . . . . . . . . . . 7 3.1. ROHC over ULE . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Dedicated IANA ULE Type for ROHC Compressed Packet . . 7 3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Establishing ROHC Channel . . . . . . . . . . . . . . . . . . 9 4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP) . . . 9 4.1.1. Compressor Advertisement . . . . . . . . . . . . . . . 11 4.1.2. Compressor Solicitation . . . . . . . . . . . . . . . 11 4.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Reply . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.4.1. Medium Information . . . . . . . . . . . . . . . . 16 4.1.4.1.1. Dedicated PID space . . . . . . . . . . . . . 16 4.1.4.1.2. ULE Medium . . . . . . . . . . . . . . . . . . 17 4.1.5. Acknowledgement/Negative Acknowledgement . . . . . . . 18 4.1.6. Compressor Shutdown . . . . . . . . . . . . . . . . . 18 4.1.7. Decompressor Shutdown . . . . . . . . . . . . . . . . 19 4.2. Interaction of RCPNP . . . . . . . . . . . . . . . . . . . 19 5. Bidirectional ROHC Channels . . . . . . . . . . . . . . . . . 21 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Wan, et al. Expires September 25, 2008 [Page 2] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 1. Introduction This document introduces approach to carry ROHC packets over ULE packets. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented. FIXME: more details Wan, et al. Expires September 25, 2008 [Page 3] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 2. Terminologies The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. DVB Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2]. MAC Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). MPEG-2 A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]). PDU Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. Receiver Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer). Transmitter Router or host that sends data. SNDU SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit. Wan, et al. Expires September 25, 2008 [Page 4] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 TS Transport stream (TS) is a format specified in MPEG-2 Part 1, Systems (ISO/IEC standard 13818-1). Its design goal is to allow multiplexing of digital video and audio and to synchronize the output. Transport stream offers features for error correction for transportation over unreliable media, and is used in broadcast applications such as DVB and ATSC. ULE stream An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2]. ROHC Robust Header Compression. A framework of compression headers of IP packet as defined in [RFC3095]. ROHC channel A logical unidirectional point-to-point channel carrying ROHC packets from one compressor to one decompressor, optionally carrying ROHC feedback information on the behalf of another compressor-decompressor pair operating on a separate ROHC channel in the opposite direction. ROHC profile A logical unidirectional point-to-point channel carrying ROHC packets from one compressor to one decompressor, optionally carrying ROHC feedback information on the behalf of another compressor-decompressor pair operating on a separate ROHC channel in the opposite direction. MRRU Maximum Reconstructed Reception Unit as defined in [RFC3095]. Context Identifier [RFC3095] provides a definition for context identifiers. MSB Wan, et al. Expires September 25, 2008 [Page 5] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Most significant bit. LSB Least significant bit. ACK Acknowledgement. NACk Negative acknowledgement. CID Contect Identifier. Wan, et al. Expires September 25, 2008 [Page 6] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 3. Packet Format of ROHC Packet This section briefly describes the notation used in all diagrams. ":" in a diagram indicates that the part is optional. Likewise, "=" in a diagram indicates the number of octets by the part is not presented in a precise manner. This situation appears when a field or part spans multiple or variable number of bytes. 3.1. ROHC over ULE The packet format for ROHC compressed packet encapsulated within ULE can be in one the following two formats: 3.1.1. Dedicated IANA ULE Type for ROHC Compressed Packet 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Length (15b) | Type = ROHC ULE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address* (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RoHC compressed packet | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ROHC compressed packet encapsulated using dedicated ULE type The semantics of D-bit, Length, Type, Destination Address and CRC-32 fields are defined in section 4 of [RFC 4326]. However, the Type fields requires a new IANA assigned ULE type value to indicate the presence of ROHC compressed packet in PDU. In the absence of multiple receivers, a transmitter can send an SNDU without Destination Address Field (D bit marked). However, when multiple receivers are listening to the same transmitter, destination address must be included in SNDU. Wan, et al. Expires September 25, 2008 [Page 7] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Length (15b) | Type = 0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source MAC (6B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EtherType = ROHC Ether | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RoHC compressed packet | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ROHC compressed packet encapsulated in SNDU bridged frame This packet format should be used when there are multiple transmitters and receivers over a DVB link. A new EtherType value needs to be assigned for this. Wan, et al. Expires September 25, 2008 [Page 8] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 4. Establishing ROHC Channel This standard presents two approaches to setup a ROHC channel over a DVB link. The first approach is to setup ROHC channel manually. This requires that the operators at the every transmitters and receivers to manually configure the ROHC channel parameters. When the size of network is small, this approach is favourable. But the former approach becomes nonviable if the network is dynamic and is not scalable as the size of the network grows. Henceforth, we present a negotiation protocol to create ROHC channel in the next section. 4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP) The approach presented in this section can only work if compressor site and decompressor site are connected through two dedicated unidirectional DVB links, with a unidirectional link originating from each of the sites, configured to form a bidirectional network link between the two sites. This protocol works through ULE packets only. It is possible to extend this protocol to work over Generic Stream Encapsulation [GSE] in the future. While it is possible to extend this protocol to work over asymmetrical link, this draft doesn't try to address this issue. Since new EtherType can be allocated, this protocol can be extended to asymmetrical link via Link-Layer Tunneling Mechanism [RFC3077] with little modifications. The basic format of a ULE SNDU packet for RCPNP message is as such: Wan, et al. Expires September 25, 2008 [Page 9] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Length (15b) | Type = RoHC Neg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address* (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Version|OpCod|X| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Address * (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ = | Body * | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Minimal format of RCPNP message Type New ULE type need to be assigned for ROHC negotiation protocol. Destination Address Destination address field should exist for all types of message except for Compressor Solicitation and Compressor Advertisement messages. Version Version of ROHC Channel Parameters Negotiation Protocol (RCPNP). Currently, only version 0 is supported. OpCod OpCod field is an abbreviation for Operation Code. The value of Operation Code field determines the message type. X This bit is not used in most messages and should be ignored unless specified otherwise. Wan, et al. Expires September 25, 2008 [Page 10] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Source Address Source address field should exist for all messages except for Compressor Solicitation message and is used to indicate the address of the sender. Body Body of message. This content of this field is dependent on Operation Code. This field may not be present for certain type of messages. All fields marked with '*' are optional and may not be present for certain type of messages. The following subsections will explain the type of messages for this protocol. As mentioned, the type of message is determined by Operation Code field. 4.1.1. Compressor Advertisement Operation Code The value is 0. Destination Address This field is not present in this message. Body This field is not present in this message. This message is used by the compressor site to advertise the availability of ROHC Compressor. Out of concern for bandwidth and energy consumption, compressor site should limit the broadcast of this message for a few times when it first joins the network. This message should also be broadcasted when a Compressor Solicitation message is received. The decompressor site will use the value specified in the Source Address field when addressing compressor site. 4.1.2. Compressor Solicitation Operation Code The value is 1. Wan, et al. Expires September 25, 2008 [Page 11] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Destination Address This field is not present in this message. Source Address This field is not present in this message. Body This field is not present in this message. This message is broadcasted by decompressor to solicit for compressor. Decompressor site should rate-limit the frequency of solicitation to avoid flooding DVB link. Wan, et al. Expires September 25, 2008 [Page 12] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 4.1.3. Request MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | = MRRU (4 octets) = | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Maximum CID + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | Number of Media | | =-----+-----+-----+ Medium Types = : : +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Num of profiles + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Profile ID 1 + | | +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID 2 + : : +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID N + : : +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 4: Format of Request message The fields shown in the figure above collectively form the Body field of a Request message. This message is sent by decompressor site to compressor site when it wishes to establish a ROHC channel. The meaning of each fields in the message are described below: Operation Code Not shown in the diagram, but this field carries the value of 2. Wan, et al. Expires September 25, 2008 [Page 13] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 MRRU Maximum Reconstructed Reception Unit tolerated by decompressor. Value of 0 indicates the negotiated channel doesn't allow for segmentation of ROHC compressed packet. Maximum CID Maximum Context Identifier tolerated by decompressor. Number of Media The number of medium types carried in Medium Types field. Medium Types This field consists of all supported medium types by the decompressor. Each medium type consists of 3 bits and corresponds to Medium field described in Medium Information (Section 4.1.4.1) section. The number of bits used by Medium Types and Number of Media fields must be expanded to multiple of 8 if actual number of required bits is not multiple of 8. The unused bits for such case should be ignored by Compressor site. Number of profiles Number of profiles supported by decompressor. Profile IDs ROHC Profile IDs supported by decompressor. Each profile ID occupies 2 octets. Wan, et al. Expires September 25, 2008 [Page 14] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 4.1.4. Reply MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | = MRRU (4 octets) = | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Maximum CID + | | +===============================================+ | Num of profiles | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Profile ID 1 + | | +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID 2 + : : +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID N + : : +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 5: Format of Reply message The fields shown in the figure above collectively form the Body field of a Reply message. This message is sent by compressor site to decompressor site in response to a Request message sent by decompressor site. The meaning of each fields in the message are described below: Operation Code Not shown in the diagram, but this field carries the value of 3. MRRU Maximum Reconstructed Reception Unit tolerated by compressor. Decompressor site should send a NACK if it is receives higher MRRU than what it requested. Wan, et al. Expires September 25, 2008 [Page 15] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Maximum CID Maximum CID tolerated by compressor. This value of this field should be less than or equal to its counterpart in Request message. Decompressor site should send a NACK if it receives Maximum CID that is higher than the initial negotiated value. Number of profile IDs Note that this field occupies 1 octet instead of 2 because there can be only 256 active profiles at any given ROHC channel. Decompressor site should send a NACK if it receives more profile IDs than it can support. FIXME: Add more notes here. Profile IDs Profile Identifiers of the ROHC profiles that will be used for the negotiated ROHC channel. Decompressor site should send a NACK if it receives any profile ID that it doesn't support. 4.1.4.1. Medium Information The following notation depicted in the previous figure 10 indicates the presence of medium information. +===============================================+ Medium information conveys how compressor is to send ROHC compressed packets to decompressor over ULE packets. The details of packet format for ROHC over ULE are described in section 3. Medium type is conveyed by Medium field. Other media may be supported in the future and the support for these media will specified in other documents. Decompressor receiving unsupported medium type should send a NACK. When an unrecognized medium type is received, decompressor site should send a NACK message to compressor. 4.1.4.1.1. Dedicated PID space MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Medium=0 | | +-----+-----+-----+ PID + | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 6: Medium information for ROHC over ULE over dedicated PID space Wan, et al. Expires September 25, 2008 [Page 16] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 PID Packet Identifier of MPEG2-TS frames that will carry ROHC compressed packet. This approach should only be used when the current negotiating PID channel of MPEG2-TS is shared by multiple senders and receivers and the need to shave off the destination and source addresses from each ULE packet at the cost of using additional PID is reasonable. It is pointless to use this approach the PID channel of MPEG2-TS is only used for Point to Point communication between a sender and a receiver where there is no need to send source and destination addresses. For such case, compressor site should opt the approach mentioned in the next section. 4.1.4.1.2. ULE Medium MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Medium=1 | Type | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7: Medium information for ROHC over ULE Type: 0 No MAC address will be sent in ULE packets. This option should only be used if the compressor site is certain that there is only one receiver and one transmitter over DVB link. This is similar to what is mentioned in section Section 4.1.4.1.1, but without the cost of additional PID channel. 1 Only destination MAC address will be sent in ULE packets that carry ROHC compressed packet. This means that Destination Absent bit in ULE header will be cleared. This option is used only if there is one transmitter and many receivers listening to that transmitter via DVB link. 2 Wan, et al. Expires September 25, 2008 [Page 17] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 ROHC packets will be encapsulated in Ethernet bridged frame. This option is used when there multiple transmitters and receivers over a DVB link. 3 Not used. Receiver should treat it as corrupted packet, silently discard the message and wait for a valid Reply message or until a timeout occur at which the decompressor site will start the negotiation afresh by sending a Request message. Reserved field is not used and should be ignored. 4.1.5. Acknowledgement/Negative Acknowledgement Operation Code The value is 4. X If this bit is set, this message is an acknowledgement. Otherwise, it is a negative acknowledgement. Body This field is not present in this message. Decompressor site should send either an acknowledgement or negative acknowledgement if it receives a valid Reply message. If compressor site doesn't receive ACK nor NACK within a reasonable interval, it should discard any information of negotiated ROHC channel parameters. An acknowledgement must be sent to decompressor site when compressor site receives Decompressor Shutdown message. 4.1.6. Compressor Shutdown Operation Code The value is 5. Body This field is not present in this message. This message is sent by the compressor site to notify the decompressor site that it is about to stop compressing IP packets. Upon receiving this message, decompressor should release all Wan, et al. Expires September 25, 2008 [Page 18] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 resources that are being held for decompression. Compressor must wait for an acknowledgement from decompressor site before freeing its resource. If it doesn't receive an acknowledgement within a reasonable interval, it should keep sending a shutdown message for a number of times before freeing its resource. 4.1.7. Decompressor Shutdown Operation Code The value is 6. Body This field is not present in this message. This message is sent by the decompressor site to notify the compressor that it is about to stop decompressing IP packets. Upon receiving this message, compressor should release all resources that are being held and stop sending compressed IP packets. Decompressor must wait for an acknowledgement from compressor site before freeing its resource. If it doesn't receive an acknowledgement within a reasonable interval, it should keep sending a shutdown message for a number of times before freeing its resource. 4.2. Interaction of RCPNP The following diagram depicts a possible interaction between compressor site and decompressor site in negotiating ROHC channel parameters. Wan, et al. Expires September 25, 2008 [Page 19] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Compressor Site Decompressor Site |<---------------- Solicit ---------------| | | |-------------- Advertise --------------->| | | |<-------------- Request -----------------| | | |---------------- Reply ----------------->| | | Create instance | | of decompressor Create |<---------------- ACK -------------------| compressor | | | | |= (Compression can begin at this point) =| | | | | Destroy |<------- Decompressor Shutdown ----------| compressor | | |----------------- ACK --- -------------->| Destroy | | decompressor Figure 8: Packets flow of RCPNP Wan, et al. Expires September 25, 2008 [Page 20] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 5. Bidirectional ROHC Channels While establishing bidirectional ROHC channels allows for the use of ROHC bidirectional optimistic mode and bidirectional reliable mode, RCPNP doesn't concern itself with the establishment of bidirectional ROHC channels. Therefore, it is up to implementers of this protocol to support bidirectional ROHC channels. The implementation should be as straightforward as mapping correct pair of ROHC channels. Wan, et al. Expires September 25, 2008 [Page 21] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 6. IANA Consideration Two ULE types should be assigned. One of it is for RCPNP and the other is to indicate the presence of ROHC compressed packet. Wan, et al. Expires September 25, 2008 [Page 22] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 7. Acknowledgements We would like to thank Rod Walsh (Nokia) for his valuable input and feedback. We also want to extend our gratitude to Dr. Gorry Fairhurst for his guidance. Wan, et al. Expires September 25, 2008 [Page 23] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 8. Security Considerations - None - Wan, et al. Expires September 25, 2008 [Page 24] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 9. References 9.1. Normative References [GSE] European Telecommunication Standards Institute, "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol", TS 102 606, 2007. [IEEE-802.3] IEEE 802.3, "Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Computer Society, (also ISO/ IEC 8802-3), 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3095] Borman, C., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 2001. 9.2. Informative References [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification Version 2.0", November 1982. [ISO-MPEG2] ISO 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000. [ITU-H222] H.222.0, "Information technology - Generic coding of moving pictures and associated audio information: Systems, International Telecommunication Union, (ITU-T)", 1995. [RFC3077] Duros, E., "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, 2001. Wan, et al. Expires September 25, 2008 [Page 25] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Authors' Addresses Tat-Chee Wan Universiti Sains Malaysia School of Computer Science Universiti Sains Malaysia Penang Malaysia Phone: +6 04 653 4633 Email: tcwan@nav6.org URI: http://nrg.cs.usm.my/~tcwan Way-Chuang Ang Universiti Sains Malaysia School of Computer Science Universiti Sains Malaysia Penang Malaysia Email: wcang@nav6.org Chee-Hong Teh Universiti Sains Malaysia School of Computer Science Universiti Sains Malaysia Penang Malaysia Email: chteh@nav6.org Wan, et al. Expires September 25, 2008 [Page 26] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wan, et al. Expires September 25, 2008 [Page 27] --------------090706090407040105040409-- From owner-ipdvb@erg.abdn.ac.uk Fri Mar 28 08:49:27 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C3D28C396 for ; Fri, 28 Mar 2008 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gvKxDRm0SdN for ; Fri, 28 Mar 2008 08:49:25 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id A65F028C1AA for ; Fri, 28 Mar 2008 08:49:20 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2SFUuZM024380 for ; Fri, 28 Mar 2008 15:30:56 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2SFUuOq024379 for ipdvb-subscribed-users; Fri, 28 Mar 2008 15:30:56 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from dexter.ooi.net (dexter.ooi.net [66.251.134.16]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id m2SFUjd1024366 for ; Fri, 28 Mar 2008 15:30:46 GMT Received: (qmail 19086 invoked by uid 108); 28 Mar 2008 15:30:41 -0000 Received: from unknown (HELO LatD820547VXB1) (kevin@eccincorp.com@199.106.52.17) by dexter.ooi.net with SMTP; 28 Mar 2008 15:30:41 -0000 From: "Kevin Kimmich" To: Subject: GSE Zero Length PDU Date: Fri, 28 Mar 2008 11:31:13 -0400 Organization: Efficient Channel Coding, Inc. Message-ID: <002601c890e8$c3602690$53f8a8c0@hq.corp.viasat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C890C7.3C4E8690" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciQ6MGas3Z64V8tTsOrj2iffkd1/g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C890C7.3C4E8690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, We're in the process of defining a system that will use GSE. We are looking at cases that are ambiguous in the GSE specification. One such case is how to deal with zero length PDUs. It's possible, though probably not advisable, for an encapsulator to send such a packet. Any advice on how to handle this case? Thanks, Kevin Kimmich Senior Software Engineer Efficient Channel Coding, Inc. The University of Aberdeen is a charity registered in Scotland, No SC013683. ------=_NextPart_000_0027_01C890C7.3C4E8690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

We’re in the process of defining a system that will use GSE.

 

We are looking at cases that are ambiguous in the GSE specification. One such case is how to deal with zero length PDUs. It’= ;s possible, though probably not advisable, for an encapsulator to send such a packet.

 

Any advice on how to handle this case?=

 

Thanks,

Kevin Kimmich

Senior Software Engineer

Efficient Channel Coding, Inc.<= /p>

 

The University of Aberdeen is a charity registered in Scotland, No= SC013683. ------=_NextPart_000_0027_01C890C7.3C4E8690-- From owner-ipdvb@erg.abdn.ac.uk Fri Mar 28 08:49:27 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76E328C1AA for ; Fri, 28 Mar 2008 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l4loLdF9jGz for ; Fri, 28 Mar 2008 08:49:25 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 6DDBF3A6D38 for ; Fri, 28 Mar 2008 08:49:13 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2SFWxlv024446 for ; Fri, 28 Mar 2008 15:32:59 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2SFWxDx024445 for ipdvb-subscribed-users; Fri, 28 Mar 2008 15:32:59 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from dexter.ooi.net (dexter.ooi.net [66.251.134.16]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id m2SFWlT2024427 for ; Fri, 28 Mar 2008 15:32:48 GMT Received: (qmail 20577 invoked by uid 108); 28 Mar 2008 15:32:44 -0000 Received: from unknown (HELO LatD820547VXB1) (kevin@eccincorp.com@199.106.52.17) by dexter.ooi.net with SMTP; 28 Mar 2008 15:32:44 -0000 From: "Kevin Kimmich" To: Subject: Advice for adding support for DOCSIS frames in compliant way Date: Fri, 28 Mar 2008 11:33:15 -0400 Organization: Efficient Channel Coding, Inc. Message-ID: <002b01c890e9$0c4ad670$53f8a8c0@hq.corp.viasat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C890C7.85393670" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciQ6QpQimFQ9xsVRBWEVR4jFkskCg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C890C7.85393670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, We are defining a system which will carry DOCSIS frames over GSE. We would like to extend the GSE/ULE specifications in a compliant way. Does anyone have advice about how to proceed? Thank you, Kevin Kimmich Senior Software Engineer Efficient Channel Coding, Inc. The University of Aberdeen is a charity registered in Scotland, No SC013683. ------=_NextPart_000_002C_01C890C7.85393670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

We are defining a system which will carry DOCSIS frames = over GSE. We would like to extend the GSE/ULE specifications in a compliant way.=

 

Does anyone have advice about how to proceed?=

 

Thank you,

Kevin Kimmich

Senior Software Engineer

Efficient Channel Coding, Inc.<= /p>

 

The University of Aberdeen is a charity registered in Scotland, No= SC013683. ------=_NextPart_000_002C_01C890C7.85393670-- From owner-ipdvb@erg.abdn.ac.uk Sat Mar 29 10:03:45 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8B73A7058 for ; Sat, 29 Mar 2008 10:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrKl62-qv7b8 for ; Sat, 29 Mar 2008 10:03:34 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 0126228C493 for ; Sat, 29 Mar 2008 10:02:21 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2TGe4wb000004 for ; Sat, 29 Mar 2008 16:40:04 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2TGe4p1029999 for ipdvb-subscribed-users; Sat, 29 Mar 2008 16:40:04 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [141.201.2.23]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2TGdqd6029973 for ; Sat, 29 Mar 2008 16:39:52 GMT Received: from [141.201.2.21] (milbe.cosy.sbg.ac.at [141.201.2.21]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 3F7C2229667; Sat, 29 Mar 2008 17:39:52 +0100 (CET) Message-ID: <47EE70D7.2030702@cosy.sbg.ac.at> Date: Sat, 29 Mar 2008 17:39:51 +0100 From: Bernhard Collini-Nocker User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: kevin@eccincorp.com Cc: ipdvb@erg.abdn.ac.uk Subject: Re: Advice for adding support for DOCSIS frames in compliant way References: <002b01c890e9$0c4ad670$53f8a8c0@hq.corp.viasat.com> In-Reply-To: <002b01c890e9$0c4ad670$53f8a8c0@hq.corp.viasat.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Hello Kevin, Kevin Kimmich schrieb: > Hello, > > We are defining a system which will carry DOCSIS frames over GSE. We > would like to extend the GSE/ULE specifications in a compliant way. maybe I am missing the point, but what would be the benefit of carrying DOCSIS frames over GSE instead of sending the PDU via GSE only? I do see only management/signalling reasons but did not catch its value yet. > Does anyone have advice about how to proceed? I see two fast tracks: 1. apply for an EtherType value that would allow to send DOCSIS frames also over any "Ethernet" and bridge it accordingly over GSE (that could provide some added value for the interconnection of DOCSIS-modem and GSE-encapsulator but adds bridging overhead) 2. go for an (ULE/)GSE mandatory extension header I-D and have a Extension Header (carrying DOCSIS frames) value being assigned therefor (less overhead but also less and maby too little functionality) > Thank you, > Kevin Kimmich Regards, Bernhard Collini-Nocker > Senior Software Engineer > Efficient Channel Coding, Inc. Ass.Prof. University of Salzburg > > The University of Aberdeen is a charity registered in Scotland, No SC013683. > The University of Aberdeen is a charity registered in Scotland, No SC013683. From owner-ipdvb@erg.abdn.ac.uk Sat Mar 29 10:13:06 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898383A696B for ; Sat, 29 Mar 2008 10:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyyWY4TdA9Vj for ; Sat, 29 Mar 2008 10:13:05 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id E5C163A6A01 for ; Sat, 29 Mar 2008 10:12:59 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2TGv3e0000358 for ; Sat, 29 Mar 2008 16:57:03 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2TGv3rO000357 for ipdvb-subscribed-users; Sat, 29 Mar 2008 16:57:03 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [141.201.2.23]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2TGupk5000342 for ; Sat, 29 Mar 2008 16:56:51 GMT Received: from [141.201.2.21] (milbe.cosy.sbg.ac.at [141.201.2.21]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 7B5E522843F; Sat, 29 Mar 2008 17:56:51 +0100 (CET) Message-ID: <47EE74D3.3080602@cosy.sbg.ac.at> Date: Sat, 29 Mar 2008 17:56:51 +0100 From: Bernhard Collini-Nocker User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: kevin@eccincorp.com Cc: ipdvb@erg.abdn.ac.uk Subject: Re: GSE Zero Length PDU References: <002601c890e8$c3602690$53f8a8c0@hq.corp.viasat.com> In-Reply-To: <002601c890e8$c3602690$53f8a8c0@hq.corp.viasat.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Hello (again), Kevin Kimmich schrieb: > Hello, > > We’re in the process of defining a system that will use GSE. > > We are looking at cases that are ambiguous in the GSE specification. > One such case is how to deal with zero length PDUs. It’s possible, > though probably not advisable, for an encapsulator to send such a > packet. on one side a zero length PDU (interpreted as having a valid protocol header but empty payload) is not a "problem" for GSE rather than the upper layer protocol(s) that handles the PDU. As long as the GSE-Protocol-Type field is valid it will pass this "problem" to the upper layer indicated by Protocol-Type. On the other side (interpreting zero length PDU as having no header at all) GSE would need a special Protocol-Type value to support transport of it (nothing?). Currently only the test-extension-header (see RFC 4326, 5.1) could support this, but would prevent a receiver from forwarding this (non-existing) data... > Any advice on how to handle this case? Combining this with your next question (DOCSIS over GSE) I would assume that signalling is being carried in DOCSIS frames (as GSE PDUs) that have only a header but no payload, in what case the first of above options should work. > Thanks, > Kevin Kimmich Regards, Bernhard > Senior Software Engineer > > Efficient Channel Coding, Inc. > > > > The University of Aberdeen is a charity registered in Scotland, No > SC013683. > The University of Aberdeen is a charity registered in Scotland, No SC013683. From owner-ipdvb@erg.abdn.ac.uk Sat Mar 29 11:34:07 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C323A6E52 for ; Sat, 29 Mar 2008 11:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7Xjf2giq5T8 for ; Sat, 29 Mar 2008 11:34:06 -0700 (PDT) Received: from erg.abdn.ac.uk (unknown [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 5B1C33A6BE0 for ; Sat, 29 Mar 2008 11:34:06 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2TIDCAX002384 for ; Sat, 29 Mar 2008 18:13:12 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m2TIDCkP002383 for ipdvb-subscribed-users; Sat, 29 Mar 2008 18:13:12 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from gorry-fairhursts-macbook-pro.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m2TICxLC002373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Mar 2008 18:13:00 GMT Message-ID: <47EE86AB.60909@erg.abdn.ac.uk> Date: Sat, 29 Mar 2008 18:12:59 +0000 From: Gorry Fairhurst Organization: Univeristy of Aberdeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: TC Wan Subject: Re: I-D ACTION:draft-wan-ipdvb-rohc-00.txt References: <47E3ADC2.80108@erg.abdn.ac.uk> <47E7516A.8080902@nav6.org> In-Reply-To: <47E7516A.8080902@nav6.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Thanks, See in-line for a clarification, and some suggestions on formatting. Best wishes, Gorry Ang Way Chuang wrote: > Dear Dr. Fairhurst, > > Here is updated version according your previous feedback, but still > incomplete. I removed the section that carries ROHC compressed packet > directly over MPEG2-TS. So, what works for ULE should also work for GSE > except for section 4.1.4.1.1 which relies on MPEG2-TS. > > In addition to 2 new ULE type, we also need to have a new EtherType for > section 3.1.2. If getting new EtherType is hard, we may need to redefine > the packet format. > > As for your previous comment: > > 2) In Section 3.1.1: > > > > "In the absence of multiple receivers, a transmitter can send an > > SNDU"... > > > > I think this is only partially true, it may be safer to refer this to > > RFC4326, since this is also dependent on the way in which the ULE > > Stream is used. > > I'm not sure what you meant exactly. I refer to figure 11 of RFC4326 and > the Receiver Destination NPA address field seems redundant since MAC > destination address is there. Any practical scenario where Receiver > Destination needs to be different from MAC destination address? > There could be - when the receiver is an Ethernet Bridge and this is feeding a local area network. In the case in Figure 11, the NPA address is the address of the receiver itself. This topology resembles that of Metro-Ethernet - where Ethernet frames are bridged between two or more attached LANs using a L2 network. The NPA addresses are local only to the DVB/MPEG network and used to construct the "virtual" transmission network. > Diagrams has been changed to conform with the style used by RFC4326, but > style of diagram 4, 5, 6 and 7 is left untouched since it is difficult > to represent variable format imposed by medium information using the > former style. > > Thank you. > --- The abstract should state the name of the specification it is extendin in full, hence: " This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC4326." --- You may also wish to define: B: Byte. Groups of bytes are represented in Internet byte order. Next-Header: A Type value indicating an Extension Header [RFC4326]. NPA: Network Point of Attachment [RFC4326]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers. ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation defines an extension format and an associated IANA Registry. --- I suggest rewriting the IANA section, so that reads something like the following. This is the form of words we used in previous IANA requests. This document requires IANA involvement for the assignment of two new Next-Header Type values from the IANA ULE Next-Header Registry. The following assignments have been made in this document, and registered by IANA: XXX NOTE: IANA please replace TBD and TBD-1 when assigned XXX Type Name Reference TBD: ULE-ROHC Section 3.1 TBD-1: ULE-ROHC-Neg Section 4.1 The ULE-ROHC Extension is a Mandatory next-type Extension Header, specified in section 3.1 of this document. The value of this next- header is defined by an IANA assigned H-Type value of TBD. The ULE-ROHC-Neg Extension is a Mandatory next-type Extension Header specified in section 4.1 of this document. The value of this next- header is defined by an IANA assigned H-Type value of TBD-1. --- The University of Aberdeen is a charity registered in Scotland, No SC013683. From iporpr-bounces@ietf.org Sun Mar 30 01:38:42 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0D93A6CCF for ; Sun, 30 Mar 2008 01:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.256 X-Spam-Level: X-Spam-Status: No, score=-62.256 tagged_above=-999 required=5 tests=[AWL=-10.257, BAYES_00=-2.599, GB_REPLICA=50, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHU-NG6R7MQ8 for ; Sun, 30 Mar 2008 01:38:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6513A6CBA for ; Sun, 30 Mar 2008 01:38:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to IPORPR awaits moderator approval From: iporpr-bounces@ietf.org To: ipdvb-archive@ietf.org Message-ID: Date: Sun, 30 Mar 2008 01:38:40 -0700 Precedence: bulk X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.1.9 List-Id: IP over Resilient Packet Rings X-List-Administrivia: yes Sender: iporpr-bounces@ietf.org Errors-To: iporpr-bounces@ietf.org Your mail to 'IPORPR' with the subject ***SPAM*** 219.5 (5) Repl1ca watch is a perfect gift Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/iporpr/bd6fe15cc8439d1659d69efc6a810fd0a039cdf3