[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IP over DVB-S2 early structure
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