From owner-ipdvb@erg.abdn.ac.uk Mon May 3 13:50:35 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i43CnUoB013503 for ; Mon, 3 May 2004 13:49:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i43CnT7V013502 for ipdvb-subscribed-users; Mon, 3 May 2004 13:49:29 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i43CmQiL013447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 3 May 2004 13:48:27 +0100 (BST) Message-ID: <40963F9D.1050301@erg.abdn.ac.uk> Date: Mon, 03 May 2004 13:48:29 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: 60th IETF Meeting - San Diego, CA, USA Content-Type: text/plain; charset=us-ascii; 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-Information: See www.mailscanner.info for information X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk The Sixtieth IETF meeting will be held 1-6 August 2004 in San Diego, CA, USA. Please note the following cut-off dates for submission of documents to this meeting. http://www.ietf.org/meetings/cutoff_dates_60.html I will (of course) be requesting a meeting slot for the ipdvb working group, and would welcome any suggestions of agenda items or volunteers to present on WG IDs. Please send agenda items to: gorry@erg.abdn.ac.uk Gorry Fairhurst ipdvb WG Chair From owner-ipdvb@erg.abdn.ac.uk Fri May 14 11:26:22 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4EAP1xn003701 for ; Fri, 14 May 2004 11:25:01 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i4EAP04U003700 for ipdvb-subscribed-users; Fri, 14 May 2004 11:25:00 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4EANIXJ003600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2004 11:23:20 +0100 (BST) Message-ID: <40A49E17.7090000@erg.abdn.ac.uk> Date: Fri, 14 May 2004 11:23:19 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hilmar Linder , ip-dvb@erg.abdn.ac.uk Subject: Qustion about minimum Ethertype value. Content-Type: text/plain; charset=us-ascii; 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-Information: See www.mailscanner.info for information X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk A question was raised regarding the Type value that should separate the ULE Type 1 and Type 2 headers. The current rev -00 of the ULE Spec is incorrect (bearing in mind tagged LLC frames that may be longer than 1500B). The current text says: >>> "Ethertypes were originally specified by Xerox under the DIX framework for Ethernet. After specification of IEEE 802.3 [LLC], the set of Ethertypes less than or equal to 1500 (0x05FC), assumed the role of a length indicator. Ethernet receivers use this feature to discriminate LLC format frames. Hence any IEEE Ethertype <= 1500 indicates an LLC frame, and the actual value indicates the length of the LLC frame." <<< Based on the IEEE specification (see below), I propose that the text in the ULE Spec should now be ammended to: >>> "Ethertypes were originally specified by Xerox under the DIX framework for Ethernet. After specification of IEEE 802.3 [LLC], the set of Ethertypes less than 1536 (0x600 in hexadecimal), assumed the role of a length indicator. Ethernet receivers use this feature to discriminate LLC format frames. Hence any IEEE Ethertype < 1536 indicates an LLC frame, and the actual value indicates the length of the LLC frame." <<< This implies changes to the protocol text in other places also where 1500/1501 are referenced in the text. Do other people agree with this change? Gorry Fairhurst (ULE Author) ------ The IEEE allocation is described at: http://standards.ieee.org/regauth/ethertype/type-tut.html It says: "The IEEE 802.3, 1998 Length/Type Field, originally known as EtherType, is a two-octet field which takes one of two meanings, depending on its numeric value. For numeric evaluation, the first octet is the most significant octet of this field. This document only deals with the type interpretation of the Length/Type Field. See standards IEEE 802.3, 1998 Clause 3.2.6 Length/Type Field specifications and IEEE 802.1H-1995 for use of the Type Field with other media access methods. When the value of this field is greater than or equal to 1536 decimal (equal to 0600 hexadecimal) the Type Field indicates the nature of the MAC client protocol (Type interpretation). The length and type interpretations of this field are mutually exclusive. Therefore when the value of the two octet field is equal to or greater than 0600 hex then it is a Type Field and the value of the Type Field is obtained from the IEEE Type Field Registrar. New values obtained from the IEEE Type Field Registrar will not interfere with the existing Type Field assignments from Xerox or the IEEE. Former assignments are still valid." The IANA view is: Assignments: Ethernet Exp. Ethernet Description References ------------- ------------- ----------- ---------- decimal Hex decimal octal 0000 0000-05DC - - IEEE802.3 Length Field [XEROX] 0257 0101-01FF - - Experimental [XEROX] 0512 0200 512 1000 XEROX PUP (see 0A00) [8,XEROX] 0513 0201 - - PUP Addr Trans (see 0A01)[XEROX] 0400 Nixdorf [XEROX] 1536 0600 1536 3000 XEROX NS IDP [133,XEROX] The corresponding IEEE Registry is at: http://standards.ieee.org/regauth/ethertype/type-pub.html From owner-ipdvb@erg.abdn.ac.uk Thu May 20 08:29:46 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4K7Pfj3001942 for ; Thu, 20 May 2004 08:25:41 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i4K7Pe0O001941 for ipdvb-subscribed-users; Thu, 20 May 2004 08:25:40 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from lin.calsoft.co.in ([203.129.222.68]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4K7LvTg001670 for ; Thu, 20 May 2004 08:22:00 +0100 (BST) Received: from calsoftwilliam ([203.129.222.92]) by lin.calsoft.co.in (8.11.0/8.11.0) with SMTP id i4K6uUE12313 for ; Thu, 20 May 2004 12:26:32 +0530 From: "William StanisLaus" To: Subject: RE: Adaptation field use in ULE / MPG2-TS specification Date: Thu, 20 May 2004 12:37:35 +0530 Message-ID: <002501c43e39$23fd3030$8c0210ac@calsoftwilliam> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001201c423be$6b4726c0$8c0210ac@calsoftwilliam> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-MailScanner: Found to be clean 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-Information: See www.mailscanner.info for information X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk Hi, Is there any decision/conclusion made by the work group on Adaption field use in ULE by MPEG2-TS. Best Regards, William. > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of William StanisLaus > Sent: Friday, April 16, 2004 7:54 PM > To: ip-dvb@erg.abdn.ac.uk > Subject: RE: Adaptation field use in ULE / MPG2-TS specification > > > > > Let me add my understanding with MPEG2-TS decode. > > transport_packet(){ > sync_byte > 8 bslbf > transport_error_indicator > 1 bslbf > payload_unit_start_indicator > 1 bslbf > transport_priority > 1 bslbf > PID > 13 uimsbf > transport_scrambling_control > 2 bslbf > adaptation_field_control > 2 bslbf > continuity_counter > 4 uimsbf > if(adaptation_field_control=='10' || > adaptation_field_control=='11'){ > adaptation_field() > } > if(adaptation_field_control=='01' || > adaptation_field_control=='11') > { > for (i=0;i data_byte > 8 bslbf > } > } > } > > here PUSI, says the start of new payload or continuation of > the pervious > payload for this MPEG packet. > i.e. if PUSI = 0 , continuation/end of the previous payload > and PUSI = 1 > start of new payload. > > NOTE the packet is identified based on the PID. > > Continuity counter plays a decent role, if the MPE packet > doesn't fit in one > MPEG header. > > Regarding Adaptation field, i have already explained in detail. > > Tor's concern (if i am not wrong) is "transport private data" > in adaptation > field which he wants to use to carry some private information > within his > network, which is purely internal and propieratory, which he > uses for his > network management. and also he is concerned that, his > transport private > data is going to be less than 50 bytes say for example and > doesn't want to > waste rest of the payload capacity, hence he wants to club > with the traffic > payload, so he updates the adaptation field control as "11". > i.e it contains > adaptation field as well as SNDU payload. BUT ULE draft > doesn't support this > AFC and discards the packet. > > Tor correct me if my understand is wrong. > > Best Regards, > William. > > > > -----Original Message----- > > From: owner-ip-dvb@erg.abdn.ac.uk > > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > > Behalf Of Gorry Fairhurst > > Sent: Friday, April 16, 2004 6:43 PM > > To: ip-dvb@erg.abdn.ac.uk > > Subject: Re: Adaptation field use in ULE / MPG2-TS specification > > > > > > I'm interested in use-cases that could illustrate how the > AF would be > > used (if equipment supported this) with ULE TS. > > > > Can you give me more details of what how you see an AF > being added by > > some "lower layer" equipment, and how this > > could actually be used with a stream of SNDUs using ULE? > > > > Tor Brekke wrote: > > > > > > > > In the MPG transport stream packet definition the MPG > > header format is > > > defined. There is an explicit exception for the PUSI bit which the > > > standard does not define for private data (in this context > > I guess ULE > > > must be considered private). All other fields are defined either > > > independent of the payload type. I interpret this to say > > that we are > > > not free to redefine the use of the adaptation field for a > > new payload > > > type, > > > > >>> The following worries/interests me, specifically > > - does this assume the "lower layer processing" understands the > > semantics of the PUSI? > > Can you explain what you mean by this statement, so that we can > > understand the full implications... > > > > > and that adaptation fields may be inserted at lower layers > > (seen from > > > the MPG layer the payload is only a stream of octets, possibly > > > including synchronisation points as signalld by PUSI). > > > > > > Note again that we are not interested in enforcing the use of the > > > adaptation field in other systems. We only want to ensure > > that ULE can > > > be used on systems which use the adaptation field. > > > > > > --Tor > > > > > > > > > > > > > > > "HDClausen" > > > Sent by: owner-ip-dvb@erg.abdn.ac.uk > > > > > > 14.04.2004 21:45 > > > Please respond to > > > ip-dvb@erg.abdn.ac.uk > > > > > > > > > > > > To > > > > > > cc > > > > > > Subject > > > Re: Adaptation field use in ULE / MPG2-TS specification > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Explicitly > > > > prohibiting this in the ULE specification seems to be > in violation > > > > the MPG2 specification (i.e. ISO/IEC-13818-1). > > > > > > Could you, please, indicate where in the decument I can find this. > > > Art Allison wrote: "Only PES or PSI structures are > standardized for > > > carriage > > > by 13838-1 in > > > MPEG-2 TS packets." If that is the case (and this is what I > > understood > > > from > > > the document) than any other use is not in violation with > > MPEG-2 but with > > > something else i.e. the question is: is DVB-RCS imposing a > > recommendation > > > which is not (yet) required by MPEG-2. > > > > > > This does not mean we should not discuss this subject and > > come up with a > > > solution. > > > > > > --H. Clausen > > > > > > > > > > > > ----- Original Message ----- > > > From: "Tor Brekke" > > > To: > > > Cc: ; > > > Sent: Wednesday, April 14, 2004 1:01 AM > > > Subject: Re: Adaptation field use in ULE / MPG2-TS specification > > > > > > > > > > Want to fill in somewhat to William's detailed answer. > > > > > > > > 1) There is a proposal in DVB-RCS to utilise the > > adaptation field to > > > > perform inband signalling for the DVB-RCS network. This > > signalling > > > has to > > > > be independent of the higher layers, as it has to be > > available before > > > > these are up (same applies for Ethernet, which may of > > course not even be > > > > present). This was the reason for bringing this up in the first > > > place. The > > > > problem is more general though. The adaptation field can > > be used by the > > > > MPG2-TS layer (ref. William's detailed explanation). Explicitly > > > > prohibiting this in the ULE specification seems to be in > > violation with > > > > the MPG2 specification (i.e. ISO/IEC-13818-1). > > > > > > > > 2) All receivers should as a minimum be able to rip off > > the field. As > > > > William S. says this is part of MPG processing and should not > > > concern ULE > > > > at all (unless you have a specific design in mind....). > > In any case the > > > > performance hit of checking one bit and throwing away some data > > > every now > > > > and then (most likely never in most systems) should not affect > > > performance > > > > much. > > > > > > > > --Tor Brekke > > > > > > > > > > > > > > > > > > > > Gorry Fairhurst > > > > Sent by: owner-ip-dvb@erg.abdn.ac.uk > > > > 13.04.2004 17:59 > > > > Please respond to > > > > ip-dvb@erg.abdn.ac.uk > > > > > > > > > > > > To > > > > ip-dvb@erg.abdn.ac.uk > > > > cc > > > > > > > > Subject > > > > Re: Adaptation field use in ULE / MPG2-TS specification > > > > > > > > > > > > > > > > > > > > > > > > > > > > So... as I recall, the rationale behind the current rev. was: > > > > > > > > 1) There was no stated requirement for the Adaptation Field > > > > when used with ULE, if this requirement has emerged, then > > > > I think we need to know what function is being propossed > > > > and why this is performed at the MPEG-2 layer, rather than > > > > at the IP/Ethernet layers. Please send text! > > > > > > > > 2) There is a cost at adding Adaptation Field processing, in > > > > that it impacts implementation/performance of the ULE receiver. > > > > This has a performance hit, if it is mandatory to support it. > > > > If it is optional, then there is a compatability hit. > > > > > > > > Thoughts? > > > > > > > > Gorry > > > > > > > > P.S. Note: ULE does *NOT* use the PES syntax for the data > > > > sent on these streams. > > > > > > > > William StanisLaus wrote: > > > > > > > > > Here ULE is not preventing use of lower level MPEG2 > > packet header > > > > > fields, rather we should figure out why we drop the > > packet based on > > > > > the adaptation field control, is there any reason > > behind to specify in > > > > > the draft to drop packets other than AFC is "01" > > > > > > > > > > In the case of adaptation field, which is coupled > with MPEG2-TS > > > > > header, itself will be decoded and action could have > > taken well before > > > > > the control reaches ULE. Hence the goal of adaptation field is > > > > > accomplished, if it is going to be a sequential/linear > > processing. But > > > > > the question is, when the AFC is "11" in such case > > MPEG2-TS payload > > > > > contains both adaptation field private section data and > > actual payload > > > > > (SNDU), SNDU payload processing will be dropped as per > > the ULE draft. > > > > > > > > > > Best Regards, > > > > > William. > > > > > > > > > > -----Original Message----- > > > > > From: owner-ip-dvb@erg.abdn.ac.uk > > > > > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of > > Allison, Art > > > > > Sent: Tuesday, April 13, 2004 6:51 PM > > > > > To: 'ip-dvb@erg.abdn.ac.uk' > > > > > Subject: RE: Adaptation field use in ULE / MPG2-TS > > specification > > > > > > > > > > I agree with Tor (and am a bit chagrined that I > > didn't notice > > > > > this). The ULE draft should not prevent use of the > > 'lower' level > > > > > MPEG-2 packet header fields, and that included the > > adaptation > > > > > field. A key concept ( Tor's point #2) in MPEG-2 > > systems is the > > > > > layering with each layer having a separable > > function. Building > > > > > vertically integrated designs that constrain this > > reduce long term > > > > > flexibility and can have other impacts like the one Tor > > > identified. > > > > > > > > > > However, now that I glance at the header > > structure...to send this > > > > > data in TS packets, 'payload start indicator' must > > be set to a > > > > > value. It is one bit, where 0= no PES start in this > > packet, and 1= > > > > > PES or PSI start in this packet. Suggest define > > that it be set > > > to 0. > > > > > > > > > > Art > > > > > ::{)> > > > > > Art Allison > > > > > Director Advanced Engineering > > > > > NAB > > > > > 1771 N St NW > > > > > Washington DC 20036 > > > > > 202 429 5418 > > > > > > > > > > -----Original Message----- > > > > > From: William StanisLaus > [mailto:williams@calsoft.co.in] > > > > > Sent: Tuesday, April 13, 2004 8:18 AM > > > > > To: ip-dvb@erg.abdn.ac.uk > > > > > Subject: RE: Adaptation field use in ULE / MPG2-TS > > > specification > > > > > > > > > > Hi Marie-Jose, > > > > > I understand your point here about > > extension headers. But > > > > > actually Adaptation field specified here is part of > > > > > MPEG2-TS header and not ULE, in that case > even ULE is a > > > > > payload for MPEG2-TS. If adaption field control > > is 10 or 11 in > > > > > bits, MPEG2-TS contains private adaption field, > > and incase of > > > > > "10" we need not care about anything, but still > > ULE draft says > > > > > anything other than " 01" in AFC, receiver > MUST discard. > > > > > Thanks for your comment Tor Brekke, but i > > wonder why we > > > > > have such limitation in ULE, even though we are > > not worried in > > > > > ULE about the MPEG2-TS private section of > > Adaption field, if > > > > > we are not going to take any action based on > > the adaption > > > > > field and control field we can just ignore. I > > see this as an > > > > > implementation issue and should not be limited in > > > > > specification/draft. > > > > > > > > > > transport_packet(){ > > > > > > > > > > sync_byte > > > > > 8 bslbf > > > > > > > > > > transport_error_indicator > > > > > 1 bslbf > > > > > > > > > > payload_unit_start_indicator > > > > > 1 bslbf > > > > > > > > > > transport_priority > > > > > 1 bslbf > > > > > > > > > > PID > > > > > 13 uimsbf > > > > > > > > > > transport_scrambling_control > > > > > 2 bslbf > > > > > > > > > > adaptation_field_control > > > > > 2 bslbf > > > > > > > > > > continuity_counter > > > > > 4 uimsbf > > > > > if(adaptation_field_control=='10' || > > > > > adaptation_field_control=='11'){ > > > > > adaptation_field() > > > > > } > > > > > if(adaptation_field_control=='01' || > > > > > adaptation_field_control=='11') { > > > > > for (i=0;i > > > > > > > > > data_byte > > > > > 8 bslbf > > > > > } > > > > > } > > > > > } > > > > > > > > > > here N data_byte's is SNDU as specified by ULE. > > > > > > > > > > Also ULE cannot limit anything on exisiting underlying > > > > > protocol as such MPEG2-TS. But definitly it > can limit or > > > > > provide more services to above layers. > > > > > > > > > > > > > > > Best Regards, > > > > > William StanisLaus > > > > > CalSoft, Nortel Networks Division > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ip-dvb@erg.abdn.ac.uk > > > > > [mailto:owner-ip-dvb@erg.abdn.ac.uk]On Behalf Of > > > > > Marie-Jose Montpetit > > > > > Sent: Tuesday, April 13, 2004 4:00 PM > > > > > To: ip-dvb@erg.abdn.ac.uk > > > > > Subject: Re: Adaptation field use in ULE / MPG2-TS > > > > > specification > > > > > > > > > > Thanks for you input. If you follow recent > > discussions > > > > > there is a proposal to use extension > > headers in ULE to > > > > > support system specific signalling (and > > other). It would > > > > > be interesting to know more about how you > > process the > > > > > information but I think our philosophy > > would be to use the > > > > > headers in the same way as you describe: > > transparent to > > > > > system who do not know what to do with > > them, processed by > > > > > the ones who do. This is consistent with > > IPv6 extension > > > > > headers and also with other implementations > > of extension > > > > > headers (cable for example). > > > > > > > > > > So I do believe we could use ULE in RCS. > > Actually in a > > > > > recent study sponsored by ESA we showed > > that for traffic > > > > > with a lot of ACK bursts (http: for > > example) ULE was very > > > > > efficient because of it's packing capability. > > > > > > > > > > Again thanks for your input. > > > > > > > > > > Marie-Jose > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: Tor Brekke > > > > > > To: ip-dvb@erg.abdn.ac.uk > > > > > > > > Sent: Tuesday, April 13, 2004 3:02 AM > > > > > Subject: Adaptation field use in ULE / MPG2-TS > > > > > specification > > > > > > > > > > > > > > > Hello, > > > > > > > > > > I am jumping into this discussion at a > > fairly late > > > > > stage. Having just read the ULE draft I > > have to make a > > > > > comment about the use of the adaptation > > field though. > > > > > In the draft it says that "TS Packets > from a ULE > > > > > Encapsulator MUST be sent with an AFC > > value of '01'", > > > > > i.e. without adaptation field. Now the > > adaptation > > > > > field contains a private field which > > according to the > > > > > MPG2-TS specification (ISO/IEC 13818-1) > > can be used to > > > > > transmit system dependent data. > > > > > Now to the question: Why is this > > limitation imposed on > > > > > ULE? > > > > > > > > > > I have two main reasons to ask this. > > > > > 1) Firstly there is ongoing work to use > > the private > > > > > adaptation field for network internal > > signalling in > > > > > the DVB-RCS standard. This means that > > ULE will not > > > > > work over DVB-RCS systems employing the > > adaptation > > > > > field signalling. > > > > > 2) As far as I have been able to > > determine all other > > > > > encapsulation forms over MPG2-TS are > > transparent to > > > > > the adaptation field, i.e. the > > adaptation field and > > > > > payload are handled independently (even > > though there > > > > > may be an implicit connection between > > them). It seems > > > > > strange to break this logicinf the > > MPG2- TS mechanism > > > > > for a new encapsulation type. > > > > > > > > > > Best Regards > > > > > Tor Brekke > > > > > Nera Broadband Satellite AS. > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ipdvb@erg.abdn.ac.uk Fri May 21 21:06:49 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4LJvhXP024344 for ; Fri, 21 May 2004 20:57:43 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i4LJvh0T024343 for ipdvb-subscribed-users; Fri, 21 May 2004 20:57:43 +0100 (BST) Message-Id: <200405211957.i4LJvh0T024343@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipdvb-ule-01.txt Date: Fri, 21 May 2004 15:52:49 -0400 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-Information: See www.mailscanner.info for information X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks Author(s) : G. Fairhurst, B. Collini-Nocker Filename : draft-ietf-ipdvb-ule-01.txt Pages : 38 Date : 2004-5-21 The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes an Ultra Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over ISO MPEG- 2 Transport Streams (TS) as TS Private Data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-ule-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-ule-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-21155647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipdvb-ule-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipdvb-ule-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-21155647.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipdvb@erg.abdn.ac.uk Sun May 30 07:07:11 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4U660en024843 for ; Sun, 30 May 2004 07:06:00 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i4U65x4G024842 for ipdvb-subscribed-users; Sun, 30 May 2004 07:06:00 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from iit.demokritos.gr (aiolos.iit.demokritos.gr [143.233.6.1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4U65SOe024825 for ; Sun, 30 May 2004 07:05:28 +0100 (BST) Received: from CPQ19007325591 (ppp-a-37.dialup.ariadne-t.gr [143.233.99.37]) by iit.demokritos.gr (8.11.6+Sun/8.11.6) with ESMTP id i4U5s9o29439 for ; Sun, 30 May 2004 08:54:09 +0300 (EEST) From: "Charalabos Skianis" To: Subject: RE: Special Session - All-IP Convergence in HETNETs04 Date: Sun, 30 May 2004 09:05:14 +0300 Message-ID: <000601c4460c$168c6cb0$2563e98f@CPQ19007325591> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C44625.3BD9A4B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <4087C6CD.1010403@erg.abdn.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C44625.3BD9A4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear colleagues, You are cordially invited to submit in the Special Session of HET-NETs '04 entitled 'All-IP Convergence' Further details regarding the organisation and the themes of conference in general can be found in the website < http://www.comp.brad.ac.uk/het-net>. Kind regards, Dr. Harry Skianis Session Chair PS. Please CC any submission for the Special Session to myself!! ------=_NextPart_000_0007_01C44625.3BD9A4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = colleagues,

 

You are cordially invited to = submit in the Special Session of HET-NETs '04 entitled 'All-IP = Convergence'

 

Further details regarding the organisation and the themes of conference in = general can be found in the website <http://www.comp.brad.ac.uk/het-net>.

 

Kind = regards,

 

Dr. = Harry = Skianis

Session = Chair

 

PS. Please CC any submission for = the Special Session to myself!!

 

------=_NextPart_000_0007_01C44625.3BD9A4B0-- From owner-ipdvb@erg.abdn.ac.uk Mon May 31 00:03:44 2004 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4UN2Vas026766 for ; Mon, 31 May 2004 00:02:31 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id i4UN2VRI026765 for ipdvb-subscribed-users; Mon, 31 May 2004 00:02:31 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from bonnie.ses-astra.com (bonnie.ses-astra.com [194.154.219.59]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i4UN0qtl026688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 31 May 2004 00:00:54 +0100 (BST) Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by bonnie.ses-astra.com (8.12.10/8.12.10) with ESMTP id i4UN0oam001449 for ; Mon, 31 May 2004 01:00:50 +0200 (CEST) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Mon, 31 May 2004 01:00:48 +0200 X-MIMETrack: Serialize by Router on marge/BTZ(Release 5.0.12 |February 13, 2003) at 31/05/2004 01:00:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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 X-ERG-MailScanner-To: ipdvb-subscribed-users@mavis.erg.abdn.ac.uk I will be out of the office starting 05/29/2004 and will not return until 06/07/2004. If required, I will respond to your message when I return to office. Best Regards, Joel Grotz PS: for urgent matters, please use joel.grotz@gmx.net PS: Use joel.grotz@gmx.net for urgent matters. -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.