From fabrice.arnal at tesa.prd.fr  Wed Apr  3 14:54:40 2002
From: fabrice.arnal at tesa.prd.fr (Fabrice Arnal)
Date: Wed, 3 Apr 2002 15:54:40 +0200
Subject: IP over DVB-RCS
Message-ID: <003001c1db17$19fc4b20$1600a8c0@tesap261>

Hi everybody,
 
 
Something is not clear for me, with the DVB-RCS standard.
 
It is possible, for coding, to use either reed-solomon / convolutionnal
coding, either turbo-codes. But in specifications, it is possible not to
use MPEG-2 TS over DVB-RCS, whereas the (reed-solomon) redundancy is
well defined (trailer of the mpeg-2 TS packet). How can we do, for
coding, if we use for instance ATM cells ? Is some specific headers are
defined for this ? How can we use DVB-RCS without MPEG-2 TS about that?

 
 
 
With regards,
_______________________________________
 
Fabrice Arnal - Laboratoire T?SA 
2, rue Charles Camichel
BP 7122 - 31071 Toulouse Cedex 7 France
Tel : 05 61 58 80 15
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020403/a0b4eab5/attachment.html>

From Torsten.Jaekel at FTK.rohde-schwarz.com  Wed Apr  3 15:18:09 2002
From: Torsten.Jaekel at FTK.rohde-schwarz.com (Torsten.Jaekel at FTK.rohde-schwarz.com)
Date: Wed, 3 Apr 2002 16:18:09 +0200
Subject: Antwort: IP over DVB-RCS
Message-ID: <C1256B90.004E7AE4.00@mail.rohde-schwarz.com>



Hi,

I am not (yet) so familiar with RCS but a bit with ATM.
There are different ATM Adaption Layers (AAL). AAL5 (using jumbo frames) has
just a 32 bit CRC, no approaches for data integrity (issue of
higher layers).
But if you use AAL1 (I do not know if intended for RCS, perhaps because this is
also used for MPEG-2 via ATM),
there is an ATM based FEC algorythm (Reed Solomon), in addition to MPEG-2 FEC.

Is this similar to CableModems (DOCSIS) where the Uplink is also ATM-like ?

Best regards

Torsten

Torsten Jaekel
Product Marketing Datacasting
Rohde & Schwarz FTK GmbH
Wendenschlossstr. 168, Haus 28
12557 Berlin
Germany
Phone: +49 30 65 89 1 - 103
Mobile: +49 171 765 09 06
FAX: ? ? +49 30 65 55 02 21
email: Torsten.Jaekel at FTK.rohde-schwarz.com

|+-----------------------------+-----------------------------------------------|
||   "Fabrice Arnal"           |                                               |
||   <fabrice.arnal at tesa.prd.fr|   ? ? ? ? An: ? ? ? ?"Liste de diffusion IP / |
||   >                         |   DVB" <ip-dvb at erg.abdn.ac.uk>                |
||                             |   ? ? ? ? Kopie: ? ? ? ?(Blindkopie: Torsten  |
||   03.04.2002 15:54          |   Jaekel/FTK)                                 |
||   Bitte antworten an ip-dvb |   ? ? ? ? Thema: ? ? ? ?IP over DVB-RCS       |
||                             |                                               |
|+-----------------------------+-----------------------------------------------|






Hi everybody,


Something is not clear for me, with the DVB-RCS standard.

It is possible, for coding, to use either reed-solomon / convolutionnal coding,
either turbo-codes. But in specifications, it is possible not to use MPEG-2 TS
over DVB-RCS, whereas the (reed-solomon) redundancy is well defined (trailer of
the mpeg-2 TS packet). How can we do, for coding, if we use for instance ATM
cells ? Is some specific headers are defined for this ? How can we use DVB-RCS
without MPEG-2 TS about that?



With regards,
_______________________________________

Fabrice Arnal - Laboratoire T?SA
2, rue Charles Camichel
BP 7122 - 31071 Toulouse Cedex 7 France
Tel : 05 61 58 80 15









From l.wood at eim.surrey.ac.uk  Wed Apr  3 15:47:45 2002
From: l.wood at eim.surrey.ac.uk (Lloyd Wood)
Date: Wed, 3 Apr 2002 15:47:45 +0100 (BST)
Subject: Antwort: IP over DVB-RCS
In-Reply-To: <C1256B90.004E7AE4.00@mail.rohde-schwarz.com>
Message-ID: <Pine.SOL.4.43.0204031547040.1192-100000@phaestos.ee.surrey.ac.uk>

On Wed, 3 Apr 2002 Torsten.Jaekel at FTK.rohde-schwarz.com wrote:

> I am not (yet) so familiar with RCS but a bit with ATM.
> There are different ATM Adaption Layers (AAL). AAL5 (using jumbo frames) has
> just a 32 bit CRC, no approaches for data integrity (issue of
> higher layers).

??? that's what the 32-bit CRC is for...

L.

> But if you use AAL1 (I do not know if intended for RCS, perhaps because this is
> also used for MPEG-2 via ATM),
> there is an ATM based FEC algorythm (Reed Solomon), in addition to MPEG-2 FEC.
>
> Is this similar to CableModems (DOCSIS) where the Uplink is also ATM-like ?

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>



From adrian.tregunna at bt.com  Wed Apr  3 17:10:22 2002
From: adrian.tregunna at bt.com (adrian.tregunna at bt.com)
Date: Wed, 3 Apr 2002 17:10:22 +0100 
Subject: IP over DVB-RCS
Message-ID: <E1CFE3957BE0D211A9230000F8FE9A81091D2207@mrgmexnt02.mww.bt.com>

Hi,
 
The RS and convolutional coding is added to the MPEG TS as part of the
modulation process within the DVB-RCS compliant satellite modulator. The
additional overhead for convolutional encoding is added, along with the
interleaving and additional RS bits. This is separate from the MPEG-TS and
is purely done on a byte-by-byte (bit-by-bit?!) basis.
 
This will be the same with ATM cells - the string of 0's and 1's is encoded
with convolutional and then RS coding. At the receiver, the incoming signal
is demodulated, the RS is removed and de-interleaved, then the convolutional
decoder ideally recovers the same string of bits that went into the
modulator.
 
It does not matter to the satellite modems if the incoming string of bits
are part of an MPEG-TS or a series of ATM cells.
 
The same is true for turbo codes, although the coding is a single step.
 
Hope this is of some help?
 
Adrian.

Manager: Satellite System Engineering 
BT Ignite, B&SC - Satellite System Development 
 
This electronic message contains information from British Telecommunications
plc which may be privileged and confidential. The information is intended to
be for the  use of the individual(s) or entity named above. If you are not
the intended recipient, be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
e-mail (to the number or address above) immediately.

-----Original Message-----
From: Fabrice Arnal [mailto:fabrice.arnal at tesa.prd.fr]
Sent: 03 April 2002 14:55
To: Liste de diffusion IP / DVB
Subject: IP over DVB-RCS


Hi everybody,
 
 
Something is not clear for me, with the DVB-RCS standard.
 
It is possible, for coding, to use either reed-solomon / convolutionnal
coding, either turbo-codes. But in specifications, it is possible not to use
MPEG-2 TS over DVB-RCS, whereas the (reed-solomon) redundancy is well
defined (trailer of the mpeg-2 TS packet). How can we do, for coding, if we
use for instance ATM cells ? Is some specific headers are defined for this ?
How can we use DVB-RCS without MPEG-2 TS about that?  
 
 
 
With regards,
_______________________________________
 
Fabrice Arnal - Laboratoire T?SA 
2, rue Charles Camichel
BP 7122 - 31071 Toulouse Cedex 7 France
Tel : 05 61 58 80 15
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020403/1e14140a/attachment.html>

From Torsten.Jaekel at FTK.rohde-schwarz.com  Thu Apr  4 08:30:53 2002
From: Torsten.Jaekel at FTK.rohde-schwarz.com (Torsten.Jaekel at FTK.rohde-schwarz.com)
Date: Thu, 4 Apr 2002 09:30:53 +0200
Subject: Antwort: Re: Antwort: IP over DVB-RCS
Message-ID: <C1256B91.00293174.00@mail.rohde-schwarz.com>



The 32 bit CRC is just used to recognize transmission (packet) errors. No way to
correct missing or incorrect bits (is not a redundancy
part or Reed Solomon code). The whole packet (many ATM cells) is discarded if
the CRC is not matching.

tj
|+----------------+-------------------------------------|
||   Lloyd Wood   |                                     |
||   <l.wood at eim.s|   ? ? ? ? An:                       |
||   urrey.ac.uk> |   ip-dvb at erg.abdn.ac.uk             |
||                |   ? ? ? ? Kopie: ? ? ? ?(Blindkopie:|
||   03.04.2002   |   Torsten Jaekel/FTK)               |
||   16:47        |   ? ? ? ? Thema: ? ? ? ?Re: Antwort:|
||   Bitte        |   IP over DVB-RCS                   |
||   antworten an |                                     |
||   ip-dvb       |                                     |
||                |                                     |
|+----------------+-------------------------------------|







On Wed, 3 Apr 2002 Torsten.Jaekel at FTK.rohde-schwarz.com wrote:

> I am not (yet) so familiar with RCS but a bit with ATM.
> There are different ATM Adaption Layers (AAL). AAL5 (using jumbo frames) has
> just a 32 bit CRC, no approaches for data integrity (issue of
> higher layers).

??? that's what the 32-bit CRC is for...

L.

> But if you use AAL1 (I do not know if intended for RCS, perhaps because this
is
> also used for MPEG-2 via ATM),
> there is an ATM based FEC algorythm (Reed Solomon), in addition to MPEG-2 FEC.
>
> Is this similar to CableModems (DOCSIS) where the Uplink is also ATM-like ?

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>










From fabrice.arnal at tesa.prd.fr  Thu Apr  4 12:45:00 2002
From: fabrice.arnal at tesa.prd.fr (Fabrice Arnal)
Date: Thu, 4 Apr 2002 13:45:00 +0200
Subject: IP over DVB-RCS
In-Reply-To: <E1CFE3957BE0D211A9230000F8FE9A81091D2207@mrgmexnt02.mww.bt.com>
Message-ID: <000d01c1dbce$26d9abf0$1600a8c0@tesap261>

Ok, I think it's clear now. 
 
But I believe that in the coding scheme, Reed-Solomon is done first, and
then the convolutional instead..  
 
 
Regarding the IP over DVB requirements draft (by Gorry Fairhurst),
MPEG-2 TS layer is, in any case, present. That's why I am surprised..
 

 Fabrice. 

Hi,
 
The RS and convolutional coding is added to the MPEG TS as part of the
modulation process within the DVB-RCS compliant satellite modulator. The
additional overhead for convolutional encoding is added, along with the
interleaving and additional RS bits. This is separate from the MPEG-TS
and is purely done on a byte-by-byte (bit-by-bit?!) basis.
 
This will be the same with ATM cells - the string of 0's and 1's is
encoded with convolutional and then RS coding. At the receiver, the
incoming signal is demodulated, the RS is removed and de-interleaved,
then the convolutional decoder ideally recovers the same string of bits
that went into the modulator.
 
It does not matter to the satellite modems if the incoming string of
bits are part of an MPEG-TS or a series of ATM cells.
 
The same is true for turbo codes, although the coding is a single step.
 
Hope this is of some help?
 
Adrian.

Manager: Satellite System Engineering 
BT Ignite, B&SC - Satellite System Development 
 
This electronic message contains information from British
Telecommunications plc which may be privileged and confidential. The
information is intended to be for the  use of the individual(s) or
entity named above. If you are not the intended recipient, be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or e-mail (to the number or
address above) immediately.

-----Original Message-----
From: Fabrice Arnal [mailto:fabrice.arnal at tesa.prd.fr]
Sent: 03 April 2002 14:55
To: Liste de diffusion IP / DVB
Subject: IP over DVB-RCS


Hi everybody,
 
 
Something is not clear for me, with the DVB-RCS standard.
 
It is possible, for coding, to use either reed-solomon / convolutionnal
coding, either turbo-codes. But in specifications, it is possible not to
use MPEG-2 TS over DVB-RCS, whereas the (reed-solomon) redundancy is
well defined (trailer of the mpeg-2 TS packet). How can we do, for
coding, if we use for instance ATM cells ? Is some specific headers are
defined for this ? How can we use DVB-RCS without MPEG-2 TS about that?

 
 
 
With regards,
_______________________________________
 
Fabrice Arnal - Laboratoire T?SA 
2, rue Charles Camichel
BP 7122 - 31071 Toulouse Cedex 7 France
Tel : 05 61 58 80 15
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020404/c335b3ae/attachment.html>

From l.wood at eim.surrey.ac.uk  Thu Apr  4 12:48:15 2002
From: l.wood at eim.surrey.ac.uk (Lloyd Wood)
Date: Thu, 4 Apr 2002 12:48:15 +0100 (BST)
Subject: Antwort: Re: Antwort: IP over DVB-RCS
In-Reply-To: <C1256B91.00293174.00@mail.rohde-schwarz.com>
Message-ID: <Pine.SOL.4.43.0204041233580.2905-100000@phaestos.ee.surrey.ac.uk>

On Thu, 4 Apr 2002 Torsten.Jaekel at FTK.rohde-schwarz.com wrote:

> The 32 bit CRC is just used to recognize transmission (packet) errors. No way to
> correct missing or incorrect bits (is not a redundancy
> part or Reed Solomon code). The whole packet (many ATM cells) is discarded if
> the CRC is not matching.

data integrity is ensured by discards and retransmission.

limited amounts of redundancy or FEC can't guarantee data integrity,
though they can increase its likelihood.

L.

> On Wed, 3 Apr 2002 Torsten.Jaekel at FTK.rohde-schwarz.com wrote:
>
> > I am not (yet) so familiar with RCS but a bit with ATM.
> > There are different ATM Adaption Layers (AAL). AAL5 (using jumbo frames) has
> > just a 32 bit CRC, no approaches for data integrity (issue of
> > higher layers).
>
> ??? that's what the 32-bit CRC is for...
>
> > But if you use AAL1 (I do not know if intended for RCS, perhaps because this
> is
> > also used for MPEG-2 via ATM),
> > there is an ATM based FEC algorythm (Reed Solomon), in addition to MPEG-2 FEC.
> >
> > Is this similar to CableModems (DOCSIS) where the Uplink is also ATM-like ?

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>




From gorry at erg.abdn.ac.uk  Thu Apr 11 12:17:40 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Thu, 11 Apr 2002 12:17:40 +0100
Subject: For Your info: ATSC A92
Message-ID: <3CB570D4.1290C716@erg.abdn.ac.uk>

I thought it would be useful to draw to our attention the
recent addition of ATSC A92 - dealing with IP  multicas,
although the document seems only to address IPv4, and only
addresses use of DSMCC.

Comments on relevance or otherwise and technical issues
will be welcome.

Gorry

I have uploaded a recent ATSC document for reference.

http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/refs/

---

ATSC Standard: A92
Delivery of IP Multicast Sessions over ATSC Data Broadcast
31 January 2002

This standard specifies the delivery of IP Multicast sessions, the delivery
of data for describing the characteristics of a session, and usage of the
ATSC A/90 Data Broadcast Standard for IP Multicast.

This document defines a Standard for the asynchronous transmission of
Internet Protocols (IP) specifically including multicast addressing
compatible with the ATSC A/90 Data Broadcast Standard. This Standard assumes
the use of Session Description Protocol (SDP) as an integral
part of the IP Multicast-based Data Broadcast service. It is strongly
suggested that normative clauses that do not directly involve SDP be
retained in the case of IP Multicast-based Data Broadcast services that do
not include any SDP data, such as would be used for non-sessionbased IP
Multicast. This document focuses solely on the carriage of all information
using the DSMCC_addressable_section. Synchronous and synchronized carriage
of IP Multicast datagrams are not addressed by this document.


From Stephane.Combes at space.alcatel.fr  Thu Apr 11 12:54:38 2002
From: Stephane.Combes at space.alcatel.fr (Stephane.Combes at space.alcatel.fr)
Date: Thu, 11 Apr 2002 13:54:38 +0200
Subject: Alcatel Space interest about IP/DVB
Message-ID: <C1256B98.004199D3.00@vzmta01.netfr.alcatel.fr>



Dear colleagues,

Alcatel Space Industries would like to support the work currently undertaken by
this group.

As requested by Gorry Fairhurst, here follows a draft of the presentation we
could make at the next BOF :
(See attached file: Alcatel_space_IP_DVB_view01.pdf)
Note that this document is informational only but can be distributed freely to
anybody interested.

The general issues raised here seem to align with those expressed in
http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/charter.html and
http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ipdvb-req-00.doc

It includes our vision for MPE enhancement. We would actually be very interested
if the to-be-defined encapsulation could support protocols other than IPv4 and
v6. Ethernet and MPLS are of equal importance according to the network segment
the DVB (or other MPEG-2 based) links are deployed. It would be nice if a future
RFC could have the same role than ITU-T I.363.5 (AAL5) and RFC-2684
(Multiprotocol encapsulation) have in the ATM world.

It also details some Layer 2 labelling management procedures that we have
developed in the frame of the BRAHMS IST project. This is perhaps more targetted
to a MPE "replacement". It actually includes a label distribution protocol
(working in a similar way as Ethernet ARP) and associated encapsulation
optimised for the broadcast nature of satellites (and thefore DVB) links. Such
kind of protocol could well play for broadcast links the same role than MPLS in
backbone networks.

The main ideas behind this proposed scheme are in line with the questions about
a possible "native IP" support that Gorry raised in his 03/25 e-mail. PID would
indeed only be a first level of filtering at receivers. IP filtering would then
be based on IP destination address. An additional label at layer 2, identifying
the source of the IP flow, could help avoiding to re-assemble all the IP traffic
received on a given PID (and allow proper re-assembly if packets are mixed by a
satellite on-board processor). Therefore a limited link layer header might still
be useful. The other characteristics of our scheme is that it naturally supports
multiple feeds configurations, two-way satellite links and on-board processing
(no more multisource multicast headaches !)

You'll find more details about BRAHMS project at
http://brahms.telecomitalialab.com/. There was also a paper published at last
year's AIAA conference ("IP Dedicated : a new Internet oriented satellite
transfer scheme", I. Buret et al., 19th AIAA ICSSC conference, april 2001).
Note that some outputs of the BRAHMS project have already been presented at the
ETSI BSM. Actually, the same presentation which is included here is being sent
to the ETSI BSM mailing-list.

Feel free to share comments on this list,
Best Regards,

St?phane COMBES


ALCATEL SPACE INDUSTRIES
Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alcatel_space_IP_DVB_view01.pdf
Type: application/pdf
Size: 254789 bytes
Desc: Adobe Portable Document
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020411/cda99990/attachment.pdf>

From NChu at GI.com  Thu Apr 11 13:07:28 2002
From: NChu at GI.com (Chu, Narisa (HT-EX))
Date: Thu, 11 Apr 2002 08:07:28 -0400
Subject: For Your info: ATSC A92
Message-ID: <B0552F533A3BA54BAA9BE6244A1E6A5D02F9E4BD@pa06xchm2.gic.gi.com>

The Motorola Proposal and ATSC A92 are very much in synch because we have
worked through the North American Standards Committees (SCTE and ATSC) on
the IP over DVB (MPEG) MAC_address_list descriptor. Motorola is in the
process of writing a few use cases to facilitate discussions within DVB-GBS,
to reflect different scenarios of data usage in MPEG: be it video associated
or non-associated, as mentioned in my Requirements Presentation last July in
DVB (which is also on your website.) The chair of DVB-GBS also suggested to
invite you for a joint meeting or some sort. (I am acting like a liaison,
reflector-based only, between GBS and IETF at the moment, I guess.)

We are contemplating additions of IPv6 and subnetwork address capability to
the MAC_address_list descriptor and tables. Any stimulating discussions will
be welcome!

Best regards,
Narisa Chu
Motorola Broadband

 -----Original Message-----
From: 	Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] 
Sent:	Thursday, April 11, 2002 7:18 AM
To:	ip-dvb at erg.abdn.ac.uk
Subject:	For Your info: ATSC A92

I thought it would be useful to draw to our attention the
recent addition of ATSC A92 - dealing with IP  multicas,
although the document seems only to address IPv4, and only
addresses use of DSMCC.

Comments on relevance or otherwise and technical issues
will be welcome.

Gorry

I have uploaded a recent ATSC document for reference.

http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/refs/

---

ATSC Standard: A92
Delivery of IP Multicast Sessions over ATSC Data Broadcast
31 January 2002

This standard specifies the delivery of IP Multicast sessions, the delivery
of data for describing the characteristics of a session, and usage of the
ATSC A/90 Data Broadcast Standard for IP Multicast.

This document defines a Standard for the asynchronous transmission of
Internet Protocols (IP) specifically including multicast addressing
compatible with the ATSC A/90 Data Broadcast Standard. This Standard assumes
the use of Session Description Protocol (SDP) as an integral
part of the IP Multicast-based Data Broadcast service. It is strongly
suggested that normative clauses that do not directly involve SDP be
retained in the case of IP Multicast-based Data Broadcast services that do
not include any SDP data, such as would be used for non-sessionbased IP
Multicast. This document focuses solely on the carriage of all information
using the DSMCC_addressable_section. Synchronous and synchronized carriage
of IP Multicast datagrams are not addressed by this document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020411/a5fcdfac/attachment.html>

From juha-pekka.luoma at nokia.com  Thu Apr 11 13:18:13 2002
From: juha-pekka.luoma at nokia.com (juha-pekka.luoma at nokia.com)
Date: Thu, 11 Apr 2002 15:18:13 +0300
Subject: IP-CC Requirement Specification - release 2
Message-ID: <481D6FFB3BD60E4CB590F39C59098400DAA031@trebe004.NOE.Nokia.com>

Hi all,

Please find attached the latest release of our IP-CC requirements specification, which has also been published as SI-DAT 621R2 in the DVB-GBS working group.

This may be interesting for those considering how to discover IP services in DVB systems. Comments and questions are welcome.

Best regards,

Juha-Pekka Luoma
Communication Systems
Nokia Research Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 621_r2.pdf
Type: application/octet-stream
Size: 76847 bytes
Desc: 621_r2.pdf
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020411/106fc3d4/attachment.obj>

From clausen at cosy.sbg.ac.at  Mon Apr 15 04:28:08 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Sun, 14 Apr 2002 20:28:08 -0700
Subject: Alcatel Space interest about IP/DVB
References: <C1256B98.004199D3.00@vzmta01.netfr.alcatel.fr>
Message-ID: <004b01c1e42d$900480c0$79068a81@nmttb97i6f89th>

Hello St?phane ,

in your presentation you are using the term "Ethernet-like stack". Could
yopu, please, explain what you mean exactly under this term.
The MPEG system as defined by 13818-1 has only two layers:
* the lowest being the Transport Stream Multiplex
* the upper one being the Elementary Packet Stream, PES packets and PSI
Sections
there is no physical layer - this is provided e.g. by DVB-S

Comparing this to data networks is not very obvious. The closest might be to
look at ATM - the MPEG Transport Stream packets are somewhow similar to ATM
cells - however with the big difference that the ATM cell header specifies a
point-to-point connection with the VC/CP field whereas the PID in the TS
packet specifies a broadcast channel.

The next layer in MPEG can be interpreted as either a link- or
network-level - similar to AAL5 for example although there is no  concept of
an "address" in either Sections or PES packets. If we define a new
encapsulation we could certainly include a "label" or similar discriminator
field in the encapsulation - but unless this is bound to a PID either in
one-to-one way or by including the label field in every TS packet - for
example in an adaptation field - then filtering can only be done after the
reassembly if the encapsulated packet (IPv4, IPv6, any other network or link
layer packet).

As I tried to point out in my recent pontification about addresses -
Ethernet MAC addresses are a combination of a physical-level address and a
network-level address and are not very good examples for other types of
networks.

> Alcatel Space Industries would like to support the work currently
undertaken by
> this group.
...

> We would actually be very interested if the to-be-defined encapsulation
> could support protocols other than IPv4 and v6. Ethernet and MPLS
> are of equal importance according to the network segment the DVB
> (or other MPEG-2 based) links are deployed.
This is definitely intended - ther is no reason why we could not follow the
PPP strategy and carry any type of content.

> It would be nice if a future
> RFC could have the same role than ITU-T I.363.5 (AAL5) and RFC-2684
> (Multiprotocol encapsulation) have in the ATM world.

yes - agree; but it will be difficult to replace an existing solution (MPE)
unless we look at future systems.

> It also details some Layer 2 labelling management procedures that we have
> developed in the frame of the BRAHMS IST project. This is perhaps more
targetted
> to a MPE "replacement". It actually includes a label distribution protocol
> (working in a similar way as Ethernet ARP) and associated encapsulation
> optimised for the broadcast nature of satellites (and thefore DVB) links.
Such
> kind of protocol could well play for broadcast links the same role than
MPLS in
> backbone networks.

I have some difficulties here: MPLS and other label-based systems use this
for "switching". Of course, one could build some sort of switches into a
MPEG-TS system - in a very crude way an MPEG re-mux does this.
If we consider this, then this "label" must be included in the TS-packet,
preferably in an adaptation field and "as far to the left" as possible since
hardware filtering scans from the left (this is the reason why MPE puts
the rightmost byte of the MAC address first into the encapsulation header).

If you need to swithc AND the PID space is not sufficient you need to
introduce a "label" - but then you need to decide whether you want to put
it into each TS packet or you reassemble a complete SNDU (?). It all
depends on your system architecture and applications.


> The main ideas behind this proposed scheme are in line with the questions
about
> a possible "native IP" support that Gorry raised in his 03/25 e-mail. PID
would
> indeed only be a first level of filtering at receivers. IP filtering would
then
> be based on IP destination address. An additional label at layer 2,
identifying
> the source of the IP flow, could help avoiding to re-assemble all the IP
traffic
> received on a given PID (and allow proper re-assembly if packets are mixed
by a
> satellite on-board processor).

yes - but see my comment above

> Therefore a limited link layer header might still
> be useful.

yes - I agree. But whatever we propose - we MUST stay within the
confimenents of the MPEG standards. Luckily they are quite liberal when it
comes to "private" data.

> The other characteristics of our scheme is that it naturally supports
> multiple feeds configurations, two-way satellite links and on-board
processing
> (no more multisource multicast headaches !)

> Feel free to share comments on this list,

Looking forward to some interesting discussion,

--Horst Clausen

> Best Regards,

> St?phane COMBES





From Ghassane.Aniba at sophia.inria.fr  Mon Apr 15 15:15:47 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Mon, 15 Apr 2002 16:15:47 +0200
Subject: The DULM messages?
References: <C1256B81.00267494.00@mail.rohde-schwarz.com>
Message-ID: <3CBAE093.16CF9703@sophia.inria.fr>

Hi every body,
I've read the "DVB-RCS001rev14(03April2000)", and i read about the
DULM(Data Umit Labelling Method) in page 28. i found the diffents type
of E(Information Elements) in page 31. 
I want to know if the IE types from 0x0E to 0x10 are free or not?
because there is nothing besides (nor private nor reserved)
thank you for your help.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Mon Apr 15 18:18:56 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 15 Apr 2002 18:18:56 +0100
Subject: Suggestions for DVB-TM liason.
Message-ID: <3CBB0B83.4BDB7140@erg.abdn.ac.uk>


Andrew Vlaentine provided the Liason between this mailing list and the
DVB-TM, since he left his role in DVB, this has left a "gap" which needs to
be filled. It was always the intention that the list would work with (rather
than in competition with) the DVB-TM to develop good common standards. As
we start to discuss issues and propose new documents, this liason will become
very important.

Is there anybody, to your knowledge, who may be a suitable person/people
to 
do this? 

Please send comments to the list or recommendations in a private email to:
Gorry at erg.abdn.ac.uk

gorry


From NChu at GI.com  Mon Apr 15 18:55:05 2002
From: NChu at GI.com (Chu, Narisa (HT-EX))
Date: Mon, 15 Apr 2002 13:55:05 -0400
Subject: Suggestions for DVB-TM liason.
Message-ID: <B0552F533A3BA54BAA9BE6244A1E6A5D02F9E4D2@pa06xchm2.gic.gi.com>

Dear Gorry:

I have sort of consented to Ulrich Reimers' note, during the last DVB-TM
meeting, to notify him if there is a need to correspond with your group. I
attend, on the average, every other DVB-TM meetings. However, I work very
closely with the DVB-GBS group where IP over DVB is being specified and
monitors your reflector all the time. If this is not adequate, please don't
hesitate to accept other more generous offer from the IETF group.

Narisa Chu
Motorola Broadband

 -----Original Message-----
From: 	Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] 
Sent:	Monday, April 15, 2002 1:19 PM
To:	ip-dvb at erg.abdn.ac.uk
Subject:	Suggestions for DVB-TM liason.


Andrew Vlaentine provided the Liason between this mailing list and the
DVB-TM, since he left his role in DVB, this has left a "gap" which needs to
be filled. It was always the intention that the list would work with (rather
than in competition with) the DVB-TM to develop good common standards. As
we start to discuss issues and propose new documents, this liason will
become
very important.

Is there anybody, to your knowledge, who may be a suitable person/people
to 
do this? 

Please send comments to the list or recommendations in a private email to:
Gorry at erg.abdn.ac.uk

gorry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20020415/c013e38c/attachment.html>

From Stephane.Combes at space.alcatel.fr  Tue Apr 16 14:53:08 2002
From: Stephane.Combes at space.alcatel.fr (Stephane.Combes at space.alcatel.fr)
Date: Tue, 16 Apr 2002 15:53:08 +0200
Subject: =?iso-8859-1?Q?R=E9f._:_Re:_Alcatel_Space_interest_about_IP/DVB?=
Message-ID: <C1256B9D.004C59CA.00@vzmta01.netfr.alcatel.fr>


Hi Horst,

Thanks a lot for your reviewing and comments !

By "Ethernet-like" we only mean "connectionless layer 2 based on broadcast
medium". Nevertheless we do not propose to re-use the addressing scheme of
Ethernet. As I said in my previous e-mail, using a label uniquely identifying a
"source" in a "subnet" may be enough and much more flexible for the systems we
target.

MPEG-2 layer would indeed be seen like ATM layer where PID would bear a
significance analogous to the VPI (aggregation of flows - but here from
different sources and towards several destinations - , first level of
filtering).
 It would indeed be very nice if a new link layer protocol could be transported
seamlessly over MPEG and ATM (very interesting for DVB-RCS systems which use
MPEG as forward link and ATM as return or mesh link).
The filtering performed at the level of this new link layer on top of MPEG would
be similar to MPE filtering (we do not need to have the MPE address in each TS
packet), at least for Gateway Terminals transmission (if we consider Gateways do
not share the same PID for emission). For user Satellite Terminals (sharing a
DVB-RCS access for instance), the additional label would indeed be included in
each TS (if we consider several such terminals share the same PID for emision).

As far as switching is concerned, only the PID would be used for such a purpose
(not the additional link layer label). For example, we could have a MPEG switch
on-board the satellite. And in such a case, we are very very limited by the PID
numbering space. Therefore this additional label would be needed.

So I guess we basically agree with you that Ethernet addressing is not the ideal
solution for networks other than Ethernet. But such proposal for a complete "MPE
replacement" (although trying to keep a similar filtering and re-assembly
process) would indeed only be justified for new systems. We propose to explore
this for multiple-feeds and "mesh" capable systems (allowing direct
terminal-to-terminal communication).

Does this clarify our requirements ?

Cheers,

St?phane

ALCATEL SPACE INDUSTRIES
Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr





From Stephane.Combes at space.alcatel.fr  Tue Apr 16 15:26:33 2002
From: Stephane.Combes at space.alcatel.fr (Stephane.Combes at space.alcatel.fr)
Date: Tue, 16 Apr 2002 16:26:33 +0200
Subject: =?iso-8859-1?Q?R=E9f._:_The_DULM_messages=3F?=
Message-ID: <C1256B9D.004F6B43.00@vzmta01.netfr.alcatel.fr>



Hi,

0x0E to 0x1E are reserved. Some of them will probably be used in subsequent
versions of the standard.
cheers,

St?phane





Ghassane Aniba <Ghassane.Aniba at sophia.inria.fr> on 15/04/2002 16:15:47

Veuillez r?pondre ? ip-dvb at erg.abdn.ac.uk

Pour :    ip-dvb at erg.abdn.ac.uk
cc :   (ccc : Stephane Combes/ALCATEL-SPACE)
Objet :   The DULM messages?


-------------- next part --------------

Hi every body,
I've read the "DVB-RCS001rev14(03April2000)", and i read about the
DULM(Data Umit Labelling Method) in page 28. i found the diffents type
of E(Information Elements) in page 31.
I want to know if the IE types from 0x0E to 0x10 are free or not?
because there is nothing besides (nor private nor reserved)
thank you for your help.

--
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78









      ALCATEL SPACE INDUSTRIES
      Research Department/Advanced Telecom Satellite Systems
      Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
      Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr


From Ghassane.Aniba at sophia.inria.fr  Tue Apr 16 15:54:36 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 16 Apr 2002 16:54:36 +0200
Subject: =?iso-8859-1?Q?R=E9f=2E?= : The DULM messages?
References: <C1256B9D.004F6B43.00@vzmta01.netfr.alcatel.fr>
Message-ID: <3CBC3B2C.A775FC69@sophia.inria.fr>

Hi every body,
i ask just for types between 0x0E and 0x10.
I want to propose a use of them in the IP over DVB.
Thanks again :).

Stephane.Combes at space.alcatel.fr wrote:
> 
> Hi,
> 
> 0x0E to 0x1E are reserved. Some of them will probably be used in subsequent
> versions of the standard.
> cheers,
> 
> St?phane


------------------------------ 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78



From clausen at cosy.sbg.ac.at  Wed Apr 17 05:27:10 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Tue, 16 Apr 2002 21:27:10 -0700
Subject: =?iso-8859-1?Q?Re:_R=E9f._:_Re:_Alcatel_Space_interest_about_IP/DVB?=
References: <C1256B9D.004C59CA.00@vzmta01.netfr.alcatel.fr>
Message-ID: <009401c1e5c8$27209070$79068a81@nmttb97i6f89th>

Hello St?phane>
> Thanks a lot for your reviewing and comments !
>
let's keep the discussion cooking!
> By "Ethernet-like" we only mean "connectionless layer 2 based on broadcast
> medium".
Question - why does it have to be connectionless?
Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
particulatr multicast applications are based on the concept of a session. If
you "tune" your receiver to a PID you are basically opening a session - so
why wouild you like to have the next higher layer (link/encapsulation)
connection-less?

> Nevertheless we do not propose to re-use the addressing scheme of
> Ethernet.
I found it pretty interesting that the ATSC people renamed this thing a
device-ID - that is a pretty correct name for the thing. If in the future we
go to 64-bit exteded IEEE MAC-deviceIDs then we can use this thing for
authentication and authorization, for example on the Return Channel System
when a station becomes active. But once we assigned a "label" to this
connection or multicast stream whihc the station joined, ther is absolutely
no need to include the deviceID in every packet.

> As I said in my previous e-mail, using a label uniquely identifying a
> "source" in a "subnet" may be enough and much more flexible for the
systems we
> target.
agree
>
> MPEG-2 layer would indeed be seen like ATM layer where PID would bear a
> significance analogous to the VPI (aggregation of flows - but here from
> different sources and towards several destinations - , first level of
> filtering).
>  It would indeed be very nice if a new link layer protocol could be
transported
> seamlessly over MPEG and ATM (very interesting for DVB-RCS systems which
use
> MPEG as forward link and ATM as return or mesh link).
> The filtering performed at the level of this new link layer on top of MPEG
would
> be similar to MPE filtering (we do not need to have the MPE address in
each TS
> packet), at least for Gateway Terminals transmission (if we consider
Gateways do
> not share the same PID for emission).
I am sure we can come up with a more efficient link-layer encapsulation. The
proposal we have submitted is still very close to the audio/video (PES) and
table section (PSI) of MPEG-2. I read the standard many times - well, at
least those parts that refer to "private" data and I come to the conclusion
that the people who wrote this standard have been very nice to future "data"
applications. They did not address the Internet at that time but they left a
lot of freedom in the standard and one could come up with a much more
radical approach.
Just as an example: the semantics of the PUSI bit is left totally
unspecified for private data; hence we could do the same thing as the AAL5
people did and flag the end instead of the start of a packet. However, I am
not so sure how some of the "standard" IRDs would react to TS packets of
this type?
It also seems to me that the AFC bits could be re-interpreted for private
data streams in a different way.
I hope we will get some expert opinions on this in this group.
And I wouild be jut soo glad to get inputs from the DVB and ATSC folks!

> For user Satellite Terminals (sharing a
> DVB-RCS access for instance), the additional label would indeed be
included in
> each TS (if we consider several such terminals share the same PID for
emision).
>
yes - agree. One question that arises is - do we have a separate
encapsulation for teh forward and the return links or should only one be
proposed which can handle the differences in a hidden "convergence" layer?

> As far as switching is concerned, only the PID would be used for such a
purpose
> (not the additional link layer label). For example, we could have a MPEG
switch
> on-board the satellite. And in such a case, we are very very limited by
the PID
> numbering space. Therefore this additional label would be needed.
>
the PID number space is not this small if you use each PID as a broadcast
network and not as a point-to-point  link. If you have spot beams you wouild
have to assign (at least o ne) PID to each spot and switch onboard on the
PID only - and leave the filtering to the "gateway" and the link layer.

> So I guess we basically agree with you that Ethernet addressing is not the
ideal
> solution for networks other than Ethernet. But such proposal for a
complete "MPE
> replacement" (although trying to keep a similar filtering and re-assembly
> process) would indeed only be justified for new systems. We propose to
explore
> this for multiple-feeds and "mesh" capable systems (allowing direct
> terminal-to-terminal communication).
>
I think what we are looking for in this group is a long-term "New and
Efficient Encapsulation Scheme" for doing IP or possibly any other network
over MPEG-2.

> Does this clarify our requirements ?
>
sure

> Cheers,
>
same
--Horst

> St?phane
>
> ALCATEL SPACE INDUSTRIES
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
> Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr
>
>
>




From harri.hakulinen at nokia.com  Wed Apr 17 11:23:08 2002
From: harri.hakulinen at nokia.com (harri.hakulinen at nokia.com)
Date: Wed, 17 Apr 2002 13:23:08 +0300
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC7DE@trebe004.NOE.Nokia.com>


Hello everyone,  

after following the list in silent mode, I decided to make some 
comments to issues that I have seen frequently under discussion 
since I got involved with the "IP over DVB" concept back in -96.

My current interest to this work relates to the DVB-T domain,
but as we know, most of the issues are common for different
DVB mediums.

I am not "the great MPE lover", but the point of the standards
usually is to stick with it (until the new one comes in..). 
MPE also is a typical creation of commitee, but I think that it 
was honestly trying to reuse the capabilities of the reveiver 
hardware that existed or were in sight when it was defined.

Comparison to ATM

It is a matter of taste, if this makes any sence, but if you
do it, I think that it is fair to say that PID is roughly the
same concept as VPI(/VCI) in ATM. And, what is even more 
interesting, mpeg section format is very close to AAL5, or 
at least it offers the same functionality (and of course,
MPE builds on mpeg section format..)

If I remember it correctly, there is or was a version of DSM-CC
specification in MPEG (or some spec in DAVIC), that is/was in 
fact using the same idea to encapsulate "IP over sections" than 
the famous RFC 1483 ( by Juha Hein?nen) specified for ATM/AAL5. 

Multifeed/ "satellite onboard processing" case

If we recocnise, that PID actually forms "a connection" or "a pipe"
in a same sense than VPI/VCI does in ATM, it means that every 
"feed" should use it's own PID to transmit, and every receiver
should receive from those PID's separately (and thus listening
to those feeds that it is interested in).

This also means, that "onboard swicth" in satellite systems should
in fact be a remux, forming an "multiprogram transport stream" 
from incoming "singleprogram transport streams", if it is working 
in MPEG TS level. (In other words, satellite onboard processor
should not be able "to mix" ts packets coming in with different 
inputs by using the same PID.) 

Now, if the number of feeds is so large, that PID "space" is not
large enough, or if receivers are not able to listen/filter big
enough number of PID's, we are in trouble if we are trying 
to limit ourselves to MPEG TS processing.  

What we need to do in that case is to broke the "connection/pipe"
onboard, and do whatever layer 3/4 switching that we want
(including MPLS, Ethernet, IP etc.). After that we can create
a new connection(s)/pipe(s), that are carrying the desired 
layer 3/4 packets down to receivers.. 

This was little bit satellite specifig, but it may also apply 
to backbones that are used for terrestrial networks. Or at least
it should be kept in mind when thinking how and when to use 
(or better not to use) MPEG TS as the backbone transport medium.

Maybe one of the areas that this group wants to concentrate on 
is to clarify the roles of MPEG TS transport layer, IP layer and
the possibble switching layer in bethween (e.g. MPLS or Ethernet). 

Flexibility of MPE

I belive that originally MPE was designed so, that you could in
fact use whatever you want in the place of "MAC address", at least
in proprietary systems. I think that the "undocumented" feature in 
question may have something to do with the "payload and address 
scambling" bits (defined by service), but someone else may know 
that better.

If that is true, I quess you could use that space to something
like MPLS labels, or whatever else comes to your mind. Maybe 
this is also something that this group wants to consider together
with DVB groups.

Br,

// Harri Hakulinen
// Sr. Technology Manager
// Nokia Ventures Organization

> -----Original Message-----
> From: ext Stephane.Combes at space.alcatel.fr
> [mailto:Stephane.Combes at space.alcatel.fr]
> Sent: Thursday, April 11, 2002 2:55 PM
> To: ip-dvb at erg.abdn.ac.uk
> Cc: Sebastien.Josset at space.alcatel.fr
> Subject: Alcatel Space interest about IP/DVB
> 
> 
> 
> Dear colleagues,
> 
> Alcatel Space Industries would like to support the work 
> currently undertaken by
> this group.
> 
> As requested by Gorry Fairhurst, here follows a draft of the 
> presentation we
> could make at the next BOF :
> (See attached file: Alcatel_space_IP_DVB_view01.pdf)
> Note that this document is informational only but can be 
> distributed freely to
> anybody interested.
> 
> The general issues raised here seem to align with those expressed in
> http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/charter.html and
> http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ip
dvb-req-00.doc

It includes our vision for MPE enhancement. We would actually be very interested
if the to-be-defined encapsulation could support protocols other than IPv4 and
v6. Ethernet and MPLS are of equal importance according to the network segment
the DVB (or other MPEG-2 based) links are deployed. It would be nice if a future
RFC could have the same role than ITU-T I.363.5 (AAL5) and RFC-2684
(Multiprotocol encapsulation) have in the ATM world.

It also details some Layer 2 labelling management procedures that we have
developed in the frame of the BRAHMS IST project. This is perhaps more targetted
to a MPE "replacement". It actually includes a label distribution protocol
(working in a similar way as Ethernet ARP) and associated encapsulation
optimised for the broadcast nature of satellites (and thefore DVB) links. Such
kind of protocol could well play for broadcast links the same role than MPLS in
backbone networks.

The main ideas behind this proposed scheme are in line with the questions about
a possible "native IP" support that Gorry raised in his 03/25 e-mail. PID would
indeed only be a first level of filtering at receivers. IP filtering would then
be based on IP destination address. An additional label at layer 2, identifying
the source of the IP flow, could help avoiding to re-assemble all the IP traffic
received on a given PID (and allow proper re-assembly if packets are mixed by a
satellite on-board processor). Therefore a limited link layer header might still
be useful. The other characteristics of our scheme is that it naturally supports
multiple feeds configurations, two-way satellite links and on-board processing
(no more multisource multicast headaches !)

You'll find more details about BRAHMS project at
http://brahms.telecomitalialab.com/. There was also a paper published at last
year's AIAA conference ("IP Dedicated : a new Internet oriented satellite
transfer scheme", I. Buret et al., 19th AIAA ICSSC conference, april 2001).
Note that some outputs of the BRAHMS project have already been presented at the
ETSI BSM. Actually, the same presentation which is included here is being sent
to the ETSI BSM mailing-list.

Feel free to share comments on this list,
Best Regards,

St?phane COMBES


ALCATEL SPACE INDUSTRIES
Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr



From l.wood at eim.surrey.ac.uk  Wed Apr 17 12:07:17 2002
From: l.wood at eim.surrey.ac.uk (Lloyd Wood)
Date: Wed, 17 Apr 2002 12:07:17 +0100 (BST)
Subject: =?iso-8859-1?Q?Re:_R=E9f._:_Re:_Alcatel_Space_interest_about_IP/DVB?=
In-Reply-To: <009401c1e5c8$27209070$79068a81@nmttb97i6f89th>
Message-ID: <Pine.SOL.4.43.0204171201000.293-100000@phaestos.ee.surrey.ac.uk>

On Tue, 16 Apr 2002, Kearney wrote:

> > By "Ethernet-like" we only mean "connectionless layer 2 based on broadcast
> > medium".
> Question - why does it have to be connectionless?
> Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
> particulatr multicast applications are based on the concept of a session.

HTTP wasn't conceived as being session-like. Not all multicast
applications are based on a sessoin either.

> If you "tune" your receiver to a PID you are basically opening a
> session - so why wouild you like to have the next higher layer
> (link/encapsulation) connection-less?

that's exactly what the connectionless HTTP/1.0 does over the TCP
session; it ignores TCP session state (arguably lousy programming, and
slowly addressed in 1.1 implementations). But it made for ease of
specification and implementation.

If you look at protocol stacks you'll see connectionless/session
alternating as you go through the layers.

If you "tune" your receiver to a PID you might be joining a broadcast
session, and if several terminals share the same PID...

L.

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>




From Keith.Hogie at gsfc.nasa.gov  Wed Apr 17 18:24:04 2002
From: Keith.Hogie at gsfc.nasa.gov (Keith Hogie)
Date: Wed, 17 Apr 2002 13:24:04 -0400
Subject: =?iso-8859-1?Q?R=E9f=2E?=  Re: Alcatel Space interest about IP/DVB
References: <C1256B9D.004C59CA.00@vzmta01.netfr.alcatel.fr> <009401c1e5c8$27209070$79068a81@nmttb97i6f89th>
Message-ID: <3CBDAFB5.93283B3B@gsfc.nasa.gov>



Kearney wrote:
> 
> Hello St?phane>
> > Thanks a lot for your reviewing and comments !
> >
> let's keep the discussion cooking!
> > By "Ethernet-like" we only mean "connectionless layer 2 based on broadcast
> > medium".
> Question - why does it have to be connectionless?
> Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
> particulatr multicast applications are based on the concept of a session. If
> you "tune" your receiver to a PID you are basically opening a session - so
> why wouild you like to have the next higher layer (link/encapsulation)
> connection-less?
> 

  There may be various definitions of "connectionless" and "session"
going on here.  In one sense things like an ATM or Frame Relay 
Permanent Virtual Circuit (PVC) are a "connection" but that is a 
often a different definition than a TCP connection.

  I see the OSI terms "connection-oriented" and "connectionless" refer
more to upper layer protocols and not to things like a PVC.  Their
"connection" term relates to protocols that do some sort of handshaking
like X.25, PPP, or TCP.  The protocol actually initiates a "connection",
which may also be called a "session", by exchanging packets between
the two ends of the connection and creates the connected state. 

  I think the comment on "Ethernet-like" "connectionless" was aimed at
making sure you don't start running a connection-oriented lower layer
underneath a connection-oriented upper layer like TCP.  This relates
back to the days when people ran TCP over X.25 lower layers.  TCP is
fully prepared to wait for retransmissions and having X.25 underneath
it also doing retransmissions is redundant and causes other problems.

  When you ran multiple TCP connections over a single X.25 connection,
lost data packets could cause X.25 to slow down and wait for
retransmissions. This would delay all of the TCP connections running
over it even though the lost packets only affected one TCP connection.
This is where Frame Relay came from.  It removed the X.25 flow control
and retransmission and just accepted frames and relayed them on.

  You can call the lower layer data path a "connection" if you want
but the real point about "connectionless" is that the lower layers should
not be introducing any sort of flow control.  

----------------------------------------------------------------------
  Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov
  Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
  7700 Hubble Dr.
  Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
----------------------------------------------------------------------



From clausen at cosy.sbg.ac.at  Wed Apr 17 19:50:39 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Wed, 17 Apr 2002 11:50:39 -0700
Subject: =?iso-8859-1?Q?Re:_R=E9f.__Re:_Alcatel_Space_interest_about_IP/DVB?=
References: <C1256B9D.004C59CA.00@vzmta01.netfr.alcatel.fr> <009401c1e5c8$27209070$79068a81@nmttb97i6f89th> <3CBDAFB5.93283B3B@gsfc.nasa.gov>
Message-ID: <002901c1e640$c4e67ea0$79068a81@nmttb97i6f89th>

From: "Keith Hogie" <Keith.Hogie at gsfc.nasa.gov>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Wednesday, April 17, 2002 10:24 AM
Subject: Re: R?f. Re: Alcatel Space interest about IP/DVB

In my opinion the big difference between connectionless = datagram and
connection-oriented on the lower layers is the use of the addresses. In
connectionless systems you use the full address in every packet as
exemplified in Ethernet or Toke ring LANs, whereas in connection-oriented
systems you use thte full address only once for the set-up and then continue
using a "label", VC number etc. With adresses - or device_IDs getting bigger
and bigger (IEEE MAC -64, IPv6 ->128 bits) thjere is increased interest in
using shortel "labels - see the MPLS developments.

All I wanted to point out is the way in which we might treat the addressing
in the encapsulation. In my opinion the PID is just a "virtual broadcast
channel" and NOT a virtual circuit or path. It can be used as a
pont-to-point link but I doubt that this very sensibel; if there is a need
for this type of addressing it should probably be delegated to the
link-level i.e. the encapsulation should include an "address/label" field.

--Horst Clausen ("kearney")
>
>
> Kearney wrote:
> >
> > Hello St?phane>
> > > Thanks a lot for your reviewing and comments !
> > >
> > let's keep the discussion cooking!
> > > By "Ethernet-like" we only mean "connectionless layer 2 based on
broadcast
> > > medium".
> > Question - why does it have to be connectionless?
> > Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
> > particulatr multicast applications are based on the concept of a
session. If
> > you "tune" your receiver to a PID you are basically opening a session -
so
> > why wouild you like to have the next higher layer (link/encapsulation)
> > connection-less?
> >
>
>   There may be various definitions of "connectionless" and "session"
> going on here.  In one sense things like an ATM or Frame Relay
> Permanent Virtual Circuit (PVC) are a "connection" but that is a
> often a different definition than a TCP connection.
>
>   I see the OSI terms "connection-oriented" and "connectionless" refer
> more to upper layer protocols and not to things like a PVC.  Their
> "connection" term relates to protocols that do some sort of handshaking
> like X.25, PPP, or TCP.  The protocol actually initiates a "connection",
> which may also be called a "session", by exchanging packets between
> the two ends of the connection and creates the connected state.
>
>   I think the comment on "Ethernet-like" "connectionless" was aimed at
> making sure you don't start running a connection-oriented lower layer
> underneath a connection-oriented upper layer like TCP.  This relates
> back to the days when people ran TCP over X.25 lower layers.  TCP is
> fully prepared to wait for retransmissions and having X.25 underneath
> it also doing retransmissions is redundant and causes other problems.
>
>   When you ran multiple TCP connections over a single X.25 connection,
> lost data packets could cause X.25 to slow down and wait for
> retransmissions. This would delay all of the TCP connections running
> over it even though the lost packets only affected one TCP connection.
> This is where Frame Relay came from.  It removed the X.25 flow control
> and retransmission and just accepted frames and relayed them on.
>
>   You can call the lower layer data path a "connection" if you want
> but the real point about "connectionless" is that the lower layers should
> not be introducing any sort of flow control.
>
> ----------------------------------------------------------------------
>   Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov
>   Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
>   7700 Hubble Dr.
>   Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
> ----------------------------------------------------------------------
>




From clausen at cosy.sbg.ac.at  Thu Apr 18 01:42:32 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Wed, 17 Apr 2002 17:42:32 -0700
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC7DE@trebe004.NOE.Nokia.com>
Message-ID: <000901c1e671$ed66e140$79068a81@nmttb97i6f89th>

From: <harri.hakulinen at nokia.com>
To: <ip-dvb at erg.abdn.ac.uk>
Cc: <Stephane.Combes at space.alcatel.fr>
Sent: Wednesday, April 17, 2002 3:23 AM
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)


>
> Hello everyone,
>
> after following the list in silent mode, I decided to make some
> comments to issues that I have seen frequently under discussion
> since I got involved with the "IP over DVB" concept back in -96.
>  good - we need to get all the "silent" listeners to start participating.
Thanks for getting involved.

> My current interest to this work relates to the DVB-T domain,
> but as we know, most of the issues are common for different
> DVB mediums.
>
> I am not "the great MPE lover", but the point of the standards
> usually is to stick with it (until the new one comes in..).
> MPE also is a typical creation of commitee, but I think that it
> was honestly trying to reuse the capabilities of the reveiver
> hardware that existed or were in sight when it was defined.
>
I think we are really looking more into the future of and not at an
immediatel alternaive or raplacement of MPE. This will stick around for a
while since there is equipment available that supports it. But ther might be
nwo applications and systems showing up....

> Comparison to ATM
>
> It is a matter of taste, if this makes any sence, but if you
> do it, I think that it is fair to say that PID is roughly the
> same concept as VPI(/VCI) in ATM. And, what is even more
> interesting, mpeg section format is very close to AAL5, or
> at least it offers the same functionality (and of course,
> MPE builds on mpeg section format..)
>
this is a point where I disagree. A  VP/VC   is basically a point to point
connection whereas a PID is a broadcast channel. I guess this is one of the
reasons why MPE looks the way it is - people saw it just as another sort of
LAN - based on broadcast properties of the channel.

AAL5 is a lot "leaner" than the Section structure which is really tailored
to the transmission of tables which represent signaling and control
information for the PES streams which are part of the respective "program".
AAL5 is a good example for a minimal encapsulation - it baiscally contains a
length field so you do not have to search for a terminating bit pattern and
a type field - which in the case of AAL5 consists of two parts - both until
now pretty much open to interpretation and not (yet) standardized. And it
makes uses the last cell carry this information, together with the CRC.

> If I remember it correctly, there is or was a version of DSM-CC
> specification in MPEG (or some spec in DAVIC), that is/was in
> fact using the same idea to encapsulate "IP over sections" than
> the famous RFC 1483 ( by Juha Hein?nen) specified for ATM/AAL5.
>
> Multifeed/ "satellite onboard processing" case
>
> If we recocnise, that PID actually forms "a connection" or "a pipe"
> in a same sense than VPI/VCI does in ATM, it means that every
> "feed" should use it's own PID to transmit, and every receiver
> should receive from those PID's separately (and thus listening
> to those feeds that it is interested in).
>
of course you can consider the TS packet stream conveyed by one PID as a
"pipe" i.e. point to point, but in general it is a broadcast channel. You
can multiplex several services on one PID if you introduce a discriminator
("label", "address") on the next level and use this for filtering - actually
both, PES and Section packets have such a field called stream_id resp
table_id in the MPEG standard.

> This also means, that "onboard swicth" in satellite systems should
> in fact be a remux, forming an "multiprogram transport stream"
> from incoming "singleprogram transport streams", if it is working
> in MPEG TS level. (In other words, satellite onboard processor
> should not be able "to mix" ts packets coming in with different
> inputs by using the same PID.)
>
what is the difference between a remux and a switch ???

> Now, if the number of feeds is so large, that PID "space" is not
> large enough, or if receivers are not able to listen/filter big
> enough number of PID's, we are in trouble if we are trying
> to limit ourselves to MPEG TS processing.
>
As far as I know (but I may be mistaken) a state of the art IRD can not scan
simultaneously more than a few (say 20 .. 30) PIDs at one time - for
Ethernet interfaces the number of multicast MAC addresses it can scan at any
one time is also limited to "several" - it is definitely not a very large
number.

> What we need to do in that case is to broke the "connection/pipe"
> onboard, and do whatever layer 3/4 switching that we want
> (including MPLS, Ethernet, IP etc.). After that we can create
> a new connection(s)/pipe(s), that are carrying the desired
> layer 3/4 packets down to receivers..
>
I believe if you want to put something up in space you wsant to make it as
simple an reliable as possible and keep complex functions at the terrestrial
gateway. If you need to switch onboard you should chose a simple an robust
structure. I believe that one of the most interesting appoaches for some
types of applications, e.g. for distribution, is the SkyPlex system which
was developed by ESA and Eutelsat - this is basically an onboard
multiplexer. Of course it can not support spot beam configurations but it
can broadcast from many uplink stations to a very large footprint.

> This was little bit satellite specifig, but it may also apply
> to backbones that are used for terrestrial networks. Or at least
> it should be kept in mind when thinking how and when to use
> (or better not to use) MPEG TS as the backbone transport medium.
>
> Maybe one of the areas that this group wants to concentrate on
> is to clarify the roles of MPEG TS transport layer, IP layer and
> the possibble switching layer in bethween (e.g. MPLS or Ethernet).
>
yes - I think that is the point.

> Flexibility of MPE
>
> I belive that originally MPE was designed so, that you could in
> fact use whatever you want in the place of "MAC address", at least
> in proprietary systems. I think that the "undocumented" feature in
> question may have something to do with the "payload and address
> scambling" bits (defined by service), but someone else may know
> that better.
>
> If that is true, I quess you could use that space to something
> like MPLS labels, or whatever else comes to your mind. Maybe
> this is also something that this group wants to consider together
> with DVB groups.
>
there is one point to keep on mind: for wireless systems, in particular for
satellites, bandwidth is an EXPENSIVE resource, so you want to keep the
overhead as small as possible - and this goes in partucular for the header
which is transmitted with each cell - pardon, TS packet. People always look
at Ethernet as an example - but many of the design decision for Ethernet
were made under the assumptions (a) bandwidth is cheap, and (b) propagation
delay is low (and you can do CD - collision detection). Ther are working
groups looking very actuvely at header compressionm so you can reduce the IP
overhead down to a few bytes - and we should follow this example and look
very carefully at each byte we want to include in the encapsulation header.

And yes - we should cooperate with the DVB and ATSC groups.

--Horst Clausen ("kearney")



logy Manager
> // Nokia Ventures Organization
>
> > -----Original Message-----
> > From: ext Stephane.Combes at space.alcatel.fr
> > [mailto:Stephane.Combes at space.alcatel.fr]
> > Sent: Thursday, April 11, 2002 2:55 PM
> > To: ip-dvb at erg.abdn.ac.uk
> > Cc: Sebastien.Josset at space.alcatel.fr
> > Subject: Alcatel Space interest about IP/DVB
> >
> >
> >
> > Dear colleagues,
> >
> > Alcatel Space Industries would like to support the work
> > currently undertaken by
> > this group.
> >
> > As requested by Gorry Fairhurst, here follows a draft of the
> > presentation we
> > could make at the next BOF :
> > (See attached file: Alcatel_space_IP_DVB_view01.pdf)
> > Note that this document is informational only but can be
> > distributed freely to
> > anybody interested.
> >
> > The general issues raised here seem to align with those expressed in
> > http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/charter.html and
> > http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ip
> dvb-req-00.doc
>
> It includes our vision for MPE enhancement. We would actually be very
interested
> if the to-be-defined encapsulation could support protocols other than IPv4
and
> v6. Ethernet and MPLS are of equal importance according to the network
segment
> the DVB (or other MPEG-2 based) links are deployed. It would be nice if a
future
> RFC could have the same role than ITU-T I.363.5 (AAL5) and RFC-2684
> (Multiprotocol encapsulation) have in the ATM world.
>
> It also details some Layer 2 labelling management procedures that we have
> developed in the frame of the BRAHMS IST project. This is perhaps more
targetted
> to a MPE "replacement". It actually includes a label distribution protocol
> (working in a similar way as Ethernet ARP) and associated encapsulation
> optimised for the broadcast nature of satellites (and thefore DVB) links.
Such
> kind of protocol could well play for broadcast links the same role than
MPLS in
> backbone networks.
>
> The main ideas behind this proposed scheme are in line with the questions
about
> a possible "native IP" support that Gorry raised in his 03/25 e-mail. PID
would
> indeed only be a first level of filtering at receivers. IP filtering would
then
> be based on IP destination address. An additional label at layer 2,
identifying
> the source of the IP flow, could help avoiding to re-assemble all the IP
traffic
> received on a given PID (and allow proper re-assembly if packets are mixed
by a
> satellite on-board processor). Therefore a limited link layer header might
still
> be useful. The other characteristics of our scheme is that it naturally
supports
> multiple feeds configurations, two-way satellite links and on-board
processing
> (no more multisource multicast headaches !)
>
> You'll find more details about BRAHMS project at
> http://brahms.telecomitalialab.com/. There was also a paper published at
last
> year's AIAA conference ("IP Dedicated : a new Internet oriented satellite
> transfer scheme", I. Buret et al., 19th AIAA ICSSC conference, april
2001).
> Note that some outputs of the BRAHMS project have already been presented
at the
> ETSI BSM. Actually, the same presentation which is included here is being
sent
> to the ETSI BSM mailing-list.
>
> Feel free to share comments on this list,
> Best Regards,
>
> St?phane COMBES
>
>
> ALCATEL SPACE INDUSTRIES
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
> Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr
>




From clausen at cosy.sbg.ac.at  Thu Apr 18 01:53:19 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Wed, 17 Apr 2002 17:53:19 -0700
Subject: =?iso-8859-1?Q?Re:_R=E9f._:_Re:_Alcatel_Space_interest_about_IP/DVB?=
References: <Pine.SOL.4.43.0204171201000.293-100000@phaestos.ee.surrey.ac.uk>
Message-ID: <000f01c1e673$6ebd45d0$79068a81@nmttb97i6f89th>

From: "Lloyd Wood" <l.wood at eim.surrey.ac.uk>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Wednesday, April 17, 2002 4:07 AM
Subject: Re: R?f. : Re: Alcatel Space interest about IP/DVB


> On Tue, 16 Apr 2002, Kearney wrote:
>
> > > By "Ethernet-like" we only mean "connectionless layer 2 based on
broadcast
> > > medium".
> > Question - why does it have to be connectionless?
> > Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
> > particulatr multicast applications are based on the concept of a
session.
>
> HTTP wasn't conceived as being session-like. Not all multicast
> applications are based on a sessoin either.
>
you are right - it was designed as a request/reply protocol but operating on
top of TCP which is session/connection oriented. And HTTP1.1 has taken some
of the liberty and recommends now a "persistent" connection.
But let's look at the lower protocol level. Whatever the size of your "page"
you are sending or returning - you will have to allocate channel bandwidth
for it, and chances are you will not do this for a PID at a time but on a
more permanent basis.

> > If you "tune" your receiver to a PID you are basically opening a
> > session - so why wouild you like to have the next higher layer
> > (link/encapsulation) connection-less?
>
> that's exactly what the connectionless HTTP/1.0 does over the TCP
> session; it ignores TCP session state (arguably lousy programming, and
> slowly addressed in 1.1 implementations). But it made for ease of
> specification and implementation.
>
as I said above - it didn't care at all how the channel allocation strategy
could cope with this - and that's one of the problems we ought to address
here.

> If you look at protocol stacks you'll see connectionless/session
> alternating as you go through the layers.
>
> If you "tune" your receiver to a PID you might be joining a broadcast
> session, and if several terminals share the same PID...
>
I see this as the most important aspect - economics of satellites require
that you do as much broad-/multicasting as possible since point-to-point
services have to cover the full cost of the channel wehreas ***cast shares
the cost.
If you "tune" your receiver to a PID you are basically doing the same thing
as if you connect your laptop to a LAN - you will be sharing the total
bandwidth available for this PID. So you could run point-to-point service
antop of a shared PID if you include a "label/address" in the encapsulation
header.

--Hrst Clausen ("kearney")
> L.
>
> <L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
>
>




From harald.skinnemoen at nera.no  Thu Apr 18 08:35:44 2002
From: harald.skinnemoen at nera.no (Harald Skinnemoen)
Date: Thu, 18 Apr 2002 09:35:44 +0200
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)
In-Reply-To: <000901c1e671$ed66e140$79068a81@nmttb97i6f89th>
Message-ID: <000001c1e6ab$a690fb40$0200000a@ansur1>

Hi,

I've been following this discussion from interest from the sideline, as
I am involved with ETSI work that is related to IP over Satellite, and
in particular Multicasting and Addressing & Routing as part of a
so-called specialist task force at ETSI. 

The Broadband Satellite Multimedia group (WG BSM) is involved with a
number of issues related to what is discussed here - and yes - Alcatel
is very much involved I this work too. 

I've got two things... 

First I would like to invite comments and input on how satellite
multicast - in the future - could be made as efficient as possible with
respect to issues like those Horst Clausen points out - spectrum
efficiency. Naturally, satellite multicast would need to offer IP
multicast compatibility, but one could also imagine a special satellite
solution. I think satellite multicasting also could favorably be
combined with caching. This could increase the number of receivers that
could share the same channel, and thus reduce the cost. I would
appreciate help to find good references and for those of you who might
want to influence future ETSI standards, I would also be happy to invite
suggestions for specific issues that should be contained in a future
standard. 

Second, and as a natural follow-up of the first, I would also invite
this group to not only work with DVB and ATSC, but also ETSI... ;-) 

/Harald Skinnemoen
Recent BSM Chairman, now ETSI Team Leader STF on IP over Satellite.

> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]
On
> Behalf Of Kearney
> Sent: 18. april 2002 02:43
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Re: About some issues (RE: Alcatel Space interest about
IP/DVB)
> And yes - we should cooperate with the DVB and ATSC groups.
> 
> --Horst Clausen ("kearney")
> 
> 



From clausen at cosy.sbg.ac.at  Thu Apr 18 20:29:32 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Thu, 18 Apr 2002 12:29:32 -0700
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)
References: <000001c1e6ab$a690fb40$0200000a@ansur1>
Message-ID: <005c01c1e70f$5dd1a2b0$79068a81@nmttb97i6f89th>

Hello Harald,

Thanks for your input - and YES we are certainly willing and interested in
also working with the respective ETSI group(s).
I think we should keep the two "layers" apart - the Multicast Applications
and the encapsulation and transmission aspects.
This group, at least as I see it - Gorry might se it differently - should
concentrate on the encapsulation, keeping in mind what sort of applicatiopns
might predominantly be using it.
For multicasting applications we have developed a software system which is
noch used for the distribution of Envisat data via satellite and is working
fine. If you want an update on our system (it has changed quite a bit since
we met last time); please let me know.

Regards,
--Horst

----- Original Message -----
From: "Harald Skinnemoen" <harald.skinnemoen at nera.no>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Thursday, April 18, 2002 12:35 AM
Subject: RE: About some issues (RE: Alcatel Space interest about IP/DVB)


> Hi,
>
> I've been following this discussion from interest from the sideline, as
> I am involved with ETSI work that is related to IP over Satellite, and
> in particular Multicasting and Addressing & Routing as part of a
> so-called specialist task force at ETSI.
>
> The Broadband Satellite Multimedia group (WG BSM) is involved with a
> number of issues related to what is discussed here - and yes - Alcatel
> is very much involved I this work too.
>
> I've got two things...
>
> First I would like to invite comments and input on how satellite
> multicast - in the future - could be made as efficient as possible with
> respect to issues like those Horst Clausen points out - spectrum
> efficiency. Naturally, satellite multicast would need to offer IP
> multicast compatibility, but one could also imagine a special satellite
> solution. I think satellite multicasting also could favorably be
> combined with caching. This could increase the number of receivers that
> could share the same channel, and thus reduce the cost. I would
> appreciate help to find good references and for those of you who might
> want to influence future ETSI standards, I would also be happy to invite
> suggestions for specific issues that should be contained in a future
> standard.
>
> Second, and as a natural follow-up of the first, I would also invite
> this group to not only work with DVB and ATSC, but also ETSI... ;-)
>
> /Harald Skinnemoen
> Recent BSM Chairman, now ETSI Team Leader STF on IP over Satellite.
>
> > -----Original Message-----
> > From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]
> On
> > Behalf Of Kearney
> > Sent: 18. april 2002 02:43
> > To: ip-dvb at erg.abdn.ac.uk
> > Subject: Re: About some issues (RE: Alcatel Space interest about
> IP/DVB)
> > And yes - we should cooperate with the DVB and ATSC groups.
> >
> > --Horst Clausen ("kearney")
> >
> >
>



From harald.skinnemoen at nera.no  Thu Apr 18 23:33:34 2002
From: harald.skinnemoen at nera.no (Harald Skinnemoen)
Date: Fri, 19 Apr 2002 00:33:34 +0200
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)
In-Reply-To: <005c01c1e70f$5dd1a2b0$79068a81@nmttb97i6f89th>
Message-ID: <000601c1e729$13839370$0200000a@ansur1>

Hello Horst, 

Thanks for your positive response. I believe you're right, at least it
seems so to me at this stage, that THIS group should concentrate as you
say on the encapsulation. However, Gorry (if he agrees to how we think
he may see it...) also has a valid point, in the sense that the
applications must also be considered somehow, as these will define the
real benefit of a lower layer technology. There is no practical effect
(but there may be an academic one) in developing a technology - or
concept- that is not really used. 

Looking further ahead into the future, there may not always be 188 byte
or 53 byte packets to encapsulate things into, and when encapsulation is
considered it may be beneficial to also consider cases where other cell
(packet) sizes may be beneficial. The ETSI BSM group is not limited to
one single air interface technology, and there are a number of good
reasons why future satellite payloads choose other cell-size numbers
than 53 or 188. Could it be possible to define an encapsulation scheme
that was somehow not limited to the MPEG-TS (or ATM)? (I believe this is
in line with conclusions from packet size traffic measurements that both
you and Otto have done). 

/Harald

PS: yes - naturally ETSI (and I) is (are) interested in an update on
your system and it's evolvement. 


> -----Original Message-----
> From: owner-ip-dvb at erg.abdn.ac.uk [mailto:owner-ip-dvb at erg.abdn.ac.uk]
On
> Behalf Of Kearney
> Sent: 18. april 2002 21:30
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Re: About some issues (RE: Alcatel Space interest about
IP/DVB)
> 
> 
> Hello Harald,
> 
> Thanks for your input - and YES we are certainly willing and
interested in
> also working with the respective ETSI group(s).
> I think we should keep the two "layers" apart - the Multicast
Applications
> and the encapsulation and transmission aspects.
> This group, at least as I see it - Gorry might se it differently -
should
> concentrate on the encapsulation, keeping in mind what sort of
> applicatiopns
> might predominantly be using it.
> For multicasting applications we have developed a software system
which is
> noch used for the distribution of Envisat data via satellite and is
> working
> fine. If you want an update on our system (it has changed quite a bit
> since
> we met last time); please let me know.
> 
> Regards,
> --Horst
> 
> ----- Original Message -----
> From: "Harald Skinnemoen" <harald.skinnemoen at nera.no>
> To: <ip-dvb at erg.abdn.ac.uk>
> Sent: Thursday, April 18, 2002 12:35 AM
> Subject: RE: About some issues (RE: Alcatel Space interest about
IP/DVB)
> 
> 
> > Hi,
> >
> > I've been following this discussion from interest from the sideline,
as
> > I am involved with ETSI work that is related to IP over Satellite,
and
> > in particular Multicasting and Addressing & Routing as part of a
> > so-called specialist task force at ETSI.
> >
> > The Broadband Satellite Multimedia group (WG BSM) is involved with a
> > number of issues related to what is discussed here - and yes -
Alcatel
> > is very much involved I this work too.
> >
> > I've got two things...
> >
> > First I would like to invite comments and input on how satellite
> > multicast - in the future - could be made as efficient as possible
with
> > respect to issues like those Horst Clausen points out - spectrum
> > efficiency. Naturally, satellite multicast would need to offer IP
> > multicast compatibility, but one could also imagine a special
satellite
> > solution. I think satellite multicasting also could favorably be
> > combined with caching. This could increase the number of receivers
that
> > could share the same channel, and thus reduce the cost. I would
> > appreciate help to find good references and for those of you who
might
> > want to influence future ETSI standards, I would also be happy to
invite
> > suggestions for specific issues that should be contained in a future
> > standard.
> >
> > Second, and as a natural follow-up of the first, I would also invite
> > this group to not only work with DVB and ATSC, but also ETSI... ;-)
> >
> > /Harald Skinnemoen
> > Recent BSM Chairman, now ETSI Team Leader STF on IP over Satellite.
> >
> > > -----Original Message-----
> > > From: owner-ip-dvb at erg.abdn.ac.uk
[mailto:owner-ip-dvb at erg.abdn.ac.uk]
> > On
> > > Behalf Of Kearney
> > > Sent: 18. april 2002 02:43
> > > To: ip-dvb at erg.abdn.ac.uk
> > > Subject: Re: About some issues (RE: Alcatel Space interest about
> > IP/DVB)
> > > And yes - we should cooperate with the DVB and ATSC groups.
> > >
> > > --Horst Clausen ("kearney")
> > >
> > >
> >




From gorry at erg.abdn.ac.uk  Fri Apr 19 10:30:54 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 19 Apr 2002 10:30:54 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
Message-ID: <3CBFE3D0.1FC09428@erg.abdn.ac.uk>


Dear all,

find below the first draft for a submission for a next generation encapsulation
for IP over DVB.  All comments / corrections are welcome, please  send
to the
authors or this list.

Gorry Fairhurst

-----------------

From: Internet-Drafts at ietf.org
Reply-To: Internet-Drafts at ietf.org
Date: Thu, 18 Apr 2002 08:00:23 -0400
To: IETF-Announce: ;
Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


    Title        : Simple Encapsulation for transmission of IP datagrams
                          over MPEG-2/DVB networks
    Author(s)    : H. Clausen et al.
    Filename    : draft-clausen-ipdvb-enc-00.txt
    Pages        : 14
    Date        : 17-Apr-02
    
This document contains the Simple Encapsulation, a simple and lean
encapsulation mechanism for the transport of IP Datagrams over ISO
MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely
accepted not only for providing digital TV services, but also as a
subnetwork technology for building IP networks. One example is the
Digital Video Broadcast (DVB), specified by standards published by
the European Telecommunications Standards Institute (ETSI).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-clausen-ipdvb-enc-00.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-clausen-ipdvb-enc-00.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.


------ End of Forwarded Message
-------------- next part --------------
Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6CTwyMDAyMDQxNzE1MTYwNi5J
LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm
dC1jbGF1c2VuLWlwZHZiLWVuYy0wMC50eHQNDQ==
-------------- next part --------------
Content-Type: text/plain
Content-ID:	<20020417151606.I-D at ietf.org>


From gorry at erg.abdn.ac.uk  Fri Apr 19 11:48:51 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 19 Apr 2002 11:48:51 +0100
Subject: 54th IETF Meeting Information: July 14-19, 2002
Message-ID: <3CBFF616.11D889FC@erg.abdn.ac.uk>


I would be interested to know who on this list intends to be at the 
next IETF - and if there would be sufficient interest to organise
a meeting of this group. If you are attending do you wish to make 
a specific contribution to the DVB group?

Please email me (below) with details:

mail:gorry at erg.abdn.ac.uk

Gorry Fairhurst

----


Registration for the 54th IETF is now open.
Information can be found on the IETF web site at:
http://www.ietf.org/meetings/IETF-54.html

MEETING SITE:
Pacifico Yokohama Convention Center
1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan
Tel: + 81 (45) 221-2112
Fax: + 81 (45) 221-2136

HOTEL ACCOMMODATIONS:
Information is available on
http://www.e-side.co.jp/ietf54/accommodation.html.
Please be advised that ONLINE RESERVATIONS will be available after April
22nd.



------ End of Forwarded Message


From harri.hakulinen at nokia.com  Fri Apr 19 12:40:38 2002
From: harri.hakulinen at nokia.com (harri.hakulinen at nokia.com)
Date: Fri, 19 Apr 2002 14:40:38 +0300
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC89C@trebe004.NOE.Nokia.com>

Hello, 

nice doc, in terms of information exhange.

Couple of quick comments, more may follow::

- Have you calculated, what is the actual efficiency 
  gain compared to MPE (1 or 2 % ?) ?

  (I assume that in dowstream most packets are rather big)

- Related to that, is it justified to do this without taking
  header compression into consideration from the beginning ?

- Do you, by any change, know who has the IPR for the
  "MPLS label" in adaptation field ? 

Br,

//Harri

> -----Original Message-----
> From: ext Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
> Sent: Friday, April 19, 2002 12:31 PM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
> 
> 
> 
> Dear all,
> 
> find below the first draft for a submission for a next 
> generation encapsulation
> for IP over DVB.  All comments / corrections are welcome, please  send
> to the
> authors or this list.
> 
> Gorry Fairhurst
> 
> -----------------
> 
> From: Internet-Drafts at ietf.org
> Reply-To: Internet-Drafts at ietf.org
> Date: Thu, 18 Apr 2002 08:00:23 -0400
> To: IETF-Announce: ;
> Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>     Title        : Simple Encapsulation for transmission of 
> IP datagrams
>                           over MPEG-2/DVB networks
>     Author(s)    : H. Clausen et al.
>     Filename    : draft-clausen-ipdvb-enc-00.txt
>     Pages        : 14
>     Date        : 17-Apr-02
>     
> This document contains the Simple Encapsulation, a simple and lean
> encapsulation mechanism for the transport of IP Datagrams over ISO
> MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely
> accepted not only for providing digital TV services, but also as a
> subnetwork technology for building IP networks. One example is the
> Digital Video Broadcast (DVB), specified by standards published by
> the European Telecommunications Standards Institute (ETSI).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> 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-clausen-ipdvb-enc-00.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-clausen-ipdvb-enc-00.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.
> 
> 
> ------ End of Forwarded Message
> 



From gorry at erg.abdn.ac.uk  Fri Apr 19 13:14:42 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 19 Apr 2002 13:14:42 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC89C@trebe004.NOE.Nokia.com>
Message-ID: <3CC00A34.ADBA4C44@erg.abdn.ac.uk>



harri.hakulinen at nokia.com wrote:
> 
> Hello,
> 
> nice doc, in terms of information exhange.
> 
> Couple of quick comments, more may follow::
> 
> - Have you calculated, what is the actual efficiency
>   gain compared to MPE (1 or 2 % ?) ?

Well, that depends...

First, processing COST is significantly smaller 
- far fewer fields to process and decode.

Second, there is a small gain compared to the best case for MPE,
and a much larger gain compared to the worst case (small packets,
unpacked). 

Some analysis of MPE was previously sent to this list at:
http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/docs/Overhead-Analysis.doc

> 
>   (I assume that in dowstream most packets are rather big)
> 
> - Related to that, is it justified to do this without taking
>   header compression into consideration from the beginning ?
> 
I beleive you are right, we SHOULD look at header compression,
you'll see that the proposed scheme seems very suited to use
with a scheme such as ROHC header compression, however the
details of this scheme are still being pursued by the ROHC WG.

I think header compression is going to be important for many
applications, - one obvious case is transmission of small
IPv6 datagrams over links with limited bandwidth.

> - Do you, by any change, know who has the IPR for the
>   "MPLS label" in adaptation field ?
> 

Not sure what you mean...

> Br,
> 
> //Harri
> 
> > -----Original Message-----
> > From: ext Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
> > Sent: Friday, April 19, 2002 12:31 PM
> > To: ip-dvb at erg.abdn.ac.uk
> > Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
> >
> >
> >
> > Dear all,
> >
> > find below the first draft for a submission for a next
> > generation encapsulation
> > for IP over DVB.  All comments / corrections are welcome, please  send
> > to the
> > authors or this list.
> >
> > Gorry Fairhurst
> >
> > -----------------
> >
> > From: Internet-Drafts at ietf.org
> > Reply-To: Internet-Drafts at ietf.org
> > Date: Thu, 18 Apr 2002 08:00:23 -0400
> > To: IETF-Announce: ;
> > Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >     Title        : Simple Encapsulation for transmission of
> > IP datagrams
> >                           over MPEG-2/DVB networks
> >     Author(s)    : H. Clausen et al.
> >     Filename    : draft-clausen-ipdvb-enc-00.txt
> >     Pages        : 14
> >     Date        : 17-Apr-02
> >
> > This document contains the Simple Encapsulation, a simple and lean
> > encapsulation mechanism for the transport of IP Datagrams over ISO
> > MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely
> > accepted not only for providing digital TV services, but also as a
> > subnetwork technology for building IP networks. One example is the
> > Digital Video Broadcast (DVB), specified by standards published by
> > the European Telecommunications Standards Institute (ETSI).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body
> > of the message.
> >
> > 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-clausen-ipdvb-enc-00.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-clausen-ipdvb-enc-00.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.
> >
> >
> > ------ End of Forwarded Message
> >


From Patrick.Cipiere at udcast.com  Fri Apr 19 19:35:14 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Fri, 19 Apr 2002 20:35:14 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CBFE3D0.1FC09428@erg.abdn.ac.uk> (message from Gorry Fairhurst
	on Fri, 19 Apr 2002 10:30:54 +0100)
Message-ID: <200204191835.g3JIZE824561@ra.udcast.com>

Hi,

My first comments:

> 0x???? : Bridged Ethernet Frame

I would recommend 0x6558 (Transparent Ethernet Bridging)
What about 0x0806 : ARP

More generally speaking, why not allow any defined IEEE Ether Type?

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From clausen at cosy.sbg.ac.at  Fri Apr 19 20:44:28 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Fri, 19 Apr 2002 12:44:28 -0700
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC89C@trebe004.NOE.Nokia.com> <3CC00A34.ADBA4C44@erg.abdn.ac.uk>
Message-ID: <007801c1e7da$9e8e57a0$79068a81@nmttb97i6f89th>

Harri and Gorry,

> > Couple of quick comments, more may follow::
> >
> > - Have you calculated, what is the actual efficiency
> >   gain compared to MPE (1 or 2 % ?) ?
>
> Well, that depends...
>
> First, processing COST is significantly smaller
> - far fewer fields to process and decode.
>
The measurements we did about 2 years ago show that the bulk of the packets
on the forward channel are either 576 or 1500 bytes - there are a few
percent with 512 bytes and some control packets with 40 and 48 bytes - the
rest is more or less insignificant. Be careful when interpreting this - a
new "killer" application such as e.g. Napster might change this profile very
quickly - we saw this in the '90-ies when the Web cam up and made most
statistics obsolete overnight.
On the return channel of course the majority are the short 40+48 byte
packets which TCP gerenates and then some.
However, think of Haralds remark the other day - other cell sizes besides 48
and 184 might be used in other wireless and satellite systems - and the
overhead if you do NOT pack depends significantly on the cell size.

> Second, there is a small gain compared to the best case for MPE,
> and a much larger gain compared to the worst case (small packets,
> unpacked).
>
> Some analysis of MPE was previously sent to this list at:
> http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/docs/Overhead-Analysis.doc
>
yes - and if you look at the green curves with their sawtooth
characteristics - every transmission system with fixed length cells exhibits
this - except if you do it as SDH/Sonet does it with pointers and a
"floating" container. You could of course optimize by choosing a SNDU block
size which nicely fragments into cells - but if anything should change, the
cell size or the block size, then you end up on top of the inefficiency
peak. Ergo- we should pack.
> >
> >   (I assume that in dowstream most packets are rather big)
> >
> > - Related to that, is it justified to do this without taking
> >   header compression into consideration from the beginning ?
> >
> I believe you are right, we SHOULD look at header compression,
> you'll see that the proposed scheme seems very suited to use
> with a scheme such as ROHC header compression, however the
> details of this scheme are still being pursued by the ROHC WG.
>
AGREE - we should really look at header compression but the question is
whether ROHC is applicable for a simplex channel. As far as I know ROHC
makes use of a more or less periodic handshake between the compressor and
the decompressor - we might have to resort to some PSI tables for conveying
this "refresh" information.
But we really should look at header compression right away!

> I think header compression is going to be important for many
> applications, - one obvious case is transmission of small
> IPv6 datagrams over links with limited bandwidth.
>

> > - Do you, by any change, know who has the IPR for the
> >   "MPLS label" in adaptation field ?
> >
>
> Not sure what you mean...
>
me too

--Horst



From harri.hakulinen at nokia.com  Mon Apr 22 09:08:43 2002
From: harri.hakulinen at nokia.com (harri.hakulinen at nokia.com)
Date: Mon, 22 Apr 2002 11:08:43 +0300
Subject: IPR & other considerations (RE: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt)
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8D5@trebe004.NOE.Nokia.com>

Moro, (as they say in this town istead of hello)

> -----Original Message-----
> From: ext Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
> Sent: Friday, April 19, 2002 3:15 PM
> 
> harri.hakulinen at nokia.com wrote:
> > - Have you calculated, what is the actual efficiency
> >   gain compared to MPE (1 or 2 % ?) ?
> 
> Well, that depends... 
> First, processing COST is significantly smaller 
> - far fewer fields to process and decode.

I think that "processing cost" is really a non argument here.
In my opinnion the possible new encapsulation needs to have 
mandatory header compression support, and in that case that 
cost will anyway be much higher than with current MPE.

> Second, there is a small gain compared to the best case for MPE,
> and a much larger gain compared to the worst case (small packets,
> unpacked). 
> Some analysis of MPE was previously sent to this list at:
> http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/docs/Overhead-Ana
> lysis.doc

It is totally different thing to recommend the use of section
packing of the existing standard than to propose a new standard ..

> > - Do you, by any change, know who has the IPR for the
> >   "MPLS label" in adaptation field ? 
> 
> Not sure what you mean...
 
By knowing something about "the state of art" in this subject,
I would classify that idea as very easy to patent. 

In the old DAVIC times some Japanese company proposed something
similar in the scope of PES for IP headers (instead of MPLS), 
but I don't remember anymore, what was the company and I am too
lazy to do patent search right now.

Bottom line(s)::

Be prepared to find some resistance towards solutions that are
possibly under heavy IPR, especially if that is owned by companies
that are outside of DVB/Etsi scope.

Minimum req. in this subject is to get "IETF IPR statements" from
authors, but in this case it doesn't necessarily help much, because
we don't know to what companies they may be connected.

//Harri

> > Br,
> > 
> > //Harri
> > 
> > > -----Original Message-----
> > > From: ext Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
> > > Sent: Friday, April 19, 2002 12:31 PM
> > > To: ip-dvb at erg.abdn.ac.uk
> > > Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
> > >
> > >
> > >
> > > Dear all,
> > >
> > > find below the first draft for a submission for a next
> > > generation encapsulation
> > > for IP over DVB.  All comments / corrections are welcome, 
> please  send
> > > to the
> > > authors or this list.
> > >
> > > Gorry Fairhurst
> > >
> > > -----------------
> > >
> > > From: Internet-Drafts at ietf.org
> > > Reply-To: Internet-Drafts at ietf.org
> > > Date: Thu, 18 Apr 2002 08:00:23 -0400
> > > To: IETF-Announce: ;
> > > Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >     Title        : Simple Encapsulation for transmission of
> > > IP datagrams
> > >                           over MPEG-2/DVB networks
> > >     Author(s)    : H. Clausen et al.
> > >     Filename    : draft-clausen-ipdvb-enc-00.txt
> > >     Pages        : 14
> > >     Date        : 17-Apr-02
> > >
> > > This document contains the Simple Encapsulation, a simple and lean
> > > encapsulation mechanism for the transport of IP Datagrams over ISO
> > > MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely
> > > accepted not only for providing digital TV services, but also as a
> > > subnetwork technology for building IP networks. One example is the
> > > Digital Video Broadcast (DVB), specified by standards published by
> > > the European Telecommunications Standards Institute (ETSI).
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-00.txt
> > >
> > > To remove yourself from the IETF Announcement list, send 
> a message to
> > > ietf-announce-request with the word unsubscribe in the body
> > > of the message.
> > >
> > > 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-clausen-ipdvb-enc-00.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-clausen-ipdvb-enc-00.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.
> > >
> > >
> > > ------ End of Forwarded Message
> > >
> 



From gorry at erg.abdn.ac.uk  Mon Apr 22 09:49:19 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 22 Apr 2002 09:49:19 +0100
Subject: IPR & other considerations (RE: Subject: I-D 
 ACTION:draft-clausen-ipdvb-enc-00.txt)
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8D5@trebe004.NOE.Nokia.com>
Message-ID: <3CC3CE8E.3CD1F2EE@erg.abdn.ac.uk>



harri.hakulinen at nokia.com wrote:
> 
> Moro, (as they say in this town istead of hello)
> 
> > -----Original Message-----
> > From: ext Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk]
> > Sent: Friday, April 19, 2002 3:15 PM
> >
> > harri.hakulinen at nokia.com wrote:
> > > - Have you calculated, what is the actual efficiency
> > >   gain compared to MPE (1 or 2 % ?) ?
> >
> > Well, that depends...
> > First, processing COST is significantly smaller
> > - far fewer fields to process and decode.
> 
> I think that "processing cost" is really a non argument here.
> In my opinnion the possible new encapsulation needs to have
> mandatory header compression support, and in that case that
> cost will anyway be much higher than with current MPE.
> 

This is an interesting debate - but, I'm not sure I entirely agree.
Lower level processing (operating on each SNDU or part of, rather
than packets which have passed a "filter" and will be forwarded
ultimately) is always more painful than simply servicing a queue 
of filtered packets (e.g. within a device driver), which is where I
would expect header compression to be implemented. 

The issue is also that using header compression, the SIZE of a
SNDU may be very small (few-tens of bytes), then MPE/section
overhead becomes very large in comparison.

> > Second, there is a small gain compared to the best case for MPE,
> > and a much larger gain compared to the worst case (small packets,
> > unpacked).
> > Some analysis of MPE was previously sent to this list at:
> > http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/docs/Overhead-Ana
> > lysis.doc
> 
> It is totally different thing to recommend the use of section
> packing of the existing standard than to propose a new standard ..
> 

Sure, well an alternate/complementary approach would be to define
a profile for MPE which says exactly what fields are to be used,
how options are to be defined, etc. Given the expected continued life
of MPE, which will be long in some applications at least, this
could be a useful document - would you be willing to write it?

I would expect any signalling protocol that comes from this
group to address MPE and also any new encapsulation - this
would also be useful as a basis for this discussion.

> > > - Do you, by any change, know who has the IPR for the
> > >   "MPLS label" in adaptation field ?
> >
> > Not sure what you mean...
> 
> By knowing something about "the state of art" in this subject,
> I would classify that idea as very easy to patent.
> 
> In the old DAVIC times some Japanese company proposed something
> similar in the scope of PES for IP headers (instead of MPLS),
> but I don't remember anymore, what was the company and I am too
> lazy to do patent search right now.
> 
> Bottom line(s)::
> 
> Be prepared to find some resistance towards solutions that are
> possibly under heavy IPR, especially if that is owned by companies
> that are outside of DVB/Etsi scope.
> 

The IETF has a stated policy of choosing non-patent solutions where
possible. I personally would support this whole heatedly. I would
like to see an open standard appear, if this is possible.

> Minimum req. in this subject is to get "IETF IPR statements" from
> authors, but in this case it doesn't necessarily help much, because
> we don't know to what companies they may be connected.
> 

YES. 

> //Harri
> 

<<snip>>


From Ghassane.Aniba at sophia.inria.fr  Mon Apr 22 13:04:01 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Mon, 22 Apr 2002 14:04:01 +0200
Subject: Switching mpeg2 packets on satellite
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8D5@trebe004.NOE.Nokia.com>
Message-ID: <3CC3FC31.F4239A81@sophia.inria.fr>

HI,
First, if we want switch the mpeg packet on the satellite, we need to
add a label to distinguish between the differents flows.

Second, if we have two SNDUs with differents destinations, we can't put
them or their fragments in 
the same mpeg2-tp, or we need a label for each fragment added to the
pointer which is specified in the last draft.

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Mon Apr 22 13:54:13 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 22 Apr 2002 13:54:13 +0100
Subject: Switching mpeg2 packets on satellite
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8D5@trebe004.NOE.Nokia.com> <3CC3FC31.F4239A81@sophia.inria.fr>
Message-ID: <3CC407F8.A8D6B774@erg.abdn.ac.uk>


See in-line comments

Ghassane Aniba wrote:
> 
> HI,
> First, if we want switch the mpeg packet on the satellite, we need to
> add a label to distinguish between the differents flows.

> With a new generation of satellite OBP(OnBoard Processor), with
> multi-spots, we need a label in each TS Packet, to switch packet to the
> spots interested by this packet. 

Yes, you refer to an interesting case. There are going to be very many
different variants ion the future... For instance, I would not be in the
least surprised to find MPEG-2 remultiplexors in terrestrial DVB-T networks
which also want to "route" packets based on a PID to different broadcast
cells.

So where does your label go in the SI table associated with a PID,
or in each SNDU "tag"???

This comes down to:

- Should you be switching at then PID level? - i.e. PID represents a 
destination - that would make sense - at least for unicast.

- Should you be switching on a packet by packet level
WITHIN a TS stream (shared PID), forwarding some packets
with one "tag", and not others on an output port?
(There could be some merit in multicast?)


> Second, if we have two SNDUs with differents destinations, we can't put
> them or their fragments in
> the same mpeg2-tp, or we need a label for each fragment added to the
> pointer which is specified in the last draft.
> 

You're talking about the shared-PID switched case above, yes?

OK, you can place each SNDU in a separate TS-packet.
That's not ILLEGAL in the new encapsulation, and, I guess you
would be free to define your own encapsulation / adaptation header
to carry any extra tags...

BUT, by default, the design assumes you WILL pack SNDUs, or at least
the encapsulating gateway device MAY choose to do so, on a per-SNDU
basis.

> Aniba.
> 
> --
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From harri.hakulinen at nokia.com  Mon Apr 22 14:53:49 2002
From: harri.hakulinen at nokia.com (harri.hakulinen at nokia.com)
Date: Mon, 22 Apr 2002 16:53:49 +0300
Subject: ATM comparison etc..RE: About some issues (RE: Alcatel Space interest about IP/DVB)
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8E9@trebe004.NOE.Nokia.com>


Moro, It seems that I have already been falling behind 
      with my answers ..

> -----Original Message-----
> From: ext Kearney [mailto:clausen at cosy.sbg.ac.at]
> Sent: Thursday, April 18, 2002 3:43 AM
> >From: <harri.hakulinen at nokia.com>
> >Sent: Wednesday, April 17, 2002 3:23 AM
> 
> > Comparison to ATM
> > It is a matter of taste, if this makes any sence, but if you
> > do it, I think that it is fair to say that PID is roughly the
> > same concept as VPI(/VCI) in ATM. 
> >
> this is a point where I disagree. A  VP/VC   is basically a 
> point to point connection whereas a PID is a broadcast channel. 

Lets play that PID is analogous for point-to-multipoint VP/VC,
that is also defined in ATM. Then, what is the functional 
difference ?  

I think that "switching" or multiplexing on TS level really is
designed to work based on PID's, in the same way than it works  
on ATM based on VP/VC.

You can always do something in different way that it was designed
to work in the first place, but I am not sure if you should
(I guess that unrelated, but "a classic" example of that kind of 
 work in "IETF world" would be the consept of NAT's (Network Address
 Translators). They work, they are usefull in some cases, but overall 
 they tend to introduce lots of new/stupid problems, that were not 
 part of the original concept (end-to-end IP based routing)).

> > And, what is even more
> > interesting, mpeg section format is very close to AAL5, or
> > at least it offers the same functionality (and of course,
> > MPE builds on mpeg section format..)
>>
> AAL5 is a lot "leaner" than the Section structure which is 
> really tailored to the transmission of tables ...

I agree, that AAL5 is "leaner", but the additional fields
to section structure were added to tailor it for broadcast
kind of network..

Still I think that they have the same level of functionality.


> > Multifeed/ "satellite onboard processing" case
> >
> > If we recocnise, that PID actually forms "a connection" or "a pipe"
> > in a same sense than VPI/VCI does in ATM, it means that every
> > "feed" should use it's own PID to transmit, and every receiver
> > should receive from those PID's separately (and thus listening
> > to those feeds that it is interested in).
> >
> of course you can consider the TS packet stream conveyed by 
> one PID as a "pipe" i.e. point to point, but in general it is 
> a broadcast  channel. You can multiplex several services on one PID 
> if you introduce a discriminator ("label", "address") on the next 
> level and use this for filtering - actually both, PES and Section 
> packets have such a field called stream_id resp table_id in
> the MPEG standard.
> 

There is only one table_id (so far?) reserved for MPE. 

If you are really "multiplexing" other table_id:s to same PID,
they need to contain something else than MPE encapsulated data packets. 

You can of course introduce a swicth that is working on "MPE level" and
relies e.g. MPE MAC address on "multiplexing".

> > This also means, that "onboard swicth" in satellite systems should
> > in fact be a remux, forming an "multiprogram transport stream"
> > from incoming "singleprogram transport streams", if it is working
> > in MPEG TS level. (In other words, satellite onboard processor
> > should not be able "to mix" ts packets coming in with different
> > inputs by using the same PID.)
> >
> what is the difference between a remux and a switch ???

I quess in this context it is used to describe a device that takes
in n times "complete" Transport Streams and outputs only one. Btw,
I think that their "swithing" functionality is based on PID's..

//Harri



From harri.hakulinen at nokia.com  Mon Apr 22 15:06:33 2002
From: harri.hakulinen at nokia.com (harri.hakulinen at nokia.com)
Date: Mon, 22 Apr 2002 17:06:33 +0300
Subject: Switching mpeg2 packets on satellite
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8EA@trebe004.NOE.Nokia.com>

Moro, It seems that we are approaching the point...

If you put "Label" to TS level, you are really playing
the "ATM card", because you now have PID/Label pair in
comparison to VPI/VCI pair.

In other words, that label can't really relate to individual
SNDU's, because they really are "inside the pipe". 

If you want to switch SNDU's, you need to do it based on 
a field that is inside SNDU...

//Harri

> -----Original Message-----
> From: ext Ghassane Aniba [mailto:Ghassane.Aniba at sophia.inria.fr]
> Sent: Monday, April 22, 2002 3:04 PM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Switching mpeg2 packets on satellite
> 
> 
> HI,
> First, if we want switch the mpeg packet on the satellite, we need to
> add a label to distinguish between the differents flows.
> 
> Second, if we have two SNDUs with differents destinations, we can't put
> them or their fragments in  the same mpeg2-tp, or we need a label for
> each fragment added to the pointer which is specified in the last draft.
> 
> Aniba.
> 
> -- 
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr  
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78
> 



From Ghassane.Aniba at sophia.inria.fr  Mon Apr 22 15:41:18 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Mon, 22 Apr 2002 16:41:18 +0200
Subject: Label_link
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8EA@trebe004.NOE.Nokia.com>
Message-ID: <3CC4210E.8F74DEC1@sophia.inria.fr>

harri.hakulinen at nokia.com wrote:
> 
> Moro, It seems that we are approaching the point...
> 
> If you put "Label" to TS level, you are really playing
> the "ATM card", because you now have PID/Label pair in
> comparison to VPI/VCI pair.

It's not really the same. In the ATM we put many ATN cells in one
MPEG2-TS packet, but here, we put only one label for each fragment of
SNDU.
 
> In other words, that label can't really relate to individual
> SNDU's, because they really are "inside the pipe".

No, they are really outside :

|----------------------------------------------------|
|		      SNDU                           |
------------------------------------------------------

we will fragment the SNDU in many 181 octets:

|------------------|-------------|------------------|
|  MPEG2-TP Header | link_label  |  SNDU fragment   |
|------------------|-------------|------------------|

> If you want to switch SNDU's, you need to do it based on
> a field that is inside SNDU...

I'll use PID in the first level, and after we will use
link_label.(because we can just filter 20 pid simultanously)

> 
> //Harri

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Mon Apr 22 15:49:56 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 22 Apr 2002 15:49:56 +0100
Subject: [Fwd: New Descriptor.]
Message-ID: <3CC42317.C8B8744C@erg.abdn.ac.uk>



Gorry Fairhurst wrote:
> 
> Ghassane Aniba wrote:
> >
> > Hi,
> > thanks to gorry for his explanation..
> > For me, i'm thinking to give for each connection (source,groupe or
> > destination) an unique identifier, which is (PID, @link_sat_adress):
> >
> > |-----------------|-------------------|----------------------|
> > | mpeg2-tp header |  @link_sat_adress |  SNDU Fragment       |
> > |-----------------|-------------------|----------------------|
> >
> > The  @link_ID, will be 3 bytes. we will use 20 of PID combination with 3
> > bytes @link_sat_adress, which give us a 2^28 possible connections in the
> > same time.
> 
Could the " @link_sat_adress" be an adaptation header of EACH TS
Packet?

If so, then  I think the combined (PID<label) looks very much as an
ATM (VP,VCI) in a pure ATM networks and the DVB  satellite - or MPEG-2 
remux looks like an ATM VP_switch.

In that case the thing you mark "SNDU" be a SNDU including header, 
and encapsulation  fields including length, type, CRC, etc. ? 

If so , we may be fairly near in terms of format? - and each TS Packet
carries a part of a SNDU payload + encapsulation.

> 
> >
> > In the satellite we will have, a switching table (PID, at link_sat_adress)
> > --> List of spots.
> >
> > For informing about the mapping between (PID, at link_sat_adress) and the
> > (source,destination), i will use a new Descriptor, called "
> > channel_Descriptor", which will be as below:
> >
> > --------------------------------------
> > Channel_Descriptor {
> > descriptor_tag       8 bits
> > descriptor_length    8 bits
> > link_sat_adress      24 bits
> > label_switching      32 bits
> > adress_type           1 bit
> > source_adress        32/48 bits
> > group_adress         32/48 bits
> > }
> >
> > -----------------------------
> > this descriptor will be, if necessary, in the PMT table, with each PID
> > reserved for IP traffic.
> >

- This seems like the signalling part.

> > I presented here a general idea, and i hope sincerly that we could
> > improve this idea.
> > I hope that the new RFC of IP over DVB, will be more switable with the
> > IP over DVB-S, and specialy with the IP Multicasting traffic over
> > satellite with the OnBoard Processor.

Multicast will be interesting... and probably non-trivial.

> > Thanks, and i'm waiting for all your remark or ask.
> >
> > --
> > Ghassane ANIBA
> > INRIA (Projet PLANETE)             | Email :
> > ghassane.aniba at sophia.inria.fr
> > 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> > 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Mon Apr 22 16:00:11 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 22 Apr 2002 16:00:11 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <200204191835.g3JIZE824561@ra.udcast.com>
Message-ID: <3CC4257E.65958B0@erg.abdn.ac.uk>


Looks like some good input to the next rev. Can I clarify
a couple of things?

Patrick Cipiere wrote:
> 
> Hi,
> 
> My first comments:
> 
> > 0x???? : Bridged Ethernet Frame
> 
> I would recommend 0x6558 (Transparent Ethernet Bridging)
>
What do you think the FCS should contain? 
Should the SNDU include an Ethernet padding (I assume this doesn't matter)?

> What about 0x0806 : ARP
> 
OK, but you don't need Ethernet-ARP if there is no MAC address, so am I
right in thinking this only applies for bridging. If so, does that mean
we should carry arp's natively or in "bridged SNDUs" - the latter would
seem to be more simple.

>
> More generally speaking, why not allow any defined IEEE Ether Type?
> 

I am not sure we need to do this in the "native" encapsulation, may be
others think so?

We MUST I think allow this as the "type" field of a bridged SNDU - i.e.
one which carries MAC destination & source address in the header.


> Patrick.
> --
> UDcast: Full IP over Broadcast Media
> 
> Phone:  (+33) (0)4 93 00 16 99
> Mobile: (+33) (0)6 14 21 55 98
> Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From clausen at cosy.sbg.ac.at  Tue Apr 23 05:43:19 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Mon, 22 Apr 2002 21:43:19 -0700
Subject: ATM comparison etc..RE: About some issues (RE: Alcatel Space interest about IP/DVB)
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8E9@trebe004.NOE.Nokia.com>
Message-ID: <002a01c1ea81$64429350$79068a81@nmttb97i6f89th>


----- Original Message -----
From: <harri.hakulinen at nokia.com>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Monday, April 22, 2002 6:53 AM
Subject: ATM comparison etc..RE: About some issues (RE: Alcatel Space
interest about IP/DVB)


>
> Moro, It seems that I have already been falling behind
>       with my answers ..
>
Hello Harri,

I agree with your comments mostly but for the sake of discussion and
possibly more insight, lets continue the arguments:
> >
> > > Comparison to ATM
> > > It is a matter of taste, if this makes any sence, but if you
> > > do it, I think that it is fair to say that PID is roughly the
> > > same concept as VPI(/VCI) in ATM.
> > >
> > this is a point where I disagree. A  VP/VC   is basically a
> > point to point connection whereas a PID is a broadcast channel.
>
> Lets play that PID is analogous for point-to-multipoint VP/VC,
> that is also defined in ATM. Then, what is the functional
> difference ?
>
> I think that "switching" or multiplexing on TS level really is
> designed to work based on PID's, in the same way than it works
> on ATM based on VP/VC.
>
The ATM VP/VC has a global i.e. network-wide scope and it is bound at
connection set-up using the E.164 or NSAP address which is sued for routing;
its basic purpose is to enable switching. A Mac-level address has a local
scope just on that one link/channel where it is used and it assists in
deciding which interface is the recipient. In the case of the PID - as long
as you do not consider a re-mux as a switch but just as some sort of
repeater, the PID is more like a physical address. As soon as you do
switching based on the PID field you are extending the scope of that
identifier and adding semantics to it.

> You can always do something in different way that it was designed
> to work in the first place, but I am not sure if you should
> (I guess that unrelated, but "a classic" example of that kind of
>  work in "IETF world" would be the consept of NAT's (Network Address
>  Translators). They work, they are usefull in some cases, but overall
>  they tend to introduce lots of new/stupid problems, that were not
>  part of the original concept (end-to-end IP based routing)).
>
Actually, that is what happende to the ATM VP/VC which originally was never
intended to be used for multicasting but just for point - point services;
then multicast functionality was defined into it at a later point in time.

> > > And, what is even more
> > > interesting, mpeg section format is very close to AAL5, or
> > > at least it offers the same functionality (and of course,
> > > MPE builds on mpeg section format..)
> >>
> > AAL5 is a lot "leaner" than the Section structure which is
> > really tailored to the transmission of tables ...
>
> I agree, that AAL5 is "leaner", but the additional fields
> to section structure were added to tailor it for broadcast
> kind of network..
>
> Still I think that they have the same level of functionality.
>

that is the  point - the Section is very specifically tailored to the
reliable and robust transmission of PSI tables and several of the fields in
the Section header suppor this specific application.
What AAL5 is doing and we are trying to do is define a very simple
encapsulation for different payloads and put the specific fields in what
IPv6 calls the "next level" header; this si in principle very similar to
what the adaptation fieds in the TS packet are for - the basic header is
extremely simple - 4 bytes - and if you need more functionality you extend
it with an adaptation header.
>
> > > Multifeed/ "satellite onboard processing" case
> > >
> > > If we recocnise, that PID actually forms "a connection" or "a pipe"
> > > in a same sense than VPI/VCI does in ATM, it means that every
> > > "feed" should use it's own PID to transmit, and every receiver
> > > should receive from those PID's separately (and thus listening
> > > to those feeds that it is interested in).
> > >
> > of course you can consider the TS packet stream conveyed by
> > one PID as a "pipe" i.e. point to point, but in general it is
> > a broadcast  channel. You can multiplex several services on one PID
> > if you introduce a discriminator ("label", "address") on the next
> > level and use this for filtering - actually both, PES and Section
> > packets have such a field called stream_id resp table_id in
> > the MPEG standard.
> >
>
> There is only one table_id (so far?) reserved for MPE.
>
> If you are really "multiplexing" other table_id:s to same PID,
> they need to contain something else than MPE encapsulated data packets.
>
> You can of course introduce a swicth that is working on "MPE level" and
> relies e.g. MPE MAC address on "multiplexing".
>
my point was that the table_ID or stream_ID in teh case of PES packets is a
discriminator field which the receiver might use to decide what to do with
this payload; it is sort of a UU signaling in terms of the ATM/AAL5 people.
But you could as well introduce a "label" field which could assist in
routing/switching. The reals question is - Gorry has addressed this in his
message - that you would either have to reassemble the encapsulated packet,
or - and this makes more sense, project the label into each TS packet as a
sort of extension to the PID. In this case you are really emanating the ATM
VP/VC structure with the PID/Label fields - and you can do this in a point-
point ore -multipoint way.

> > > This also means, that "onboard swicth" in satellite systems should
> > > in fact be a remux, forming an "multiprogram transport stream"
> > > from incoming "singleprogram transport streams", if it is working
> > > in MPEG TS level. (In other words, satellite onboard processor
> > > should not be able "to mix" ts packets coming in with different
> > > inputs by using the same PID.)
> > >
> > what is the difference between a remux and a switch ???
>
> I quess in this context it is used to describe a device that takes
> in n times "complete" Transport Streams and outputs only one. Btw,
> I think that their "swithing" functionality is based on PID's..
>
Coming back to your recent remark on how much overhead we could save with
the new encapsulation: it is interesting to look at the design of the RTP
protocol and some of the rearks in the ROHC area: these people worry about
every bit they transmit - RTP has a clever scheme for signaling Padding
information without actually including it in the packet structure, assuming
that the lower layer protocol(s) know best how to make use of the basic
transmission units.
And as Haral remarked - we might be confronted with a bunch of different
cell sizes (Pardon TS packet) in the future, particularly on the various
return channel systems.

> //Harri
>
-- Horst



From clausen at cosy.sbg.ac.at  Tue Apr 23 05:47:30 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Mon, 22 Apr 2002 21:47:30 -0700
Subject: Switching mpeg2 packets on satellite
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8EA@trebe004.NOE.Nokia.com>
Message-ID: <003201c1ea81$f9b39060$79068a81@nmttb97i6f89th>


----- Original Message -----
From: <harri.hakulinen at nokia.com>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Monday, April 22, 2002 7:06 AM
Subject: RE: Switching mpeg2 packets on satellite


> Moro, It seems that we are approaching the point...
>
> If you put "Label" to TS level, you are really playing
> the "ATM card", because you now have PID/Label pair in
> comparison to VPI/VCI pair.
>
> In other words, that label can't really relate to individual
> SNDU's, because they really are "inside the pipe".
>
> If you want to switch SNDU's, you need to do it based on
> a field that is inside SNDU...
>
Right - if you really want to use the Label for switching you need to map it
into each TS-packet header, as close as possible to the PID field. Otherwise
you have to reassemble the complete SNDU and switch that packet - fragment
it again into TS-packets etc...; except, of course, if the next link is e.g.
a PPP link.....

> //Harri
--Horst
>
> > -----Original Message-----
> > From: ext Ghassane Aniba [mailto:Ghassane.Aniba at sophia.inria.fr]
> > Sent: Monday, April 22, 2002 3:04 PM
> > To: ip-dvb at erg.abdn.ac.uk
> > Subject: Switching mpeg2 packets on satellite
> >
> >
> > HI,
> > First, if we want switch the mpeg packet on the satellite, we need to
> > add a label to distinguish between the differents flows.
> >
> > Second, if we have two SNDUs with differents destinations, we can't put
> > them or their fragments in  the same mpeg2-tp, or we need a label for
> > each fragment added to the pointer which is specified in the last draft.
> >
> > Aniba.
> >
> > --
> > Ghassane ANIBA
> > INRIA (Projet PLANETE)             | Email :
> > ghassane.aniba at sophia.inria.fr
> > 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> > 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78
> >
>



From clausen at cosy.sbg.ac.at  Tue Apr 23 05:53:35 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Mon, 22 Apr 2002 21:53:35 -0700
Subject: Label_link
References: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC8EA@trebe004.NOE.Nokia.com> <3CC4210E.8F74DEC1@sophia.inria.fr>
Message-ID: <003801c1ea82$d36479f0$79068a81@nmttb97i6f89th>


----- Original Message -----
From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Monday, April 22, 2002 7:41 AM
Subject: Label_link


> harri.hakulinen at nokia.com wrote:
> >
> > Moro, It seems that we are approaching the point...
> >
> > If you put "Label" to TS level, you are really playing
> > the "ATM card", because you now have PID/Label pair in
> > comparison to VPI/VCI pair.
>
> It's not really the same. In the ATM we put many ATN cells in one
> MPEG2-TS packet, but here, we put only one label for each fragment of
> SNDU.
>
Do you put complete 53-byte ATM cells into one TS-packet or do you follow
the strategy which has been proposed some time ago to just take the payload
part of the ATM cell and map the ATM header to a TS header? "many" is either
3 or 4 - or did I understand this wrong?



> > In other words, that label can't really relate to individual
> > SNDU's, because they really are "inside the pipe".
>
> No, they are really outside :
>
> |----------------------------------------------------|
> |       SNDU                           |
> ------------------------------------------------------
>
> we will fragment the SNDU in many 181 octets:
>
> |------------------|-------------|------------------|
> |  MPEG2-TP Header | link_label  |  SNDU fragment   |
> |------------------|-------------|------------------|
>
> > If you want to switch SNDU's, you need to do it based on
> > a field that is inside SNDU...
>
> I'll use PID in the first level, and after we will use
> link_label.(because we can just filter 20 pid simultanously)
>
> >
> > //Harri
>
> Aniba.
>
> --
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78
>



From clausen at cosy.sbg.ac.at  Tue Apr 23 06:05:28 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Mon, 22 Apr 2002 22:05:28 -0700
Subject: New Descriptor.]
References: <3CC42317.C8B8744C@erg.abdn.ac.uk>
Message-ID: <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th>

From: "Gorry Fairhurst" <gorry at erg.abdn.ac.uk>
>
>
> Gorry Fairhurst wrote:
> >
> > Ghassane Aniba wrote:
> > >
> > > Hi,
> > > thanks to gorry for his explanation..
> > > For me, i'm thinking to give for each connection (source,groupe or
> > > destination) an unique identifier, which is (PID, @link_sat_adress):
> > >
> > > |-----------------|-------------------|----------------------|
> > > | mpeg2-tp header |  @link_sat_adress |  SNDU Fragment       |
> > > |-----------------|-------------------|----------------------|
> > >
> > > The  @link_ID, will be 3 bytes. we will use 20 of PID combination with
3
> > > bytes @link_sat_adress, which give us a 2^28 possible connections in
the
> > > same time.
> >
I think this is absolute overkill - to address 2^28 multicast groups or
individual stations in ONE PID stream is unrealistic. And remember: every
bit counts.

> Could the " @link_sat_adress" be an adaptation header of EACH TS
> Packet?
>
> If so, then  I think the combined (PID<label) looks very much as an
> ATM (VP,VCI) in a pure ATM networks and the DVB  satellite - or MPEG-2
> remux looks like an ATM VP_switch.
>
> In that case the thing you mark "SNDU" be a SNDU including header,
> and encapsulation  fields including length, type, CRC, etc. ?
>
> If so , we may be fairly near in terms of format? - and each TS Packet
> carries a part of a SNDU payload + encapsulation.
>
agree!
> >
> > >
> > > In the satellite we will have, a switching table
(PID, at link_sat_adress)
> > > --> List of spots.
> > >
that would make your switching table (theoretically) 2^13 * 2^28 = 2^41
=approx 4*10^13 entries - how do you intend to implement this for an
on-board switch?

> > > For informing about the mapping between (PID, at link_sat_adress) and the
> > > (source,destination), i will use a new Descriptor, called "
> > > channel_Descriptor", which will be as below:
> > >
> > > --------------------------------------
> > > Channel_Descriptor {
> > > descriptor_tag       8 bits
> > > descriptor_length    8 bits
> > > link_sat_adress      24 bits
> > > label_switching      32 bits
> > > adress_type           1 bit
> > > source_adress        32/48 bits
> > > group_adress         32/48 bits
> > > }
> > >
> > > -----------------------------
> > > this descriptor will be, if necessary, in the PMT table, with each PID
> > > reserved for IP traffic.
> > >
>
> - This seems like the signalling part.
>
> > > I presented here a general idea, and i hope sincerly that we could
> > > improve this idea.
> > > I hope that the new RFC of IP over DVB, will be more switable with the
> > > IP over DVB-S, and specialy with the IP Multicasting traffic over
> > > satellite with the OnBoard Processor.
>
> Multicast will be interesting... and probably non-trivial.
>
yes - but absolutely important.
And we must base it on realistic assumptions and keep the overhead low. Any
additional functionality required for specific services should go into a
"next level" or adaptation header - pretty much what RTP is doing which also
limits itself to the basic real time transport function.

> > > Thanks, and i'm waiting for all your remark or ask.
> > >
> > > --
> > > Ghassane ANIBA
> > > INRIA (Projet PLANETE)             | Email :
> > > ghassane.aniba at sophia.inria.fr
> > > 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> > > 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78
>



From Ghassane.Aniba at sophia.inria.fr  Tue Apr 23 09:19:45 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 23 Apr 2002 10:19:45 +0200
Subject: (4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th>
Message-ID: <3CC51921.809A3F1E@sophia.inria.fr>

Kearney wrote:
> 
> From: "Gorry Fairhurst" <gorry at erg.abdn.ac.uk>
> >
> >
> > Gorry Fairhurst wrote:
> > >
> > > Ghassane Aniba wrote:
> > > >
> > > > Hi,
> > > > thanks to gorry for his explanation..
> > > > For me, i'm thinking to give for each connection (source,groupe or
> > > > destination) an unique identifier, which is (PID, @link_sat_adress):
> > > >
> > > > |-----------------|-------------------|----------------------|
> > > > | mpeg2-tp header |  @link_sat_adress |  SNDU Fragment       |
> > > > |-----------------|-------------------|----------------------|
> > > >
> > > > The  @link_ID, will be 3 bytes. we will use 20 of PID combination with
> 3
> > > > bytes @link_sat_adress, which give us a 2^28 possible connections in
> the
> > > > same time.
> > >
> I think this is absolute overkill - to address 2^28 multicast groups or
> individual stations in ONE PID stream is unrealistic. And remember: every
> bit counts.

No, when i say that we'll map 2^28, i mean that we will use 4 bits from
PID and 24 bits which represent @link_sat_adress.
So we'll have for each PID 2^24, so what's the problem with that?

> > Could the " @link_sat_adress" be an adaptation header of EACH TS
> > Packet?
> >
> > If so, then  I think the combined (PID<label) looks very much as an
> > ATM (VP,VCI) in a pure ATM networks and the DVB  satellite - or MPEG-2
> > remux looks like an ATM VP_switch.
> >
> > In that case the thing you mark "SNDU" be a SNDU including header,
> > and encapsulation  fields including length, type, CRC, etc. ?
> >
> > If so , we may be fairly near in terms of format? - and each TS Packet
> > carries a part of a SNDU payload + encapsulation.
> >
> agree!
> > >
> > > >
> > > > In the satellite we will have, a switching table
> (PID, at link_sat_adress)
> > > > --> List of spots.
> > > >
> that would make your switching table (theoretically) 2^13 * 2^28 = 2^41
> =approx 4*10^13 entries - how do you intend to implement this for an
> on-board switch?

Absolutly not, we will have at the maximum 2^28 entries (4 bits for PID
* 24 bits from @link_sat_adress).

> 
> > > > For informing about the mapping between (PID, at link_sat_adress) and the
> > > > (source,destination), i will use a new Descriptor, called "
> > > > channel_Descriptor", which will be as below:
> > > >
> > > > --------------------------------------
> > > > Channel_Descriptor {
> > > > descriptor_tag       8 bits
> > > > descriptor_length    8 bits
> > > > link_sat_adress      24 bits
> > > > label_switching      32 bits
> > > > adress_type           1 bit
> > > > source_adress        32/48 bits
> > > > group_adress         32/48 bits
> > > > }
> > > >
> > > > -----------------------------
> > > > this descriptor will be, if necessary, in the PMT table, with each PID
> > > > reserved for IP traffic.
> > > >
> >
> > - This seems like the signalling part.
> >
> > > > I presented here a general idea, and i hope sincerly that we could
> > > > improve this idea.
> > > > I hope that the new RFC of IP over DVB, will be more switable with the
> > > > IP over DVB-S, and specialy with the IP Multicasting traffic over
> > > > satellite with the OnBoard Processor.
> >
> > Multicast will be interesting... and probably non-trivial.
> >
> yes - but absolutely important.
> And we must base it on realistic assumptions and keep the overhead low. Any
> additional functionality required for specific services should go into a
> "next level" or adaptation header - pretty much what RTP is doing which also
> limits itself to the basic real time transport function.

If we take in consideration, that most of IP packet are 1500 or 576, and
40 or 48, and with a simple calcul, we see that the overhead don't
affect.
One thing more, i'll present another schema of encapsulation, into
reduce the treatment on board the satellite.

> 
> > > > Thanks, and i'm waiting for all your remark or ask.
> > > >

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From Patrick.Cipiere at udcast.com  Tue Apr 23 09:22:12 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Tue, 23 Apr 2002 10:22:12 +0200
Subject: New Descriptor.]
In-Reply-To: <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th>
	(clausen@cosy.sbg.ac.at)
Message-ID: <200204230822.g3N8MC602422@ra.udcast.com>


"Kearney" <clausen at cosy.sbg.ac.at> wrote:

> I think this is absolute overkill - to address 2^28 multicast groups or
> individual stations in ONE PID stream is unrealistic. And remember: every
> bit counts.

How many addresses do you think is realistic?
I don't understand why we should not allow the full IP adresses scope
on one PID.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Ghassane.Aniba at sophia.inria.fr  Tue Apr 23 09:45:26 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 23 Apr 2002 10:45:26 +0200
Subject: Self routing
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th>
Message-ID: <3CC51F26.E6DDED05@sophia.inria.fr>

Hi,
i've a remark:
if we have 96% of traffic with 1500 or 576 bytes, and 40 or 48 bytes, we
found this:

if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
will have this results:

148 bytes free  ----->  1508 bytes (9 * 184 bytes)

152 bytes free  ----->   584 bytes (4*184 bytes)

128 bytes free  ----->   56 bytes ( 1 * 184 bytes)

136 bytes  free ----->   48 bytes ( 1 * 184 bytes)

this results confirm that we have enough space for adding our labels.
Although, if we though about using a pointer, and a @ling_sat for each
fragment of SNDU, we will have other results.

I'm thinking about adding another label, to the @link_sat_adress (I know
that most of us, will say that's a lot of overhead, but i'm sur that it
will be interesting).
The name of label, will be " label_sitching". if you remember the
descriptor which i've proposed, we foung this field.
For each MPEG2-TS packet we will add 4 bytes, for this new label. We
suppose that we have in maximum 32 spots. Each bit of the
label_switching in the MPEG2-TS packet, will specify if this spot is
concerned by this packet of not.
So, we will eliminate the switching table from satellite, and having in
her place, a smaller tables in each terrestrial terminal.

|---------------|------------|-----------------|------------------|
| Mpeg2 Header  | @link_sat  | label_switching |  SNDU fragment   |
|---------------|------------|-----------------|------------------|
     4 bytes       3 bytes        4 bytes             177 bytes

With this new label, we will find that the nombre of MPEG2-TS packet for
each SNDU didn't change.

Aniba.


-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From dent at cosy.sbg.ac.at  Tue Apr 23 09:58:11 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Tue, 23 Apr 2002 10:58:11 +0200 (MET DST)
Subject: New Descriptor.]
In-Reply-To: <200204230822.g3N8MC602422@ra.udcast.com>
Message-ID: <Pine.GSO.4.05.10204231046100.21900-100000@mausmaki.cosy.sbg.ac.at>

On Tue, 23 Apr 2002, Patrick Cipiere wrote:

> 
> "Kearney" <clausen at cosy.sbg.ac.at> wrote:
> 
> > I think this is absolute overkill - to address 2^28 multicast groups or
> > individual stations in ONE PID stream is unrealistic. And remember: every
> > bit counts.
> 
> How many addresses do you think is realistic?
> I don't understand why we should not allow the full IP adresses scope
> on one PID.

another related question would be: 

how does the correct scheme for segmenting the IP-address space
into PIDs look like.

and there are a couple of possible solutions (also remember there
	are receivers out there which are not capable of filtering
	2^13 PIDs)

1) put all the traffic in one PID
	+ simple implementation on the receiver side (just filter a
		single PID)
	- load on the receiver

2) put unicast inside one PID
   group multicast in several other PIDs
	+ (see above - at least for P2P connections)
	- for the unicast case, there's no easy way to
		do fast filtering (ar HW/FW level, without
		looking at the IP address - so the work
		needs to be done in the IP stack)

3) put every connection into a single PID (like PVCs)	
	- PID space exhaustion: possible problems with OBPs (like skyplex)
	- most existing receivers cannot HW-filter more than n-PIDs

all the above points share the need for an IP->PID table.

	tm
-- 
in some way i do, and in some way i don't.



From Ghassane.Aniba at sophia.inria.fr  Tue Apr 23 10:24:56 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 23 Apr 2002 11:24:56 +0200
Subject: Number of PID
References: <Pine.GSO.4.05.10204231046100.21900-100000@mausmaki.cosy.sbg.ac.at>
Message-ID: <3CC52868.10CB468C@sophia.inria.fr>

Thomas 'Dent' Mirlacher wrote:
> 
> On Tue, 23 Apr 2002, Patrick Cipiere wrote:
> 
> >
> > "Kearney" <clausen at cosy.sbg.ac.at> wrote:
> >
> > > I think this is absolute overkill - to address 2^28 multicast groups or
> > > individual stations in ONE PID stream is unrealistic. And remember: every
> > > bit counts.
> >
> > How many addresses do you think is realistic?
> > I don't understand why we should not allow the full IP adresses scope
> > on one PID.
> 
> another related question would be:
> 
> how does the correct scheme for segmenting the IP-address space
> into PIDs look like.
> 
> and there are a couple of possible solutions (also remember there
>         are receivers out there which are not capable of filtering
>         2^13 PIDs)

We will not use 2^13 PID. In the first time we'll use just 4 bits from
13 bits (20 PID), as you say, the receivers, until now, could only
filter 20 PID.
That's why i've said, we will have 2^28 connection (4 bits from PID and
24 from @link_sat)

> 
> 1) put all the traffic in one PID
>         + simple implementation on the receiver side (just filter a
>                 single PID)
>         - load on the receiver

We won't profit from the PID if we do like this.
In fthe future if the receivers, will be able to filter more PID, it
will be profitable for us, and we won't need any change in our schema.

> 
> 2) put unicast inside one PID
>    group multicast in several other PIDs
>         + (see above - at least for P2P connections)
>         - for the unicast case, there's no easy way to
>                 do fast filtering (ar HW/FW level, without
>                 looking at the IP address - so the work
>                 needs to be done in the IP stack)

Another problem, there isn't enough PID to do it.2^13.

> 
> 3) put every connection into a single PID (like PVCs)
>         - PID space exhaustion: possible problems with OBPs (like skyplex)
>         - most existing receivers cannot HW-filter more than n-PIDs

This is why we will just use i20 PID n the first time.

> 
> all the above points share the need for an IP->PID table.
> 
It's clear.

>         tm
> --
> in some way i do, and in some way i don't.

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From vze2prqh at verizon.net  Tue Apr 23 10:26:31 2002
From: vze2prqh at verizon.net (Marie-Jose Montpetit)
Date: Tue, 23 Apr 2002 05:26:31 -0400
Subject: Self routing
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51F26.E6DDED05@sophia.inria.fr>
Message-ID: <037101c1eaa8$f4bfcb60$0201a8c0@pavilion>

I would be worried to propose a scheme based on user traffic statistics of
today. Yes there are huge numbers of IPv4 ACK packets out there and yes a
ton of http: traffic too. This is April 2002. Deploy IPv6 in a grand scale
and the 40 bytes traffic will go down significantly. Non TCP or http: based
protocols will have other sizes, will they dominate? Don't know...

If we want to change MPE then the solution should be robust enough to
support the changes the other IETF groups will propose... BTW I would
recommend the group works on a draft on the requirements (look at what NSIS
did). It would foster a better discussion about what we are trying to
achieve here.

Marie-Jose


----- Original Message -----
From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
To: <ip-dvb at erg.abdn.ac.uk>
Sent: Tuesday, April 23, 2002 4:45 AM
Subject: Self routing


> Hi,
> i've a remark:
> if we have 96% of traffic with 1500 or 576 bytes, and 40 or 48 bytes, we
> found this:
>
> if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
> will have this results:
>
> 148 bytes free  ----->  1508 bytes (9 * 184 bytes)
>
> 152 bytes free  ----->   584 bytes (4*184 bytes)
>
> 128 bytes free  ----->   56 bytes ( 1 * 184 bytes)
>
> 136 bytes  free ----->   48 bytes ( 1 * 184 bytes)
>
> this results confirm that we have enough space for adding our labels.
> Although, if we though about using a pointer, and a @ling_sat for each
> fragment of SNDU, we will have other results.
>
> I'm thinking about adding another label, to the @link_sat_adress (I know
> that most of us, will say that's a lot of overhead, but i'm sur that it
> will be interesting).
> The name of label, will be " label_sitching". if you remember the
> descriptor which i've proposed, we foung this field.
> For each MPEG2-TS packet we will add 4 bytes, for this new label. We
> suppose that we have in maximum 32 spots. Each bit of the
> label_switching in the MPEG2-TS packet, will specify if this spot is
> concerned by this packet of not.
> So, we will eliminate the switching table from satellite, and having in
> her place, a smaller tables in each terrestrial terminal.
>
> |---------------|------------|-----------------|------------------|
> | Mpeg2 Header  | @link_sat  | label_switching |  SNDU fragment   |
> |---------------|------------|-----------------|------------------|
>      4 bytes       3 bytes        4 bytes             177 bytes
>
> With this new label, we will find that the nombre of MPEG2-TS packet for
> each SNDU didn't change.
>
> Aniba.
>
>
> --
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78



From gorry at erg.abdn.ac.uk  Tue Apr 23 12:02:27 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Tue, 23 Apr 2002 12:02:27 +0100
Subject: Self routing
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51F26.E6DDED05@sophia.inria.fr>
Message-ID: <3CC53F42.6F25F948@erg.abdn.ac.uk>

Marie-Jose Montpetit wrote <forwarded by admin for ip-dvb>:

I would be worried to propose a scheme based on user traffic statistics of
today. Yes there are huge numbers of IPv4 ACK packets out there and yes a
ton of http: traffic too. This is April 2002. Deploy IPv6 in a grand scale
and the 40 bytes traffic will go down significantly. Non TCP or http: based
protocols will have other sizes, will they dominate? Don't know...

If we want to change MPE then the solution should be robust enough to
support the changes the other IETF groups will propose... BTW I would
recommend the group works on a draft on the requirements (look at what NSIS
did). It would foster a better discussion about what we are trying to
achieve here.

Marie-Jose



Ghassane Aniba wrote:
> 
> Hi,
> i've a remark:
> if we have 96% of traffic with 1500 or 576 bytes, and 40 or 48 bytes, we
> found this:
> 
> if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
> will have this results:
> 
> 148 bytes free  ----->  1508 bytes (9 * 184 bytes)
> 
> 152 bytes free  ----->   584 bytes (4*184 bytes)
> 
> 128 bytes free  ----->   56 bytes ( 1 * 184 bytes)
> 
> 136 bytes  free ----->   48 bytes ( 1 * 184 bytes)
> 
> this results confirm that we have enough space for adding our labels.
> Although, if we though about using a pointer, and a @ling_sat for each
> fragment of SNDU, we will have other results.
> 
> I'm thinking about adding another label, to the @link_sat_adress (I know
> that most of us, will say that's a lot of overhead, but i'm sur that it
> will be interesting).
> The name of label, will be " label_sitching". if you remember the
> descriptor which i've proposed, we foung this field.
> For each MPEG2-TS packet we will add 4 bytes, for this new label. We
> suppose that we have in maximum 32 spots. Each bit of the
> label_switching in the MPEG2-TS packet, will specify if this spot is
> concerned by this packet of not.
> So, we will eliminate the switching table from satellite, and having in
> her place, a smaller tables in each terrestrial terminal.
> 
> |---------------|------------|-----------------|------------------|
> | Mpeg2 Header  | @link_sat  | label_switching |  SNDU fragment   |
> |---------------|------------|-----------------|------------------|
>      4 bytes       3 bytes        4 bytes             177 bytes
> 
> With this new label, we will find that the nombre of MPEG2-TS packet for
> each SNDU didn't change.
> 
> Aniba.
> 
> --
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Tue Apr 23 12:11:15 2002
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Tue, 23 Apr 2002 12:11:15 +0100
Subject: (4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51921.809A3F1E@sophia.inria.fr>
Message-ID: <3CC54153.B8D473F7@erg.abdn.ac.uk>



<<snip>>

> 
> If we take in consideration, that most of IP packet are 1500 or 576, and
> 40 or 48, and with a simple calcul, we see that the overhead don't
> affect.
> One thing more, i'll present another schema of encapsulation, into
> reduce the treatment on board the satellite.
> 

NOT a good starting point. We should also be addressing IPv6, and not constrain
the discussion to individual types of application. Some new applications have
very different packet length distributions.

The charter has also suggested we should consider compressed packet headers
which may significantly change things for the smaller packet sizes.

> >
> > > > > Thanks, and i'm waiting for all your remark or ask.
> > > > >
> 
> Aniba.
> 
> --
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From Ghassane.Aniba at sophia.inria.fr  Tue Apr 23 12:32:03 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 23 Apr 2002 13:32:03 +0200
Subject: Solution for IPv6
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51921.809A3F1E@sophia.inria.fr> <3CC54153.B8D473F7@erg.abdn.ac.uk>
Message-ID: <3CC54633.AC4C49F7@sophia.inria.fr>

Gorry Fairhurst wrote:
> 
> <<snip>>
> 
> >
> > If we take in consideration, that most of IP packet are 1500 or 576, and
> > 40 or 48, and with a simple calcul, we see that the overhead don't
> > affect.
> > One thing more, i'll present another schema of encapsulation, into
> > reduce the treatment on board the satellite.
> >
> 
> NOT a good starting point. We should also be addressing IPv6, and not constrain
> the discussion to individual types of application. Some new applications have
> very different packet length distributions.
> 

In my opinion, to propose a good and the best solution, we must wait for
the satistics of the deployment of IPv6.
The proposed encapsulation don't depend totaly on the lenght of the IP
packets. I agree that if we change the lenght, we'll have other values,
but it don't mean that it's a problem for us.

> The charter has also suggested we should consider compressed packet headers
> which may significantly change things for the smaller packet sizes.
> 
> > >
> > > > > > Thanks, and i'm waiting for all your remark or ask.
> > > > > >
> >
> > Aniba.
> >

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From vze2prqh at verizon.net  Tue Apr 23 22:03:15 2002
From: vze2prqh at verizon.net (Marie-Jose Montpetit)
Date: Tue, 23 Apr 2002 17:03:15 -0400
Subject: What are we trying to do?
Message-ID: <005601c1eb0a$4c77bb40$0201a8c0@pavilion>

I've been following the list for quite a while. The discussions are great
but I worry that we are forgetting a bit what we are trying to achieve here.
Especially, if we want to submit this to the transport people in the IETF,
we need so know exactly what the result of our WG will be. I tend to agree
that changing a standard for a trickle of improvement is not worthwhile. If
this small improvement however comes with a lot of added flexibility and
added interworking with other people then great!

So here is my shopping list of requirements/questions to ask ourselves.
Maybe this will evolve in a requirements ID so feel free to trash.

1. What satellite network  topology are we talking about
seems an idiotic question but I think some of the discussion we have had on
the use of PIDs and connectionless/connection oriented is related to the
overall topology; where are the switches/routers, are the PIDS rewritten
anywhere?
I can think of a few basic architectures:
- standard bentpipe with gateways: the users are "hidden" behind the
gateway; really the easy architecture and the ones I suppose favored by the
original broadcasters; in this really there is one fat pipe
- multiple gateways - more interesting since then you can get in mux/demux
issues and multicasting; this scales to the case where you have meshed
terminals that act one side as satellite gateways and the other as routers;
cute issues of return channel and satellite to MAC to IP addressing; the IP
DVB people have looked at that a lot when Patrick Schnell was there.
- meshed topology with onboard processing - much more addressing challenges!
Switching onboard creates interesting questions for the use of DVB; BTW the
usual "VC" is to link an uplink cell to a downlink beam in essence creating
a satellite switching from uplink to downlink (hence my question on
re-writing PIDs on board)
there are probably other architectures and variants of the above... the
DVB-T people may have other topologies...
2. What services are we transporting?
The discussion this morning about IPv6 was interesting... I think the
services should be looked into more closely than just unicast-multicast.
Satellites can be used for many things and if we want to be part of the
mobile-ip infrastructure then IPv6 is a requirement... But is it? I think we
need a list of things we will transport and to go a bit beyond the usual VBR
traffic for multimedia... Also it would help define what we need in terms of
QoS and availability of the service - a big thing as you know if you go Ka
band
3. Where are the users?
If we do not have direct access to the end users then we should look
carefully at addressing and not make it overly complicated. I have the
mentality that the routers above us are fast at IP routing and cheap and we
should not try to do their jobs; also filtering on too many addresses could
be interesting in another way: are we going to have a satellite-BGP-like
architecture?
4. Where are we in the stack?
We seem to discuss disparately about link, MAC, network... I suppose the new
encapsulation would be both link and MAC; the Internet works so maybe we
want to leave the upper layer alone except in terms of intercepting QoS?
5. QoS
How are we going to use TOS or RSVP or whatever NSIS comes up with (are we
monitoring them?);  do we want to do inband or out of band signaling/setup
ahead a flow?
6. Related to above: end to end delay
We need a delay budget that includes the end to end: modulation, coding etc.
not just segmentation. Then we may find that
for certain VBR services that have tight jitter requirements sending a 1/2
empty packet is the only way to meet the QoS. Yes wasted bandwidth but added
revenues...

I think I could go on forever... Could be fun to see what the DVB-T and even
the cable people have to say. Also the people on commercial implementations,
speak up! The new encapsulation should enable new services yes but also I
suppose increased revenues somewhere.

BTW about the IPR issues: there are patented protocols in the Internet (Real
and RTSP I think for example) and tag switching and MPLS probably have
specifics patented by one company or another.

Sorry for this long email. I've been off for a long time (maybe that was a
good thing?).

Marie-Jose
marie at mjmontpetit.com





From clausen at cosy.sbg.ac.at  Wed Apr 24 03:15:15 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Tue, 23 Apr 2002 19:15:15 -0700
Subject: (4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51921.809A3F1E@sophia.inria.fr>
Message-ID: <006701c1eb35$df800e30$79068a81@nmttb97i6f89th>

 From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
Sent: Tuesday, April 23, 2002 1:19 AM
Subject: (4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.


.....SNIP.
>
> If we take in consideration, that most of IP packet are 1500 or 576, and
> 40 or 48, and with a simple calcul, we see that the overhead don't
> affect.
> One thing more, i'll present another schema of encapsulation, into
> reduce the treatment on board the satellite.
>
We should not base an encapsulation design on the momentarily observed
packet statistics - as has been pointed out by several people, this might
change very quickly.
Furthermore, when we start packing - and with a 184 byte payload field this
seems advisable, then your argument

> if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
..... assume for example a FTP transfer of a file of 100KByte
>
> 152 bytes free  ----->   584 bytes (4*184 bytes)
>
 leads to the following comparison:
without packing you transmit a total of 126,592 (give or take a few) Bytes,
with packing you transfer 100,096 bytes (give or take a few, depending on
your encapsulation)
and that IS a significant difference.

if you think that is too big - take 10KB in which case the number come out
to 13,248/10,120.

--Horst


BTW I don't seem to get all your messages - from Gorrys replies I can see
that I am missing some.



From clausen at cosy.sbg.ac.at  Wed Apr 24 03:24:57 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Tue, 23 Apr 2002 19:24:57 -0700
Subject: New Descriptor.]
References: <Pine.GSO.4.05.10204231046100.21900-100000@mausmaki.cosy.sbg.ac.at>
Message-ID: <007301c1eb37$3a780f80$79068a81@nmttb97i6f89th>

 From: "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at>
Sent: Tuesday, April 23, 2002 1:58 AM
Subject: Re: New Descriptor.]


> On Tue, 23 Apr 2002, Patrick Cipiere wrote:
>
> >
> > "Kearney" <clausen at cosy.sbg.ac.at> wrote:
> >
> > > I think this is absolute overkill - to address 2^28 multicast groups
or
> > > individual stations in ONE PID stream is unrealistic. And remember:
every
> > > bit counts.
> >
> > How many addresses do you think is realistic?
> > I don't understand why we should not allow the full IP adresses scope
> > on one PID.
>
> another related question would be:
>
> how does the correct scheme for segmenting the IP-address space
> into PIDs look like.
>
Question: how does the scheme for segmenting NSAP or E.164 addresses into
ATM VP/VC connection IDs look?
What we really need is a solution for mapping IP addresses to either local
subnetwork addresses (connectionless) or to connecti0on_IDs (labels -
connection-oriented) and, of course, multicast groups.

> and there are a couple of possible solutions (also remember there
> are receivers out there which are not capable of filtering
> 2^13 PIDs)
>
> 1) put all the traffic in one PID
> + simple implementation on the receiver side (just filter a
> single PID)
> - load on the receiver
>
> 2) put unicast inside one PID
>    group multicast in several other PIDs
> + (see above - at least for P2P connections)
> - for the unicast case, there's no easy way to
> do fast filtering (ar HW/FW level, without
> looking at the IP address - so the work
> needs to be done in the IP stack)
>
> 3) put every connection into a single PID (like PVCs)
> - PID space exhaustion: possible problems with OBPs (like skyplex)
> - most existing receivers cannot HW-filter more than n-PIDs
>
> all the above points share the need for an IP->PID table.
>
not quite: IP->local subnetwork address ("LSA" - classical Internet datagram
philosophy), and then LSA->PID
or  IP -> local subnetwork connection_ID ("label" - see MPLS), and then
Label -> PID
> tm
> --
> in some way i do, and in some way i don't.
>
--



From clausen at cosy.sbg.ac.at  Wed Apr 24 03:30:51 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Tue, 23 Apr 2002 19:30:51 -0700
Subject: Number of PID
References: <Pine.GSO.4.05.10204231046100.21900-100000@mausmaki.cosy.sbg.ac.at> <3CC52868.10CB468C@sophia.inria.fr>
Message-ID: <007901c1eb38$0d48b810$79068a81@nmttb97i6f89th>

From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
Sent: Tuesday, April 23, 2002 2:24 AM
Subject: Number of PID


> Thomas 'Dent' Mirlacher wrote:
...
SNIP
...
> > and there are a couple of possible solutions (also remember there
> >         are receivers out there which are not capable of filtering
> >         2^13 PIDs)
>
> We will not use 2^13 PID. In the first time we'll use just 4 bits from
> 13 bits (20 PID), as you say, the receivers, until now, could only
> filter 20 PID.
> That's why i've said, we will have 2^28 connection (4 bits from PID and
> 24 from @link_sat)
>
> >
> > 1) put all the traffic in one PID
> >         + simple implementation on the receiver side (just filter a
> >                 single PID)
> >         - load on the receiver
>
> We won't profit from the PID if we do like this.
> In fthe future if the receivers, will be able to filter more PID, it
> will be profitable for us, and we won't need any change in our schema.
>
in the future faster chips might allow you to scan more than 20 PIDs
simultaneously but certainly not one or two orders of magnitude more
and in the future you might encounter higher data rates from the channel
which would compensate the increase in processing speed


> >
> > 2) put unicast inside one PID
> >    group multicast in several other PIDs
> >         + (see above - at least for P2P connections)
> >         - for the unicast case, there's no easy way to
> >                 do fast filtering (ar HW/FW level, without
> >                 looking at the IP address - so the work
> >                 needs to be done in the IP stack)
>
> Another problem, there isn't enough PID to do it.2^13.
>
the way in which Ethernet treats IP multicast address binding is not the
only way in which this could be done - how are ATM networks doing this?

> >
> > 3) put every connection into a single PID (like PVCs)
> >         - PID space exhaustion: possible problems with OBPs (like
skyplex)
> >         - most existing receivers cannot HW-filter more than n-PIDs
>
> This is why we will just use i20 PID n the first time.
>
> >
> > all the above points share the need for an IP->PID table.
> >
> It's clear.
>
> >         tm
> > --
> > in some way i do, and in some way i don't.
>
> Aniba.
>
SNIP

--cls



From clausen at cosy.sbg.ac.at  Wed Apr 24 03:42:18 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Tue, 23 Apr 2002 19:42:18 -0700
Subject: Self routing
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51F26.E6DDED05@sophia.inria.fr> <3CC53F42.6F25F948@erg.abdn.ac.uk>
Message-ID: <007f01c1eb39$a688a200$79068a81@nmttb97i6f89th>

From: "Gorry Fairhurst" <gorry at erg.abdn.ac.uk>
Sent: Tuesday, April 23, 2002 4:02 AM
Subject: Re: Self routing


> Marie-Jose Montpetit wrote <forwarded by admin for ip-dvb>:
>
> I would be worried to propose a scheme based on user traffic statistics of
> today. Yes there are huge numbers of IPv4 ACK packets out there and yes a
> ton of http: traffic too. This is April 2002. Deploy IPv6 in a grand scale
> and the 40 bytes traffic will go down significantly. Non TCP or http:
based
> protocols will have other sizes, will they dominate? Don't know...
>
> If we want to change MPE then the solution should be robust enough to
> support the changes the other IETF groups will propose... BTW I would
> recommend the group works on a draft on the requirements (look at what
NSIS
> did). It would foster a better discussion about what we are trying to
> achieve here.
>
> Marie-Jose
>
I don't think we want to change MPE but come up with an alternative, more
efficient and more flexible solution.
I agree with Gorry and Harri concerning header compression - we should keep
this in mind and come up with a design that fully supports it, but we should
not include it in the encapsulation.


>
>
> Ghassane Aniba wrote:
> >
> > Hi,
> > i've a remark:
> > if we have 96% of traffic with 1500 or 576 bytes, and 40 or 48 bytes, we
> > found this:
> >
> > if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
> > will have this results:
> >
> > 148 bytes free  ----->  1508 bytes (9 * 184 bytes)
> >
> > 152 bytes free  ----->   584 bytes (4*184 bytes)
> >
> > 128 bytes free  ----->   56 bytes ( 1 * 184 bytes)
> >
> > 136 bytes  free ----->   48 bytes ( 1 * 184 bytes)
> >
> > this results confirm that we have enough space for adding our labels.
> > Although, if we though about using a pointer, and a @ling_sat for each
> > fragment of SNDU, we will have other results.
> >
> > I'm thinking about adding another label, to the @link_sat_adress (I know
> > that most of us, will say that's a lot of overhead, but i'm sur that it
> > will be interesting).
> > The name of label, will be " label_sitching". if you remember the
> > descriptor which i've proposed, we foung this field.
> > For each MPEG2-TS packet we will add 4 bytes, for this new label. We
> > suppose that we have in maximum 32 spots. Each bit of the
> > label_switching in the MPEG2-TS packet, will specify if this spot is
> > concerned by this packet of not.
> > So, we will eliminate the switching table from satellite, and having in
> > her place, a smaller tables in each terrestrial terminal.
> >
> > |---------------|------------|-----------------|------------------|
> > | Mpeg2 Header  | @link_sat  | label_switching |  SNDU fragment   |
> > |---------------|------------|-----------------|------------------|
> >      4 bytes       3 bytes        4 bytes             177 bytes
> >
> > With this new label, we will find that the nombre of MPEG2-TS packet for
> > each SNDU didn't change.
> >
> > Aniba.
I like this 177 bytes number - this fits very well into todays 16/32 aligned
architectures and makes for efficient moves.

one more point: you said that you only use 4 bits of the 13 bits of the PID
since your hardware can scan only a maximum of 20 PIDs - who or what is
scanning your 24 bits of the link_sat field? I suppose this is a separate
box - i.e. one protocol layer up.

--cls



From clausen at cosy.sbg.ac.at  Wed Apr 24 03:47:47 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Tue, 23 Apr 2002 19:47:47 -0700
Subject: Solution for IPv6
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51921.809A3F1E@sophia.inria.fr> <3CC54153.B8D473F7@erg.abdn.ac.uk> <3CC54633.AC4C49F7@sophia.inria.fr>
Message-ID: <008701c1eb3a$6ab98c20$79068a81@nmttb97i6f89th>

From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
Sent: Tuesday, April 23, 2002 4:32 AM
Subject: Solution for IPv6


> Gorry Fairhurst wrote:
> >
> > <<snip>>
> >
> > >
> > > If we take in consideration, that most of IP packet are 1500 or 576,
and
> > > 40 or 48, and with a simple calcul, we see that the overhead don't
> > > affect.
> > > One thing more, i'll present another schema of encapsulation, into
> > > reduce the treatment on board the satellite.
> > >
> >
> > NOT a good starting point. We should also be addressing IPv6, and not
constrain
> > the discussion to individual types of application. Some new applications
have
> > very different packet length distributions.
> >
>
> In my opinion, to propose a good and the best solution, we must wait for
> the satistics of the deployment of IPv6.
> The proposed encapsulation don't depend totaly on the lenght of the IP
> packets. I agree that if we change the lenght, we'll have other values,
> but it don't mean that it's a problem for us.
>
I disagree - we should NOT base the design on a parameter value which could
(and will) change such as packet statistics. We should comu up with a
flexible design that can support different services. Please take a look at
the RTP design, for example, for a flexible and lean protocol design.


> > The charter has also suggested we should consider compressed packet
headers
> > which may significantly change things for the smaller packet sizes.
> >
we should keep in mind that header compression might be required by some
services but this should not be included in the design of an encapsulation
for a link/subnetwork level.

--cls



From dent at cosy.sbg.ac.at  Wed Apr 24 08:01:03 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Wed, 24 Apr 2002 09:01:03 +0200 (MET DST)
Subject: Self routing
In-Reply-To: <007f01c1eb39$a688a200$79068a81@nmttb97i6f89th>
Message-ID: <Pine.GSO.4.05.10204240851270.22636-100000@mausmaki.cosy.sbg.ac.at>

--snip/snip

> I don't think we want to change MPE but come up with an alternative, more
> efficient and more flexible solution.

which set of requirements in mind? MPE probably is not the best solution,
but it works.
it is layer2+layer3, and your proposal would be layer3 - which is fine, 
if you have a specific set of services you'd like to support, but you'll
have troubles supporting a different set of services in an efficient way.

> I agree with Gorry and Harri concerning header compression - we should keep
> this in mind and come up with a design that fully supports it, but we should
> not include it in the encapsulation.

right. - shouldn't the encapsulation just encapsulate the upper layers
(e.g. IP - which is know to work, and cannot be the layer we'd like to
change here), and do it in an efficient way (not only bandwith/troughput-wise,
but also in respect for possible other QoS requirements)

--snip/snip
> one more point: you said that you only use 4 bits of the 13 bits of the PID
> since your hardware can scan only a maximum of 20 PIDs - who or what is
> scanning your 24 bits of the link_sat field? I suppose this is a separate
> box - i.e. one protocol layer up.

one problem is the misuse of the PID here - well or probably i simply don't
understand the usage of the PID in your case.
the PID is used for segmenting the physical channel into several logical
ones, and if you reassign the meaning of the PID for beeing part of your
label thats fine for you, but on a transponder where video and data is
mixed, you run into a strange ituation where the PID is used in two
different ways at once. 

	++Thomas

-- 
in some way i do, and in some way i don't.



From Ghassane.Aniba at sophia.inria.fr  Wed Apr 24 09:35:51 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Wed, 24 Apr 2002 10:35:51 +0200
Subject: (4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51921.809A3F1E@sophia.inria.fr> <006701c1eb35$df800e30$79068a81@nmttb97i6f89th>
Message-ID: <3CC66E67.1CDB77C3@sophia.inria.fr>

Kearney wrote:
> 
>  From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
> Sent: Tuesday, April 23, 2002 1:19 AM
> Subject: (4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.
> 
> .....SNIP.
> >
> > If we take in consideration, that most of IP packet are 1500 or 576, and
> > 40 or 48, and with a simple calcul, we see that the overhead don't
> > affect.
> > One thing more, i'll present another schema of encapsulation, into
> > reduce the treatment on board the satellite.
> >
> We should not base an encapsulation design on the momentarily observed
> packet statistics - as has been pointed out by several people, this might
> change very quickly.
> Furthermore, when we start packing - and with a 184 byte payload field this
> seems advisable, then your argument
> 
> > if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
> ..... assume for example a FTP transfer of a file of 100KByte
> >
> > 152 bytes free  ----->   584 bytes (4*184 bytes)
> >
>  leads to the following comparison:
> without packing you transmit a total of 126,592 (give or take a few) Bytes,
> with packing you transfer 100,096 bytes (give or take a few, depending on
> your encapsulation)
> and that IS a significant difference.
> 

I totaly agree with you, but this encapsulation, until now, is the
unique wich give us possibility to switch mpeg2-TS. with other ther
encapsulation, we have to reassembly the fragments of packet, if we want
switching it.
It's sur that it takes a lot of places, but this propose a new
possibilities like switching onboard satellite.

> if you think that is too big - take 10KB in which case the number come out
> to 13,248/10,120.
> 
> --Horst
> 
> BTW I don't seem to get all your messages - from Gorrys replies I can see
> that I am missing some.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From Ghassane.Aniba at sophia.inria.fr  Wed Apr 24 09:43:13 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Wed, 24 Apr 2002 10:43:13 +0200
Subject: Self routing
References: <3CC42317.C8B8744C@erg.abdn.ac.uk> <003e01c1ea84$7c9903f0$79068a81@nmttb97i6f89th> <3CC51F26.E6DDED05@sophia.inria.fr> <3CC53F42.6F25F948@erg.abdn.ac.uk> <007f01c1eb39$a688a200$79068a81@nmttb97i6f89th>
Message-ID: <3CC67021.E49828DE@sophia.inria.fr>

Kearney wrote:

> I like this 177 bytes number - this fits very well into todays 16/32 aligned
> architectures and makes for efficient moves.

It's not the most important problem (16/32 alligned), if we stand that
it's important to use this encapsulation, we will use 176 bytes.
Which is important now, is to propose different possibilities of
encapsulation, which solves and give us possibility to :
-> identify the connection
-> to switch the mpeg2-Ts packet.
-> to have less overhead.
-> and which is adapted to the multicast flows.

> 
> one more point: you said that you only use 4 bits of the 13 bits of the PID
> since your hardware can scan only a maximum of 20 PIDs - who or what is
> scanning your 24 bits of the link_sat field? I suppose this is a separate
> box - i.e. one protocol layer up.

As i know, the receiver could just filter 20 PID by Hardware, but he can
filter more by software. the PID will be filtred by the hardware
implementation, and the @link_sat, by software.
> 
> --cls

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From Patrick.Cipiere at udcast.com  Wed Apr 24 13:20:11 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Wed, 24 Apr 2002 14:20:11 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
Message-ID: <200204241220.g3OCKBK04561@ra.udcast.com>

I am pretty much OK with what is said about the packing, but today,
the mpeg2 transport packets I am dealing with, do not use the
adaptation field, but just use the first byte of the transport packet
payload as an offset if PUSI bit is 1.
Of course doing this, breaks the 32 bits alignment.
If we think we need to respect this alignment, having this offset == 3
might do the job.
I am not sure we have to use the 32 bits AFC in all cases.
If saving bits is the goal, let's keep a single byte offset.

I have a lot of concerns about the lack of layer 2 adresses in the new
design.
I think there are a lot of situations where we need layer 2 MAC
addresses in the datagram:
Without layer 2 destination address, the filtering has to be done at
layer 3.
Without layer 2 destination address, what will be the behaviour of a
router receiving a layer 3 packet.
Without layer 2 source address, how do we recognize our own datagrams,
when we get them back on the link several ms after sending them.
...

If we are really convinced that in some cases either the destination
and/or source MAC address are uneeded, and if the goal is to save some
bits not having them, we could use 2 bits out of the length field
The length field would then be 14 bits ([0,16383])
MAC_FLAG

00 : no dst MAC, no src MAC
01 : dst MAC, no src MAC
10 : src MAC, no dst MAC
11 : dst MAC, src MAC

MAC is IEEE 48 bits
no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff

+--+--------------+----------------+----------
|00|    length    |      type      |Payload
+--+--------------+----------------+----------

+--+--------------+----------------+-----------  --+----------
|01|    length    |      type      |48 bits dst ~  | Paylaod
+--+--------------+----------------+-----------  --+----------

+--+--------------+----------------+-----------  --+----------
|10|    length    |      type      |48 bits src  ~ | Paylaod
+--+--------------+----------------+-----------  --+----------

+--+--------------+----------------+-----------  --+-----------  --+---------
|11|    length    |      type      |48 bits dst ~  |48 bits src ~  |Payload
+--+--------------+----------------+-----------  --+-----------  --+---------


Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Patrick.Cipiere at udcast.com  Wed Apr 24 13:34:23 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Wed, 24 Apr 2002 14:34:23 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC4257E.65958B0@erg.abdn.ac.uk> (message from Gorry Fairhurst
	on Mon, 22 Apr 2002 16:00:11 +0100)
Message-ID: <200204241234.g3OCYNt04566@ra.udcast.com>


Gorry wrote:

>> > 0x???? : Bridged Ethernet Frame
>> 
>> I would recommend 0x6558 (Transparent Ethernet Bridging)
>>

> What do you think the FCS should contain? 

If you are talking about the ethernet FCS, this is an interesting
question, and I think we have to make things clear about that.
So the question is: does packets with EtherType 0x6558 (Transparent
Ethernet Bridging) have a 4 bytes FCS?
I have been chasing this answer for several years, and it looks like
nobody has the answer.
So my answer, so far, is no FCS for the encapsulated ethernet packet.
However we should use the LAN FCS defined in the draft.

> Should the SNDU include an Ethernet padding (I assume this doesn't matter)?

I am not sure to understand what you mean. So I guess we do not need
padding.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Ghassane.Aniba at sophia.inria.fr  Wed Apr 24 13:41:52 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Wed, 24 Apr 2002 14:41:52 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <200204241220.g3OCKBK04561@ra.udcast.com>
Message-ID: <3CC6A810.1DF67303@sophia.inria.fr>

Patrick Cipiere wrote:
> 
> I am pretty much OK with what is said about the packing, but today,
> the mpeg2 transport packets I am dealing with, do not use the
> adaptation field, but just use the first byte of the transport packet
> payload as an offset if PUSI bit is 1.
> Of course doing this, breaks the 32 bits alignment.
> If we think we need to respect this alignment, having this offset == 3
> might do the job.
> I am not sure we have to use the 32 bits AFC in all cases.
> If saving bits is the goal, let's keep a single byte offset.
> 
> I have a lot of concerns about the lack of layer 2 adresses in the new
> design.
> I think there are a lot of situations where we need layer 2 MAC
> addresses in the datagram:
> Without layer 2 destination address, the filtering has to be done at
> layer 3.
> Without layer 2 destination address, what will be the behaviour of a
> router receiving a layer 3 packet.
> Without layer 2 source address, how do we recognize our own datagrams,
> when we get them back on the link several ms after sending them.
> ...
> 
> If we are really convinced that in some cases either the destination
> and/or source MAC address are uneeded, and if the goal is to save some
> bits not having them, we could use 2 bits out of the length field
> The length field would then be 14 bits ([0,16383])
> MAC_FLAG
> 
> 00 : no dst MAC, no src MAC
> 01 : dst MAC, no src MAC
> 10 : src MAC, no dst MAC
> 11 : dst MAC, src MAC
> 
> MAC is IEEE 48 bits
> no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
> 
> +--+--------------+----------------+----------
> |00|    length    |      type      |Payload
> +--+--------------+----------------+----------
> 
> +--+--------------+----------------+-----------  --+----------
> |01|    length    |      type      |48 bits dst ~  | Paylaod
> +--+--------------+----------------+-----------  --+----------
> 
> +--+--------------+----------------+-----------  --+----------
> |10|    length    |      type      |48 bits src  ~ | Paylaod
> +--+--------------+----------------+-----------  --+----------
> 
> +--+--------------+----------------+-----------  --+-----------  --+---------
> |11|    length    |      type      |48 bits dst ~  |48 bits src ~  |Payload
> +--+--------------+----------------+-----------  --+-----------  --+---------
> 
> Patrick.
But for the satellite network, how we can switch MPEG2-TS packet
onboard?

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Wed Apr 24 13:54:51 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Wed, 24 Apr 2002 13:54:51 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <200204241234.g3OCYNt04566@ra.udcast.com>
Message-ID: <3CC6AB1A.55E58E04@erg.abdn.ac.uk>



Patrick Cipiere wrote:
> 
> Gorry wrote:
> 
> >> > 0x???? : Bridged Ethernet Frame
> >>
> >> I would recommend 0x6558 (Transparent Ethernet Bridging)
> >>
> 
> > What do you think the FCS should contain?
> 
> If you are talking about the ethernet FCS, this is an interesting
> question, and I think we have to make things clear about that.
> So the question is: does packets with EtherType 0x6558 (Transparent
> Ethernet Bridging) have a 4 bytes FCS?
> I have been chasing this answer for several years, and it looks like
> nobody has the answer.
> So my answer, so far, is no FCS for the encapsulated ethernet packet.
> However we should use the LAN FCS defined in the draft.
> 
> > Should the SNDU include an Ethernet padding (I assume this doesn't matter)?
> 
> I am not sure to understand what you mean. So I guess we do not need
> padding.

Just to be sure... A small payload will normally be padded to the 
Ethernet Minimum frame size - this involves sending padding bytes to
make the frame >= 64B (incl 4B FCS).

IP devices normally ignore this padding.

Some remote bridges don't do IP-level processing, and therefore
forward the payload and also the padding - particularly those devices
which also forward the original LAN FCS.

I guess if the frame has a length field (i.e. LLC) then, it's easy
for bridges to spot the padding, with DIX format frames, this is less easy.

> 
> Patrick.
> --
> UDcast: Full IP over Broadcast Media
> 
> Phone:  (+33) (0)4 93 00 16 99
> Mobile: (+33) (0)6 14 21 55 98
> Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Patrick.Cipiere at udcast.com  Wed Apr 24 14:35:31 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Wed, 24 Apr 2002 15:35:31 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC6AB1A.55E58E04@erg.abdn.ac.uk> (message from Dr G Fairhurst
	on Wed, 24 Apr 2002 13:54:51 +0100)
Message-ID: <200204241335.g3ODZVZ04711@ra.udcast.com>

Gorry wrote:

> Just to be sure... A small payload will normally be padded to the 
> Ethernet Minimum frame size - this involves sending padding bytes to
> make the frame >= 64B (incl 4B FCS).

Got the point.
My understanding: the padding is only needed at the physical layer, so
I think in our design there is no use to add padding because in this
case ethernet is not at the physical layer.

mpeg2, MPE and the new design will have their own padding if needed.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From l.wood at eim.surrey.ac.uk  Wed Apr 24 14:51:09 2002
From: l.wood at eim.surrey.ac.uk (Lloyd Wood)
Date: Wed, 24 Apr 2002 14:51:09 +0100 (BST)
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <200204241335.g3ODZVZ04711@ra.udcast.com>
Message-ID: <Pine.SOL.4.43.0204241444290.25444-100000@artemis.ee.surrey.ac.uk>

On Wed, 24 Apr 2002, Patrick Cipiere wrote:

> Gorry wrote:
>
> > Just to be sure... A small payload will normally be padded to the
> > Ethernet Minimum frame size - this involves sending padding bytes to
> > make the frame >= 64B (incl 4B FCS).
>
> Got the point.
> My understanding: the padding is only needed at the physical layer, so
> I think in our design there is no use to add padding because in this
> case ethernet is not at the physical layer.

you might want to take a look at the martini drafts in mpls/pwe3,
which have been making a Big Thing of the ethernet padding.

draft-martini-l2circuit-encap-mpls has a fixup length field to cater
just for this, rather than having a sensible per-payload length field:

   The next 6 bits provide a length field, which is used as follows: If
   the packet's length (defined as the length of the layer 2 payload
   plus the length of the control word) is less than 64 bytes, the
   length field MUST be set to the packet's length. Otherwise the length
   field MUST be set to zero. The value of the length field, if non-
   zero, can be used to remove any padding. When the packet reaches the
   service provider's egress router, it may be desirable to remove the
   padding before forwarding the packet.

lots of heated discussion of this on the pwe3 list.

L.

> mpeg2, MPE and the new design will have their own padding if needed.
>
> Patrick.
> --
> UDcast: Full IP over Broadcast Media
>
> Phone:  (+33) (0)4 93 00 16 99
> Mobile: (+33) (0)6 14 21 55 98
> Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com
>

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>



From clausen at cosy.sbg.ac.at  Thu Apr 25 00:54:14 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Wed, 24 Apr 2002 16:54:14 -0700
Subject: Self routing
References: <Pine.GSO.4.05.10204240851270.22636-100000@mausmaki.cosy.sbg.ac.at>
Message-ID: <00bb01c1ebeb$567ae0e0$79068a81@nmttb97i6f89th>

From: "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at>
Sent: Wednesday, April 24, 2002 12:01 AM
Subject: Re: Self routing


> --snip/snip
>
> > I don't think we want to change MPE but come up with an alternative,
more
> > efficient and more flexible solution.
>
> which set of requirements in mind? MPE probably is not the best solution,
> but it works.
> it is layer2+layer3, and your proposal would be layer3 - which is fine,
> if you have a specific set of services you'd like to support, but you'll
> have troubles supporting a different set of services in an efficient way.
>
would you, please, define what you mean with "layer 3"  -  why is an
encapsulation layer three, what functionality do you see that belongs into
the "network lauer"??

--cls



From clausen at cosy.sbg.ac.at  Thu Apr 25 06:20:47 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Wed, 24 Apr 2002 22:20:47 -0700
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <200204241220.g3OCKBK04561@ra.udcast.com>
Message-ID: <00c901c1ec18$f54c19a0$79068a81@nmttb97i6f89th>

From: "Patrick Cipiere" <Patrick.Cipiere at udcast.com>
Sent: Wednesday, April 24, 2002 5:20 AM
Subject: Re: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt


> I am pretty much OK with what is said about the packing, but today,
> the mpeg2 transport packets I am dealing with, do not use the
> adaptation field, but just use the first byte of the transport packet
> payload as an offset if PUSI bit is 1.
> Of course doing this, breaks the 32 bits alignment.
> If we think we need to respect this alignment, having this offset == 3
> might do the job.
> I am not sure we have to use the 32 bits AFC in all cases.
> If saving bits is the goal, let's keep a single byte offset.
>
This is an important point. If you look at my draft - I had indicated that
using the standard adaptation field format of four bytes might be required
due to compatibility with the MPEG-2 standard.  I have looked very carefully
at the 13818-1 document but nowhere could I find an indication of how the
AFC bits have to be treated or can be treated for "private data". Tables
2.2, 2.5  and 2.6 of this document seem to require that the syntax of the
adaptation field be adhered to - and this would mean we have to insert all 4
bytes. If this is NOT the case, we are free to make a different choice.
Looking at 2.4.3.5 - where the semantics for adaptation fields used in PES
packets is defined one could interpret this as allowing to override the
4-byte form - how else would you carry 2 or 3 padding bytes ?  And a little
later (several paragraphs below table 2.6) is a remark saying if the
transport_private_data_flag is set, the rest of the adaptation field is
private data; one byte with the length (possibly ==0) and then ...?

WE REALLY NEED TO GET AN ANSWER FROM THE PEOPLE WHO "OWN" MPEG-2 AND CAN
TELL US WHETHER IT IS OK FOR "PRIVATE DATA" to make use of the AFC bits and
the adaptation field in a different way i.e. in a way which deviates from
Table 2.2, 25 and Table 2.6. Ssure, you can always do this inside a
"private" network but when you have to interoperate with other equipment you
might run into serious incompatibilities. For example, TS packets with
AFC=="00" shall be discarded by standard decoders - what will they do if
they get a TS packet which can not be parsed according to 2.2, 2.5 and 2.6 -
will they trop the packet or forward it?

Is there anybody reading this list who can help???


> I have a lot of concerns about the lack of layer 2 adresses in the new
> design.
> I think there are a lot of situations where we need layer 2 MAC
> addresses in the datagram:
> Without layer 2 destination address, the filtering has to be done at
> layer 3.
> Without layer 2 destination address, what will be the behaviour of a
> router receiving a layer 3 packet.
> Without layer 2 source address, how do we recognize our own datagrams,
> when we get them back on the link several ms after sending them.
> ...
I agree with you but I have on purpose left an address field out of the
encapsulation, assuming that it will follow inside as a part of the
encapsulated structure. Of course this address will have to be bound to an
IP address (in case we carry an IP datagram) on the one side and then it
will have to be mapped to a PID on the other side.
In a way similar to PPP which also leaves this open and there are standards
for doing PPP over ATM or PPP over SDH/Sonet. I am still convinced that for
an MPEG-2 system it is better to assume flow "labels" instead of datagram
addresses.

>
> If we are really convinced that in some cases either the destination
> and/or source MAC address are uneeded, and if the goal is to save some
> bits not having them, we could use 2 bits out of the length field
> The length field would then be 14 bits ([0,16383])
> MAC_FLAG
>
> 00 : no dst MAC, no src MAC
> 01 : dst MAC, no src MAC
> 10 : src MAC, no dst MAC
> 11 : dst MAC, src MAC
>
> MAC is IEEE 48 bits
> no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
>
I do believe that you need a link-level "address/label" but it is NOT your
typical IEEE MAC address. MAC addresses are globally unique identifiers
carrying, for example 3 bytes of "manufacturer prefix" and the 3 bytes of a
manufacturer assigned serial number. Binding an IP address to an Ethernet
address is done by an ARP and the frame carries both address field = 32 + 48
bits; but you couild also bind a 32-bit address to any other "label" and the
label could have >32 bits (e.g. IPv6 addresses), ==32 bits (not very
sensible) or <32 bits. In that latter case you ought to know how many IP
addresses your network will maximally use in order to find out how long your
"label" should be.

If we carry IP datagrams we have in that packet the source and the
destination address; if we consider the MPEG-2 system a subnetwork, we can
look at it as either a connectionless network in which case we would have to
carry a source and a destination local address (taking Ethernet MAC
addresses for this is not very efficient) or we look at it as a connection
oriented network in which case we could use a single connection_ID - and the
PID could be a subfield of this.
Thte length of this field depends on your requirements: if you feel that
65000 individual stations AND/OR multicast groups are sufficient, then 16
bits are enough. And remenber, for satellites this applies for one footprint
only.


> +--+--------------+----------------+----------
> |00|    length    |      type      |Payload
> +--+--------------+----------------+----------
>
> +--+--------------+----------------+-----------  --+----------
> |01|    length    |      type      |48 bits dst ~  | Paylaod
> +--+--------------+----------------+-----------  --+----------
>
> +--+--------------+----------------+-----------  --+----------
> |10|    length    |      type      |48 bits src  ~ | Paylaod
> +--+--------------+----------------+-----------  --+----------
>
>
--+--------------+----------------+-----------  --+-----------  --+---------
> |11|    length    |      type      |48 bits dst ~  |48 bits src ~
|Payload
>
--+--------------+----------------+-----------  --+-----------  --+---------
>
>
> Patrick.

If you want to do on-board switching of TS packets, then, of course, this
"label" has to be in every cell - as outlined in Ghassane's messages. But
this is a separate subject - it has more to tdo with the segmentation and
reassembly strategy but the label field must come from "above" i.e. the next
higher layer.

Sorry this got so long but I hope it helps in our discussion.

--Horst



From clausen at cosy.sbg.ac.at  Thu Apr 25 06:26:57 2002
From: clausen at cosy.sbg.ac.at (Kearney)
Date: Wed, 24 Apr 2002 22:26:57 -0700
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <200204241220.g3OCKBK04561@ra.udcast.com> <3CC6A810.1DF67303@sophia.inria.fr>
Message-ID: <00d101c1ec19$d1afc720$79068a81@nmttb97i6f89th>

From: "Ghassane Aniba" <Ghassane.Aniba at sophia.inria.fr>
Sent: Wednesday, April 24, 2002 5:41 AM
Subject: Re: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt


...SNIP...

> > Without layer 2 source address, how do we recognize our own datagrams,
> > when we get them back on the link several ms after sending them.
> > ...
> >
> > If we are really convinced that in some cases either the destination
> > and/or source MAC address are uneeded, and if the goal is to save some
> > bits not having them, we could use 2 bits out of the length field
> > The length field would then be 14 bits ([0,16383])
> > MAC_FLAG
> >
> > 00 : no dst MAC, no src MAC
> > 01 : dst MAC, no src MAC
> > 10 : src MAC, no dst MAC
> > 11 : dst MAC, src MAC
> >
> > MAC is IEEE 48 bits
> > no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
> >
> > +--+--------------+----------------+----------
> > |00|    length    |      type      |Payload
> > +--+--------------+----------------+----------
> >
> > +--+--------------+----------------+-----------  --+----------
> > |01|    length    |      type      |48 bits dst ~  | Paylaod
> > +--+--------------+----------------+-----------  --+----------
> >
> > +--+--------------+----------------+-----------  --+----------
> > |10|    length    |      type      |48 bits src  ~ | Paylaod
> > +--+--------------+----------------+-----------  --+----------
> >
> >
--+--------------+----------------+-----------  --+-----------  --+---------
> > |11|    length    |      type      |48 bits dst ~  |48 bits src ~
|Payload
> >
--+--------------+----------------+-----------  --+-----------  --+---------
> >
> > Patrick.
> But for the satellite network, how we can switch MPEG2-TS packet
> onboard?
>
Ghassane,
by including this (hopefully not 48 byte long) address or label in every TS
packet just as you proposed in your previous messages. In that case you do
not have to include it in the encapsulation and bind it directly to the
higher-layer address, e.g. IP multicast.
> --
> Ghassane ANIBA




From dent at cosy.sbg.ac.at  Thu Apr 25 07:51:40 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Thu, 25 Apr 2002 08:51:40 +0200 (MET DST)
Subject: Self routing
In-Reply-To: <00bb01c1ebeb$567ae0e0$79068a81@nmttb97i6f89th>
Message-ID: <Pine.GSO.4.05.10204250848280.23230-100000@mausmaki.cosy.sbg.ac.at>

> > --snip/snip
> >
> > > I don't think we want to change MPE but come up with an alternative,
> more
> > > efficient and more flexible solution.
> >
> > which set of requirements in mind? MPE probably is not the best solution,
> > but it works.
> > it is layer2+layer3, and your proposal would be layer3 - which is fine,
> > if you have a specific set of services you'd like to support, but you'll
> > have troubles supporting a different set of services in an efficient way.
> >
> would you, please, define what you mean with "layer 3"  -  why is an
> encapsulation layer three, what functionality do you see that belongs into
> the "network lauer"??

this hould be 2+2.5 instead of 2+3 (MAC+LLC) - the 3 came out of a rounding
error ;)

	++Thomas
-- 
in some way i do, and in some way i don't.



From dent at cosy.sbg.ac.at  Thu Apr 25 08:32:59 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Thu, 25 Apr 2002 09:32:59 +0200 (MET DST)
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <00d101c1ec19$d1afc720$79068a81@nmttb97i6f89th>
Message-ID: <Pine.GSO.4.05.10204250927010.23230-100000@mausmaki.cosy.sbg.ac.at>

--snip/snip

> > > Without layer 2 source address, how do we recognize our own datagrams,
> > > when we get them back on the link several ms after sending them.
> > > ...
> > >
> > > If we are really convinced that in some cases either the destination
> > > and/or source MAC address are uneeded, and if the goal is to save some
> > > bits not having them, we could use 2 bits out of the length field
> > > The length field would then be 14 bits ([0,16383])
> > > MAC_FLAG
> > >
> > > 00 : no dst MAC, no src MAC
> > > 01 : dst MAC, no src MAC
> > > 10 : src MAC, no dst MAC
> > > 11 : dst MAC, src MAC
> > >
> > > MAC is IEEE 48 bits
> > > no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
> > >
> > > +--+--------------+----------------+----------
> > > |00|    length    |      type      |Payload
> > > +--+--------------+----------------+----------
> > >
> > > +--+--------------+----------------+-----------  --+----------
> > > |01|    length    |      type      |48 bits dst ~  | Paylaod
> > > +--+--------------+----------------+-----------  --+----------
> > >
> > > +--+--------------+----------------+-----------  --+----------
> > > |10|    length    |      type      |48 bits src  ~ | Paylaod
> > > +--+--------------+----------------+-----------  --+----------

in case "10" you're exaclty at the bandwidth-consumtion where MPE is
(well +/- 2 byte per PDU)

also it's a point to discuss if you need all the fields in the MPE
header - but at least it's a start, after having the requirements
to go from (probably most of the people wouldn't be happy with the
MAC address layout in the MPE header ...)

	++Thomas

-- 
in some way i do, and in some way i don't.



From Patrick.Cipiere at udcast.com  Thu Apr 25 08:48:38 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Thu, 25 Apr 2002 09:48:38 +0200
Subject: Self routing
In-Reply-To: 	<Pine.GSO.4.05.10204240851270.22636-100000@mausmaki.cosy.sbg.ac.at>
	(dent@cosy.sbg.ac.at)
Message-ID: <200204250748.g3P7mcq05887@ra.udcast.com>

"Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:

> which set of requirements in mind? MPE probably is not the best solution,
> but it works.

I completely agree. If we come up with a new design, it must
drastically improve the previous and answer useful ans usable
requirements that can't be currently addressed.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Patrick.Cipiere at udcast.com  Thu Apr 25 09:09:47 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Thu, 25 Apr 2002 10:09:47 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <00c901c1ec18$f54c19a0$79068a81@nmttb97i6f89th>
	(clausen@cosy.sbg.ac.at)
Message-ID: <200204250809.g3P89lp05937@ra.udcast.com>

"Kearney" <clausen at cosy.sbg.ac.at> wrote:

> If we carry IP datagrams we have in that packet the source and the
> destination address;

Yes, layer 3 addresses.
On a broadcast link, I believe we need layer 2 addresses.

> if we consider the MPEG-2 system a subnetwork, we can
> look at it as either a connectionless network in which case we would have to
> carry a source and a destination local address (taking Ethernet MAC
> addresses for this is not very efficient)

Could you explain "this is not very efficient"?

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Patrick.Cipiere at udcast.com  Thu Apr 25 09:14:05 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Thu, 25 Apr 2002 10:14:05 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: 	<Pine.GSO.4.05.10204250927010.23230-100000@mausmaki.cosy.sbg.ac.at>
	(dent@cosy.sbg.ac.at)
Message-ID: <200204250814.g3P8E5v05954@ra.udcast.com>

"Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:

> in case "10" you're exaclty at the bandwidth-consumtion where MPE is
> (well +/- 2 byte per PDU)

Yes.
In between wou might have received my previous mail


> "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:
>
>> which set of requirements in mind? MPE probably is not the best solution,
>> but it works.
>
> I completely agree. If we come up with a new design, it must
> drastically improve the previous and answer useful ans usable
> requirements that can't be currently addressed.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From Ghassane.Aniba at sophia.inria.fr  Thu Apr 25 09:17:50 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Thu, 25 Apr 2002 10:17:50 +0200
Subject: Self routing
References: <200204250748.g3P7mcq05887@ra.udcast.com>
Message-ID: <3CC7BBAE.F3E0B21D@sophia.inria.fr>

Patrick Cipiere wrote:
> 
> "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:
> 
> > which set of requirements in mind? MPE probably is not the best solution,
> > but it works.
> 
> I completely agree. If we come up with a new design, it must
> drastically improve the previous and answer useful ans usable
> requirements that can't be currently addressed.
> 
Sur. With MPE encapsulation we couldn't doing a filtring depending on
the source adress( for exemple in Multicast SSM). The new encapsulation
has to do it.

> Patrick.
> --
> UDcast: Full IP over Broadcast Media
> 

Ghassane.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From Ghassane.Aniba at sophia.inria.fr  Thu Apr 25 09:21:49 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Thu, 25 Apr 2002 10:21:49 +0200
Subject: Switching in new encapsulation.
References: <200204250748.g3P7mcq05887@ra.udcast.com>
Message-ID: <3CC7BC9D.CC9CF9DE@sophia.inria.fr>

Hi,
i've a question : the new encapsulation will give us possibility to
switch mpeg packets in the layer 2 or not?
Because i see that most of the proposed encapsulations don't do it,
unless we make ressembling of mpeg packets.

Ghassane.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From gorry at erg.abdn.ac.uk  Thu Apr 25 10:14:37 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Thu, 25 Apr 2002 10:14:37 +0100
Subject: Self routing
References: <200204250748.g3P7mcq05887@ra.udcast.com> <3CC7BBAE.F3E0B21D@sophia.inria.fr>
Message-ID: <3CC7C8FC.53607816@erg.abdn.ac.uk>



Ghassane Aniba wrote:
> 
> Patrick Cipiere wrote:
> >
> > "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:
> >
> > > which set of requirements in mind? MPE probably is not the best solution,
> > > but it works.
> >
> > I completely agree. If we come up with a new design, it must
> > drastically improve the previous and answer useful ans usable
> > requirements that can't be currently addressed.
> >
> Sur. With MPE encapsulation we couldn't doing a filtring depending on
> the source adress( for exemple in Multicast SSM). The new encapsulation
> has to do it.
> 

hey... you mean IP SOURCE ADDRESS!!!!!

That's level 3 information, not level 2. We shouldn't map this into
level 2
simply to allow level 2 filtering - do the filtering at level 3 (using hardware
if you so desitre).  It is a level 3 function.

> > Patrick.
> > --
> > UDcast: Full IP over Broadcast Media
> >
> 
> Ghassane.
> 
> --
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From dent at cosy.sbg.ac.at  Thu Apr 25 10:21:34 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Thu, 25 Apr 2002 11:21:34 +0200 (MET DST)
Subject: Self routing
In-Reply-To: <3CC7C8FC.53607816@erg.abdn.ac.uk>
Message-ID: <Pine.GSO.4.05.10204251117420.23230-100000@mausmaki.cosy.sbg.ac.at>

On Thu, 25 Apr 2002, Dr G Fairhurst wrote:

> 
> 
> Ghassane Aniba wrote:
> > 
> > Patrick Cipiere wrote:
> > >
> > > "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:
> > >
> > > > which set of requirements in mind? MPE probably is not the best solution,
> > > > but it works.
> > >
> > > I completely agree. If we come up with a new design, it must
> > > drastically improve the previous and answer useful ans usable
> > > requirements that can't be currently addressed.
> > >
> > Sur. With MPE encapsulation we couldn't doing a filtring depending on
> > the source adress( for exemple in Multicast SSM). The new encapsulation
> > has to do it.
> > 
> 
> hey... you mean IP SOURCE ADDRESS!!!!!

well - if you're transporting IP. - is that a strict requirement?

> That's level 3 information, not level 2. We shouldn't map this into
> level 2
> simply to allow level 2 filtering - do the filtering at level 3 (using hardware
> if you so desitre).  It is a level 3 function.

see above - it's fine if you restrict yourself to IPv[46]
... and yes, i don't know if filtering on the SOURCE in layer2 needs
to be there - in most of the cases (all?) the destination address
is more useful. (in terms of keeping the load on the receiver low,
as well as really simply (non-)security mechanism)

	++Thomas

-- 
in some way i do, and in some way i don't.



From Ghassane.Aniba at sophia.inria.fr  Thu Apr 25 10:39:48 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Thu, 25 Apr 2002 11:39:48 +0200
Subject: Self routing
References: <200204250748.g3P7mcq05887@ra.udcast.com> <3CC7BBAE.F3E0B21D@sophia.inria.fr> <3CC7C8FC.53607816@erg.abdn.ac.uk>
Message-ID: <3CC7CEE4.9345F042@sophia.inria.fr>

Dr G Fairhurst wrote:
> 
> Ghassane Aniba wrote:
> >
> > Patrick Cipiere wrote:
> > >
> > > "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:
> > >
> > > > which set of requirements in mind? MPE probably is not the best solution,
> > > > but it works.
> > >
> > > I completely agree. If we come up with a new design, it must
> > > drastically improve the previous and answer useful ans usable
> > > requirements that can't be currently addressed.
> > >
> > Sur. With MPE encapsulation we couldn't doing a filtring depending on
> > the source adress( for exemple in Multicast SSM). The new encapsulation
> > has to do it.
> >
> 
> hey... you mean IP SOURCE ADDRESS!!!!!
> 
> That's level 3 information, not level 2. We shouldn't map this into
> level 2
> simply to allow level 2 filtering - do the filtering at level 3 (using hardware
> if you so desitre).  It is a level 3 function.

ok,I know. I mean that we have to ditinguish between flows
(source,group). In Multicast it's more important to do it. If we use
PIM-SSM with the satellite network, we'll need information about the
source adress.

> 
> > > Patrick.
> > > --
> > > UDcast: Full IP over Broadcast Media
> > >
> >
> > Ghassane.
> >

Ghassane.


From gorry at erg.abdn.ac.uk  Thu Apr 25 10:41:00 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Thu, 25 Apr 2002 10:41:00 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <Pine.GSO.4.05.10204250927010.23230-100000@mausmaki.cosy.sbg.ac.at>
Message-ID: <3CC7CF2C.A550FC51@erg.abdn.ac.uk>



Thomas 'Dent' Mirlacher wrote:
> 
> --snip/snip
> 
> > > > Without layer 2 source address, how do we recognize our own datagrams,
> > > > when we get them back on the link several ms after sending them.
> > > > ...
> > > >
> > > > If we are really convinced that in some cases either the destination
> > > > and/or source MAC address are uneeded, and if the goal is to save some
> > > > bits not having them, we could use 2 bits out of the length field
> > > > The length field would then be 14 bits ([0,16383])
> > > > MAC_FLAG
> > > >
> > > > 00 : no dst MAC, no src MAC
> > > > 01 : dst MAC, no src MAC
> > > > 10 : src MAC, no dst MAC
> > > > 11 : dst MAC, src MAC
> > > >
> > > > MAC is IEEE 48 bits
> > > > no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
> > > >
> > > > +--+--------------+----------------+----------
> > > > |00|    length    |      type      |Payload
> > > > +--+--------------+----------------+----------
> > > >
> > > > +--+--------------+----------------+-----------  --+----------
> > > > |01|    length    |      type      |48 bits dst ~  | Paylaod
> > > > +--+--------------+----------------+-----------  --+----------
> > > >
> > > > +--+--------------+----------------+-----------  --+----------
> > > > |10|    length    |      type      |48 bits src  ~ | Paylaod
> > > > +--+--------------+----------------+-----------  --+----------
> 
> in case "10" you're exaclty at the bandwidth-consumtion where MPE is
> (well +/- 2 byte per PDU)
> 
> also it's a point to discuss if you need all the fields in the MPE
> header - but at least it's a start, after having the requirements
> to go from (probably most of the people wouldn't be happy with the
> MAC address layout in the MPE header ...)
> 
>         ++Thomas

Not so.

First, there is no section filtering, etc. So the processing is very simple.

Second, the encapulsation byte overhead is actually much better.
You have in this case full MAC source and destination address, type. In some
applications this is needed. If you want to do that in MPE, you have
to add an LLC/SNAP header - that's a lot more overhead.

Native IP applications could still use 00 format, if they like, and
"MPE-like" applications could yse 01 encoding if they need it.

----

The main advantages seem to be:

(1) For type 01, 10 there is a more efficient header. In the previous
scheme in the draft these require an extra TYPE field - part of the 
fixed format header which then indicates this is a bridged payload,
and carries the MAC layer information (addreses and ether-type).

The main drawbacks I can see of this approach are:

(1) We reduce maximum SNDU length from nearly 64 KB to just udner 16 KB.
- Is that an issue?
- I can see why 4 KB is a useful size, and also, posisbly 10 KB, do we
need more 16 KB (or so) packets in this context?

(2) The lower layer processing now has to be aware of the various
format options, previously all frames used the same initial format.
- But probbaly one wants to do level 2 processing of MAC addresses
anyway (if present) so, not sure the variable format is an issue?

(2) We have only one unused format indicator '11'. 

(3) We fix the PDU format for 01, 10 based on 6B MAC addresses only.
It may be difficult to use a larger/smaller value in the future.

thoughts?

Gorry


From Ghassane.Aniba at sophia.inria.fr  Thu Apr 25 10:52:38 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Thu, 25 Apr 2002 11:52:38 +0200
Subject: Self routing
References: <Pine.GSO.4.05.10204251117420.23230-100000@mausmaki.cosy.sbg.ac.at>
Message-ID: <3CC7D1E6.8B8FF327@sophia.inria.fr>

Thomas 'Dent' Mirlacher wrote:
> 
> On Thu, 25 Apr 2002, Dr G Fairhurst wrote:
> 
> >
> >
> > Ghassane Aniba wrote:
> > >
> > > Patrick Cipiere wrote:
> > > >
> > > > "Thomas 'Dent' Mirlacher" <dent at cosy.sbg.ac.at> wrote:
> > > >
> > > > > which set of requirements in mind? MPE probably is not the best solution,
> > > > > but it works.
> > > >
> > > > I completely agree. If we come up with a new design, it must
> > > > drastically improve the previous and answer useful ans usable
> > > > requirements that can't be currently addressed.
> > > >
> > > Sur. With MPE encapsulation we couldn't doing a filtring depending on
> > > the source adress( for exemple in Multicast SSM). The new encapsulation
> > > has to do it.
> > >
> >
> > hey... you mean IP SOURCE ADDRESS!!!!!
> 
> well - if you're transporting IP. - is that a strict requirement?
> 
> > That's level 3 information, not level 2. We shouldn't map this into
> > level 2
> > simply to allow level 2 filtering - do the filtering at level 3 (using hardware
> > if you so desitre).  It is a level 3 function.
> 
> see above - it's fine if you restrict yourself to IPv[46]
> ... and yes, i don't know if filtering on the SOURCE in layer2 needs
> to be there - in most of the cases (all?) the destination address
> is more useful. (in terms of keeping the load on the receiver low,
> as well as really simply (non-)security mechanism)

If the Muticast case, if we have a terminal wich join Group G but
doesn't want the data from the source S. So, in this case, we don't need
to transmit data in the uplink of the satellite network, and so we
reduce the no need traffic. into doing that, we have to know the source
adress (PIM-SM and the Rendez-vous Point RP).

> 
>         ++Thomas
> 
> --
> in some way i do, and in some way i don't.

Ghassane.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78


From dent at cosy.sbg.ac.at  Thu Apr 25 11:00:27 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Thu, 25 Apr 2002 12:00:27 +0200 (MET DST)
Subject: Self routing
In-Reply-To: <3CC7D1E6.8B8FF327@sophia.inria.fr>
Message-ID: <Pine.GSO.4.05.10204251159280.23230-100000@mausmaki.cosy.sbg.ac.at>

--snip/snip

> > see above - it's fine if you restrict yourself to IPv[46]
> > ... and yes, i don't know if filtering on the SOURCE in layer2 needs
> > to be there - in most of the cases (all?) the destination address
> > is more useful. (in terms of keeping the load on the receiver low,
> > as well as really simply (non-)security mechanism)
> 
> If the Muticast case, if we have a terminal wich join Group G but
> doesn't want the data from the source S. So, in this case, we don't need
> to transmit data in the uplink of the satellite network, and so we
> reduce the no need traffic. into doing that, we have to know the source
> adress (PIM-SM and the Rendez-vous Point RP).

but in this case, you're filtering the traffic BEFORE the air interface?

	++Thomas

-- 
in some way i do, and in some way i don't.



From Patrick.Cipiere at udcast.com  Thu Apr 25 11:24:07 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Thu, 25 Apr 2002 12:24:07 +0200
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC7CF2C.A550FC51@erg.abdn.ac.uk> (message from Dr G Fairhurst
	on Thu, 25 Apr 2002 10:41:00 +0100)
Message-ID: <200204251024.g3PAO7A06217@ra.udcast.com>

Gorry wrote:

> (2) We have only one unused format indicator '11'. 

I would rather say that the seldom format indicator is '10'

10 : src MAC, no dst MAC

But i definitely need '11'

11 : dst MAC, src MAC

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From dent at cosy.sbg.ac.at  Thu Apr 25 11:40:01 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Thu, 25 Apr 2002 12:40:01 +0200 (MET DST)
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC7CF2C.A550FC51@erg.abdn.ac.uk>
Message-ID: <Pine.GSO.4.05.10204251200550.23230-100000@mausmaki.cosy.sbg.ac.at>

--snip/snip

> > in case "10" you're exaclty at the bandwidth-consumtion where MPE is
> > (well +/- 2 byte per PDU)
> > 
> > also it's a point to discuss if you need all the fields in the MPE
> > header - but at least it's a start, after having the requirements
> > to go from (probably most of the people wouldn't be happy with the
> > MAC address layout in the MPE header ...)
> 
> Not so.
> 
> First, there is no section filtering, etc. So the processing is very simple.

well, if you assume you will just receive MPE sections you can also
skip sektion filtering. - and with the new encapsulation, tou can
only transport this encapsulation per PID also.

> Second, the encapulsation byte overhead is actually much better.

well, the %tage depends on the MTU, and actually it is about

 1B pointer-field
12B MPE (flags+MAC) 
 8B LLC+SNAP
 4B CRC
---
25B	for MPE		~ 1.1% overhead (MTU=1500)

 2B length+flags_for_MAC_type
 2B type
 6B MAC
 4B AF_lenght
---
14B	for the new schem ~ 0.9% overhead

... did i miss anything here?


don't misunderstand me here, i'm not a proponent of MPE, nor against
a new encapsulation - i just want to view this discussions in a
critical way, and probably ask to clarify some things (for myself)

> You have in this case full MAC source and destination address, type. In some
> applications this is needed. If you want to do that in MPE, you have
> to add an LLC/SNAP header - that's a lot more overhead.

well, LLC/SNAP includes "overhead" which is the LLC + 3 byte org code,
yes.

> Native IP applications could still use 00 format, if they like, and
> "MPE-like" applications could yse 01 encoding if they need it.

the format is not MPE compatible in any way, but yes, an application
could use the formats on the fly. - but the problem here is: if the
"application" decides to do that, the whole point of the fields
goes away, since the application shouldn't be aware of the topology.

- it is the gateway which should know the topology, but when changing
topology, that means changing the gateway - is that alway the case?
(nowadays yes, but do we want to do this also in the future?)

> ----
> 
> The main advantages seem to be:
> 
> (1) For type 01, 10 there is a more efficient header. In the previous
> scheme in the draft these require an extra TYPE field - part of the 
> fixed format header which then indicates this is a bridged payload,
> and carries the MAC layer information (addreses and ether-type).
> 
> The main drawbacks I can see of this approach are:
> 
> (1) We reduce maximum SNDU length from nearly 64 KB to just udner 16 KB.
> - Is that an issue?

this could also be a good thing (e.g. for delay jitter)

> - I can see why 4 KB is a useful size, and also, posisbly 10 KB, do we
> need more 16 KB (or so) packets in this context?
> 
> (2) The lower layer processing now has to be aware of the various
> format options, previously all frames used the same initial format.

if you take a look at 802.11, the lower layers also need to be aware
of special formats (even the meaning for address-fields could change)

> - But probbaly one wants to do level 2 processing of MAC addresses
> anyway (if present) so, not sure the variable format is an issue?
> 
> (2) We have only one unused format indicator '11'. 

... again: if we would have requirements we could reserve a byte, or
a nibble from the length (i will stop talking about requirements now)

> (3) We fix the PDU format for 01, 10 based on 6B MAC addresses only.
> It may be difficult to use a larger/smaller value in the future.

you could reserve more space for the address, and use it for MAC addresses,
now - and later for some other addressing-scheme (this would require a
version field)

	just my $0.02

		++Thomas
-- 
in some way i do, and in some way i don't.



From gorry at erg.abdn.ac.uk  Thu Apr 25 11:43:02 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Thu, 25 Apr 2002 11:43:02 +0100
Subject: URGENT - call for interest at next IETF
Message-ID: <3CC7DDB5.2FD0C19E@erg.abdn.ac.uk>


We now have 120 list members and two IDs.

Is there interest in calling a meeting at the next IETF?

Given the next IETF will be in Japan, it seems there may a lack of
European interest,
I wanted to check whether this is so. It is important that if we do have
a BoF,
that we have sufficient participation to ensure the views of the group are
properly represented.

If you are/may be going, please do return form below to:
gorry at erg.abdn.ac.uk

---

[ ] I am keen to attend the next IETF, but have not yet registered.

[ ] I expect to be attending the next IETF and would like to see a BoF on
this topic.

[ ] I would like to present a short presentation at a BoF on this topic

-----

I am interested in co-authoring/editing an Internet Draft on 

[ ] DVB Address Resolution for IP over DVB 
[ ] Multicast Support for IP over DVB 
[ ] Other

-----


From gorry at erg.abdn.ac.uk  Thu Apr 25 11:45:23 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Thu, 25 Apr 2002 11:45:23 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <200204251024.g3PAO7A06217@ra.udcast.com>
Message-ID: <3CC7DE43.58D0B4E7@erg.abdn.ac.uk>


Yes, you are correct. Sorry. I belive the type:

10 : src MAC, no dst MAC

has no function. I think if we go down this path, we should
reserve this, rather than allocate this.

Gorry

Patrick Cipiere wrote:
> 
> Gorry wrote:
> 
> > (2) We have only one unused format indicator '11'.
> 
> I would rather say that the seldom format indicator is '10'
> 
> 10 : src MAC, no dst MAC
> 
> But i definitely need '11'
> 
> 11 : dst MAC, src MAC
> 
> Patrick.
> --
> UDcast: Full IP over Broadcast Media
> 
> Phone:  (+33) (0)4 93 00 16 99
> Mobile: (+33) (0)6 14 21 55 98
> Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From gorry at erg.abdn.ac.uk  Thu Apr 25 12:04:26 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Thu, 25 Apr 2002 12:04:26 +0100
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <Pine.GSO.4.05.10204251200550.23230-100000@mausmaki.cosy.sbg.ac.at>
Message-ID: <3CC7E2BA.AE2E17CC@erg.abdn.ac.uk>



Thomas 'Dent' Mirlacher wrote:
> 
> --snip/snip
> 
> > > in case "10" you're exaclty at the bandwidth-consumtion where MPE is
> > > (well +/- 2 byte per PDU)
> > >
> > > also it's a point to discuss if you need all the fields in the MPE
> > > header - but at least it's a start, after having the requirements
> > > to go from (probably most of the people wouldn't be happy with the
> > > MAC address layout in the MPE header ...)
> >
> > Not so.
> >
> > First, there is no section filtering, etc. So the processing is very simple.
> 
> well, if you assume you will just receive MPE sections you can also
> skip sektion filtering. - and with the new encapsulation, tou can
> only transport this encapsulation per PID also.
> 
> > Second, the encapulsation byte overhead is actually much better.
> 
> well, the %tage depends on the MTU, and actually it is about
> 
>  1B pointer-field
> 12B MPE (flags+MAC)
>  8B LLC+SNAP
>  4B CRC
> ---
> 25B     for MPE         ~ 1.1% overhead (MTU=1500)
> 

or 25% for 100B, 63% for 40B, etc. - assuming PACKING is used.

>  2B length+flags_for_MAC_type
>  2B type
>  6B MAC
>  4B AF_lenght
> ---
> 14B     for the new schem ~ 0.9% overhead
> 
> ... did i miss anything here?

  2B length+flags_for_MAC_type
  2B type
  ---
  4B     for the new scheme 

0.3% overhead (MTU=1500)
or 4% for 100B, 10% for 40B, etc.

- All assuming that you don't look at the detail of padding, and PUSI 
pointers, etc.

> don't misunderstand me here, i'm not a proponent of MPE, nor against
> a new encapsulation - i just want to view this discussions in a
> critical way, and probably ask to clarify some things (for myself)
> 

Agreed, maybe someone should some real calculations...

> > You have in this case full MAC source and destination address, type. In some
> > applications this is needed. If you want to do that in MPE, you have
> > to add an LLC/SNAP header - that's a lot more overhead.
> 
> well, LLC/SNAP includes "overhead" which is the LLC + 3 byte org code,
> yes.
> 
> > Native IP applications could still use 00 format, if they like, and
> > "MPE-like" applications could yse 01 encoding if they need it.
> 
> the format is not MPE compatible in any way, but yes, an application
> could use the formats on the fly. - but the problem here is: if the
> "application" decides to do that, the whole point of the fields
> goes away, since the application shouldn't be aware of the topology.
> 
> - it is the gateway which should know the topology, but when changing
> topology, that means changing the gateway - is that alway the case?
> (nowadays yes, but do we want to do this also in the future?)

Actually, I'm not sure we should have 'MAC destination-only' as an option....
but I'm happy to define it for the moment.

> 
> > ----
> >
> > The main advantages seem to be:
> >
> > (1) For type 01, 10 there is a more efficient header. In the previous

10 should have been 11.

> > scheme in the draft these require an extra TYPE field - part of the
> > fixed format header which then indicates this is a bridged payload,
> > and carries the MAC layer information (addreses and ether-type).
> >
> > The main drawbacks I can see of this approach are:
> >
> > (1) We reduce maximum SNDU length from nearly 64 KB to just udner 16 KB.
> > - Is that an issue?
> 
> this could also be a good thing (e.g. for delay jitter)

Yes.

> > - I can see why 4 KB is a useful size, and also, posisbly 10 KB, do we
> > need more 16 KB (or so) packets in this context?
> >
> > (2) The lower layer processing now has to be aware of the various
> > format options, previously all frames used the same initial format.
> 
> if you take a look at 802.11, the lower layers also need to be aware
> of special formats (even the meaning for address-fields could change)
> 
> > - But probbaly one wants to do level 2 processing of MAC addresses
> > anyway (if present) so, not sure the variable format is an issue?
> >
> > (2) We have only one unused format indicator '11'.
 
whoops, the "odd" one is '10' as Patrick said, 11 is needed.

> ... again: if we would have requirements we could reserve a byte, or
> a nibble from the length (i will stop talking about requirements now)

Yes, I'd advocate '01' as reserved.

OK.

> > (3) We fix the PDU format for 01, 10 based on 6B MAC addresses only.
> > It may be difficult to use a larger/smaller value in the future.
> 
A
> you could reserve more space for the address, and use it for MAC addresses,
> now - and later for some other addressing-scheme (this would require a
> version field)
> 
>         just my $0.02
> 
>                 ++Thomas
> --
> in some way i do, and in some way i don't.


From dent at cosy.sbg.ac.at  Thu Apr 25 12:14:58 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Thu, 25 Apr 2002 13:14:58 +0200 (MET DST)
Subject: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC7E2BA.AE2E17CC@erg.abdn.ac.uk>
Message-ID: <Pine.GSO.4.05.10204251307200.23230-100000@mausmaki.cosy.sbg.ac.at>

--snip/snip
> > 
> >  1B pointer-field
> > 12B MPE (flags+MAC)
> >  8B LLC+SNAP
> >  4B CRC
> > ---
> > 25B     for MPE         ~ 1.1% overhead (MTU=1500)
> > 
> 
> or 25% for 100B, 63% for 40B, etc. - assuming PACKING is used.

you can also use PACKING with sections (even multiple times per TSC)

> >  2B length+flags_for_MAC_type
> >  2B type
> >  6B MAC
> >  4B AF_lenght
> > ---
> > 14B     for the new schem ~ 0.9% overhead
> > 
> > ... did i miss anything here?
> 
>   2B length+flags_for_MAC_type
>   2B type
>   ---
>   4B     for the new scheme 

i was assuming the case where you need to have a destination
MAC address.
and doesn't the new scheme require an AF at the end of a PDU?
	(which is at least one byte or 4 byte when another
	 PDU is packed into the cell)

> 0.3% overhead (MTU=1500)
> or 4% for 100B, 10% for 40B, etc.

right.

> - All assuming that you don't look at the detail of padding, and PUSI 
> pointers, etc.

sure.

--snip/snip

> > the format is not MPE compatible in any way, but yes, an application
> > could use the formats on the fly. - but the problem here is: if the
> > "application" decides to do that, the whole point of the fields
> > goes away, since the application shouldn't be aware of the topology.
> > 
> > - it is the gateway which should know the topology, but when changing
> > topology, that means changing the gateway - is that alway the case?
> > (nowadays yes, but do we want to do this also in the future?)
> 
> Actually, I'm not sure we should have 'MAC destination-only' as an option....
> but I'm happy to define it for the moment.

at least for filtering at the receiver side, as well as L2 switching
it could be useful (and you probably don't need the source in that
case)

	++Thomas

-- 
in some way i do, and in some way i don't.



From harri.hakulinen at nokia.com  Thu Apr 25 13:20:36 2002
From: harri.hakulinen at nokia.com (harri.hakulinen at nokia.com)
Date: Thu, 25 Apr 2002 15:20:36 +0300
Subject: Switching in the old encapsulation .. RE: Switching in new encapsulation.
Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B807011AC98A@trebe004.NOE.Nokia.com>

Moro,

Have you ever considered to use those "labels" or 
"link addresses" with MPE ?

If they are implemented in TS adaptation field,
I think that you could use MPE as well. Thats why 
I am little bit worrying that we are somewhat 
mixmuxin things here. 

PS. Our research people once made a feasibility
    study about HW based MPE filtering on receiver.
    As they are HW people, they of course made their
    thing in a weird way (;) and I think that they 
    also accidentally proved that you can in fact do 
    (whatever layer) switching for TS that carries 
    MPE encapsulated frames based on any field 
    (in "TS packet level", without re-assembling and 
     that stuff, at least if you are not using 
      section packing).

    In order to get some free time to do something 
    else than read these emails, I leave it to you 
    as a home execsise to find the solution. Just 
    forget everything that you have ever learned and 
     think like HW person ;) 

//Harri

> -----Original Message-----
> From: ext Ghassane Aniba [mailto:Ghassane.Aniba at sophia.inria.fr]
> Sent: Thursday, April 25, 2002 11:22 AM
> To: ip-dvb at erg.abdn.ac.uk
> Subject: Switching in new encapsulation.
> 
> 
> Hi,
> i've a question : the new encapsulation will give us possibility to
> switch mpeg packets in the layer 2 or not?
> Because i see that most of the proposed encapsulations don't do it,
> unless we make ressembling of mpeg packets.
> 
> Ghassane.
> 
> -- 
> Ghassane ANIBA
> INRIA (Projet PLANETE)             | Email :
> ghassane.aniba at sophia.inria.fr  
> 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78
> 



From H.Cruickshank at eim.surrey.ac.uk  Thu Apr 25 15:44:38 2002
From: H.Cruickshank at eim.surrey.ac.uk (Haitham Cruickshank)
Date: Thu, 25 Apr 2002 15:44:38 +0100
Subject: Extra comments - I-D ACTION:draft-clausen-ipdvb-enc-00.txt
Message-ID: <3CC81656.B38D6927@eim.surrey.ac.uk>

Hi Everybody,

I attended (also Bernard Collini- Nocker was there) the ESA presentation
on "ip security over satellites" .  There was a good interest in the ip
encapsulation for DVB.

Back to the draft, I think the new draft looks good and I had been
following the recent discussions.  I have few extra comments and I hope
it will improve the final version:

* A table of content is missing in the beginning.
* A Security Considerations section is missing.  I would like to
contribute to this section, but I am not sure about the issues.  Has
anybody thought about any security problems, then I could make some
comments.
* I think it will be beneficial to add a small section about the main
problems with current MPE (such as large overheads and complex options,
implementation compatibility, etc ..) and provide a brief comparison
with the new leaner encapsulation.  This will help a lot the people who
are not familiar with MPE.
* Finally I have two a basic comment:
1. The size of "type" field in the SNDU encapsulation format (figure
1).  Why do we have to stick with two bytes size (16 bits) where the
types are only 4 types only (ipv4, ipv6, mpls and Br. Ethernet)
2. Is there really a need for CRC ?

Regards
Haitham
--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank at surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/




From gorry at erg.abdn.ac.uk  Thu Apr 25 18:50:23 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Thu, 25 Apr 2002 18:50:23 +0100
Subject: Extra comments - I-D ACTION:draft-clausen-ipdvb-enc-00.txt
References: <3CC81656.B38D6927@eim.surrey.ac.uk>
Message-ID: <3CC841DF.7E3BED32@erg.abdn.ac.uk>


Haitham Cruickshank wrote:
> 
> Hi Everybody,
> 
<<snip>>
> 
> Back to the draft, I think the new draft looks good and I had been
> following the recent discussions.  I have few extra comments and I hope
> it will improve the final version:
> 
> * A table of content is missing in the beginning.

OK - we can fix that, I'll add it to the list.

> * A Security Considerations section is missing.  I would like to
> contribute to this section, but I am not sure about the issues.  Has
> anybody thought about any security problems, then I could make some
> comments.

Actually, it is there - section 8, but doesn't suggest any issues.
Are there issues we should talk about?

> * I think it will be beneficial to add a small section about the main
> problems with current MPE (such as large overheads and complex options,
> implementation compatibility, etc ..) and provide a brief comparison
> with the new leaner encapsulation.  This will help a lot the people who
> are not familiar with MPE.

I disagree - in that this is a protocol spec, however we wondered
whether to update the requirements ID:

or should we create a new ID with this infromation?

> * Finally I have two a basic comment:
> 1. The size of "type" field in the SNDU encapsulation format (figure
> 1).  Why do we have to stick with two bytes size (16 bits) where the
> types are only 4 types only (ipv4, ipv6, mpls and Br. Ethernet)

But, it's not clear to me, there may be some more...

e.g. there are two different MAC bridge encapsulations in use elsewhere
in the internet and, we *DO* plan to support ROHC.

> 2. Is there really a need for CRC ?

A dificult one. It would seem that bit errors should be rare, due to the
under-lying coding in most cases. But the IETF has previously suggested 
we should be certain there are no undetected bit errors to the same
level of certaintity as a 32-bit CRC would give.  So, my main worry
is reassembly bugs and hardware-related transfer problems, rather than
the physical channel. Recent experience shows we should NOT ignore such
things, they happen often in IP Routers, so why not here? I personnaly
would advocate at least a CRC-16.

> 
> Regards
> Haitham
> --
> Dr. Haitham S. Cruickshank
> 
> Senior Research Fellow in Communications
> Centre for Communication Systems Research (CCSR)
> School of Electronics, Computing and Mathematics
> University of Surrey
> Guildford, Surrey GU2 7XH, UK
> 
> Tel: +44 1483 686007 (indirect 689844)
> Fax: +44 1483 686011
> e-mail: H.Cruickshank at surrey.ac.uk
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/


From l.wood at eim.surrey.ac.uk  Thu Apr 25 23:11:03 2002
From: l.wood at eim.surrey.ac.uk (Lloyd Wood)
Date: Thu, 25 Apr 2002 23:11:03 +0100 (BST)
Subject: Extra comments - I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC841DF.7E3BED32@erg.abdn.ac.uk>
Message-ID: <Pine.SOL.4.43.0204251933110.28173-100000@artemis.ee.surrey.ac.uk>

On http://www.watersprings.org/pub/id/draft-clausen-ipdvb-enc-00.txt:

On Thu, 25 Apr 2002, Gorry Fairhurst wrote:
> Haitham Cruickshank wrote:
> > * I think it will be beneficial to add a small section about the main
> > problems with current MPE (such as large overheads and complex options,
> > implementation compatibility, etc ..) and provide a brief comparison
> > with the new leaner encapsulation.  This will help a lot the people who
> > are not familiar with MPE.
>
> I disagree - in that this is a protocol spec, however we wondered
> whether to update the requirements ID:
>
> or should we create a new ID with this infromation?

isn't that really part of the protocharter of the protoWG, justifying
the WG's purpose for existence - which the requirements draft could
include?


> > 1. The size of "type" field in the SNDU encapsulation format (figure
> > 1).  Why do we have to stick with two bytes size (16 bits) where the
> > types are only 4 types only (ipv4, ipv6, mpls and Br. Ethernet)
>
> But, it's not clear to me, there may be some more...
>
> e.g. there are two different MAC bridge encapsulations in use elsewhere
> in the internet and, we *DO* plan to support ROHC.

(ROHC has ethertypes these days?)

on type, I imagine 0x0000 is reserved as it is for ethertypes (making
it available for local use?)

$ The special value 0x0000 indicates that there are no further SNDUs
$ within the current TS packet (see section 5.1)

what is type set to when length field is zero (final frame)? Does it
matter at all (for multiplexing, I think so)? how will this
affect/weaken CRC computation of the final frame? (okay, depends on
CRC choice, but something to think about.)

You'd have to have a lot of SNDUs in the TS to justify an empty SNDU
rather than the overhead of a couple of first/intermediate/last bits
per SNDU.

> > 2. Is there really a need for CRC ?
>
> A dificult one.

The CRC is also needed to protect the length and payload type fields,
so that you don't attempt to parse gibberish. if you're going to
checksum length+type or payload, you may as well do the whole thing
so that reassembly can be checked.

> It would seem that bit errors should be rare, due to the
> under-lying coding in most cases. But the IETF has previously suggested
> we should be certain there are no undetected bit errors to the same
> level of certaintity as a 32-bit CRC would give.  So, my main worry
> is reassembly bugs and hardware-related transfer problems, rather than
> the physical channel. Recent experience shows we should NOT ignore such
> things, they happen often in IP Routers, so why not here? I personnaly
> would advocate at least a CRC-16.

A trailing CRC should be slightly better for spotting router
overwrite/truncation problems.

A minor beef with the draft: section 4 defines (is titled) the SNDU
format, but the SNDU is the datagram encapsulated inside this,
according to the earlier SNDU definition anyway. When the CRC is said
to protect the entire SNDU I presume it means the outer SNDU, not the
inner SNDU which is the payload. This isn't stated explicitly, and you
have to read carefully to distinguish between SNDU (the carrying
frame) and SNDU field (the payload). I'd be tempted to dump the SNDU
term entirely, or use PDU for the payload (as in ENCAPSULATOR
definition), so that the SNDU field is a PDU field.

Having a maximum length of 65531 (because you've reserved 4 bytes for
the CRC, but aren't subtracting the length and type field lengths?
Doesn't gel with length=0 for checksummed final empty frame)  will not
play that nicely with jumbograms imo. RFC791 lets even IPv4 go to
65535 bytes - the sort of thing the IESG would pay attention to.

(Some security text is mandatory for drafts these days. But is the
SNDU the right place to do link security? I suspect not.)

L.

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>








From Patrick.Cipiere at udcast.com  Fri Apr 26 08:25:36 2002
From: Patrick.Cipiere at udcast.com (Patrick Cipiere)
Date: Fri, 26 Apr 2002 09:25:36 +0200
Subject: Extra comments - I-D ACTION:draft-clausen-ipdvb-enc-00.txt
In-Reply-To: <3CC841DF.7E3BED32@erg.abdn.ac.uk> (message from Dr G Fairhurst
	on Thu, 25 Apr 2002 18:50:23 +0100)
Message-ID: <200204260725.g3Q7PaY07898@ra.udcast.com>

Haitham Cruickshank wrote:

> 2. Is there really a need for CRC ?

Yes, there is a need.
With low quality signals, I have seen MPE packets delivered with bits
error (shown by the MPE CRC32) with no indication error given from the
hardware (in mpeg2 transport packet).
This could be poorly designed hardware, but I had this with
different chips, either with DVB-S and DVB-T

So I would definitely advocate for a CRC32.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com


From bnocker at cosy.sbg.ac.at  Fri Apr 26 16:09:51 2002
From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker)
Date: Fri, 26 Apr 2002 17:09:51 +0200
Subject: URGENT - call for interest at next IETF
In-Reply-To: <3CC7DDB5.2FD0C19E@erg.abdn.ac.uk>
Message-ID: <ABELIICPAMIFMLCEMIHIMEBLDMAA.bnocker@cosy.sbg.ac.at>

Hi Gorry,

glad to hear that at least two of us are attending... hope
that was not only a e-mail discussion...
Actually I am planning to stay for the whole IETF meeting.

See my answers below...

> We now have 120 list members and two IDs.
>
> Is there interest in calling a meeting at the next IETF?
>
> Given the next IETF will be in Japan, it seems there may a lack of
> European interest,
> I wanted to check whether this is so. It is important that if we do have
> a BoF,
> that we have sufficient participation to ensure the views of the group are
> properly represented.
>
> If you are/may be going, please do return form below to:
> gorry at erg.abdn.ac.uk
>
> ---
>
[X ] I am keen to attend the next IETF, but have not yet registered.
>
[X] I expect to be attending the next IETF and would like to see a BoF on
> this topic.
>
> [ ] I would like to present a short presentation at a BoF on this topic
>
> -----
>
> I am interested in co-authoring/editing an Internet Draft on
>
[X] DVB Address Resolution for IP over DVB
[X] Multicast Support for IP over DVB
[X] Other: "Synchronisation of DVB A/V streams with IP flows"
>
> -----



From Stephane.Combes at space.alcatel.fr  Fri Apr 26 17:16:40 2002
From: Stephane.Combes at space.alcatel.fr (Stephane.Combes at space.alcatel.fr)
Date: Fri, 26 Apr 2002 18:16:40 +0200
Subject: ASPI comments about draft-clausen-ipdvb-enc-00.txt
Message-ID: <C1256BA7.0059A801.00@vzmta01.netfr.alcatel.fr>


Hi,

a few comments on the draft  :

- page header to be corrected : it is not the ID "Requirements..." anymore
- in the introduction, something should be said about bidirectionnal systems
(UDLR, DVB-RCS) and the ones including MPEG switches (satellite OBP for
instance). DVB-RCS (either for transparent or regenerative satellites) is very
interesting since it specifies MPEG-2 transport both for the forward and
(optionally) for the return link.
- when we think about DVB-RCS's MPEG mode for the return link (shared access
between terminals), we may want to have a slightly different encapsulation
scheme. For instance it could include an additional sublayer performing IP
packet segmentation into several SNDU (AAL2 like scheme).
- on the other hand, we could allow IP packets "packing" into a same SNDU
- I tend to agree with P. Cipi?re comment : why making such a complex use of
PUSI and AFC ? Sticking to the simpler solution that some drivers currently
implement might be better (less complex, less overhead).
- I am not convinced we need to envisage that many SNDU types : aren't IPv4, v6,
Ethernet, MPLS enough ? 2 bytes for this like Ethertype is long...
- the famous "label" needs to be specified. A 16-bit field should be enough for
all kinds of usage, provided it is complemented by an ARP protocol.
- why should the format of bridged payload be specified in this document ?
- is it so important to keep the 16/32 bit alignment ?
- I am not sure to understand well the paragraph about the MPLS header. Why
putting it into the adaptation field ? it is not the case for other higher layer
headers like IP and Ethernet.
- Do you have an adaptation field inserted before each SNDU ? why ?

As far as regenerative satellites are concerned, here are our views :

- currently we only envisage ATM VP or MPEG PID switching at the OBP. Switching
on an extra label would cost a lot... and currently we do not see any concrete
need to do that. Currently forget about Ethernet or IP layer processing on-board
!
- large capacity multi spot-beam "mesh" systems based on regenerative payload
and MPEG switch handle a lot of terminals (hence a lot of "feeds"). Being able
to use the same PID for several feeds may prove to be interesting (PID used as a
"broadcast network" as Horst put it). It is possible to do this, even with a
"simple" MPEG TS level switch a the OBP. The only need is to have an extra label
(e.g. the SNDU label) being used to discriminate the SOURCE of the SNDU and have
only one such SNDU per MPEG cell.
- concerning G. Anissa's mail about "Channel-descriptor" signalling the mapping
Source/Destination @ -> PID, Label : DVB-RCS group is currently working on such
protocol.


Best regards,


St?phane

ALCATEL SPACE INDUSTRIES
Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr





From gorry at erg.abdn.ac.uk  Mon Apr 29 20:37:41 2002
From: gorry at erg.abdn.ac.uk (Dr G Fairhurst)
Date: Mon, 29 Apr 2002 20:37:41 +0100
Subject: ASPI comments about draft-clausen-ipdvb-enc-00.txt
References: <C1256BA7.0059A801.00@vzmta01.netfr.alcatel.fr>
Message-ID: <3CCDA105.4786F06D@erg.abdn.ac.uk>


Thanks,

That's a very useful list - these will help to improve the enxt
draft. WE'll start compiling a list of issues in a few weeks.

See a few in-line comments.

Stephane.Combes at space.alcatel.fr wrote:
> 
> Hi,
> 
> a few comments on the draft  :
> 
> - page header to be corrected : it is not the ID "Requirements..." anymore
> - in the introduction, something should be said about bidirectionnal systems
> (UDLR, DVB-RCS) and the ones including MPEG switches (satellite OBP for
> instance). DVB-RCS (either for transparent or regenerative satellites) is very
> interesting since it specifies MPEG-2 transport both for the forward and
> (optionally) for the return link.
> - when we think about DVB-RCS's MPEG mode for the return link (shared access
> between terminals), we may want to have a slightly different encapsulation
> scheme. For instance it could include an additional sublayer performing IP
> packet segmentation into several SNDU (AAL2 like scheme).
> - on the other hand, we could allow IP packets "packing" into a same SNDU
> - I tend to agree with P. Cipi?re comment : why making such a complex use of
> PUSI and AFC ? Sticking to the simpler solution that some drivers currently
> implement might be better (less complex, less overhead).

Well, we use the PUSI at the moment - but if we remove the section header,
we need at least some way to identify that a packet doesn't contain another
whole/partial SNDU following the end of the first.  I believe the AFC could
be used to introduce the appropriate padding - and is probably best. The scheme
in the draft may need a little more work?

> - I am not convinced we need to envisage that many SNDU types : aren't IPv4, v6,
> Ethernet, MPLS enough ? 2 bytes for this like Ethertype is long...

There are many more types possible, one mentioned in our charter is "ROHC"
compressed IP packets.

I agree though, it seems unlikely there would initially be more than 255.
One reason, I favoured 2B was to allow reuse of existing type codes, 
is this important?
Do we care about the byte-alignment?

> - the famous "label" needs to be specified. A 16-bit field should be enough for
> all kinds of usage, provided it is complemented by an ARP protocol.

Is that yet another type?

> - why should the format of bridged payload be specified in this document ?
> - is it so important to keep the 16/32 bit alignment ?
> - I am not sure to understand well the paragraph about the MPLS header. Why
> putting it into the adaptation field ? it is not the case for other higher layer
> headers like IP and Ethernet.
> - Do you have an adaptation field inserted before each SNDU ? why ?
> 
No - As I see it, this an overhead per MPEG-2 TS Packet.

> As far as regenerative satellites are concerned, here are our views :
> 
> - currently we only envisage ATM VP or MPEG PID switching at the OBP. Switching
> on an extra label would cost a lot... and currently we do not see any concrete
> need to do that. Currently forget about Ethernet or IP layer processing on-board
> !
> - large capacity multi spot-beam "mesh" systems based on regenerative payload
> and MPEG switch handle a lot of terminals (hence a lot of "feeds"). Being able
> to use the same PID for several feeds may prove to be interesting (PID used as a
> "broadcast network" as Horst put it). It is possible to do this, even with a
> "simple" MPEG TS level switch a the OBP. The only need is to have an extra label
> (e.g. the SNDU label) being used to discriminate the SOURCE of the SNDU and have
> only one such SNDU per MPEG cell.

This doesn't seem incompatible with the proposed encapsulation, more an
issue to
do with the way the encapsulator chooses to process IP packets. So, this seems
good.

> - concerning G. Anissa's mail about "Channel-descriptor" signalling the mapping
> Source/Destination @ -> PID, Label : DVB-RCS group is currently working on such
> protocol.

It would be good to know more of this.

> 
> Best regards,
> 
> St?phane
> 
> ALCATEL SPACE INDUSTRIES
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
> Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr


From Ghassane.Aniba at sophia.inria.fr  Tue Apr 30 09:23:54 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 30 Apr 2002 10:23:54 +0200
Subject: Commants on the comments of Alcatel. space.
References: <C1256BA7.0059A801.00@vzmta01.netfr.alcatel.fr>
Message-ID: <3CCE549A.6CF0325D@sophia.inria.fr>

Hi every body,

Stephane.Combes at space.alcatel.fr wrote:
> 
> Hi,
> 
> a few comments on the draft  :
> 
> - page header to be corrected : it is not the ID "Requirements..." anymore
> - in the introduction, something should be said about bidirectionnal systems
> (UDLR, DVB-RCS) and the ones including MPEG switches (satellite OBP for
> instance). DVB-RCS (either for transparent or regenerative satellites) is very
> interesting since it specifies MPEG-2 transport both for the forward and
> (optionally) for the return link.
> - when we think about DVB-RCS's MPEG mode for the return link (shared access
> between terminals), we may want to have a slightly different encapsulation
> scheme. For instance it could include an additional sublayer performing IP
> packet segmentation into several SNDU (AAL2 like scheme).

Why you want to segment IP in many SNDU. If we use the lenght == 16
bits?
We will nwwd segmentation of SNDU in many MPEG2-TP.

> - on the other hand, we could allow IP packets "packing" into a same SNDU
> - I tend to agree with P. Cipi?re comment : why making such a complex use of
> PUSI and AFC ? Sticking to the simpler solution that some drivers currently
> implement might be better (less complex, less overhead).

I agree with you, it will be more complex to manage.

> - I am not convinced we need to envisage that many SNDU types : aren't IPv4, v6,
> Ethernet, MPLS enough ? 2 bytes for this like Ethertype is long...

We can use just 1 byte.

> - the famous "label" needs to be specified. A 16-bit field should be enough for
> all kinds of usage, provided it is complemented by an ARP protocol.

Do you propose a label for each SNDU or for each fragment of SNDU?

> - why should the format of bridged payload be specified in this document ?
> - is it so important to keep the 16/32 bit alignment ?
> - I am not sure to understand well the paragraph about the MPLS header. Why
> putting it into the adaptation field ? it is not the case for other higher layer
> headers like IP and Ethernet.
> - Do you have an adaptation field inserted before each SNDU ? why ?
> 
> As far as regenerative satellites are concerned, here are our views :
> 
> - currently we only envisage ATM VP or MPEG PID switching at the OBP. Switching
> on an extra label would cost a lot... and currently we do not see any concrete
> need to do that. Currently forget about Ethernet or IP layer processing on-board
> !

How will you use switching just on the PID? Don't forget that in the
receiver we can just distinguish between 20 PID, i think.

> - large capacity multi spot-beam "mesh" systems based on regenerative payload
> and MPEG switch handle a lot of terminals (hence a lot of "feeds"). Being able
> to use the same PID for several feeds may prove to be interesting (PID used as a
> "broadcast network" as Horst put it). It is possible to do this, even with a
> "simple" MPEG TS level switch a the OBP. The only need is to have an extra label
> (e.g. the SNDU label) being used to discriminate the SOURCE of the SNDU and have
> only one such SNDU per MPEG cell.

That what i've already propose, to have a label in each mpeg-ts packet.
So what's your opinion about the overhead of this idea?

> - concerning G. Anissa's mail about "Channel-descriptor" signalling the mapping

G.Aniba and not Anissa :).

> Source/Destination @ -> PID, Label : DVB-RCS group is currently working on such
> protocol.

I've more detail about this proposed Descriptor.

> 
> Best regards,
> 
> St?phane
> 
> ALCATEL SPACE INDUSTRIES
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
> Porte : F1027  /  E-Mail : stephane.combes at space.alcatel.fr

Best regards,

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78



From OZGUR.AKSU at startv.com.tr  Tue Apr 30 11:52:04 2002
From: OZGUR.AKSU at startv.com.tr (OZGUR.AKSU at startv.com.tr)
Date: Tue, 30 Apr 2002 13:52:04 +0300
Subject: DVB-RCS
Message-ID: <OF19701DA1.939974C9-ONC2256BAB.0037AF16@star.com.tr>


Hi everyone,

I am preparing master thesis about the DVB-RCS. I need some documents or
any other informations about this subject.Also  if you have documents about
Turbo Coding ,pls also send these documents or send me links of them.

Thanks..

Best Regards..

OZGUR B. AKSU
STAR DIGITAL A.S
HEAD-END SYSTEMS CHIEF
+905424880042
+902124484776



From Ghassane.Aniba at sophia.inria.fr  Tue Apr 30 15:59:37 2002
From: Ghassane.Aniba at sophia.inria.fr (Ghassane Aniba)
Date: Tue, 30 Apr 2002 16:59:37 +0200
Subject: Simultanous PID!?
References: <C1256BA7.0059A801.00@vzmta01.netfr.alcatel.fr>
Message-ID: <3CCEB159.C94A80EE@sophia.inria.fr>

Hi,
I've a simple question to ask:
? when we say that the receiver can just deal with 8 simultanous pid (
Udcast Document and many mails), we mean that we can't receive more pid,
or we can receive them but we'll have a queue?
Please detailed your answers.
Thank you.
I hope that the answers and the dialogue will be more and more
interesting ;).

Best regards.

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78



From christian.maciocco at intel.com  Tue Apr 30 17:15:07 2002
From: christian.maciocco at intel.com (Maciocco, Christian)
Date: Tue, 30 Apr 2002 09:15:07 -0700
Subject: Simultanous PID!?
Message-ID: <AA5ED351DFA4D5118A2C00508B68BB7E075D4391@orsmsx109.jf.intel.com>

That's a limitation of hardware based MPEG-2 TS decoder, usually limited to
8, 16 or 32 PIDs. Software based decoder such as the one available with
Windows XP BDA (Broadcast Data Architecture) where the full MPEG2 TS is fed
out of the tuner to the software decoder there is no PID limit beside your
available memory.
Christian

-----Original Message-----
From: Ghassane Aniba [mailto:Ghassane.Aniba at sophia.inria.fr]
Sent: Tuesday, April 30, 2002 8:00 AM
To: ip-dvb at erg.abdn.ac.uk
Subject: Simultanous PID!?


Hi,
I've a simple question to ask:
? when we say that the receiver can just deal with 8 simultanous pid (
Udcast Document and many mails), we mean that we can't receive more pid,
or we can receive them but we'll have a queue?
Please detailed your answers.
Thank you.
I hope that the answers and the dialogue will be more and more
interesting ;).

Best regards.

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba at sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78



From dent at cosy.sbg.ac.at  Tue Apr 30 19:15:20 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Tue, 30 Apr 2002 20:15:20 +0200 (MET DST)
Subject: Simultanous PID!?
In-Reply-To: <3CCEB159.C94A80EE@sophia.inria.fr>
Message-ID: <Pine.GSO.4.05.10204302013490.22988-100000@mausmaki.cosy.sbg.ac.at>

On Tue, 30 Apr 2002, Ghassane Aniba wrote:

> Hi,
> I've a simple question to ask:
> ? when we say that the receiver can just deal with 8 simultanous pid (
> Udcast Document and many mails), we mean that we can't receive more pid,
> or we can receive them but we'll have a queue?

your receiver will get all the PIDs at once.

the 8 or 20 PIDs just stem from the current implementation of the way
some (most) receivers have implemented the PID filtering.

hope that explains at least this problem,

	++Thomas

-- 
in some way i do, and in some way i don't.




From dent at cosy.sbg.ac.at  Tue Apr 30 19:25:52 2002
From: dent at cosy.sbg.ac.at (Thomas 'Dent' Mirlacher)
Date: Tue, 30 Apr 2002 20:25:52 +0200 (MET DST)
Subject: Simultanous PID!?
In-Reply-To: <AA5ED351DFA4D5118A2C00508B68BB7E075D4391@orsmsx109.jf.intel.com>
Message-ID: <Pine.GSO.4.05.10204302015400.22988-100000@mausmaki.cosy.sbg.ac.at>

On Tue, 30 Apr 2002, Maciocco, Christian wrote:

> That's a limitation of hardware based MPEG-2 TS decoder, usually limited to
> 8, 16 or 32 PIDs. Software based decoder such as the one available with
> Windows XP BDA (Broadcast Data Architecture) where the full MPEG2 TS is fed
> out of the tuner to the software decoder there is no PID limit beside your
> available memory.

just a remark: there are also capable implementations for other OSes out there.

filtering itself is not a problem with memory.

quick calculation:
	2^13 PIDs. - so a lookup table would have 2^13bits, which is 1KB.
	(most current computers have more then that :)

	... also if you have a table with one byte per PID (because you
	want to lookup a specific encapsulation, which you're binding
	to the PIDs, this shouldn't be a problem (8KB))

the only problem you could have with memory is if you have all the datastreams
interleaved on all the PIDs (for simplicity assume we're using all the PIDs
for network data), also another thing we will not account is the overhead
for encapsulation (and TS headers)

worst case memory usage for reassembling/decapsulation:

	(MTU-184)*2^13	... around that at least.

and with an MTU of 64K this would lead to 64M if i'm correct. - this
could well be some problem, but with a smaller MTU=1500, we need 10M
for reassembling the data. (worst case)

	++Thomas	

-- 
in some way i do, and in some way i don't.