Subject: IP over DVB-S2 requirements draft

From: "Juan Cantillo" <[email-masked]>
Date: Fri, 30 Sep 2005 13:49:41 +0200

Re: Non-IP Protocol SupportDear all,

Following the 63th meeting discussions, we have produced a brand-new version of our document concerning the IP/DVB-S2 issues. The I-D "draft-cantillo-ipdvb-s2encaps-01.txt" si bnow available online at: 

http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-01.txt

We look forward to discussing the draft together in Vancouver. Of course, we warmly encourage you to take a look at it from now; comments, questions and remarks are most welcome via @.

Best regards,

-----------------------------------------------------------------------
Juan CANTILLO - SatComs PhD. Researcher
Tel +33 6 23 54 59 65- Fax  +33 5 61 61 86 88
ENST/TeSA/ENSICA/AAS, Toulouse, FR

---

From: Fausto Vieira <[email-masked]>
Date: Fri, 30 Sep 2005 17:39:50 +0200

Some ideas for encapsulation protocol of IP over DVB-S2. This is not in 
a draft structure because it is still an idea and I have never done a 
IETF draft. No security support is described yet.

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

The frames should fit the exact size of the BBFRAME DATAFIELD.

The structure would be something like:

HEADER+OPTIONAL_FIELDS+PAYLOAD+PADDING+OPTIONAL_CRC

or for multiple packet encapsulation:

HEADER+OPTIONAL_FIELDS+PAYLOAD+MINI_HEADER+PADDING+OPTIONAL_CRC

The HEADER should consist of:

ID - Required to determine encapsulation protocol

VERSION - Required for future versions on the protocol

ENCAP_PROTO - Network layer protocol ID: IPv4 unicast, IPv4 multicast, 
IPv6 unicast, IPv6 multicast, IPv4/IPv6 compressed datagrams, other 
(specified in optional field

MULTI_PACKETS - True if more than one packet in the encapsulation frame

MAC_FIELDS - MAC addresses present for this packet. Four possible 
values: No MAC addresses, Destination only MAC address, Source only MAC 
address, Source and Destination MAC address

FRAG_STATUS - Four possible values: NO - packet not fragmented, BEGIN - 
packet is fragmented and starts in this frame, CONTINUED - The start of 
the packet was in a past frame and it will continue in a future frame

OTHER_FIELDS - Defines if a next_field+field_data kind of structure is 
present in this frame

CRC_CHECK - Exists CRC field in the end of the frame. Four possible 
values: NO, CRC8, CRC16, CRC32

This would be the fixed header. According to the options in the header, 
possible fields may follow the header:

If ENCAP_PROTO is not native, this field would specify the protocol with 
a ETHER_TYPE field.

If MAC_FIELDS is different from NO, then one or two MAC addresses will 
follow according to the value of the MAC_fields

If FRAG_STATUS is not NO, then a FRAG_ID number is inserted here in 
other to send several fragmented packets in non-consecutive frames.

If MULTI_PACKETS is true then offset field is inserted here to inform 
the decoder where to jump to process next packet. From the information 
sent to this point, the decoder probably knows if the packet is meant 
for it.

If OTHER_FIELDS is true then a sequence of NEXT_FIELD+FIELD_DATA is 
inserted here.

After these fields, the payload itself would be inserted here.

PAYLOAD

After the PAYLOAD, another packet may be present, but if not jump to 
PADDING section. MULTI_PACKETS must be true for this to be allowed.

The other packets present in the frame do not require the same header 
information. These packets could be preceded by the following:

MINI_HEADER:

ENCAP_PROTO+MAC_FIELDS+FRAG_STATUS+MULTI_PACKETS+OTHER_FIELDS

The sequence of optional fields should follow according to the MINI_HEADER.
After these fields, the payload itself would be inserted here.

PAYLOAD

After the PAYLOAD, another packet may be present, but if not jump to 
PADDING section. MULTI_PACKETS must be true for this to be allowed.

PADDING - even with multiple packets and fragmentation in one frame, 
these may not fit perfectly inside the frame and therefore some padding 
could be required.

OPTIONAL_CRC - This field could be mandatory for some payload. CRC 
checks could be chosen according to the free space in the frame that 
would be otherwise wasted on padding.

-- 
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