From owner-ip-dvb@erg.abdn.ac.uk Sat Mar 1 13:34:13 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.7/8.12.7) with ESMTP id h21DXtvh016465 for ; Sat, 1 Mar 2003 13:33:55 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.7/8.12.2/Submit) id h21DXtsg016464 for ip-dvb-subscribed-users; Sat, 1 Mar 2003 13:33:55 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from post.webmailer.de (natsmtp01.webmailer.de [192.67.198.81]) by erg.abdn.ac.uk (8.12.7/8.12.7) with ESMTP id h21DXavh016441 for ; Sat, 1 Mar 2003 13:33:36 GMT Received: from news (B8ca6.pppool.de [213.7.140.166]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id OAA28981 for ; Sat, 1 Mar 2003 14:33:33 +0100 (MET) Message-ID: <001a01c2dff6$a6b62920$a68c07d5@dpiag.de> From: "Karsten Siebert" To: References: <4CADE2B66476214AA9633994B7A8777B03564C@exchange.telenor.sk> Subject: Re: MPE and DSMCC section_length Date: Sat, 1 Mar 2003 14:29:51 +0100 Organization: data planet international AG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C2DFFF.05134A40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C2DFFF.05134A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Everything looks ok. The 7th packet contains the remaining 34 data bytes = (including CRC_32). 0x46e (1134) + 3 =3D 1137 6* 184 -1 (pointer byte) + 34 =3D 1137. Karsten data planet international AG Horstfeldstrasse 5 D-31832 Springe Germany Tel.: +49 (0) 5045 980 85 Fax: +49 (0) 5045 980 86 http://www.dpi-ag.de -----Urspr=FCngliche Nachricht-----=20 Von: Daniel Imriska=20 An: ip-dvb@erg.abdn.ac.uk=20 Gesendet: Freitag, 28. Februar 2003 16:28 Betreff: MPE and DSMCC section_length Hallo,=20 =20 I plan to write DVB/IP gateway and I have question related to meaning = of the section_length field within DSMCC section.=20 =20 Based on specs, it is defined as follows: =20 dsmcc_section_length -- This 12 bit field specifies the number of = remaining bytes in the DSMCC_section immediately following this field up = to the end of the dsmcc_section. The value in this field shall not = exceed 4093 (indicating a section maximum data length of 4084 bytes, = following the last_section_number field and up to the CRC_32/checksum = field). =20 There is also one "example" saying =20 . else if (table_id =3D=3D 0x3E) { =20 for (i=3D0;i

Everything looks ok. The 7th packet contains the = remaining 34=20 data bytes (including CRC_32). 0x46e (1134) + 3 =3D 1137

6* 184 -1 (pointer byte) + 34 =3D 1137.

Karsten

data planet international AG
Horstfeldstrasse 5
D-31832=20 Springe
Germany

Tel.: +49 (0) 5045 980 85
Fax: +49 (0) 5045 980 86

http://www.dpi-ag.de

-----Urspr=FCngliche Nachricht----- =
Von:=20 Daniel Imriska
An: ip-dvb@erg.abdn.ac.uk

Gesendet: Freitag, 28. Februar = 2003=20 16:28

Betreff: MPE and DSMCC=20 section_length

Hallo,

I plan to write DVB/IP gateway and I have = question=20 related to meaning of the section_length = field=20 within DSMCC section.

Based on specs, it is defined as=20 follows:

dsmcc_section_length=20 -- This 12 bit field specifies the number of remaining bytes in the = DSMCC_section immediately following this field = up to the=20 end of the dsmcc_section. The value in = this field=20 shall not exceed 4093 (indicating a section maximum data length of = 4084 bytes,=20 following the last_section_number field = and up to=20 the CRC_32/checksum field).

There is also one “example”=20 saying

…

else if (table_id =3D=3D 0x3E) {

           &n= bsp;           =20 for (i=3D0;i<dsmcc_section_length-9;i++)=20 {

           &n= bsp;           &nb= sp;           =20 private_data_byte

           &n= bsp;           =20 }

.

I have grabbed some TS packets, please see = attached=20 word document. Based on this data, third packet within data, section_length =3D 0x463 =3D 1134. Data are = included in the=20 6x188 TS packets. This makes 6x188 =3D 1128 bytes. I am not able to find = relation between=20 those numbers and specs.

Could you, please, someone explain?=20

How is it with CRC, where is it within those = packets?

Thank you in = advance.

Regards, Daniel

------=_NextPart_000_0015_01C2DFFF.05134A40-- From owner-ip-dvb@erg.abdn.ac.uk Sun Mar 2 09:01:49 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.7/8.12.7) with ESMTP id h2291Vvh025088 for ; Sun, 2 Mar 2003 09:01:32 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.7/8.12.2/Submit) id h2291VDn025087 for ip-dvb-subscribed-users; Sun, 2 Mar 2003 09:01:31 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from exchange.TELENOR.SK (mailhost.telenor.sk [195.20.162.4]) by erg.abdn.ac.uk (8.12.7/8.12.7) with ESMTP id h2291Bvh025074 for ; Sun, 2 Mar 2003 09:01:16 GMT Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E09A.BA81183E" Subject: FW: MPE and DSMCC section_length X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sun, 2 Mar 2003 10:04:27 +0100 Message-ID: <4CADE2B66476214AA9633994B7A8777B03564F@exchange.telenor.sk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPE and DSMCC section_length thread-index: AcLf+jwmf2TdRerLT3Wc/yClrXEB7QAoD8fw From: =?iso-8859-1?Q?Daniel_Imriska?= To: X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E09A.BA81183E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unfortunatelly, if you count it one's more, there are only 6 packets = there and remaining 34 bytes are in the 6-th packet. =20 Daniel =20 -----Original Message----- From: Karsten Siebert [mailto:Karsten.Siebert@sv-gmbh.de]=20 Sent: Saturday, March 01, 2003 2:30 PM To: ip-dvb@erg.abdn.ac.uk Subject: Re: MPE and DSMCC section_length =20 Everything looks ok. The 7th packet contains the remaining 34 data bytes = (including CRC_32). 0x46e (1134) + 3 =3D 1137 =20 6* 184 -1 (pointer byte) + 34 =3D 1137. =20 =20 Karsten =20 data planet international AG Horstfeldstrasse 5 D-31832 Springe Germany =20 Tel.: +49 (0) 5045 980 85 Fax: +49 (0) 5045 980 86 =20 http://www.dpi-ag.de -----Urspr=FCngliche Nachricht-----=20 Von: Daniel Imriska =20 An: ip-dvb@erg.abdn.ac.uk=20 Gesendet: Freitag, 28. Februar 2003 16:28 Betreff: MPE and DSMCC section_length =20 Hallo,=20 =20 I plan to write DVB/IP gateway and I have question related to meaning = of the section_length field within DSMCC section.=20 =20 Based on specs, it is defined as follows: =20 dsmcc_section_length -- This 12 bit field specifies the number of = remaining bytes in the DSMCC_section immediately following this field up = to the end of the dsmcc_section. The value in this field shall not = exceed 4093 (indicating a section maximum data length of 4084 bytes, = following the last_section_number field and up to the CRC_32/checksum = field). =20 There is also one "example" saying =20 ... else if (table_id =3D=3D 0x3E) { =20 for (i=3D0;i

Unfortunatelly, if you count it one’s more, there are only 6 packets = there and remaining 34 bytes are in the 6-th = packet.

Daniel

-----Original Message-----
From: Karsten Siebert [mailto:Karsten.Siebert@sv-gmbh.de]
Sent: = Saturday, March 01, = 2003 2:30 PM
To: = ip-dvb@erg.abdn.ac.uk
Subject: Re: MPE and = DSMCC section_length

Everything looks ok. The 7th packet contains the remaining 34 = data bytes (including CRC_32). 0x46e (1134) + 3 =3D = 1137

6* 184 -1 (pointer byte) + 34 =3D = 1137.

Karsten

data planet international AG
Horstfeldstrasse 5
D-31832 Springe
Germany

Tel.: +49 (0) 5045 980 85
Fax: +49 (0) 5045 980 86

http://www.dpi-ag.de<= /font>

-----Urspr=FCngliche Nachricht----- =

Von:= Daniel Imriska

An: ip-dvb@erg.abdn.ac.uk

Gesendet: = Freitag, 28. Februar 2003 16:28

Betreff: MPE and = DSMCC section_length

Hallo,

I plan to write DVB/IP gateway and I have question related to = meaning of the section_length field within DSMCC section. =

Based on specs, it is defined as = follows:

dsmcc_section_length -- This 12 bit field specifies the number = of remaining bytes in the DSMCC_section immediately following this field up = to the end of the dsmcc_section. The value in this field shall not exceed 4093 (indicating a section maximum data length of 4084 bytes, following the last_section_number field and up to the CRC_32/checksum = field).

There is also one “example” = saying

…

else if (table_id =3D=3D 0x3E) {

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 for (i=3D0;i<dsmcc_section_length-9;i++) {

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 private_data_byte

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 }

.

I have grabbed some TS packets, please see attached word = document. Based on this data, third packet within data, section_length =3D 0x463 = =3D 1134. Data are included in the 6x188 TS packets. This makes 6x188 =3D 1128 = bytes.=A0 I am not able to find relation = between those numbers and specs.

Could you, please, someone explain? =

How is it with CRC, where is it within those = packets?

Thank you in advance.

Regards, Daniel

=00 ------_=_NextPart_001_01C2E09A.BA81183E-- From owner-ip-dvb@erg.abdn.ac.uk Tue Mar 4 17:16:38 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h24HGRkw009829 for ; Tue, 4 Mar 2003 17:16:27 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h24HGRPn009828 for ip-dvb-subscribed-users; Tue, 4 Mar 2003 17:16:27 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from esacom56-int.estec.esa.int (esacom56-ext.estec.esa.int [131.176.107.3]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h24HGBkw009816 for ; Tue, 4 Mar 2003 17:16:11 GMT Received: from esacom52.estec.esa.int. (esacom52.estec.esa.nl [131.176.7.7]) by esacom56-int.estec.esa.int (8.10.2/8.10.2/ESA-External-v2.0) with ESMTP id h24HG6v05923 for ; Tue, 4 Mar 2003 18:16:06 +0100 (MET) Received: from estecmail4.estec.esa.int (estecmail4.estec.esa.nl [131.176.7.65]) by esacom52.estec.esa.int. (8.9.2/8.9.2/ESA-ESTEC-mail-gw-v1.6) with SMTP id RAA13699 for ; Tue, 4 Mar 2003 17:16:02 GMT Received: by estecmail4.estec.esa.int(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 41256CDF.005EE235 ; Tue, 4 Mar 2003 18:16:22 +0100 X-Lotus-FromDomain: ESA From: Frank.Zeppenfeldt@esa.int To: ip-dvb@erg.abdn.ac.uk Message-ID: <41256CDF.005EE098.00@estecmail4.estec.esa.int> Date: Tue, 4 Mar 2003 18:15:56 +0100 Subject: Announcement of opportunity by ESA/ESTEC to support IP-over-DVB activities Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear ip-over-dvb-interested, We would like to use this reflector to draw your attention to an ITT (Invitation to Tender) AO 4372 which ESA (European Space Agency) has published on its website: http://emits.esa.int/ . This is the result of a request for ideas in http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/archive/msg00238.html The aim of the tender is to support developments related to emerging ideas on IP encapsulations and IP services over DVB-S/RCS. A number of Tasks have been described in this tender, such as: - make an inventory of on-going IP-over-DVB activities within fora such as DVB-CM, DVB-RCS, DVB-GBS, DVB IP Datacasting, ATSC, DVB-S2, DVB-SI DAT, DAB, IP Datacasting Forum, etc. - evaluate current MPE methods; - develop proof-of-concept implementations for improved encapsulation methods in receivers (IRDs) and senders (IP encapsulators/gateways); - prove interoperability with parallel implementations; - demonstrate applications that use new encapsulation methods, such as VoIPv6 or MPLS, or applications that demonstrate the more efficient use of the satellite capacity. We acknowledge that the title "Standardisation Support of enhanced IETF IP Encapsulation Techniques" may sound a bit limiting, but we encourage you to have look at the contents of the Statement of Work and discover that there is room to investigate issues which are outside of the pure encapsulation topic, such as address resolution, service announcements issues (INT/MMT), etc. The tender is open until 1 April 2003, and the idea is to initiate two parallel contracts. All correspondance needs to go via the official channels, have a look at http://emits.esa.int/ for all official information. Best regards, Frank.Zeppenfeldt@esa.int http://telecom.esa.int/ D-APP/TSM ESA/ESTEC (European Space & Technology Centre) From owner-ip-dvb@erg.abdn.ac.uk Thu Mar 6 16:48:42 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h26GmVkw023297 for ; Thu, 6 Mar 2003 16:48:31 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h26GmVFS023296 for ip-dvb-subscribed-users; Thu, 6 Mar 2003 16:48:31 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h26GmHkw023283 for ; Thu, 6 Mar 2003 16:48:17 GMT Received: from [68.100.8.94] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1619196 for ip-dvb@erg.abdn.ac.uk; Thu, 06 Mar 2003 11:48:10 -0500 Date: Thu, 6 Mar 2003 11:48:10 -0500 Subject: Re: IP-DVB: Notes from Atlanta Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Marshall Eubanks To: ip-dvb@erg.abdn.ac.uk Content-Transfer-Encoding: 7bit In-Reply-To: <3DF07A5D.F54975F7@erg.abdn.ac.uk> Message-Id: <69D445C3-4FF3-11D7-B81E-003065BA697E@multicasttech.com> X-Mailer: Apple Mail (2.482) X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Will there be a meeting of this group in San Francisco ? If so, when ? On Friday, December 6, 2002, at 05:22 AM, Dr G Fairhurst wrote: > > There was an unofficial meeting of people from the ip-dvb list at 5:30pm > after the IETF meeting on 20th November. > > Here's a brief summary of what was discussed. > > New encapsulation > ----------------- > Discussion again about "why" this was needed? > - Was it processing efficiency in software? > - Was it to improve bandwidth utilisation? > - Was it to help standardise features? (add new features?) > All were true, but motivation depends heavily on the intended > application. > There were some plans to do pilot implementations in 2003. > > Simple configuration of clients > ------------------------------- > "plug & play" . How could we make schemes for DVB/ATSC so > that were flexible and allowed IPv6 autoconfiguration? > - this implied the ability to do flexible IP address to PID > and TS-MUX mapping. > > There was some discussion of the recent draft from DVB > "ETSI EN drTS 102 00X V0.4.2 (2002-07) > Digital Video Broadcasting (DVB) > Specification for IP Notification in DVB Systems > Use of the IP/MAC Notification Table" > > - How general-purpose was this? > - Would it scale to large IP edge networks? > - How would it relate to the way IP multicast seemed > to be going (see discussions about the future of > multicast in mboned WG > & "draft-ietf-mboned-iesg-gap-analysis-00.txt") > > Unfortunately few people had access to this document, > since it is currently private to DVB members. > > Those who did have access to the document said they would look > at it and see what they thought. The current requirements > ID suggested three potential options: > > (i) Use the SI information for address resolution. > (ii) Provide an alternative mechanism at the IP-level > - similar to IPv6 ND? > (ii) Provide a complementary scheme at the IP-level > - similar to IPv6 ND, but able to import information > from SI tables (if able to). > > - Which should be done? - Why? > > The main challenge was to figure out what ELSE was necessary > to make the framework auto-configuartion flexible and > IP-friendly. > > Please send questions and answers on the list. > > Plans > ----- > There is now some enthusiasm now to start work on this in 2003, > and several promises of contributions (IDs) have been received > by Gorry Fairhurst. When we get sufficient Internet Drafts > on the table, so we can start doing the real work! > > Afterwards we adjourned to the "Polaris" bar to literally watch the > world spin by... > > Gorry Fairhurst > ip-dvb mailing list. > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. Phone : 703-293-9601 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Our New Multicast Workshop : http://www.multicasttech.com/workshop Test your network for multicast : http://www.multicasttech.com/mt/ From owner-ip-dvb@erg.abdn.ac.uk Fri Mar 7 09:27:34 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h279ROkw005919 for ; Fri, 7 Mar 2003 09:27:24 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h279ROfE005918 for ip-dvb-subscribed-users; Fri, 7 Mar 2003 09:27:24 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h279RFkw005908 for ; Fri, 7 Mar 2003 09:27:15 GMT Message-ID: <3E6865F2.7F47A842@erg.abdn.ac.uk> Date: Fri, 07 Mar 2003 09:27:14 +0000 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: IP-DVB: Notes from Atlanta References: <69D445C3-4FF3-11D7-B81E-003065BA697E@multicasttech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk No, no BoF this time either! So, what progress have we made? - First, I promise to rev. the ID on the encapsulation, and will do a call for comments to see if there any more changes needed / desirable. There has been a recent ESA ITT issued to do some implementation of this scheme and evaluation in a real link. so that should help this. - I hope that people will start writing down their ideas on other topics relating to security, MIBs, address resoltion, etc and prepare for the next meeting in Vienna. I would like to see more than two IDs so we can have a good range of topics and opinions.... - Finally I have been really busy since November, so some of the lack of progress is my fault. I am sorry. If you will be at the IETF in San Francisco, I'd like to talk to find out what your views / needs are.... Email me please. Gorry Fairhurst Marshall Eubanks wrote: > > Will there be a meeting of this group in San Francisco ? If so, when ? > > On Friday, December 6, 2002, at 05:22 AM, Dr G Fairhurst wrote: > > > > > There was an unofficial meeting of people from the ip-dvb list at 5:30pm > > after the IETF meeting on 20th November. > > > > Here's a brief summary of what was discussed. > > > > New encapsulation > > ----------------- > > Discussion again about "why" this was needed? > > - Was it processing efficiency in software? > > - Was it to improve bandwidth utilisation? > > - Was it to help standardise features? (add new features?) > > All were true, but motivation depends heavily on the intended > > application. > > There were some plans to do pilot implementations in 2003. > > > > Simple configuration of clients > > ------------------------------- > > "plug & play" . How could we make schemes for DVB/ATSC so > > that were flexible and allowed IPv6 autoconfiguration? > > - this implied the ability to do flexible IP address to PID > > and TS-MUX mapping. > > > > There was some discussion of the recent draft from DVB > > "ETSI EN drTS 102 00X V0.4.2 (2002-07) > > Digital Video Broadcasting (DVB) > > Specification for IP Notification in DVB Systems > > Use of the IP/MAC Notification Table" > > > > - How general-purpose was this? > > - Would it scale to large IP edge networks? > > - How would it relate to the way IP multicast seemed > > to be going (see discussions about the future of > > multicast in mboned WG > > & "draft-ietf-mboned-iesg-gap-analysis-00.txt") > > > > Unfortunately few people had access to this document, > > since it is currently private to DVB members. > > > > Those who did have access to the document said they would look > > at it and see what they thought. The current requirements > > ID suggested three potential options: > > > > (i) Use the SI information for address resolution. > > (ii) Provide an alternative mechanism at the IP-level > > - similar to IPv6 ND? > > (ii) Provide a complementary scheme at the IP-level > > - similar to IPv6 ND, but able to import information > > from SI tables (if able to). > > > > - Which should be done? - Why? > > > > The main challenge was to figure out what ELSE was necessary > > to make the framework auto-configuartion flexible and > > IP-friendly. > > > > Please send questions and answers on the list. > > > > Plans > > ----- > > There is now some enthusiasm now to start work on this in 2003, > > and several promises of contributions (IDs) have been received > > by Gorry Fairhurst. When we get sufficient Internet Drafts > > on the table, so we can start doing the real work! > > > > Afterwards we adjourned to the "Polaris" bar to literally watch the > > world spin by... > > > > Gorry Fairhurst > > ip-dvb mailing list. > > > Regards > Marshall Eubanks > > T.M. Eubanks > Multicast Technologies, Inc. > Phone : 703-293-9601 Fax : 703-293-9609 > e-mail : tme@multicasttech.com > http://www.multicasttech.com > > Our New Multicast Workshop : > http://www.multicasttech.com/workshop > Test your network for multicast : > http://www.multicasttech.com/mt/ From owner-ip-dvb@erg.abdn.ac.uk Sun Mar 9 12:30:17 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h29CTvew012933 for ; Sun, 9 Mar 2003 12:29:57 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h29CTuT6012932 for ip-dvb-subscribed-users; Sun, 9 Mar 2003 12:29:56 GMT Date: Sun, 9 Mar 2003 12:29:56 GMT Message-Id: <200303091229.h29CTuT6012932@mavis.erg.abdn.ac.uk> X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f From: Joerg Ott To: ip-dvb@erg.abdn.ac.uk Subject: Re: IP-DVB: Notes from Atlanta Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk X-MailScanner: Found to be clean I will be at the IETF but will have to leave on Wednesday at noon. If there is a chance to get together some time Monday or Tuesday in a small group (maybe for breakfast or so), I'd be interested. Joerg Dr G Fairhurst wrote: > No, no BoF this time either! > > So, what progress have we made? > > - First, I promise to rev. the ID on the encapsulation, and will do > a call for comments to see if there any more changes needed / desirable. > There has been a recent ESA ITT issued to do some implementation of > this scheme and evaluation in a real link. so that should help this. > > - I hope that people will start writing down their ideas on other > topics relating to security, MIBs, address resoltion, etc and prepare > for the next meeting in Vienna. I would like to see more than two IDs > so we can have a good range of topics and opinions.... > > - Finally I have been really busy since November, so some of the > lack of progress is my fault. I am sorry. > > If you will be at the IETF in San Francisco, I'd like to talk to > find out what your views / needs are.... Email me please. > > Gorry Fairhurst > > Marshall Eubanks wrote: > >>Will there be a meeting of this group in San Francisco ? If so, when ? >> >>On Friday, December 6, 2002, at 05:22 AM, Dr G Fairhurst wrote: >> >> >>>There was an unofficial meeting of people from the ip-dvb list at 5:30pm >>>after the IETF meeting on 20th November. >>> >>>Here's a brief summary of what was discussed. >>> >>>New encapsulation >>>----------------- >>>Discussion again about "why" this was needed? >>> - Was it processing efficiency in software? >>> - Was it to improve bandwidth utilisation? >>> - Was it to help standardise features? (add new features?) >>>All were true, but motivation depends heavily on the intended >>>application. >>>There were some plans to do pilot implementations in 2003. >>> >>>Simple configuration of clients >>>------------------------------- >>>"plug & play" . How could we make schemes for DVB/ATSC so >>>that were flexible and allowed IPv6 autoconfiguration? >>>- this implied the ability to do flexible IP address to PID >>>and TS-MUX mapping. >>> >>>There was some discussion of the recent draft from DVB >>>"ETSI EN drTS 102 00X V0.4.2 (2002-07) >>>Digital Video Broadcasting (DVB) >>>Specification for IP Notification in DVB Systems >>>Use of the IP/MAC Notification Table" >>> >>>- How general-purpose was this? >>>- Would it scale to large IP edge networks? >>>- How would it relate to the way IP multicast seemed >>> to be going (see discussions about the future of >>> multicast in mboned WG >>> & "draft-ietf-mboned-iesg-gap-analysis-00.txt") >>> >>>Unfortunately few people had access to this document, >>>since it is currently private to DVB members. >>> >>>Those who did have access to the document said they would look >>>at it and see what they thought. The current requirements >>>ID suggested three potential options: >>> >>>(i) Use the SI information for address resolution. >>>(ii) Provide an alternative mechanism at the IP-level >>> - similar to IPv6 ND? >>>(ii) Provide a complementary scheme at the IP-level >>> - similar to IPv6 ND, but able to import information >>> from SI tables (if able to). >>> >>>- Which should be done? - Why? >>> >>>The main challenge was to figure out what ELSE was necessary >>>to make the framework auto-configuartion flexible and >>>IP-friendly. >>> >>>Please send questions and answers on the list. >>> >>>Plans >>>----- >>>There is now some enthusiasm now to start work on this in 2003, >>>and several promises of contributions (IDs) have been received >>>by Gorry Fairhurst. When we get sufficient Internet Drafts >>>on the table, so we can start doing the real work! >>> >>>Afterwards we adjourned to the "Polaris" bar to literally watch the >>>world spin by... >>> >>>Gorry Fairhurst >>>ip-dvb mailing list. >>> >>> >> Regards >> Marshall Eubanks >> >>T.M. Eubanks >>Multicast Technologies, Inc. >>Phone : 703-293-9601 Fax : 703-293-9609 >>e-mail : tme@multicasttech.com >>http://www.multicasttech.com >> >> Our New Multicast Workshop : >> http://www.multicasttech.com/workshop >>Test your network for multicast : >>http://www.multicasttech.com/mt/ >> > From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 24 10:04:56 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h2OA4Gu9007589 for ; Mon, 24 Mar 2003 10:04:16 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h2OA4GgQ007588 for ip-dvb-subscribed-users; Mon, 24 Mar 2003 10:04:16 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from post.webmailer.de (natsmtp00.webmailer.de [192.67.198.74]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h2OA3eu9007560 for ; Mon, 24 Mar 2003 10:03:40 GMT Received: from news (Bc4de.pppool.de [213.7.196.222]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h2OA3d7S006013 for ; Mon, 24 Mar 2003 11:03:39 +0100 (MET) Message-ID: <000d01c2f1ec$0f5b1b00$dec407d5@dpiag.de> From: "Karsten Siebert" To: References: <3E3E9D13.FF8A70F1@erg.abdn.ac.uk> Subject: throughput improvements Date: Mon, 24 Mar 2003 10:59:13 +0100 Organization: data planet international AG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Are there any ISP reps in this list ? We would be interested in getting some information about IP packet length distribution in a standard Sat-ISP environment. We are currently investigating, where we can save some overhead bytes in the stream and encountered that it really makes sense only, if there are a lot of small packets (in terms of IP payload) in the distribution. (What for instance is the percentage of TCP acks in the Sat-link ?, large packets ?, medium size ?) Thanks, Karsten From owner-ip-dvb@erg.abdn.ac.uk Mon Mar 24 19:01:53 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h2OJ1Uu9016282 for ; Mon, 24 Mar 2003 19:01:30 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h2OJ1Tm8016281 for ip-dvb-subscribed-users; Mon, 24 Mar 2003 19:01:30 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mailscanner.cyberstar.com (gateway.cyberstar.com [209.239.66.36]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h2OJ12u9016267 for ; Mon, 24 Mar 2003 19:01:05 GMT Received: from dorado.cyberstar.com (dorado.cyberstar.com [144.14.246.27]) by mailscanner.cyberstar.com (8.11.6/8.11.6) with ESMTP id h2OKvVn21280 for ; Mon, 24 Mar 2003 20:57:31 GMT Received: by dorado.cyberstar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 14:05:12 -0500 Message-ID: <0557CD8F3528A44F9A812EFAE4AA60F214A374@Carina.cyberstar.com> From: "Clawson, Michael" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: RE: throughput improvements Date: Mon, 24 Mar 2003 13:51:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MailScanner: Found to be clean, Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I work for a satellite based ISP... Here is a snapshot of some data that may get you started. It's the CEF flow statistics of the traffic coming from three Cisco routers connecting to my upstream ISPs. This is for the traffic going toward the satellite links; I don't have data for the traffic coming back. These three represent about 150Megabits/second daily peak on a five minute average (MRTG). Hopefully you will find the packet size distribution data useful. ************************************************** ************************************************** ash-ccr-02#show ip cac flow IP packet size distribution (2709M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .001 .304 .053 .023 .068 .015 .013 .010 .007 .006 .004 .006 .006 .005 .004 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .004 .004 .260 .014 .185 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 9561 active, 55975 inactive, 222864669 added 418369334 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 923629 2.2 10 166 22.8 33.5 22.2 TCP-FTP 712871 1.7 2 72 4.3 4.7 20.5 TCP-FTPD 268984 0.6 22 690 14.7 37.8 22.0 TCP-WWW 137001562 332.8 11 581 3932.0 8.2 16.5 TCP-SMTP 7367835 17.9 16 410 295.3 17.8 15.3 TCP-X 3082 0.0 9 150 0.0 16.4 15.8 TCP-BGP 2304 0.0 101 119 0.5 165.4 20.8 TCP-NNTP 441047 1.0 11 220 11.9 35.1 22.4 TCP-Frag 1286 0.0 10 57 0.0 10.5 22.4 TCP-other 43566106 105.8 12 529 1302.6 18.1 19.7 UDP-DNS 3933340 9.5 2 95 25.5 4.5 22.3 UDP-NTP 53894 0.1 1 76 0.1 0.0 22.7 UDP-TFTP 271 0.0 2 83 0.0 1.9 20.7 UDP-Frag 3782 0.0 154 702 1.4 50.2 23.0 UDP-other 21151471 51.3 17 121 904.1 4.3 22.6 ICMP 7411758 18.0 3 69 61.8 4.3 22.9 IPINIP 1 0.0 4 104 0.0 3.0 18.3 GRE 284 0.0 538 133 0.3 141.5 22.8 IP-other 11601 0.0 78 409 2.1 168.1 21.8 Total: 222855108 541.4 12 491 6580.2 10.1 18.1 ************************************************** ************************************************** sjc-ccr-01#show ip cac flow IP packet size distribution (51329M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .002 .447 .126 .027 .020 .009 .008 .005 .005 .004 .003 .005 .004 .002 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .002 .002 .122 .014 .181 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 0 active, 65536 inactive, 65853 added 1282799 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 1818080 0.4 5 181 2.3 10.7 46.5 TCP-FTP 32756564 8.0 3 62 29.0 7.2 47.1 TCP-FTPD 1471307 0.3 158 924 57.5 81.5 36.8 TCP-WWW 1439655398 355.8 12 692 4613.1 11.4 44.6 TCP-SMTP 83482005 20.6 15 404 313.5 18.6 36.0 TCP-X 25771 0.0 15 397 0.0 25.9 49.3 TCP-BGP 662979 0.1 2 52 0.3 14.1 28.9 TCP-NNTP 222896 0.0 121 1185 6.6 38.5 43.2 TCP-Frag 51394 0.0 13 122 0.1 16.1 48.5 TCP-other 549602723 135.8 15 601 2085.6 22.3 44.7 UDP-DNS 143969611 35.5 3 87 112.5 5.6 46.3 UDP-NTP 2182971 0.5 1 76 0.6 11.2 35.4 UDP-TFTP 14978 0.0 2 80 0.0 3.2 57.2 UDP-Frag 106557 0.0 215 1112 5.6 38.7 46.7 UDP-other 622427117 153.8 33 74 5164.9 5.1 52.2 ICMP 185057663 45.7 3 132 180.8 9.8 47.8 IGMP 1356 0.0 4 649 0.0 1.4 30.5 IPINIP 4548 0.0 36 98 0.0 73.0 34.0 GRE 145331 0.0 1148 166 41.2 196.9 26.2 IP-other 1497987 0.3 191 306 70.8 88.6 29.3 Total: 3065157236 757.6 16 401 12685.4 11.9 46.2 ************************************************** ************************************************** sjc-ccr-02#show ip cac flow IP packet size distribution (36018M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .019 .285 .227 .029 .013 .007 .009 .005 .004 .004 .003 .004 .004 .002 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .002 .003 .155 .014 .202 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 5705 active, 59831 inactive, 1248335821 added 82873875 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 2207642 0.5 8 188 4.6 21.4 21.7 TCP-FTP 20858733 5.1 2 64 13.6 4.5 21.3 TCP-FTPD 1192435 0.2 83 982 24.5 46.9 16.7 TCP-WWW 1351276996 333.9 11 677 3905.8 8.7 15.7 TCP-SMTP 51001900 12.6 16 355 201.7 13.6 14.9 TCP-X 103459 0.0 16 632 0.4 16.8 19.2 TCP-BGP 355932 0.0 3 220 0.3 7.2 12.0 TCP-NNTP 932796 0.2 245 1451 56.6 29.5 22.3 TCP-Frag 45896 0.0 7 92 0.0 4.1 20.0 TCP-other 476041394 117.6 12 601 1490.6 16.6 19.4 UDP-DNS 73598583 18.1 6 80 112.8 3.6 22.5 UDP-NTP 1337752 0.3 1 76 0.3 1.3 22.2 UDP-TFTP 16659 0.0 2 54 0.0 3.1 18.9 UDP-Frag 73596 0.0 208 1188 3.7 33.7 21.5 UDP-other 574563013 141.9 19 69 2826.8 3.0 18.2 ICMP 94787331 23.4 9 113 222.2 4.8 22.6 IGMP 22 0.0 334 1388 0.0 54.7 23.8 IPINIP 23 0.0 707 104 0.0 736.1 13.9 GRE 68013 0.0 378 202 6.3 101.8 21.4 IP-other 659217 0.1 181 542 29.5 92.3 21.1 Total: 2649121392 654.6 13 446 8900.3 8.7 17.4 ************************************************** ************************************************** -----Original Message----- From: Karsten Siebert [mailto:Karsten.Siebert@sv-gmbh.de] Sent: Monday, March 24, 2003 4:59 AM To: ip-dvb@ERG.ABDN.AC.UK Subject: throughput improvements Are there any ISP reps in this list ? We would be interested in getting some information about IP packet length distribution in a standard Sat-ISP environment. We are currently investigating, where we can save some overhead bytes in the stream and encountered that it really makes sense only, if there are a lot of small packets (in terms of IP payload) in the distribution. (What for instance is the percentage of TCP acks in the Sat-link ?, large packets ?, medium size ?) Thanks, Karsten From owner-ip-dvb@erg.abdn.ac.uk Tue Mar 25 17:04:12 2003 Received: from mavis.erg.abdn.ac.uk (localhost [127.0.0.1]) by erg.abdn.ac.uk (8.12.8/8.12.8) with ESMTP id h2PH3gH9004393 for ; Tue, 25 Mar 2003 17:03:42 GMT Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.8/8.12.2/Submit) id h2PH3gZP004392 for ip-dvb-subscribed-users; Tue, 25 Mar 2003 17:03:42 GMT X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by erg.abdn.ac.uk (8.12.8/8.12.8) with SMTP id h2PH3CH9004365 for ; Tue, 25 Mar 2003 17:03:13 GMT Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 17:03:13 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B88750@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'ip-dvb@erg.abdn.ac.uk'" Subject: Adaptation field Date: Tue, 25 Mar 2003 17:03:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, I've just started looking ip-over-dvb and have a question about part of draft-clausen-ipdvb-enc-00.txt which I hope someone can answer. On page 10 there is a table showing the meaning of the PUSI and AFC bits in the TS packet header, followed by 2 paragraphs of explanation. The second paragraph says: " The TS Packet that carries the last byte of a SNDU MUST always have an adaptation field. In case this was the last SNDU (0/11 PUSI/AFC) the TS Packet is filled with stuffing bytes. In case another SNDU starts in this TS Packet, another 4-byte adaptation field is inserted before the next SNDU. " I think this means that the adaptation field is used as stuffing bytes when there are no more SNDUs, so there will be 184 - x bytes of stuffing where x is the length of the last part of the SNDU. Is this correct? If there is another SNDU does 'another 4-byte adaptation field' mean the one that is always carried or another one on top of that? In other words, do you get ________________ ____________ ______________ ... end of SNDU | adap field | next SNDU ... ________________ ____________ ______________ or ________________ ____________ ____________ _____________ ... end of SNDU | adap field | adap field | next SNDU... ________________ ____________ ____________ _____________ ? Thanks, Abbie Abbie Surtees Engineer Internet Applications and Mobility Roke Manor Research Ltd Tel: +44 (0) 1794 833131 Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary--