From wcang at nav6.org Sun Mar 2 07:55:39 2008 From: wcang at nav6.org (Ang Way Chuang) Date: Sun, 02 Mar 2008 15:55:39 +0800 Subject: Draft for ROHC over DVB - comments on your text. In-Reply-To: <47C0663E.20100@erg.abdn.ac.uk> 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> Message-ID: <47CA5D7B.1000609@nav6.org> 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 postmaster at experian.com Sat Mar 8 09:36:56 2008 From: postmaster at experian.com (Experian.com Postmaster) Date: Sat, 8 Mar 2008 03:36:56 -0600 Subject: Delivery Status Notification (Failure) Message-ID: This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. ipdvertical at smrb.com -------------- next part -------------- An embedded message was scrubbed... From: Subject: RE: MedHelp 113151 Date: 8 Mar 2008 03:38:56 -0600 Size: 11024 URL: From gorry at erg.abdn.ac.uk Thu Mar 13 17:26:19 2008 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 13 Mar 2008 13:26:19 -0400 Subject: opsdir review of draft-ietf-ipdvb-ule-ext-07] - Proposed changes. Message-ID: <47D963BB.7030804@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 at comcast.net > > ietfdbh at comcast.net > From gorry at erg.abdn.ac.uk Fri Mar 21 12:44:50 2008 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Fri, 21 Mar 2008 12:44:50 +0000 Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt Message-ID: <47E3ADC2.80108@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 wcang at nav6.org Mon Mar 24 06:59:54 2008 From: wcang at nav6.org (Ang Way Chuang) Date: Mon, 24 Mar 2008 14:59:54 +0800 Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt In-Reply-To: <47E3ADC2.80108@erg.abdn.ac.uk> References: <47E3ADC2.80108@erg.abdn.ac.uk> Message-ID: <47E7516A.8080902@nav6.org> 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. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-wan-ipdvb-rohc-01-pre.txt URL: From kevin at eccincorp.com Fri Mar 28 15:31:13 2008 From: kevin at eccincorp.com (Kevin Kimmich) Date: Fri, 28 Mar 2008 11:31:13 -0400 Subject: GSE Zero Length PDU Message-ID: <002601c890e8$c3602690$53f8a8c0@hq.corp.viasat.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at eccincorp.com Fri Mar 28 15:33:15 2008 From: kevin at eccincorp.com (Kevin Kimmich) Date: Fri, 28 Mar 2008 11:33:15 -0400 Subject: Advice for adding support for DOCSIS frames in compliant way Message-ID: <002b01c890e9$0c4ad670$53f8a8c0@hq.corp.viasat.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnocker at cosy.sbg.ac.at Sat Mar 29 16:39:51 2008 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Sat, 29 Mar 2008 17:39:51 +0100 Subject: Advice for adding support for DOCSIS frames in compliant way In-Reply-To: <002b01c890e9$0c4ad670$53f8a8c0@hq.corp.viasat.com> References: <002b01c890e9$0c4ad670$53f8a8c0@hq.corp.viasat.com> Message-ID: <47EE70D7.2030702@cosy.sbg.ac.at> 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 bnocker at cosy.sbg.ac.at Sat Mar 29 16:56:51 2008 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Sat, 29 Mar 2008 17:56:51 +0100 Subject: GSE Zero Length PDU In-Reply-To: <002601c890e8$c3602690$53f8a8c0@hq.corp.viasat.com> References: <002601c890e8$c3602690$53f8a8c0@hq.corp.viasat.com> Message-ID: <47EE74D3.3080602@cosy.sbg.ac.at> 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 gorry at erg.abdn.ac.uk Sat Mar 29 18:12:59 2008 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sat, 29 Mar 2008 18:12:59 +0000 Subject: I-D ACTION:draft-wan-ipdvb-rohc-00.txt In-Reply-To: <47E7516A.8080902@nav6.org> References: <47E3ADC2.80108@erg.abdn.ac.uk> <47E7516A.8080902@nav6.org> Message-ID: <47EE86AB.60909@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.