From owner-ipdvb@erg.abdn.ac.uk Mon May 2 06:46:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00277 for ; Mon, 2 May 2005 06:46:05 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSYet-00086P-5x for ipdvb-archive@ietf.org; Mon, 02 May 2005 07:00:15 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j429npsj029339 for ; Mon, 2 May 2005 10:49:51 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j429npTk029338 for ipdvb-subscribed-users; Mon, 2 May 2005 10:49:51 +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 rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j429mh7s029283 for ; Mon, 2 May 2005 10:48:44 +0100 (BST) Received: from fenestro.dyndns.org ([24.6.155.213]) by comcast.net (rwcrmhc14) with ESMTP id <2005050209483701400fkhs9e>; Mon, 2 May 2005 09:48:37 +0000 Received: from [192.168.116.133] (localhost [127.0.0.1]) by fenestro.dyndns.org (8.12.9p2/8.12.9) with ESMTP id j429mT6U014204 for ; Mon, 2 May 2005 02:48:35 -0700 (PDT) (envelope-from margaret@thingmagic.com) Mime-Version: 1.0 Message-Id: Date: Mon, 2 May 2005 05:45:31 -0400 To: ipdvb From: Margaret Wasserman Subject: AD Review Comments on draft-ietf-ipdvb-ule-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi All, I have reviewed draft-ietf-ipdvb-ule-05.txt. I do have a few comments/questions on this document (see below), but they are not very fundamental issues. So, I will send this document to IETF Last Call, and we can resolve my issues along with any other IETF LC comments. Gorry and Bernhard, thanks for your excellent work on this document. Margaret --- 4. SNDU Format PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is illustrated below: < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Figure 1: SNDU Encapsulation All multi-byte values in ULE (including Length, Type, and Destination fields) are transmitted in network byte order (most significant byte first). The most significant bit of each byte is placed in the left-most position of the 8-bit field. Appendix A provides informative examples of usage. >> A destination field is mentioned in the text, but not shown in >> the diagram? It might make sense to how/where the destination >> may be included before mentioning it. 5.1 Test SNDU A Test SNDU (figure 10) is of a Mandatory Extension Header of Type 1. This header must be the final (or only) extension header specified in the header chain of a SNDU. [...] 5.2 Bridge Frame SNDU Encapsulation A bridged SNDU is a Mandatory Extension Header of Type 1. It must be the final (or only) extension header specified in the header chain of a SNDU. >> Is it intentional that the Test SNDU and the Bridge Frame SNDU >> headers cannot be used in the same SNDU? 3. Description of the Method [...] The ULE encapsulation is limited to TS private streams only. The header of each TS Packet carries a one bit Payload Unit Start Indicator (PUSI) field. A PUSI field with a value of 1 indicates the presence of at least one Payload Unit (SNDU) within the TS Packet payload. >> s/the presence of at least one/the start of at last one/ ?? >> >> If I understand this correctly, the PUSI field will be 0 if >> the TS does not include the start of an SNDU. From owner-ipdvb@erg.abdn.ac.uk Mon May 2 06:55:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00960 for ; Mon, 2 May 2005 06:55:42 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSYoB-0008Gd-M0 for ipdvb-archive@ietf.org; Mon, 02 May 2005 07:09:52 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42ANMg4000020 for ; Mon, 2 May 2005 11:23:22 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j42ANLHb000019 for ipdvb-subscribed-users; Mon, 2 May 2005 11:23:21 +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 notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42AMcK9029978 for ; Mon, 2 May 2005 11:22:39 +0100 (BST) In-Reply-To: <200504291556.j3TFuC1V026477@erg.abdn.ac.uk> To: ipdvb@erg.abdn.ac.uk Subject: RE: MPE Question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Tor Brekke Date: Mon, 2 May 2005 12:25:14 +0200 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.5.3FP1|December 15, 2004) at 2005-05-02 12:21:27, Serialize complete at 2005-05-02 12:21:27 Content-Type: multipart/alternative; boundary="=_alternative 0038FC7EC1256FF5_=" 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-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 This is a multipart message in MIME format. --=_alternative 0038FC7EC1256FF5_= Content-Type: text/plain; charset="US-ASCII" Hi William, I think you are somewhat confused in the use of terminology here. Section packing is the process of having more than one (partial) IP packet in each MPG frame. This has nothing to do with maximum section size. All IP encapsulators probably support MPE Section packing. MPE Does additionally support fragmentation of an IP packet into multiple DSM-CC sections (I guess this is what you are really talking about). This is only useful for IP packets which do not fit into the maximum section size of 4096 octets. This function, while defined by the MPE standard, is not (normally?) supported by the IP encapsulators. I have to admit that I have not checked details on ever vendor here, but have not seen this in any of the ones I have used myself. Regards Tor Brekke "William StanisLaus" Sent by: owner-ipdvb@erg.abdn.ac.uk 29.04.2005 17:56 Please respond to ipdvb@erg.abdn.ac.uk To cc Subject RE: MPE Question Hi Siva and Bernhard, DSM-CC which is a potential MPE of our present day DOES NOT support section packing for normal IP data transmissions. In DSM-CC we have section length of 12 bits, which can hold maximum of 4096 Bytes of payload data (IP in our discussion). In Normal scenario we don't even use this big, since section packing is not supported practically (theoretically YES), we use DVB router one interface as Ethernet and other as DVB, on Ethernet wire we get only 1500 bytes the max, though there is a room for section packing(theoretically) real time packet routing don't wait for another IP packet, just push each and every ip packet received with MPE (DSM-CC) and to MPEG2-TS (supports section packing, based on the timer - reason MPEG2-TS MUST be 188 bytes, instead of wasting bytes with stuffing we have section packing). When we are talking about stuffing bytes, that was perfect by Bernhard, we use for packet alignment, to be more specific, real time operating system like PSOS, requires it be WORD aligned ( Multiples of Four) before encryption algorithm to be applied for scrambling. -William. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Bernhard Collini-Nocker > Sent: Friday, April 29, 2005 6:55 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: MPE Question > > Dear Siva, > > you are right in that I had understood your question different. > > Generally Sections do allow for numbering that is, one can put a payload > (for example a DSM-CC object) into a number of Sections and with > section_number and last_section_number the reassebler knows what to do. > MPE uses this Section mechanism, so multiple Section operations should > be possible. Actually I have never tested whether MPE decapsulators do > support this in real, in principle they should (again the DVB > databroadacst standard does not say too much, if anything, about it) but > in DSM-CC Obejct carousels is a very usual mode of operation. > > Siva Veerepalli wrote: > > Thanks for the response Bernhard, but I am a bit > > confused about the answer. Please see my question > > below: > > > > --- Bernhard Collini-Nocker > > wrote: > > > >>Siva Veerepalli wrote: > [...] > > I understand that two MPE sections could probably > > start in the same TS packet (I guess that is what you > > mean by section packing). > > Yes. > > > My original questions was, what is the usual practice > > with regards to fragmenting an IP datagram over > > multiple MPE sections (irrespective of how these > > sections are transported in TS packets)? The DVB-H > > (data broadcast standard) allows for this, however, > > the IPDC interim specification requires that one > > datagram be encapsulated entirely in one mpe section > > i.e., no datagram fragmentation over multiple MPE > > sections. > > Now the confusion starts when one introduces the wording of "over > multiple MPE sections", because there is no such thing as a MPE section > fragmentation. > I will have to read the DVB-H standard again in order to find out what > it really says. I guess the only real issues the DVB-H wrt to IP is > addressing is the necessity of a IP datagram encapsulated in MPE is to > support time slicing (ie a burst transmission of the resulting TS > packets to allow for power saving) and MPE-FEC (adding redundant code to > allow for reconstruction). In that case I woould assume that it is very > reasonable (especially with legacy equipment) to avoid all potential > interpretations of MPE wrt multiple section operation and section packing. > > > thanks, > > Siva > [...] > > Yor are very welcome, > and I hope I got THE expected answer closer, > Bernhard --=_alternative 0038FC7EC1256FF5_= Content-Type: text/html; charset="US-ASCII"
Hi William,

I think you are somewhat confused in the use of terminology here. Section packing is the process of having more than one (partial) IP packet in each MPG frame. This has nothing to do with maximum section size. All IP encapsulators probably support MPE Section packing.

MPE Does additionally support fragmentation of an IP packet into multiple DSM-CC sections (I guess this is what you are really talking about). This is only useful for IP packets which do not fit into the maximum section size of 4096 octets. This function, while defined by the MPE standard, is not (normally?) supported by the IP encapsulators. I have to admit that I have not checked details on ever vendor here, but have not seen this in any of the ones I have used myself.

Regards
Tor Brekke




"William StanisLaus" <william@erg.abdn.ac.uk>
Sent by: owner-ipdvb@erg.abdn.ac.uk

29.04.2005 17:56
Please respond to
ipdvb@erg.abdn.ac.uk
To
<ipdvb@erg.abdn.ac.uk>
cc
Subject
RE: MPE Question





Hi Siva and Bernhard,
DSM-CC which is a potential MPE of our present day DOES NOT support section
packing for normal IP data transmissions. In DSM-CC we have section length
of 12 bits, which can hold maximum of 4096 Bytes of payload data (IP in our
discussion). In Normal scenario we don't even use this big, since section
packing is not supported practically (theoretically YES), we use DVB router
one interface as Ethernet and other as DVB, on Ethernet wire we get only
1500 bytes the max, though there is a room for section
packing(theoretically) real time packet routing don't wait for another IP
packet, just push each and every ip packet received with MPE (DSM-CC) and to
MPEG2-TS (supports section packing, based on the timer - reason MPEG2-TS
MUST be 188 bytes, instead of wasting bytes with stuffing we have section
packing).

When we are talking about stuffing bytes, that was perfect by Bernhard, we
use for packet alignment, to be more specific, real time operating system
like PSOS, requires it be WORD aligned ( Multiples of Four) before
encryption algorithm to be applied for scrambling.

-William.

> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
> Behalf Of Bernhard Collini-Nocker
> Sent: Friday, April 29, 2005 6:55 AM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: MPE Question
>
> Dear Siva,
>
> you are right in that I had understood your question different.
>
> Generally Sections do allow for numbering that is, one can put a payload
> (for example a DSM-CC object) into a number of Sections and with
> section_number and last_section_number the reassebler knows what to do.
> MPE uses this Section mechanism, so multiple Section operations should
> be possible. Actually I have never tested whether MPE decapsulators do
> support this in real, in principle they should (again the DVB
> databroadacst standard does not say too much, if anything, about it) but
> in DSM-CC Obejct carousels is a very usual mode of operation.
>
> Siva Veerepalli wrote:
> > Thanks for the response Bernhard, but I am a bit
> > confused about the answer. Please see my question
> > below:
> >
> > --- Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>
> > wrote:
> >
> >>Siva Veerepalli wrote:
> [...]
> > I understand that two MPE sections could probably
> > start in the same TS packet (I guess that is what you
> > mean by section packing).
>
> Yes.
>
> > My original questions was, what is the usual practice
> > with regards to fragmenting an IP datagram over
> > multiple MPE sections (irrespective of how these
> > sections are transported in TS packets)? The DVB-H
> > (data broadcast standard) allows for this, however,
> > the IPDC interim specification requires that one
> > datagram be encapsulated entirely in one mpe section
> > i.e., no datagram fragmentation over multiple MPE
> > sections.
>
> Now the confusion starts when one introduces the wording of "over
> multiple MPE sections", because there is no such thing as a MPE section
> fragmentation.
> I will have to read the DVB-H standard again in order to find out what
> it really says. I guess the only real issues the DVB-H wrt to IP is
> addressing is the necessity of a IP datagram encapsulated in MPE is to
> support time slicing (ie a burst transmission of the resulting TS
> packets to allow for power saving) and MPE-FEC (adding redundant code to
> allow for reconstruction). In that case I woould assume that it is very
> reasonable (especially with legacy equipment) to avoid all potential
> interpretations of MPE wrt multiple section operation and section packing.
>
> > thanks,
> > Siva
> [...]
>
> Yor are very welcome,
> and I hope I got THE expected answer closer,
> Bernhard
--=_alternative 0038FC7EC1256FF5_=-- From owner-ipdvb@erg.abdn.ac.uk Mon May 2 07:47:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04970 for ; Mon, 2 May 2005 07:47:19 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSZc7-00017N-MI for ipdvb-archive@ietf.org; Mon, 02 May 2005 08:01:28 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42BKBu3001430 for ; Mon, 2 May 2005 12:20:11 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j42BKBpu001429 for ipdvb-subscribed-users; Mon, 2 May 2005 12:20:11 +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 mail.future.futsoft.com ([202.56.251.200]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42BJcS9001394 for ; Mon, 2 May 2005 12:19:43 +0100 (BST) Received: from kailash.future.futsoft.com (unverified [10.203.112.3]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 2 May 2005 16:49:36 +0530 Received: from anurags ([10.203.118.55]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id j42BHe7L024763 for ; Mon, 2 May 2005 16:47:45 +0530 From: "Anurag Sharma" To: Subject: RE: MPE Question Date: Mon, 2 May 2005 16:50:42 +0530 Message-ID: <001401c54f08$fae87c40$3776cb0a@future.futsoft.com> 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) Importance: Normal In-Reply-To: <200504291556.j3TFuC1V026477@erg.abdn.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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-Spam-Score: 0.2 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Hi William, DSM-CC doesn't carry any information about section packing. The Payload Unit Start Indicator (PUSI) field in the MPEG header is used to indicate the beginning of new DSM-CC section. But that doesnt really specify if there is more than one section present in the payload. PSUI field in combination with other available information (DSM-CC headers) can be used to check the presence of multiple sections in the payload. Fragmentation of IP packets is supported, in case the size of the packet exceeds a DSM-CC section size (4096 bytes) In such cases section_number, last_section_number fields in the DSM-CC header can be used for reassembly of the IP packets. regards, Anurag Sharma -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On Behalf Of William StanisLaus Sent: Friday, 29 April 2005 9:26 PM To: ipdvb@erg.abdn.ac.uk Subject: RE: MPE Question Hi Siva and Bernhard, DSM-CC which is a potential MPE of our present day DOES NOT support section packing for normal IP data transmissions. In DSM-CC we have section length of 12 bits, which can hold maximum of 4096 Bytes of payload data (IP in our discussion). In Normal scenario we don't even use this big, since section packing is not supported practically (theoretically YES), we use DVB router one interface as Ethernet and other as DVB, on Ethernet wire we get only 1500 bytes the max, though there is a room for section packing(theoretically) real time packet routing don't wait for another IP packet, just push each and every ip packet received with MPE (DSM-CC) and to MPEG2-TS (supports section packing, based on the timer - reason MPEG2-TS MUST be 188 bytes, instead of wasting bytes with stuffing we have section packing). When we are talking about stuffing bytes, that was perfect by Bernhard, we use for packet alignment, to be more specific, real time operating system like PSOS, requires it be WORD aligned ( Multiples of Four) before encryption algorithm to be applied for scrambling. -William. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Bernhard Collini-Nocker > Sent: Friday, April 29, 2005 6:55 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: MPE Question > > Dear Siva, > > you are right in that I had understood your question different. > > Generally Sections do allow for numbering that is, one can put a payload > (for example a DSM-CC object) into a number of Sections and with > section_number and last_section_number the reassebler knows what to do. > MPE uses this Section mechanism, so multiple Section operations should > be possible. Actually I have never tested whether MPE decapsulators do > support this in real, in principle they should (again the DVB > databroadacst standard does not say too much, if anything, about it) but > in DSM-CC Obejct carousels is a very usual mode of operation. > > Siva Veerepalli wrote: > > Thanks for the response Bernhard, but I am a bit > > confused about the answer. Please see my question > > below: > > > > --- Bernhard Collini-Nocker > > wrote: > > > >>Siva Veerepalli wrote: > [...] > > I understand that two MPE sections could probably > > start in the same TS packet (I guess that is what you > > mean by section packing). > > Yes. > > > My original questions was, what is the usual practice > > with regards to fragmenting an IP datagram over > > multiple MPE sections (irrespective of how these > > sections are transported in TS packets)? The DVB-H > > (data broadcast standard) allows for this, however, > > the IPDC interim specification requires that one > > datagram be encapsulated entirely in one mpe section > > i.e., no datagram fragmentation over multiple MPE > > sections. > > Now the confusion starts when one introduces the wording of "over > multiple MPE sections", because there is no such thing as a MPE section > fragmentation. > I will have to read the DVB-H standard again in order to find out what > it really says. I guess the only real issues the DVB-H wrt to IP is > addressing is the necessity of a IP datagram encapsulated in MPE is to > support time slicing (ie a burst transmission of the resulting TS > packets to allow for power saving) and MPE-FEC (adding redundant code to > allow for reconstruction). In that case I woould assume that it is very > reasonable (especially with legacy equipment) to avoid all potential > interpretations of MPE wrt multiple section operation and section packing. > > > thanks, > > Siva > [...] > > Yor are very welcome, > and I hope I got THE expected answer closer, > Bernhard *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ipdvb@erg.abdn.ac.uk Mon May 2 08:34:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10357 for ; Mon, 2 May 2005 08:34:45 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSaM1-0002WP-J8 for ipdvb-archive@ietf.org; Mon, 02 May 2005 08:48:54 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42C3G5b002590 for ; Mon, 2 May 2005 13:03:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j42C3GkX002589 for ipdvb-subscribed-users; Mon, 2 May 2005 13:03:16 +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 wills (wills.erg.abdn.ac.uk [139.133.204.225]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42C27Yp002540 for ; Mon, 2 May 2005 13:02:07 +0100 (BST) Message-Id: <200505021202.j42C27Yp002540@erg.abdn.ac.uk> From: "William StanisLaus" To: Subject: RE: MPE Question Date: Mon, 2 May 2005 13:01:59 +0100 Organization: University of Aberdeen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C54F17.23969380" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVPAPdyXKrJ5tHhTVCsnONflNhCDAACDTiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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-Spam-Score: 0.3 (/) X-Scan-Signature: 5a985ed7c9101086bea2cd7287e9f83a This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C54F17.23969380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Tor Brekke, Sorry if I have confused, may be I should make it more detailed :-) In DSM-CC (MPE) we have section-length to specify the size of the payload it carries, this can be maximum of 4096 bytes. Hence any IP packet as a potential payload for DSM-CC can be maximum of 4096 bytes, this length normally discovered using L2 MTU size and IP packets gets fragmented if the packet is greater than 4096 bytes. But theoretically, DSM-CC supports multiple segments/fragments by itself (section number and last section number) which gives room for bigger ip packet even greater than 4096 bytes. Does any of the vendor uses this functionally for ip data transmission is a question !!!. I myself never come across such support for ip data transmission. Next, if a single DSM-CC (MPE) can carry more than one IP packet??, I don't understand if it is possible, since we don't have payload start indicator and pointer to perform IP datagram section packing in single DSM-CC (MPE) payload, which can be decapsulated at the other end. Next, MPEG2-TS, for any MPEG2-TS packet it MUST be of length 188 bytes. Any MPE (DSM-CC) packet less than 183 bytes (considering after MPEG2-TS header and payload pointer) needs to be stuffed/padding, instead of doing so we can do section packing, by sending next MPE packet into the same MPEG2-Transport Stream. Hope now it is clear Update me if I'm wrong :-) -William. _____ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Tor Brekke Sent: Monday, May 02, 2005 11:25 AM To: ipdvb@erg.abdn.ac.uk Subject: RE: MPE Question Hi William, I think you are somewhat confused in the use of terminology here. Section packing is the process of having more than one (partial) IP packet in each MPG frame. This has nothing to do with maximum section size. All IP encapsulators probably support MPE Section packing. MPE Does additionally support fragmentation of an IP packet into multiple DSM-CC sections (I guess this is what you are really talking about). This is only useful for IP packets which do not fit into the maximum section size of 4096 octets. This function, while defined by the MPE standard, is not (normally?) supported by the IP encapsulators. I have to admit that I have not checked details on ever vendor here, but have not seen this in any of the ones I have used myself. Regards Tor Brekke "William StanisLaus" Sent by: owner-ipdvb@erg.abdn.ac.uk 29.04.2005 17:56 Please respond to ipdvb@erg.abdn.ac.uk To cc Subject RE: MPE Question Hi Siva and Bernhard, DSM-CC which is a potential MPE of our present day DOES NOT support section packing for normal IP data transmissions. In DSM-CC we have section length of 12 bits, which can hold maximum of 4096 Bytes of payload data (IP in our discussion). In Normal scenario we don't even use this big, since section packing is not supported practically (theoretically YES), we use DVB router one interface as Ethernet and other as DVB, on Ethernet wire we get only 1500 bytes the max, though there is a room for section packing(theoretically) real time packet routing don't wait for another IP packet, just push each and every ip packet received with MPE (DSM-CC) and to MPEG2-TS (supports section packing, based on the timer - reason MPEG2-TS MUST be 188 bytes, instead of wasting bytes with stuffing we have section packing). When we are talking about stuffing bytes, that was perfect by Bernhard, we use for packet alignment, to be more specific, real time operating system like PSOS, requires it be WORD aligned ( Multiples of Four) before encryption algorithm to be applied for scrambling. -William. > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Bernhard Collini-Nocker > Sent: Friday, April 29, 2005 6:55 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: MPE Question > > Dear Siva, > > you are right in that I had understood your question different. > > Generally Sections do allow for numbering that is, one can put a payload > (for example a DSM-CC object) into a number of Sections and with > section_number and last_section_number the reassebler knows what to do. > MPE uses this Section mechanism, so multiple Section operations should > be possible. Actually I have never tested whether MPE decapsulators do > support this in real, in principle they should (again the DVB > databroadacst standard does not say too much, if anything, about it) but > in DSM-CC Obejct carousels is a very usual mode of operation. > > Siva Veerepalli wrote: > > Thanks for the response Bernhard, but I am a bit > > confused about the answer. Please see my question > > below: > > > > --- Bernhard Collini-Nocker > > wrote: > > > >>Siva Veerepalli wrote: > [...] > > I understand that two MPE sections could probably > > start in the same TS packet (I guess that is what you > > mean by section packing). > > Yes. > > > My original questions was, what is the usual practice > > with regards to fragmenting an IP datagram over > > multiple MPE sections (irrespective of how these > > sections are transported in TS packets)? The DVB-H > > (data broadcast standard) allows for this, however, > > the IPDC interim specification requires that one > > datagram be encapsulated entirely in one mpe section > > i.e., no datagram fragmentation over multiple MPE > > sections. > > Now the confusion starts when one introduces the wording of "over > multiple MPE sections", because there is no such thing as a MPE section > fragmentation. > I will have to read the DVB-H standard again in order to find out what > it really says. I guess the only real issues the DVB-H wrt to IP is > addressing is the necessity of a IP datagram encapsulated in MPE is to > support time slicing (ie a burst transmission of the resulting TS > packets to allow for power saving) and MPE-FEC (adding redundant code to > allow for reconstruction). In that case I woould assume that it is very > reasonable (especially with legacy equipment) to avoid all potential > interpretations of MPE wrt multiple section operation and section packing. > > > thanks, > > Siva > [...] > > Yor are very welcome, > and I hope I got THE expected answer closer, > Bernhard ------=_NextPart_000_0012_01C54F17.23969380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Tor = Brekke,

 

Sorry if I have confused, may be I = should make it more detailed J

 

In DSM-CC (MPE) we have = section-length to specify the size of the payload it carries, this can be maximum of 4096 = bytes. Hence any IP packet as a potential payload for DSM-CC can be maximum of 4096 = bytes, this length normally discovered using L2 MTU size and IP packets gets fragmented if the packet is greater than 4096 bytes. But theoretically, = DSM-CC supports multiple segments/fragments by itself (section number and last = section number) which gives room for bigger ip packet even greater than 4096 = bytes. Does any of the vendor uses this functionally for ip data transmission = is a question !!!. I myself never come across such support for ip data = transmission. Next, if a single DSM-CC (MPE) can carry more than one IP packet??, I = don’t understand if it is possible, since we don’t have payload start = indicator and pointer to perform IP datagram section packing in single DSM-CC = (MPE) payload, which can be decapsulated at the other = end.

 

Next, MPEG2-TS, for any MPEG2-TS = packet it MUST be of length 188 bytes. Any MPE (DSM-CC) packet less than 183 bytes = (considering after MPEG2-TS header and payload pointer) needs to be stuffed/padding, = instead of doing so we can do section packing, by sending next MPE packet into = the same MPEG2-Transport = Stream.

 

Hope now it is = clear

 

Update me if I’m wrong = J

 

-William.

 

 

 

From: = owner-ipdvb@erg.abdn.ac.uk = [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Tor Brekke
Sent: Monday, May 02, = 2005 11:25 AM
To: ipdvb@erg.abdn.ac.uk
Subject: RE: MPE = Question

 


Hi William,

I think you are somewhat confused in the use of terminology here. Section = packing is the process of having more than one (partial) IP packet in each MPG = frame. This has nothing to do with maximum section size. All IP encapsulators = probably support MPE Section packing.

MPE Does additionally support fragmentation of an IP packet into multiple = DSM-CC sections (I guess this is what you are really talking about). This is = only useful for IP packets which do not fit into the maximum section size of = 4096 octets. This function, while defined by the MPE standard, is not = (normally?) supported by the IP encapsulators. I have to admit that I have not = checked details on ever vendor here, but have not seen this in any of the ones I = have used myself.

Regards
Tor Brekke



"William = StanisLaus" <william@erg.abdn.ac.uk>
Sent by: owner-ipdvb@erg.abdn.ac.uk

29.04.2005 17:56

Please respond to
ipdvb@erg.abdn.ac.uk

To

<ipdvb@erg.abdn.ac.uk>

cc

 

Subject

RE: MPE = Question

 

 

 




Hi Siva and Bernhard,
DSM-CC which is a potential MPE of our = present day DOES NOT support section
packing for normal IP data transmissions. = In DSM-CC we have section length
of 12 bits, which can hold maximum of = 4096 Bytes of payload data (IP in our
discussion). In Normal scenario we don't even use this big, since section
packing is not supported practically (theoretically YES), we use DVB router
one interface as Ethernet and other as = DVB, on Ethernet wire we get only
1500 bytes the max, though there is a = room for section
packing(theoretically) real time packet = routing don't wait for another IP
packet, just push each and every ip = packet received with MPE (DSM-CC) and to
MPEG2-TS (supports section packing, based = on the timer - reason MPEG2-TS
MUST be 188 bytes, instead of wasting = bytes with stuffing we have section
packing).

When we are talking about stuffing bytes, = that was perfect by Bernhard, we
use for packet alignment, to be more = specific, real time operating system
like PSOS, requires it be WORD aligned ( = Multiples of Four) before
encryption algorithm to be applied for = scrambling.

-William.

> -----Original = Message-----
> From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
> Behalf Of Bernhard = Collini-Nocker
> Sent: Friday, April 29, 2005 6:55 = AM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: MPE = Question
>
> Dear Siva,
>
> you are right in that I had = understood your question different.
>
> Generally Sections do allow for = numbering that is, one can put a payload
> (for example a DSM-CC object) into a = number of Sections and with
> section_number and = last_section_number the reassebler knows what to do.
> MPE uses this Section mechanism, so = multiple Section operations should
> be possible. Actually I have never = tested whether MPE decapsulators do
> support this in real, in principle = they should (again the DVB
> databroadacst standard does not say = too much, if anything, about it) but
> in DSM-CC Obejct carousels is a very = usual mode of operation.
>
> Siva Veerepalli = wrote:
> > Thanks for the response = Bernhard, but I am a bit
> > confused about the answer. = Please see my question
> > below:
> >
> > --- Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>
> > wrote:
> >
> >>Siva Veerepalli = wrote:
> [...]
> > I understand that two MPE = sections could probably
> > start in the same TS packet (I guess that is what you
> > mean by section = packing).
>
> Yes.
>
> > My original questions was, what = is the usual practice
> > with regards to fragmenting an = IP datagram over
> > multiple MPE sections = (irrespective of how these
> > sections are transported in TS = packets)? The DVB-H
> > (data broadcast standard) = allows for this, however,
> > the IPDC interim specification = requires that one
> > datagram be encapsulated = entirely in one mpe section
> > i.e., no datagram fragmentation = over multiple MPE
> > sections.
>
> Now the confusion starts when one = introduces the wording of "over
> multiple MPE sections", because = there is no such thing as a MPE section
> fragmentation.
> I will have to read the DVB-H = standard again in order to find out what
> it really says. I guess the only = real issues the DVB-H wrt to IP is
> addressing is the necessity of a IP = datagram encapsulated in MPE is to
> support time slicing (ie a burst = transmission of the resulting TS
> packets to allow for power saving) = and MPE-FEC (adding redundant code to
> allow for reconstruction). In that = case I woould assume that it is very
> reasonable (especially with legacy = equipment) to avoid all potential
> interpretations of MPE wrt multiple = section operation and section packing.
>
> > thanks,
> > Siva
> [...]
>
> Yor are very = welcome,
> and I hope I got THE expected answer = closer,
> Bernhard


------=_NextPart_000_0012_01C54F17.23969380-- From owner-ipdvb@erg.abdn.ac.uk Mon May 2 08:46:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12534 for ; Mon, 2 May 2005 08:46:30 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSaXP-0002qi-RZ for ipdvb-archive@ietf.org; Mon, 02 May 2005 09:00:40 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42COQ9e003075 for ; Mon, 2 May 2005 13:24:26 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j42COQbw003074 for ipdvb-subscribed-users; Mon, 2 May 2005 13:24:26 +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 notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42CLCT2002954 for ; Mon, 2 May 2005 13:21:12 +0100 (BST) In-Reply-To: <200505021202.j42C27Yp002540@erg.abdn.ac.uk> To: ipdvb@erg.abdn.ac.uk Subject: RE: MPE Question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Tor Brekke Date: Mon, 2 May 2005 14:23:52 +0200 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.5.3FP1|December 15, 2004) at 2005-05-02 14:20:01, Serialize complete at 2005-05-02 14:20:01 Content-Type: multipart/alternative; boundary="=_alternative 0043D92CC1256FF5_=" 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-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 This is a multipart message in MIME format. --=_alternative 0043D92CC1256FF5_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBXaWxsaWFtLCANCg0KSSB3YXMgbWFpbmx5IG9iamVjdGluZyB0byB5b3VyIGluaXRpYWwg Y29tbWVudCB0aGF0IG5vIHZlbmRvcnMgc3VwcG9ydCBNUEUgDQpTZWN0aW9uIHBhY2tpbmcsIHdo aWxlIGluIGZhY3QgYWxsIEkgaGF2ZSBjb21lIGFjcm9zcyBkbyBzdXBwb3J0IGl0LiBOb3cgDQp3 ZSBhcmUgc2F5aW5nIHRoZSBzYW1lIHRoaW5nLCBuYW1lbHkgdGhhdCB0aGV5IGRvIG5vdCBzdXBw b3J0IE1QRSBJUCANCmZyYWdtZW50YXRpb24uIEhlbmNlIHdlIGNhbiBwcm9iYWJseSBzdG9wIHRo aXMgZGlzY3Vzc2lvbiBub3cuIA0KDQotLVRvcg0KDQoNCg0KDQoNCiJXaWxsaWFtIFN0YW5pc0xh dXMiIDx3aWxsaWFtQGVyZy5hYmRuLmFjLnVrPiANClNlbnQgYnk6IG93bmVyLWlwZHZiQGVyZy5h YmRuLmFjLnVrDQowMi4wNS4yMDA1IDE0OjAxDQpQbGVhc2UgcmVzcG9uZCB0bw0KaXBkdmJAZXJn LmFiZG4uYWMudWsNCg0KDQpUbw0KPGlwZHZiQGVyZy5hYmRuLmFjLnVrPg0KY2MNCg0KU3ViamVj dA0KUkU6IE1QRSBRdWVzdGlvbg0KDQoNCg0KDQoNCg0KRGVhciBUb3IgQnJla2tlLA0KIA0KU29y cnkgaWYgSSBoYXZlIGNvbmZ1c2VkLCBtYXkgYmUgSSBzaG91bGQgbWFrZSBpdCBtb3JlIGRldGFp bGVkIEoNCiANCkluIERTTS1DQyAoTVBFKSB3ZSBoYXZlIHNlY3Rpb24tbGVuZ3RoIHRvIHNwZWNp ZnkgdGhlIHNpemUgb2YgdGhlIHBheWxvYWQgDQppdCBjYXJyaWVzLCB0aGlzIGNhbiBiZSBtYXhp bXVtIG9mIDQwOTYgYnl0ZXMuIEhlbmNlIGFueSBJUCBwYWNrZXQgYXMgYSANCnBvdGVudGlhbCBw YXlsb2FkIGZvciBEU00tQ0MgY2FuIGJlIG1heGltdW0gb2YgNDA5NiBieXRlcywgdGhpcyBsZW5n dGggDQpub3JtYWxseSBkaXNjb3ZlcmVkIHVzaW5nIEwyIE1UVSBzaXplIGFuZCBJUCBwYWNrZXRz IGdldHMgZnJhZ21lbnRlZCBpZiANCnRoZSBwYWNrZXQgaXMgZ3JlYXRlciB0aGFuIDQwOTYgYnl0 ZXMuIEJ1dCB0aGVvcmV0aWNhbGx5LCBEU00tQ0Mgc3VwcG9ydHMgDQptdWx0aXBsZSBzZWdtZW50 cy9mcmFnbWVudHMgYnkgaXRzZWxmIChzZWN0aW9uIG51bWJlciBhbmQgbGFzdCBzZWN0aW9uIA0K bnVtYmVyKSB3aGljaCBnaXZlcyByb29tIGZvciBiaWdnZXIgaXAgcGFja2V0IGV2ZW4gZ3JlYXRl ciB0aGFuIDQwOTYgDQpieXRlcy4gRG9lcyBhbnkgb2YgdGhlIHZlbmRvciB1c2VzIHRoaXMgZnVu Y3Rpb25hbGx5IGZvciBpcCBkYXRhIA0KdHJhbnNtaXNzaW9uIGlzIGEgcXVlc3Rpb24gISEhLiBJ IG15c2VsZiBuZXZlciBjb21lIGFjcm9zcyBzdWNoIHN1cHBvcnQgDQpmb3IgaXAgZGF0YSB0cmFu c21pc3Npb24uIE5leHQsIGlmIGEgc2luZ2xlIERTTS1DQyAoTVBFKSBjYW4gY2FycnkgbW9yZSAN CnRoYW4gb25lIElQIHBhY2tldD8/LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCBpZiBpdCBpcyBwb3Nz aWJsZSwgc2luY2Ugd2UgZG9u4oCZdCANCmhhdmUgcGF5bG9hZCBzdGFydCBpbmRpY2F0b3IgYW5k IHBvaW50ZXIgdG8gcGVyZm9ybSBJUCBkYXRhZ3JhbSBzZWN0aW9uIA0KcGFja2luZyBpbiBzaW5n bGUgRFNNLUNDIChNUEUpIHBheWxvYWQsIHdoaWNoIGNhbiBiZSBkZWNhcHN1bGF0ZWQgYXQgdGhl IA0Kb3RoZXIgZW5kLg0KIA0KTmV4dCwgTVBFRzItVFMsIGZvciBhbnkgTVBFRzItVFMgcGFja2V0 IGl0IE1VU1QgYmUgb2YgbGVuZ3RoIDE4OCBieXRlcy4gDQpBbnkgTVBFIChEU00tQ0MpIHBhY2tl dCBsZXNzIHRoYW4gMTgzIGJ5dGVzIChjb25zaWRlcmluZyBhZnRlciBNUEVHMi1UUyANCmhlYWRl ciBhbmQgcGF5bG9hZCBwb2ludGVyKSBuZWVkcyB0byBiZSBzdHVmZmVkL3BhZGRpbmcsIGluc3Rl YWQgb2YgZG9pbmcgDQpzbyB3ZSBjYW4gZG8gc2VjdGlvbiBwYWNraW5nLCBieSBzZW5kaW5nIG5l eHQgTVBFIHBhY2tldCBpbnRvIHRoZSBzYW1lIA0KTVBFRzItVHJhbnNwb3J0IFN0cmVhbS4NCiAN CkhvcGUgbm93IGl0IGlzIGNsZWFyDQogDQpVcGRhdGUgbWUgaWYgSeKAmW0gd3JvbmcgSg0KIA0K LVdpbGxpYW0uDQogDQogDQogDQoNCkZyb206IG93bmVyLWlwZHZiQGVyZy5hYmRuLmFjLnVrIFtt YWlsdG86b3duZXItaXBkdmJAZXJnLmFiZG4uYWMudWtdIE9uIA0KQmVoYWxmIE9mIFRvciBCcmVr a2UNClNlbnQ6IE1vbmRheSwgTWF5IDAyLCAyMDA1IDExOjI1IEFNDQpUbzogaXBkdmJAZXJnLmFi ZG4uYWMudWsNClN1YmplY3Q6IFJFOiBNUEUgUXVlc3Rpb24NCiANCg0KSGkgV2lsbGlhbSwgDQoN CkkgdGhpbmsgeW91IGFyZSBzb21ld2hhdCBjb25mdXNlZCBpbiB0aGUgdXNlIG9mIHRlcm1pbm9s b2d5IGhlcmUuIFNlY3Rpb24gDQpwYWNraW5nIGlzIHRoZSBwcm9jZXNzIG9mIGhhdmluZyBtb3Jl IHRoYW4gb25lIChwYXJ0aWFsKSBJUCBwYWNrZXQgaW4gZWFjaCANCk1QRyBmcmFtZS4gVGhpcyBo YXMgbm90aGluZyB0byBkbyB3aXRoIG1heGltdW0gc2VjdGlvbiBzaXplLiBBbGwgSVAgDQplbmNh cHN1bGF0b3JzIHByb2JhYmx5IHN1cHBvcnQgTVBFIFNlY3Rpb24gcGFja2luZy4gDQoNCk1QRSBE b2VzIGFkZGl0aW9uYWxseSBzdXBwb3J0IGZyYWdtZW50YXRpb24gb2YgYW4gSVAgcGFja2V0IGlu dG8gbXVsdGlwbGUgDQpEU00tQ0Mgc2VjdGlvbnMgKEkgZ3Vlc3MgdGhpcyBpcyB3aGF0IHlvdSBh cmUgcmVhbGx5IHRhbGtpbmcgYWJvdXQpLiBUaGlzIA0KaXMgb25seSB1c2VmdWwgZm9yIElQIHBh Y2tldHMgd2hpY2ggZG8gbm90IGZpdCBpbnRvIHRoZSBtYXhpbXVtIHNlY3Rpb24gDQpzaXplIG9m IDQwOTYgb2N0ZXRzLiBUaGlzIGZ1bmN0aW9uLCB3aGlsZSBkZWZpbmVkIGJ5IHRoZSBNUEUgc3Rh bmRhcmQsIGlzIA0Kbm90IChub3JtYWxseT8pIHN1cHBvcnRlZCBieSB0aGUgSVAgZW5jYXBzdWxh dG9ycy4gSSBoYXZlIHRvIGFkbWl0IHRoYXQgSSANCmhhdmUgbm90IGNoZWNrZWQgZGV0YWlscyBv biBldmVyIHZlbmRvciBoZXJlLCBidXQgaGF2ZSBub3Qgc2VlbiB0aGlzIGluIA0KYW55IG9mIHRo ZSBvbmVzIEkgaGF2ZSB1c2VkIG15c2VsZi4gDQoNClJlZ2FyZHMgDQpUb3IgQnJla2tlIA0KDQoN Cg0KDQoiV2lsbGlhbSBTdGFuaXNMYXVzIiA8d2lsbGlhbUBlcmcuYWJkbi5hYy51az4gDQpTZW50 IGJ5OiBvd25lci1pcGR2YkBlcmcuYWJkbi5hYy51ayANCjI5LjA0LjIwMDUgMTc6NTYgDQoNCg0K UGxlYXNlIHJlc3BvbmQgdG8NCmlwZHZiQGVyZy5hYmRuLmFjLnVrDQoNCg0KDQpUbw0KPGlwZHZi QGVyZy5hYmRuLmFjLnVrPiANCmNjDQogDQpTdWJqZWN0DQpSRTogTVBFIFF1ZXN0aW9uDQogDQoN Cg0KIA0KIA0KDQoNCg0KDQpIaSBTaXZhIGFuZCBCZXJuaGFyZCwNCkRTTS1DQyB3aGljaCBpcyBh IHBvdGVudGlhbCBNUEUgb2Ygb3VyIHByZXNlbnQgZGF5IERPRVMgTk9UIHN1cHBvcnQgDQpzZWN0 aW9uDQpwYWNraW5nIGZvciBub3JtYWwgSVAgZGF0YSB0cmFuc21pc3Npb25zLiBJbiBEU00tQ0Mg d2UgaGF2ZSBzZWN0aW9uIGxlbmd0aA0Kb2YgMTIgYml0cywgd2hpY2ggY2FuIGhvbGQgbWF4aW11 bSBvZiA0MDk2IEJ5dGVzIG9mIHBheWxvYWQgZGF0YSAoSVAgaW4gDQpvdXINCmRpc2N1c3Npb24p LiBJbiBOb3JtYWwgc2NlbmFyaW8gd2UgZG9uJ3QgZXZlbiB1c2UgdGhpcyBiaWcsIHNpbmNlIHNl Y3Rpb24NCnBhY2tpbmcgaXMgbm90IHN1cHBvcnRlZCBwcmFjdGljYWxseSAodGhlb3JldGljYWxs eSBZRVMpLCB3ZSB1c2UgRFZCIA0Kcm91dGVyDQpvbmUgaW50ZXJmYWNlIGFzIEV0aGVybmV0IGFu ZCBvdGhlciBhcyBEVkIsIG9uIEV0aGVybmV0IHdpcmUgd2UgZ2V0IG9ubHkNCjE1MDAgYnl0ZXMg dGhlIG1heCwgdGhvdWdoIHRoZXJlIGlzIGEgcm9vbSBmb3Igc2VjdGlvbg0KcGFja2luZyh0aGVv cmV0aWNhbGx5KSByZWFsIHRpbWUgcGFja2V0IHJvdXRpbmcgZG9uJ3Qgd2FpdCBmb3IgYW5vdGhl ciBJUA0KcGFja2V0LCBqdXN0IHB1c2ggZWFjaCBhbmQgZXZlcnkgaXAgcGFja2V0IHJlY2VpdmVk IHdpdGggTVBFIChEU00tQ0MpIGFuZCANCnRvDQpNUEVHMi1UUyAoc3VwcG9ydHMgc2VjdGlvbiBw YWNraW5nLCBiYXNlZCBvbiB0aGUgdGltZXIgLSByZWFzb24gTVBFRzItVFMNCk1VU1QgYmUgMTg4 IGJ5dGVzLCBpbnN0ZWFkIG9mIHdhc3RpbmcgYnl0ZXMgd2l0aCBzdHVmZmluZyB3ZSBoYXZlIHNl Y3Rpb24NCnBhY2tpbmcpLg0KDQpXaGVuIHdlIGFyZSB0YWxraW5nIGFib3V0IHN0dWZmaW5nIGJ5 dGVzLCB0aGF0IHdhcyBwZXJmZWN0IGJ5IEJlcm5oYXJkLCB3ZQ0KdXNlIGZvciBwYWNrZXQgYWxp Z25tZW50LCB0byBiZSBtb3JlIHNwZWNpZmljLCByZWFsIHRpbWUgb3BlcmF0aW5nIHN5c3RlbQ0K bGlrZSBQU09TLCByZXF1aXJlcyBpdCBiZSBXT1JEIGFsaWduZWQgKCBNdWx0aXBsZXMgb2YgRm91 cikgYmVmb3JlDQplbmNyeXB0aW9uIGFsZ29yaXRobSB0byBiZSBhcHBsaWVkIGZvciBzY3JhbWJs aW5nLg0KDQotV2lsbGlhbS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBvd25lci1pcGR2YkBlcmcuYWJkbi5hYy51ayBbbWFpbHRvOm93bmVyLWlwZHZiQGVyZy5hYmRu LmFjLnVrXSBPbg0KPiBCZWhhbGYgT2YgQmVybmhhcmQgQ29sbGluaS1Ob2NrZXINCj4gU2VudDog RnJpZGF5LCBBcHJpbCAyOSwgMjAwNSA2OjU1IEFNDQo+IFRvOiBpcGR2YkBlcmcuYWJkbi5hYy51 aw0KPiBTdWJqZWN0OiBSZTogTVBFIFF1ZXN0aW9uDQo+IA0KPiBEZWFyIFNpdmEsDQo+IA0KPiB5 b3UgYXJlIHJpZ2h0IGluIHRoYXQgSSBoYWQgdW5kZXJzdG9vZCB5b3VyIHF1ZXN0aW9uIGRpZmZl cmVudC4NCj4gDQo+IEdlbmVyYWxseSBTZWN0aW9ucyBkbyBhbGxvdyBmb3IgbnVtYmVyaW5nIHRo YXQgaXMsIG9uZSBjYW4gcHV0IGEgcGF5bG9hZA0KPiAoZm9yIGV4YW1wbGUgYSBEU00tQ0Mgb2Jq ZWN0KSBpbnRvIGEgbnVtYmVyIG9mIFNlY3Rpb25zIGFuZCB3aXRoDQo+IHNlY3Rpb25fbnVtYmVy IGFuZCBsYXN0X3NlY3Rpb25fbnVtYmVyIHRoZSByZWFzc2VibGVyIGtub3dzIHdoYXQgdG8gZG8u DQo+IE1QRSB1c2VzIHRoaXMgU2VjdGlvbiBtZWNoYW5pc20sIHNvIG11bHRpcGxlIFNlY3Rpb24g b3BlcmF0aW9ucyBzaG91bGQNCj4gYmUgcG9zc2libGUuIEFjdHVhbGx5IEkgaGF2ZSBuZXZlciB0 ZXN0ZWQgd2hldGhlciBNUEUgZGVjYXBzdWxhdG9ycyBkbw0KPiBzdXBwb3J0IHRoaXMgaW4gcmVh bCwgaW4gcHJpbmNpcGxlIHRoZXkgc2hvdWxkIChhZ2FpbiB0aGUgRFZCDQo+IGRhdGFicm9hZGFj c3Qgc3RhbmRhcmQgZG9lcyBub3Qgc2F5IHRvbyBtdWNoLCBpZiBhbnl0aGluZywgYWJvdXQgaXQp IGJ1dA0KPiBpbiBEU00tQ0MgT2JlamN0IGNhcm91c2VscyBpcyBhIHZlcnkgdXN1YWwgbW9kZSBv ZiBvcGVyYXRpb24uDQo+IA0KPiBTaXZhIFZlZXJlcGFsbGkgd3JvdGU6DQo+ID4gVGhhbmtzIGZv ciB0aGUgcmVzcG9uc2UgQmVybmhhcmQsIGJ1dCBJIGFtIGEgYml0DQo+ID4gY29uZnVzZWQgYWJv dXQgdGhlIGFuc3dlci4gUGxlYXNlIHNlZSBteSBxdWVzdGlvbg0KPiA+IGJlbG93Og0KPiA+DQo+ ID4gLS0tIEJlcm5oYXJkIENvbGxpbmktTm9ja2VyIDxibm9ja2VyQGNvc3kuc2JnLmFjLmF0Pg0K PiA+IHdyb3RlOg0KPiA+DQo+ID4+U2l2YSBWZWVyZXBhbGxpIHdyb3RlOg0KPiBbLi4uXQ0KPiA+ IEkgdW5kZXJzdGFuZCB0aGF0IHR3byBNUEUgc2VjdGlvbnMgY291bGQgcHJvYmFibHkNCj4gPiBz dGFydCBpbiB0aGUgc2FtZSBUUyBwYWNrZXQgKEkgZ3Vlc3MgdGhhdCBpcyB3aGF0IHlvdQ0KPiA+ IG1lYW4gYnkgc2VjdGlvbiBwYWNraW5nKS4NCj4gDQo+IFllcy4NCj4gDQo+ID4gTXkgb3JpZ2lu YWwgcXVlc3Rpb25zIHdhcywgd2hhdCBpcyB0aGUgdXN1YWwgcHJhY3RpY2UNCj4gPiB3aXRoIHJl Z2FyZHMgdG8gZnJhZ21lbnRpbmcgYW4gSVAgZGF0YWdyYW0gb3Zlcg0KPiA+IG11bHRpcGxlIE1Q RSBzZWN0aW9ucyAoaXJyZXNwZWN0aXZlIG9mIGhvdyB0aGVzZQ0KPiA+IHNlY3Rpb25zIGFyZSB0 cmFuc3BvcnRlZCBpbiBUUyBwYWNrZXRzKT8gVGhlIERWQi1IDQo+ID4gKGRhdGEgYnJvYWRjYXN0 IHN0YW5kYXJkKSBhbGxvd3MgZm9yIHRoaXMsIGhvd2V2ZXIsDQo+ID4gdGhlIElQREMgaW50ZXJp bSBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHRoYXQgb25lDQo+ID4gZGF0YWdyYW0gYmUgZW5jYXBz dWxhdGVkIGVudGlyZWx5IGluIG9uZSBtcGUgc2VjdGlvbg0KPiA+IGkuZS4sIG5vIGRhdGFncmFt IGZyYWdtZW50YXRpb24gb3ZlciBtdWx0aXBsZSBNUEUNCj4gPiBzZWN0aW9ucy4NCj4gDQo+IE5v dyB0aGUgY29uZnVzaW9uIHN0YXJ0cyB3aGVuIG9uZSBpbnRyb2R1Y2VzIHRoZSB3b3JkaW5nIG9m ICJvdmVyDQo+IG11bHRpcGxlIE1QRSBzZWN0aW9ucyIsIGJlY2F1c2UgdGhlcmUgaXMgbm8gc3Vj aCB0aGluZyBhcyBhIE1QRSBzZWN0aW9uDQo+IGZyYWdtZW50YXRpb24uDQo+IEkgd2lsbCBoYXZl IHRvIHJlYWQgdGhlIERWQi1IIHN0YW5kYXJkIGFnYWluIGluIG9yZGVyIHRvIGZpbmQgb3V0IHdo YXQNCj4gaXQgcmVhbGx5IHNheXMuIEkgZ3Vlc3MgdGhlIG9ubHkgcmVhbCBpc3N1ZXMgdGhlIERW Qi1IIHdydCB0byBJUCBpcw0KPiBhZGRyZXNzaW5nIGlzIHRoZSBuZWNlc3NpdHkgb2YgYSBJUCBk YXRhZ3JhbSBlbmNhcHN1bGF0ZWQgaW4gTVBFIGlzIHRvDQo+IHN1cHBvcnQgdGltZSBzbGljaW5n IChpZSBhIGJ1cnN0IHRyYW5zbWlzc2lvbiBvZiB0aGUgcmVzdWx0aW5nIFRTDQo+IHBhY2tldHMg dG8gYWxsb3cgZm9yIHBvd2VyIHNhdmluZykgYW5kIE1QRS1GRUMgKGFkZGluZyByZWR1bmRhbnQg Y29kZSB0bw0KPiBhbGxvdyBmb3IgcmVjb25zdHJ1Y3Rpb24pLiBJbiB0aGF0IGNhc2UgSSB3b291 bGQgYXNzdW1lIHRoYXQgaXQgaXMgdmVyeQ0KPiByZWFzb25hYmxlIChlc3BlY2lhbGx5IHdpdGgg bGVnYWN5IGVxdWlwbWVudCkgdG8gYXZvaWQgYWxsIHBvdGVudGlhbA0KPiBpbnRlcnByZXRhdGlv bnMgb2YgTVBFIHdydCBtdWx0aXBsZSBzZWN0aW9uIG9wZXJhdGlvbiBhbmQgc2VjdGlvbiANCnBh Y2tpbmcuDQo+IA0KPiA+IHRoYW5rcywNCj4gPiBTaXZhDQo+IFsuLi5dDQo+IA0KPiBZb3IgYXJl IHZlcnkgd2VsY29tZSwNCj4gYW5kIEkgaG9wZSBJIGdvdCBUSEUgZXhwZWN0ZWQgYW5zd2VyIGNs b3NlciwNCj4gQmVybmhhcmQNCg0KDQoNCg== --=_alternative 0043D92CC1256FF5_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgV2lsbGlhbSwgPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHdhcyBtYWlubHkg b2JqZWN0aW5nIHRvIHlvdXIgaW5pdGlhbA0KY29tbWVudCB0aGF0IG5vIHZlbmRvcnMgc3VwcG9y dCBNUEUgU2VjdGlvbiBwYWNraW5nLCB3aGlsZSBpbiBmYWN0IGFsbA0KSSBoYXZlIGNvbWUgYWNy b3NzIGRvIHN1cHBvcnQgaXQuIE5vdyB3ZSBhcmUgc2F5aW5nIHRoZSBzYW1lIHRoaW5nLCBuYW1l bHkNCnRoYXQgdGhleSBkbyBub3Qgc3VwcG9ydCBNUEUgSVAgZnJhZ21lbnRhdGlvbi4gSGVuY2Ug d2UgY2FuIHByb2JhYmx5IHN0b3ANCnRoaXMgZGlzY3Vzc2lvbiBub3cuIDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LS1Ub3I8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7 V2lsbGlhbSBTdGFuaXNMYXVzJnF1b3Q7DQombHQ7d2lsbGlhbUBlcmcuYWJkbi5hYy51ayZndDs8 L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTog b3duZXItaXBkdmJAZXJnLmFiZG4uYWMudWs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MDIuMDUuMjAwNSAxNDowMTwvZm9udD4NCjx0YWJsZSBib3JkZXI+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSByZXNwb25kIHRvPGJyPg0KaXBkdmJAZXJn LmFiZG4uYWMudWs8L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxicj4NCjx0ZCB3aWR0aD01OSU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtpcGR2YkBlcmcuYWJkbi5hYy51ayZndDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SRTogTVBFIFF1ZXN0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPkRlYXIgVG9yIEJyZWtr ZSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+ U29ycnkgaWYgSSBoYXZlIGNvbmZ1c2VkLCBtYXkNCmJlIEkgc2hvdWxkIG1ha2UgaXQgbW9yZSBk ZXRhaWxlZCA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iV2luZ2Rpbmdz Ij5KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwi PkluIERTTS1DQyAoTVBFKSB3ZSBoYXZlIHNlY3Rpb24tbGVuZ3RoDQp0byBzcGVjaWZ5IHRoZSBz aXplIG9mIHRoZSBwYXlsb2FkIGl0IGNhcnJpZXMsIHRoaXMgY2FuIGJlIG1heGltdW0gb2YgNDA5 Ng0KYnl0ZXMuIEhlbmNlIGFueSBJUCBwYWNrZXQgYXMgYSBwb3RlbnRpYWwgcGF5bG9hZCBmb3Ig RFNNLUNDIGNhbiBiZSBtYXhpbXVtDQpvZiA0MDk2IGJ5dGVzLCB0aGlzIGxlbmd0aCBub3JtYWxs eSBkaXNjb3ZlcmVkIHVzaW5nIEwyIE1UVSBzaXplIGFuZCBJUA0KcGFja2V0cyBnZXRzIGZyYWdt ZW50ZWQgaWYgdGhlIHBhY2tldCBpcyBncmVhdGVyIHRoYW4gNDA5NiBieXRlcy4gQnV0IHRoZW9y ZXRpY2FsbHksDQpEU00tQ0Mgc3VwcG9ydHMgbXVsdGlwbGUgc2VnbWVudHMvZnJhZ21lbnRzIGJ5 IGl0c2VsZiAoc2VjdGlvbiBudW1iZXIgYW5kDQpsYXN0IHNlY3Rpb24gbnVtYmVyKSB3aGljaCBn aXZlcyByb29tIGZvciBiaWdnZXIgaXAgcGFja2V0IGV2ZW4gZ3JlYXRlcg0KdGhhbiA0MDk2IGJ5 dGVzLiBEb2VzIGFueSBvZiB0aGUgdmVuZG9yIHVzZXMgdGhpcyBmdW5jdGlvbmFsbHkgZm9yIGlw IGRhdGENCnRyYW5zbWlzc2lvbiBpcyBhIHF1ZXN0aW9uICEhIS4gSSBteXNlbGYgbmV2ZXIgY29t ZSBhY3Jvc3Mgc3VjaCBzdXBwb3J0DQpmb3IgaXAgZGF0YSB0cmFuc21pc3Npb24uIE5leHQsIGlm IGEgc2luZ2xlIERTTS1DQyAoTVBFKSBjYW4gY2FycnkgbW9yZQ0KdGhhbiBvbmUgSVAgcGFja2V0 Pz8sIEkgZG9u4oCZdCB1bmRlcnN0YW5kIGlmIGl0IGlzIHBvc3NpYmxlLCBzaW5jZSB3ZSBkb27i gJl0DQpoYXZlIHBheWxvYWQgc3RhcnQgaW5kaWNhdG9yIGFuZCBwb2ludGVyIHRvIHBlcmZvcm0g SVAgZGF0YWdyYW0gc2VjdGlvbg0KcGFja2luZyBpbiBzaW5nbGUgRFNNLUNDIChNUEUpIHBheWxv YWQsIHdoaWNoIGNhbiBiZSBkZWNhcHN1bGF0ZWQgYXQgdGhlDQpvdGhlciBlbmQuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPk5leHQsIE1QRUcy LVRTLCBmb3IgYW55IE1QRUcyLVRTDQpwYWNrZXQgaXQgTVVTVCBiZSBvZiBsZW5ndGggMTg4IGJ5 dGVzLiBBbnkgTVBFIChEU00tQ0MpIHBhY2tldCBsZXNzIHRoYW4NCjE4MyBieXRlcyAoY29uc2lk ZXJpbmcgYWZ0ZXIgTVBFRzItVFMgaGVhZGVyIGFuZCBwYXlsb2FkIHBvaW50ZXIpIG5lZWRzDQp0 byBiZSBzdHVmZmVkL3BhZGRpbmcsIGluc3RlYWQgb2YgZG9pbmcgc28gd2UgY2FuIGRvIHNlY3Rp b24gcGFja2luZywgYnkNCnNlbmRpbmcgbmV4dCBNUEUgcGFja2V0IGludG8gdGhlIHNhbWUgTVBF RzItVHJhbnNwb3J0IFN0cmVhbS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAw ODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAw MDA4MCBmYWNlPSJBcmlhbCI+SG9wZSBub3cgaXQgaXMgY2xlYXI8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+VXBkYXRlIG1lIGlmIEnigJltIHdy b25nIDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJXaW5nZGluZ3MiPko8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+LVdp bGxpYW0uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFs Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJp YWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJB cmlhbCI+Jm5ic3A7PC9mb250Pg0KPGRpdiBhbGlnbj1jZW50ZXI+DQo8YnI+DQo8aHI+PC9kaXY+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IG93bmVyLWlwZHZi QGVyZy5hYmRuLmFjLnVrDQpbbWFpbHRvOm93bmVyLWlwZHZiQGVyZy5hYmRuLmFjLnVrXSA8Yj5P biBCZWhhbGYgT2YgPC9iPlRvciBCcmVra2U8Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBNYXkg MDIsIDIwMDUgMTE6MjUgQU08Yj48YnI+DQpUbzo8L2I+IGlwZHZiQGVyZy5hYmRuLmFjLnVrPGI+ PGJyPg0KU3ViamVjdDo8L2I+IFJFOiBNUEUgUXVlc3Rpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBXaWxsaWFtLCA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpJIHRoaW5rIHlvdSBhcmUgc29tZXdoYXQgY29uZnVzZWQgaW4gdGhl IHVzZSBvZiB0ZXJtaW5vbG9neSBoZXJlLiBTZWN0aW9uDQpwYWNraW5nIGlzIHRoZSBwcm9jZXNz IG9mIGhhdmluZyBtb3JlIHRoYW4gb25lIChwYXJ0aWFsKSBJUCBwYWNrZXQgaW4gZWFjaA0KTVBH IGZyYW1lLiBUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggbWF4aW11bSBzZWN0aW9uIHNpemUu IEFsbCBJUCBlbmNhcHN1bGF0b3JzDQpwcm9iYWJseSBzdXBwb3J0IE1QRSBTZWN0aW9uIHBhY2tp bmcuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCk1QRSBEb2VzIGFkZGl0aW9u YWxseSBzdXBwb3J0IGZyYWdtZW50YXRpb24gb2YgYW4gSVAgcGFja2V0IGludG8gbXVsdGlwbGUN CkRTTS1DQyBzZWN0aW9ucyAoSSBndWVzcyB0aGlzIGlzIHdoYXQgeW91IGFyZSByZWFsbHkgdGFs a2luZyBhYm91dCkuIFRoaXMNCmlzIG9ubHkgdXNlZnVsIGZvciBJUCBwYWNrZXRzIHdoaWNoIGRv IG5vdCBmaXQgaW50byB0aGUgbWF4aW11bSBzZWN0aW9uDQpzaXplIG9mIDQwOTYgb2N0ZXRzLiBU aGlzIGZ1bmN0aW9uLCB3aGlsZSBkZWZpbmVkIGJ5IHRoZSBNUEUgc3RhbmRhcmQsDQppcyBub3Qg KG5vcm1hbGx5Pykgc3VwcG9ydGVkIGJ5IHRoZSBJUCBlbmNhcHN1bGF0b3JzLiBJIGhhdmUgdG8g YWRtaXQgdGhhdA0KSSBoYXZlIG5vdCBjaGVja2VkIGRldGFpbHMgb24gZXZlciB2ZW5kb3IgaGVy ZSwgYnV0IGhhdmUgbm90IHNlZW4gdGhpcw0KaW4gYW55IG9mIHRoZSBvbmVzIEkgaGF2ZSB1c2Vk IG15c2VsZi4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KUmVnYXJkczwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUb3IgQnJla2tlPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NjIlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtXaWxsaWFtIFN0YW5pc0xhdXMmcXVvdDsN CiZsdDt3aWxsaWFtQGVyZy5hYmRuLmFjLnVrJmd0OzwvYj4gPGJyPg0KU2VudCBieTogb3duZXIt aXBkdmJAZXJnLmFiZG4uYWMudWs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjkuMDQu MjAwNSAxNzo1NjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwv Zm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIGJvcmRlcj00IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0xMDAlIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UGxlYXNlIHJlc3BvbmQgdG88YnI+DQppcGR2 YkBlcmcuYWJkbi5hYy51azwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTM3 JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjIlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88 L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9NzclPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mbHQ7aXBkdmJAZXJnLmFiZG4uYWMudWsmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlJFOiBNUEUgUXVlc3Rpb248L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjx0ZCB3aWR0aD00OSU+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpI aSBTaXZhIGFuZCBCZXJuaGFyZCw8YnI+DQpEU00tQ0Mgd2hpY2ggaXMgYSBwb3RlbnRpYWwgTVBF IG9mIG91ciBwcmVzZW50IGRheSBET0VTIE5PVCBzdXBwb3J0IHNlY3Rpb248YnI+DQpwYWNraW5n IGZvciBub3JtYWwgSVAgZGF0YSB0cmFuc21pc3Npb25zLiBJbiBEU00tQ0Mgd2UgaGF2ZSBzZWN0 aW9uIGxlbmd0aDxicj4NCm9mIDEyIGJpdHMsIHdoaWNoIGNhbiBob2xkIG1heGltdW0gb2YgNDA5 NiBCeXRlcyBvZiBwYXlsb2FkIGRhdGEgKElQIGluDQpvdXI8YnI+DQpkaXNjdXNzaW9uKS4gSW4g Tm9ybWFsIHNjZW5hcmlvIHdlIGRvbid0IGV2ZW4gdXNlIHRoaXMgYmlnLCBzaW5jZSBzZWN0aW9u PGJyPg0KcGFja2luZyBpcyBub3Qgc3VwcG9ydGVkIHByYWN0aWNhbGx5ICh0aGVvcmV0aWNhbGx5 IFlFUyksIHdlIHVzZSBEVkIgcm91dGVyPGJyPg0Kb25lIGludGVyZmFjZSBhcyBFdGhlcm5ldCBh bmQgb3RoZXIgYXMgRFZCLCBvbiBFdGhlcm5ldCB3aXJlIHdlIGdldCBvbmx5PGJyPg0KMTUwMCBi eXRlcyB0aGUgbWF4LCB0aG91Z2ggdGhlcmUgaXMgYSByb29tIGZvciBzZWN0aW9uPGJyPg0KcGFj a2luZyh0aGVvcmV0aWNhbGx5KSByZWFsIHRpbWUgcGFja2V0IHJvdXRpbmcgZG9uJ3Qgd2FpdCBm b3IgYW5vdGhlcg0KSVA8YnI+DQpwYWNrZXQsIGp1c3QgcHVzaCBlYWNoIGFuZCBldmVyeSBpcCBw YWNrZXQgcmVjZWl2ZWQgd2l0aCBNUEUgKERTTS1DQykgYW5kDQp0bzxicj4NCk1QRUcyLVRTIChz dXBwb3J0cyBzZWN0aW9uIHBhY2tpbmcsIGJhc2VkIG9uIHRoZSB0aW1lciAtIHJlYXNvbiBNUEVH Mi1UUzxicj4NCk1VU1QgYmUgMTg4IGJ5dGVzLCBpbnN0ZWFkIG9mIHdhc3RpbmcgYnl0ZXMgd2l0 aCBzdHVmZmluZyB3ZSBoYXZlIHNlY3Rpb248YnI+DQpwYWNraW5nKS48YnI+DQo8YnI+DQpXaGVu IHdlIGFyZSB0YWxraW5nIGFib3V0IHN0dWZmaW5nIGJ5dGVzLCB0aGF0IHdhcyBwZXJmZWN0IGJ5 IEJlcm5oYXJkLA0Kd2U8YnI+DQp1c2UgZm9yIHBhY2tldCBhbGlnbm1lbnQsIHRvIGJlIG1vcmUg c3BlY2lmaWMsIHJlYWwgdGltZSBvcGVyYXRpbmcgc3lzdGVtPGJyPg0KbGlrZSBQU09TLCByZXF1 aXJlcyBpdCBiZSBXT1JEIGFsaWduZWQgKCBNdWx0aXBsZXMgb2YgRm91cikgYmVmb3JlPGJyPg0K ZW5jcnlwdGlvbiBhbGdvcml0aG0gdG8gYmUgYXBwbGllZCBmb3Igc2NyYW1ibGluZy48YnI+DQo8 YnI+DQotV2lsbGlhbS48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiBvd25lci1pcGR2YkBlcmcuYWJkbi5hYy51ayBbbWFpbHRvOm93bmVy LWlwZHZiQGVyZy5hYmRuLmFjLnVrXQ0KT248YnI+DQomZ3Q7IEJlaGFsZiBPZiBCZXJuaGFyZCBD b2xsaW5pLU5vY2tlcjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBBcHJpbCAyOSwgMjAwNSA2OjU1 IEFNPGJyPg0KJmd0OyBUbzogaXBkdmJAZXJnLmFiZG4uYWMudWs8YnI+DQomZ3Q7IFN1YmplY3Q6 IFJlOiBNUEUgUXVlc3Rpb248YnI+DQomZ3Q7IDxicj4NCiZndDsgRGVhciBTaXZhLDxicj4NCiZn dDsgPGJyPg0KJmd0OyB5b3UgYXJlIHJpZ2h0IGluIHRoYXQgSSBoYWQgdW5kZXJzdG9vZCB5b3Vy IHF1ZXN0aW9uIGRpZmZlcmVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgR2VuZXJhbGx5IFNlY3Rp b25zIGRvIGFsbG93IGZvciBudW1iZXJpbmcgdGhhdCBpcywgb25lIGNhbiBwdXQgYSBwYXlsb2Fk PGJyPg0KJmd0OyAoZm9yIGV4YW1wbGUgYSBEU00tQ0Mgb2JqZWN0KSBpbnRvIGEgbnVtYmVyIG9m IFNlY3Rpb25zIGFuZCB3aXRoPGJyPg0KJmd0OyBzZWN0aW9uX251bWJlciBhbmQgbGFzdF9zZWN0 aW9uX251bWJlciB0aGUgcmVhc3NlYmxlciBrbm93cyB3aGF0IHRvDQpkby48YnI+DQomZ3Q7IE1Q RSB1c2VzIHRoaXMgU2VjdGlvbiBtZWNoYW5pc20sIHNvIG11bHRpcGxlIFNlY3Rpb24gb3BlcmF0 aW9ucyBzaG91bGQ8YnI+DQomZ3Q7IGJlIHBvc3NpYmxlLiBBY3R1YWxseSBJIGhhdmUgbmV2ZXIg dGVzdGVkIHdoZXRoZXIgTVBFIGRlY2Fwc3VsYXRvcnMNCmRvPGJyPg0KJmd0OyBzdXBwb3J0IHRo aXMgaW4gcmVhbCwgaW4gcHJpbmNpcGxlIHRoZXkgc2hvdWxkIChhZ2FpbiB0aGUgRFZCPGJyPg0K Jmd0OyBkYXRhYnJvYWRhY3N0IHN0YW5kYXJkIGRvZXMgbm90IHNheSB0b28gbXVjaCwgaWYgYW55 dGhpbmcsIGFib3V0IGl0KQ0KYnV0PGJyPg0KJmd0OyBpbiBEU00tQ0MgT2JlamN0IGNhcm91c2Vs cyBpcyBhIHZlcnkgdXN1YWwgbW9kZSBvZiBvcGVyYXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFNpdmEgVmVlcmVwYWxsaSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIGZvciB0aGUgcmVz cG9uc2UgQmVybmhhcmQsIGJ1dCBJIGFtIGEgYml0PGJyPg0KJmd0OyAmZ3Q7IGNvbmZ1c2VkIGFi b3V0IHRoZSBhbnN3ZXIuIFBsZWFzZSBzZWUgbXkgcXVlc3Rpb248YnI+DQomZ3Q7ICZndDsgYmVs b3c6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLSBCZXJuaGFyZCBDb2xsaW5pLU5v Y2tlciAmbHQ7Ym5vY2tlckBjb3N5LnNiZy5hYy5hdCZndDs8YnI+DQomZ3Q7ICZndDsgd3JvdGU6 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0O1NpdmEgVmVlcmVwYWxsaSB3cm90ZTo8 YnI+DQomZ3Q7IFsuLi5dPGJyPg0KJmd0OyAmZ3Q7IEkgdW5kZXJzdGFuZCB0aGF0IHR3byBNUEUg c2VjdGlvbnMgY291bGQgcHJvYmFibHk8YnI+DQomZ3Q7ICZndDsgc3RhcnQgaW4gdGhlIHNhbWUg VFMgcGFja2V0IChJIGd1ZXNzIHRoYXQgaXMgd2hhdCB5b3U8YnI+DQomZ3Q7ICZndDsgbWVhbiBi eSBzZWN0aW9uIHBhY2tpbmcpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXMuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZndDsgTXkgb3JpZ2luYWwgcXVlc3Rpb25zIHdhcywgd2hhdCBpcyB0aGUgdXN1 YWwgcHJhY3RpY2U8YnI+DQomZ3Q7ICZndDsgd2l0aCByZWdhcmRzIHRvIGZyYWdtZW50aW5nIGFu IElQIGRhdGFncmFtIG92ZXI8YnI+DQomZ3Q7ICZndDsgbXVsdGlwbGUgTVBFIHNlY3Rpb25zIChp cnJlc3BlY3RpdmUgb2YgaG93IHRoZXNlPGJyPg0KJmd0OyAmZ3Q7IHNlY3Rpb25zIGFyZSB0cmFu c3BvcnRlZCBpbiBUUyBwYWNrZXRzKT8gVGhlIERWQi1IPGJyPg0KJmd0OyAmZ3Q7IChkYXRhIGJy b2FkY2FzdCBzdGFuZGFyZCkgYWxsb3dzIGZvciB0aGlzLCBob3dldmVyLDxicj4NCiZndDsgJmd0 OyB0aGUgSVBEQyBpbnRlcmltIHNwZWNpZmljYXRpb24gcmVxdWlyZXMgdGhhdCBvbmU8YnI+DQom Z3Q7ICZndDsgZGF0YWdyYW0gYmUgZW5jYXBzdWxhdGVkIGVudGlyZWx5IGluIG9uZSBtcGUgc2Vj dGlvbjxicj4NCiZndDsgJmd0OyBpLmUuLCBubyBkYXRhZ3JhbSBmcmFnbWVudGF0aW9uIG92ZXIg bXVsdGlwbGUgTVBFPGJyPg0KJmd0OyAmZ3Q7IHNlY3Rpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBOb3cgdGhlIGNvbmZ1c2lvbiBzdGFydHMgd2hlbiBvbmUgaW50cm9kdWNlcyB0aGUgd29yZGlu ZyBvZiAmcXVvdDtvdmVyPGJyPg0KJmd0OyBtdWx0aXBsZSBNUEUgc2VjdGlvbnMmcXVvdDssIGJl Y2F1c2UgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIE1QRQ0Kc2VjdGlvbjxicj4NCiZndDsg ZnJhZ21lbnRhdGlvbi48YnI+DQomZ3Q7IEkgd2lsbCBoYXZlIHRvIHJlYWQgdGhlIERWQi1IIHN0 YW5kYXJkIGFnYWluIGluIG9yZGVyIHRvIGZpbmQgb3V0DQp3aGF0PGJyPg0KJmd0OyBpdCByZWFs bHkgc2F5cy4gSSBndWVzcyB0aGUgb25seSByZWFsIGlzc3VlcyB0aGUgRFZCLUggd3J0IHRvIElQ IGlzPGJyPg0KJmd0OyBhZGRyZXNzaW5nIGlzIHRoZSBuZWNlc3NpdHkgb2YgYSBJUCBkYXRhZ3Jh bSBlbmNhcHN1bGF0ZWQgaW4gTVBFIGlzDQp0bzxicj4NCiZndDsgc3VwcG9ydCB0aW1lIHNsaWNp bmcgKGllIGEgYnVyc3QgdHJhbnNtaXNzaW9uIG9mIHRoZSByZXN1bHRpbmcgVFM8YnI+DQomZ3Q7 IHBhY2tldHMgdG8gYWxsb3cgZm9yIHBvd2VyIHNhdmluZykgYW5kIE1QRS1GRUMgKGFkZGluZyBy ZWR1bmRhbnQgY29kZQ0KdG88YnI+DQomZ3Q7IGFsbG93IGZvciByZWNvbnN0cnVjdGlvbikuIElu IHRoYXQgY2FzZSBJIHdvb3VsZCBhc3N1bWUgdGhhdCBpdCBpcw0KdmVyeTxicj4NCiZndDsgcmVh c29uYWJsZSAoZXNwZWNpYWxseSB3aXRoIGxlZ2FjeSBlcXVpcG1lbnQpIHRvIGF2b2lkIGFsbCBw b3RlbnRpYWw8YnI+DQomZ3Q7IGludGVycHJldGF0aW9ucyBvZiBNUEUgd3J0IG11bHRpcGxlIHNl Y3Rpb24gb3BlcmF0aW9uIGFuZCBzZWN0aW9uDQpwYWNraW5nLjxicj4NCiZndDsgPGJyPg0KJmd0 OyAmZ3Q7IHRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgU2l2YTxicj4NCiZndDsgWy4uLl08YnI+DQom Z3Q7IDxicj4NCiZndDsgWW9yIGFyZSB2ZXJ5IHdlbGNvbWUsPGJyPg0KJmd0OyBhbmQgSSBob3Bl IEkgZ290IFRIRSBleHBlY3RlZCBhbnN3ZXIgY2xvc2VyLDxicj4NCiZndDsgQmVybmhhcmQ8YnI+ DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0043D92CC1256FF5_=-- From owner-ipdvb@erg.abdn.ac.uk Mon May 2 10:51:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23273 for ; Mon, 2 May 2005 10:51:59 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DScUr-0005JW-4q for ipdvb-archive@ietf.org; Mon, 02 May 2005 11:06:10 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42EDngY005404 for ; Mon, 2 May 2005 15:13:49 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j42EDncJ005403 for ipdvb-subscribed-users; Mon, 2 May 2005 15:13:49 +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.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j42ED8Z9005371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 May 2005 15:13:09 +0100 (BST) Message-ID: <42763576.8060603@erg.abdn.ac.uk> Date: Mon, 02 May 2005 15:13:10 +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: margaret@thingmagic.com, ipdvb@erg.abdn.ac.uk CC: Bernhard Collini-Nocker Subject: Re: AD Review Comments on draft-ietf-ipdvb-ule-05.txt References: In-Reply-To: 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-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Thanks Margaret, this seems like a very positive review from our AD. See below for text which we hope will resolve the issues that you raised. Do these cover your current concerns? If they do, we will add them to the edit list for the next rev (and publish when you finally call a revised I-D). Gorry & Bernhard (ULE ID Authors) Margaret Wasserman wrote: > > Hi All, > > I have finished my AD review of draft-ietf-ipdvb-ule-05.txt. This document appears to be in very good shape. I just have a couple of comments/questions on the document (see below) that I would like to resolve before sending the document to the IESG for final review. > > Since any changes related to these comments are likely to be very small, I will send the document to IETF LC in parallel with resolving these issues. Gorry, if you like, you can wait until the IETF LC completes and make any changes resulting from these comments at the same time as you make any changes to address the IETF LC comments. > > Margaret > > --- > > 4. SNDU Format > > PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an > MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs > is illustrated below: > > < ----------------------------- SNDU ----------------------------- > > +-+-------------------------------------------------------+--------+ > |D| Length | Type | PDU | CRC-32 | > +-+-------------------------------------------------------+--------+ > > Figure 1: SNDU Encapsulation > > All multi-byte values in ULE (including Length, Type, and > Destination fields) are transmitted in network byte order (most > significant byte first). The most significant bit of each byte is > placed in the left-most position of the 8-bit field. Appendix A > provides informative examples of usage. > >>> A destination field is mentioned in the text, but not shown in >>> the diagram? It might make sense to how/where the destination >>> may be included before mentioning it. > > Gorry/Bernard writes: Hmm... yes you're correct this contains a forward reference, and probably should be made explicit: OLD: < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Figure 1: SNDU Encapsulation NEW: < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | Dest Address* | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Figure 1: SNDU Encapsulation (* optional Destination Address) OLD: All multi-byte values in ULE (including Length, Type, and Destination fields) are transmitted in network byte order (most significant byte first). NEW: All multi-byte values in ULE (including the Length/End Indicator (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension Headers (5)) are transmitted in network byte order (most significant byte first). > > 5.1 Test SNDU > > A Test SNDU (figure 10) is of a Mandatory Extension Header of Type > 1. This header must be the final (or only) extension header > specified in the header chain of a SNDU. > > [...] > > 5.2 Bridge Frame SNDU Encapsulation > > A bridged SNDU is a Mandatory Extension Header of Type 1. It must be > the final (or only) extension header specified in the header chain > of a SNDU. > >>> Is it intentional that the Test SNDU and the Bridge Frame SNDU >>> headers cannot be used in the same SNDU? Gorry/Bernhard: Certainly a bridged SNDU must be the last extension header in a chain, the payload of the bridged SNDU *IS* an Ethernet MAC/LLC frame. The payload of a TEST SNDU is ignored, and teh format is not defined. - So the answer to the question is "Yes". Both these examples MUST come at the end of the header chain. I guess this could be true of other Mandatory Extension Headers, but this is not necessarily intended to be true of all mandatory extension headers: e.g. A mandatory encryption header (much discussed informally, but not yet specified - expect an I-D proposing before the next IETF) could possibly contain a Type field with further extensions specified - ROHC inside encryption would be a good example of a useful combination, bridging inside encryption also seems useful. > > > 3. Description of the Method > > [...] > > The ULE encapsulation is limited to TS private streams only. The > header of each TS Packet carries a one bit Payload Unit Start > Indicator (PUSI) field. A PUSI field with a value of 1 indicates the > presence of at least one Payload Unit (SNDU) within the TS Packet > payload. > >>> s/the presence of at least one/the start of at least one/ ?? >>> >>> If I understand this correctly, the PUSI field will be 0 if >>> the TS does not include the start of an SNDU. > YES. Your proposed edit is good. The text will be updated. ---- From owner-ipdvb@erg.abdn.ac.uk Tue May 3 03:15:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06858 for ; Tue, 3 May 2005 03:15:10 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSrqT-00009n-Nx for ipdvb-archive@ietf.org; Tue, 03 May 2005 03:29:30 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j436h9dV021709 for ; Tue, 3 May 2005 07:43:09 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j436h9Aw021708 for ipdvb-subscribed-users; Tue, 3 May 2005 07:43:09 +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 [10.0.1.24] (maxp2.dialup.abdn.ac.uk [139.133.201.161]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j436gVFW021686 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 May 2005 07:42:33 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 03 May 2005 07:42:28 +0100 Subject: I-D ACTION:draft-ietf-ipdvb-arch-04.txt From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit For you information - this revised I-D was produced to address issues raised as a part of the on-going review by the IESG. It contains some minor editorial reorganisation, fixed punctuation, and an updated security considerations section. Best wishes, Gorry Fairhurst (ipdvb WG Chair) ------ 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 : A Framework for transmission of IP datagrams over MPEG-2 Networks Author(s) : M. Montpetit, et al. Filename : draft-ietf-ipdvb-arch-04.txt Pages : 39 Date : 2005-5-2 This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-arch-04.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-arch-04.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. From owner-ipdvb@erg.abdn.ac.uk Tue May 10 11:50:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07404 for ; Tue, 10 May 2005 11:50:22 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVXFO-0000mi-St for ipdvb-archive@ietf.org; Tue, 10 May 2005 12:06:16 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4AElG8X000531 for ; Tue, 10 May 2005 15:47:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j4AElG33000530 for ipdvb-subscribed-users; Tue, 10 May 2005 15:47:16 +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.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4AEkfFk000500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 May 2005 15:46:42 +0100 (BST) Message-ID: <4280C951.5060709@erg.abdn.ac.uk> Date: Tue, 10 May 2005 15:46:41 +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: ipdvb@erg.abdn.ac.uk Subject: ipdvb WG has adopted draft: draft-fair-ipdvb-ar-04.txt References: In-Reply-To: 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-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit This email completes the period of WG Call to Adopt the I-D below. 11 Responses were received during this call (1 direct to the chair). All these responses moved to adopt the document as a WG Draft. The present authors are therefore asked to update the Internet Draft to account for comments received and a new revised draft is expected to be issued by 1-June-12005. The new draft will named draft-ietf-ipdvb-ar-00.txt. The new I-D will be a WG draft, intended for publication as an RFC (under the current 3rd item in the ipdvb Charter). **ALL** inputs to help improve the document are therfore very welcome - including what extra should be added, what should be reworked, corrected, etc. Thanks for taking the time to read this document, Best wishes, Gorry Fairhurst (ipdvb WG Chair) ---- Title : Address Resolution for IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst, et al. Filename : draft-fair-ipdvb-ar-04.txt Pages : 17 Date : 2005-4-12 This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 networks, an IP address must be associated with a Packet ID (PID) and a specific Transmission Multiplex The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and NDP, and provides guidance on usage. From owner-ipdvb@erg.abdn.ac.uk Tue May 17 15:40:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01133 for ; Tue, 17 May 2005 15:40:13 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8C9-0002Tn-4d for ipdvb-archive@ietf.org; Tue, 17 May 2005 15:57:38 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4HIq7f5002413 for ; Tue, 17 May 2005 19:52:07 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j4HIq7ce002412 for ipdvb-subscribed-users; Tue, 17 May 2005 19:52:07 +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 notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4HIpfqQ002391 for ; Tue, 17 May 2005 19:51:41 +0100 (BST) In-Reply-To: <4280C951.5060709@erg.abdn.ac.uk> Subject: 1st DVB-RCS Symposium To: ipdvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Harald Skinnemoen Date: Tue, 17 May 2005 20:55:12 +0200 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.5.3FP1|December 15, 2004) at 2005-05-17 20:50:22 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-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Dear All, please find below a link to the Call for Papers for the 1st DVB-RCS Symposium, taking place at ESA/ESTEC on the 8th-9th September 2005. The event is free of charge to attend. I encourage your paper submissions, in particular on practical systems and experiences with DVB-RCS. Best regards, /Harald Skinnemoen http://satlabs.org/pdf/DVB-RCS_Symposium_Call_for_Papers_-_Final.pdf From owner-ipdvb@erg.abdn.ac.uk Tue May 24 16:29:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22152 for ; Tue, 24 May 2005 16:29:51 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DagKR-0007jP-O1 for ipdvb-archive@ietf.org; Tue, 24 May 2005 16:48:45 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4OJrmes016707 for ; Tue, 24 May 2005 20:53:48 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j4OJrmXc016706 for ipdvb-subscribed-users; Tue, 24 May 2005 20:53:48 +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 thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4OJqhqT016661; Tue, 24 May 2005 20:52:44 +0100 (BST) Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 375635; Tue, 24 May 2005 15:48:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <42763576.8060603@erg.abdn.ac.uk> References: <42763576.8060603@erg.abdn.ac.uk> Date: Tue, 24 May 2005 15:52:37 -0400 To: gorry@erg.abdn.ac.uk, ipdvb@erg.abdn.ac.uk From: Margaret Wasserman Subject: Re: AD Review Comments on draft-ietf-ipdvb-ule-05.txt Cc: Bernhard Collini-Nocker Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi Gorry, Sorry not to write back sooner... I tend to get behind on the WG mailing lists. At 3:13 PM +0100 5/2/05, Gorry Fairhurst wrote: >Thanks Margaret, this seems like a very positive review from our AD. Yes, definitely! I think that this is a well-written and sound document. >See below for text which we hope will resolve the issues that you raised. >Do these cover your current concerns? Yes, your answers have resolved my concerns. I have this document on the IESG agenda for this Thursday, so you can wait to address these comments along with any other IESG comments. Please make sure that the edits make it into the next version, though. Thanks! Margaret From owner-ipdvb@erg.abdn.ac.uk Thu May 26 03:16:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04991 for ; Thu, 26 May 2005 03:16:38 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbCuC-0000zY-DN for ipdvb-archive@ietf.org; Thu, 26 May 2005 03:35:50 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4Q6jIOF002280 for ; Thu, 26 May 2005 07:45:18 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j4Q6jIPR002278 for ipdvb-subscribed-users; Thu, 26 May 2005 07:45:18 +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 nrg.cs.usm.my (netmon.cs.usm.my [161.142.8.104]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4Q6inMK002260 for ; Thu, 26 May 2005 07:44:51 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 14DD82200C2 for ; Thu, 26 May 2005 14:44:44 +0800 (MYT) Received: from nrg.cs.usm.my ([127.0.0.1]) by localhost (nrg.cs.usm.my [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06989-10 for ; Thu, 26 May 2005 14:44:42 +0800 (MYT) Received: from simon (unknown [10.207.140.69]) by nrg.cs.usm.my (Postfix) with ESMTP id ABC522200C0 for ; Thu, 26 May 2005 14:44:42 +0800 (MYT) From: "Simon" To: "Ip-DVB" Subject: Multicast ROHC Enhancement of ULE? Date: Thu, 26 May 2005 14:44:44 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C56201.749BBCE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVhvmZUv5+Hn4ARQoGvhsDnZjKGhw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050526064442.ABC522200C0@nrg.cs.usm.my> X-Virus-Scanned: amavisd-new at nrg.cs.usm.my 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-Spam-Score: 0.2 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C56201.749BBCE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear members, I'm doing a study on how to compress the IP packet using ROHC and encapsulate it into ULE. I would like to compress IPv4 multicast packets for a DVB link that will be using ULE Do any other people on this mailing list have understanding of how to use the ROHC framework with a multicast destination address? - Specifically how should the destination address be handled, and how do people see the multicast compression context being established? Thanks in advance! Best Regards Simon Teh Univerisiti Sains Malaysia ------=_NextPart_000_0000_01C56201.749BBCE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear members,

 

I'm doing a study on how to = compress the IP packet using ROHC and encapsulate it into = ULE.

I would like to compress = IPv4 multicast packets for a DVB link that will be using ULE =  

Do any other people on this = mailing list have understanding of how to use the ROHC framework with a = multicast destination address?

 

- Specifically how should = the destination address be handled, and how do people see the multicast = compression context being established?

 

Thanks in = advance!

 

 

= Best Regards

= Simon Teh

= Univerisiti Sains Malaysia

 

------=_NextPart_000_0000_01C56201.749BBCE0-- From owner-ipdvb@erg.abdn.ac.uk Fri May 27 07:20:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01006 for ; Fri, 27 May 2005 07:20:47 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbdCG-0008J0-Cb for ipdvb-archive@ietf.org; Fri, 27 May 2005 07:40:13 -0400 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4RAhI2A012135 for ; Fri, 27 May 2005 11:43:18 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.11/8.12.2/Submit) id j4RAhIqV012134 for ipdvb-subscribed-users; Fri, 27 May 2005 11:43:18 +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.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4RAgfVP012107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 May 2005 11:42:42 +0100 (BST) Message-ID: <4296F9A1.6060401@erg.abdn.ac.uk> Date: Fri, 27 May 2005 11:42:41 +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: ipdvb@erg.abdn.ac.uk Subject: [Fwd: ID Tracker State Update Notice: draft-ietf-ipdvb-ule] 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-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit The ULE Specification was tabled at the IESG meeting yesterday. This IESG discussion is the final in a series of detailed reviews, and following the discusssion by teh IESG a number of NiTs have been identified. There are also a small number of technical issues still to be discussed. (For those interested, the details are provided in the link below). This is good news for the ipdvb WG, and we hope to soon have another document on the way to publication as an RFC! The next stage will be issue of a revised I-D that includes all these updates. The final list of issues addressed and the resolution of the discussion will be posted to this list. Best wishes, Gorry Fairhurst (ipdvb WG Chair) -------- Original Message -------- Subject: ID Tracker State Update Notice: draft-ietf-ipdvb-ule Date: Thu, 26 May 2005 16:20:49 -0400 From: The IESG To: gorry@erg.abdn.ac.uk 'State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11634&rfc_flag=0