Subject: IP over DVB-S2

From: Jérôme Lacan <[email-masked]>
Date: Tue, 21 Jun 2005 10:05:25 +0200

Dear all,

With our colleagues from Alcatel-Space, we are working on the mapping of IP
over DVB-S2.

Recall that DVB-S2 is the "second generation" DVB system for broadband
satellite service. It will probably replace DVB-S in the next few years.
You
can find the specifications in ETSI document - EN 302 307.

One of the main business targets of DVB-S2 is IP packet transmission. The
mapping/encapsulation of IP over this system remains an open research issue.
Actually, DVB-S2 proposes 2 modes to transport the data. The first one,
Transport Stream-TS, is designed to transport MPEG2-TS packets whereas the
second one, Generic Stream-GS, is designed to transport continuous streams
(which can be compound of variable size packets). Regardless of the chosen
mode, the resulting data are then mapped on Data Fields (of length varying
from 16008 to 58192 bits) to be encoded by the FEC (LDPC + BCH).

Several options can be considered for this mapping. We think that the ipdvb
group is a good place to start a discussion on this subject.
If you are interested on this subject, could you please manifest your
interest?

best regards,

Jerome Lacan
ENSICA/TeSA/LAAS-CNRS
Toulouse, France

---

From: Fausto Vieira <[email-masked]>
Date: Tue, 21 Jun 2005 11:33:05 +0200

Dear all,

I would like to participate in this discussion. I think we could start 
to identify the objectives.
Another important thing would be to identify possible problems to solve.

Regards

------- 
Fausto Vieira
Researcher
Dpt. Telecomunicació i d'Enginyeria de Sistemes
ETSE - UNIVERSITAT AUTÒNOMA DE BARCELONA
Campus Universitari, s/n
08193 Bellatera Barcelona SPAIN
Phone :(34) 935813843
Fax   :(34) 935814031

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Tue, 21 Jun 2005 12:39:09 +0200

Dear all,

I guess in general most if not all participants of the ipdvb WG and this 
mailing list are interested in the topic, although ths topic is not 
specifically chartered in the ipdvb wg. In my view it would be a logical 
step to continue the discussions that have started from IP over fixed 
sized TS packets on IP over variable sized S2 frames...

Gorry, do you think it is appropriate to continue the discussions on 
this mailing list? I would opt for in order to avoid opening another 
track of discussions on another mailing list...

Kind regards,
Bernhard

---

From: Salvatore Pulitanò <[email-masked]>
Date: Tue, 21 Jun 2005 11:58:11 +0200

Dear all,

I like to participate in this discussion too. The identification of the 
objectives could be the first step of our work.

Regards
Salvatore

-----------------------------------------------------------------------------------------------
Eng. Salvatore Pulitanò

Dept. DIMET
University "Mediterranea" of Reggio Calabria
Faculty of Engineering

Tel. +39 0965 875 420

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.9/23 - Release Date: 20/06/2005

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 21 Jun 2005 12:02:51 +0100 (BST)

On Tue, 21 Jun 2005, Jérôme Lacan wrote to the ipdvb mailing list:

> With our colleagues from Alcatel-Space, we are working on the
> mapping of IP over DVB-S2.
>
> Recall that DVB-S2 is the "second generation" DVB system for
> broadband satellite service. It will probably replace DVB-S in the
> next few years. You can find the specifications in ETSI document -
> EN 302 307.
>
> One of the main business targets of DVB-S2 is IP packet
> transmission. The mapping/encapsulation of IP over this system
> remains an open research issue. Actually, DVB-S2 proposes 2 modes to
> transport the data. The first one, Transport Stream-TS, is designed
> to transport MPEG2-TS packets whereas the second one, Generic
> Stream-GS, is designed to transport continuous streams (which can be
> compound of variable size packets). Regardless of the chosen mode,
> the resulting data are then mapped on Data Fields (of length varying
> Several options can be considered for this mapping. We think that
> the ipdvb group is a good place to start a discussion on this
> subject.

One approach to transporting continuous streams is to carry a
continuous HDLC stream; once you come out of your DVB-S2-capable modem
the HDLC stream would be ready to go right into a serial port on any
router for the IP packets to be handled there -- and integrating
modem and router becomes easy.

This HDLC approach has been proposed in the space agency domain for
their CCSDS protocols, as easier than the various existing and arcane
IP-in-CCSDS encapsulations. A new IP-over-CCSDS space links workgroup:
http://public.ccsds.org/sites/cwe/sis-ipo/default.aspx
has been formed to discuss this, in a kind of parallel way to this
IP-over-DVB IETF workgroup.

This sapproach separates the layering quite cleanly. You'll find a
description of the engineering advantages of layering an HDLC stream
over your link in:

K. Hogie, E. Criscuolo and R. Parise, Using standard Internet
Protocols and applications in space, Computer Networks, special issue
on Interplanetary Internet, vol. 47 no. 5, pp. 603-650, April 2005.

...which describes the HDLC-into-modem case (with a number of
practical anecdotes) and proposes the HDLC-into-CCSDS-device case.

One source for a copy of that paper is:
http://www.uni-bamberg.de/wiai/ktr/html/lehre/2005ss/hauptsem/unterlagen/hogie.pdf

If you think of DVB-S2 as, like CCSDS, being a very complex link
layer, this approach makes a lot of sense.

L.

> If you are interested on this subject, could you please manifest your

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: "Julien Fasson" <[email-masked]>
Date: Tue, 21 Jun 2005 13:17:19 +0200

Dear all,

I will be glad to participate to this discussion too since I am working a
bit on this topic.
DVB-S2 seems to offer good perspectives for IP support, but it seems
interesting to identify first the issues of IP integration, their
differences with IP over DVB-S problems, and therefore the objectives of
this discussion.

Best Regards,

******************************************
**   Julien Fasson                                                    **
**   Département Réseaux et Télécommunications    **
**   ENSEEIHT / Laboratoire IRIT                         **
**   Tel: 05 61 58 80 22                                          **
**   Email: [email-masked]                         **
******************************************

---

From: "Adrian J. Hooke" <[email-masked]>
Date: Tue, 21 Jun 2005 08:24:00 -0700

At 04:02 AM 6/21/2005, Lloyd Wood of Cisco wrote:
>This HDLC approach has been proposed in the space agency domain for their 
>CCSDS protocols, as easier than the various existing and arcane 
>IP-in-CCSDS encapsulations.

"Easier" and "arcane" are subjective terms. The current four variants of 
internationally standardized space link protocols that are defined by the 
CCSDS Space Link Services Area 
http://public.ccsds.org/publications/default.aspx provide standard 
mechanisms for directly multiplexing variable-length IP packets into the 
link framing mechanisms, as well as a lightweight encapsulation mechanism 
http://public.ccsds.org/sites/cwe/rids/Lists/1331R3/Attachments/133x1r3.pdf 
that may be useful for carrying a variety of upper layer data units such as 
IPv6 (including jumbograms). The current standards also allow a serial 
stream to be carried point-to-point across a single link. The goal of the 
current BOF is to examine whether there is a need to more clearly and 
centrally define how these various IP transfer options operate. We would 
welcome a liaison relationship with the new IP over DVB-S2 study.

Best regards

Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)
NASA Jet Propulsion Laboratory,
Interplanetary Network Directorate
Pasadena, California, USA

---

From: Fausto Vieira <[email-masked]>
Date: Tue, 21 Jun 2005 18:13:33 +0200

Due to the different length sizes for the data fields, clearly the first 
objective is:
- Support multiple IP packets in one data field.

A not so obvious one is the support for packet segmentation.
For me, I would be in favour of making this optional. When you have 
large data fields, you loose at maximum 11999 bytes (8*MTU-1 bit).
But of small data fields this is quite important.
Of course, the delay could have important consequences. Imagine the 
scenario where you transmit the first part of the packet in one data 
field. In the next scheduler slot, the user is experiencing bad channel 
conditions and if you transmit in the same data field, the user will 
receive the packet corrupted. This would mean that by system design, the 
segmented packets would need to be outside the mechanism that decides 
the appropriate Coding and modulation rate.

I don't know if I was very clear with this example.

---

From: Jérôme Lacan <[email-masked]>
Date: Wed, 22 Jun 2005 13:42:26 +0200

> Due to the different length sizes for the data fields, 
> clearly the first objective is:

Yes, it seems mandatory because the size of the Data Fields can be very
large 
(until 58192 bits) compared to the IP packet length.

> For me, I would be in favour of making this optional. When 
> you have large data fields, you loose at maximum 11999 bytes 
> (8*MTU-1 bit). 

"11999 bits", it's better :-) 
Intuitively, on average, without segmentation, you should loose about half
of the 
average length of an IP packet per Data field. For short Data Fields, it 
can be very important. 

> Of course, the delay could have important consequences. 
> Imagine the scenario where you transmit the first part of the 
> packet in one data field. In the next scheduler slot, the 
> user is experiencing bad channel conditions and if you 
> transmit in the same data field, the user will receive the 
> packet corrupted. 
>
> This would mean that by system design, the 
> segmented packets would need to be outside the mechanism that 
> decides the appropriate Coding and modulation rate.

I think that the segmentation is indeed one of the things that should be
evaluated by taking 
into account all the parameters, including delays, probabilities of data
field corruption, .... 

Jerome Lacan

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 22 Jun 2005 13:16:18 +0100

I think DVB-S2 is a topic which seems related to the work of the ipdvb WG, and 
that there is probably sufficient expertise within this WG to discuss this 
(I've seen several responses already).

I'd encourage three things:

(i) This is an IETF mailing list - all contributions must adhere to the IETF 
copyright rules, please do not introduce things that include IPR, unless you 
notify the IETF of this.

(ii) This topic does not address a current Charter item of the ipdvb Working 
Group. The discussion of the topic on the list does NOT imply the willingness 
of the IETF to standardise a new method. This is an IESG decision, that would 
require prior publication of an Internet Draft, and much discussion.

(iii) I think we need to start with a requirement for what needs to be done, 
this would be useful to many in this WG. The normal way to contribute such 
documents is again, by publishing of an Internet-Draft on the topic. I do 
encourage you to do this.

Best wishes,

Gorry
(ipdvb WG Chair)

P.S. I am also interested in this topic.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 22 Jun 2005 17:40:29 +0100

The article bu K. Hogie et al is interesting, but seems not to have taken a 
detailed look at DVB, specifically, I notice on page 661, section 4, it says;

"one of the most important issues in this paper is to note that unlike current 
space communication systems, commercial network products perform 
forward-error-correction (FEC) coding, such as Reed-Solomon or convolutional, 
independently from the data link framing. This is..."

- I don't believe this was true of DVB bearers, in which the R-S codec is 
synchronised using the MPEG-2 TS Synch byte, rather than embedding a 
physical-layer synch word.

- In DVB-S2, the waveform is more like a burst modulation. Two modes are 
supported. One mode uses MPEG-2 TS formatting, the other mode (GS) could 
utilise the BB frame header construct as the synchronisation point for a new 
encapsulation protocol directly mapping IP and other network protocols to the 
BB frame. The details of this have still to be defined.

Gorry

---

From: Jérôme Lacan <[email-masked]>
Date: Fri, 24 Jun 2005 15:30:31 +0200

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Gorry Fairhurst
> Envoyé : mercredi 22 juin 2005 14:16
> À : [email-masked]
> Objet : Re: Discussion on IP over DVB-S2 -
> 
> 
> I think DVB-S2 is a topic which seems related to the work of 
> the ipdvb WG, and that there is probably sufficient expertise 
> within this WG to discuss this (I've seen several responses already).
> 
> (i) This is an IETF mailing list - all contributions must 
> adhere to the IETF copyright rules, please do not introduce 
> things that include IPR, unless you notify the IETF of this.
> 
> (ii) This topic does not address a current Charter item of 
> the ipdvb Working Group. The discussion of the topic on the 
> list does NOT imply the willingness of the IETF to 
> standardise a new method. This is an IESG decision, that 
> would require prior publication of an Internet Draft, and 
> much discussion.
> 
> (iii) I think we need to start with a requirement for what 
> needs to be done, this would be useful to many in this WG. 
> The normal way to contribute such documents is again, by 
> publishing of an Internet-Draft on the topic. I do encourage 
> you to do this.

OK. I propose you to begin the preparation of this I-D.
Is it possible to have an agenda slot at the next IETF meeting to present it
? 

Jerome

> > With our colleagues from Alcatel-Space, we are working on 
> the mapping 
> > of IP over DVB-S2.
> > 
> transmission. 
> > The mapping/encapsulation of IP over this system remains an 
> open research issue.
> > Actually, DVB-S2 proposes 2 modes to transport the data. The first 
> > one, Transport Stream-TS, is designed to transport MPEG2-TS packets 
> > whereas the second one, Generic Stream-GS, is designed to transport 
> > continuous streams (which can be compound of variable size 
> packets). 
> > Regardless of the chosen mode, the resulting data are then 
> mapped on 
> > Data Fields (of length varying from 16008 to 58192 bits) to 
> be encoded by the FEC (LDPC + BCH).
> > 
> > Several options can be considered for this mapping. We 
> think that the 
> > ipdvb group is a good place to start a discussion on this subject.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Jun 2005 15:25:02 +0100

<snip>

> Is it possible to have an agenda slot at the next IETF meeting to present it

Yes, no problem.

Let me know what the name of the draft will be, as soon as you can..

I'm assuming you'll use a name draft-xxx-ipdvb-yyy-00.txt.

Send an email choosing x= your name, and y= something appropriate, and I will 
add it to the Agenda.

Gorry
(ipdvb WG Chair)

---

From: Jérôme Lacan <[email-masked]>
Date: Fri, 24 Jun 2005 17:01:18 +0200

> Send an email choosing x= your name, and y= something 
> appropriate, and I will add it to the Agenda.

ok, the name of the draft is draft-cantillo-ipdvb-S2encaps-00.txt

Jerome