Balanced matrix: Difference between revisions
en>AnomieBOT m Dating maintenance tags: {{Citation needed}} |
No edit summary |
||
Line 1: | Line 1: | ||
{{IPstack}} '''Generic Stream Encapsulation''', or GSE for short, is a [[Data link layer]] protocol defined by [[Digital Video Broadcasting|DVB]]. GSE provides means to carry packet oriented protocols, like for example [[Internet Protocol|IP]], on top of uni-directional [[physical layer]]s like e.g. [[DVB-S2]], [[DVB-T2]] and [[DVB-C2]]. | |||
GSE provides additional features beyond the pure carriage of IP datagrams that increase the protocol flexibility and applicability. Some key GSE functions/characteristics are: | |||
* Support for multi-protocol encapsulation ([[IPv4]], [[IPv6]], [[MPEG]], [[Asynchronous Transfer Mode|ATM]], [[Ethernet]], [[IEEE 802.1Q|802.1pQ]] [[VLAN]]s, etc.) | |||
* Transparency to network layer functions, including [[Internet Protocol|IP]] [[encryption]] and IP [[Van Jacobson TCP/IP Header Compression|header compression]]. | |||
* Support of several addressing modes. In addition to the 6-byte [[MAC address]] (including [[multicast]] and [[unicast]]), it supports a MAC address-less mode, and an optional 3-byte address mode. | |||
* A mechanism for fragmenting [[Internet Protocol|IP]] [[datagrams]] or other [[network layer]] [[Packet (information technology)|packets]] over [[baseband|Base Band]] frames to support [[Link adaptation|ACM]]/[[Variable Coding and Modulation|VCM]]. | |||
* Support for hardware [[Firewall (computing)|filtering]]. | |||
* Extensibility: additional [[link protocol]]s can be included through specific protocol type values (e.g. [[Layer 2]] security, IP Header Compression, etc.). | |||
== Protocol Outline == | |||
[[File:GSE diagram.png|right|thumb|400px|alt=Diagram of GSE encapsulation and fragmentation|How GSE carries datagrams and is carried in the physical layer]] | |||
The [[Communications protocol|protocol]] [[specification]] has been published as [[ETSI]] TS | |||
102 606.<ref name="ts102606">ETSI TS 102 606: "Digital Video | |||
Broadcasting (DVB); Generic Stream Encapsulation (GSE) | |||
Protocol"</ref> An accompanying [[implementation]] [[guidelines]] | |||
document has been published as [[ETSI]] TS 102 771.<ref name="ts102771">ETSI TS 102 771: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) implementation guidelines"</ref> | |||
IP datagrams, Ethernet Frames, or other network layer packets are encapsulated in one or more GSE Packets. The encapsulation process adds control information such as the network protocol type and address label, and provides an overall integrity check when needed. | |||
The payload frame may be encapsulated in a single GSE Packet or sliced into fragments and encapsulated in several GSE Packets. GSE Packets have in general variable length, in order to match the input IP traffic with minimum overhead. | |||
GSE Packets may be sent in different Base Band frames, not necessarily consecutive or with the same transmission parameters (modulation format, coding rate). No constraint on the GSE Packet position within the Base Band frame is assumed. However, GSE Packets may not be reordered between the encapsulator and the de-encapsulator. In general, a Base Band frame can contain more than a single GSE Packet. Base Band frames may have fixed, or variable length. | |||
GSE does not provide a mechanism for integrity check of single GSE Packet. A [[CRC-32]] is only appended to the last fragment of a fragmented payload to verify the correctness of the reassembly operation. GSE relies on the physical layer being able to ensure the required error detection and/or correction probability.<ref>IETF RFC 3819: "Advice for Internet Subnetwork Designers"</ref> | |||
=== GSE Header === | |||
The GSE Packet header is highly dynamic and provides for many options. The minimum header is two bytes, comprising three flags fields, and a 12-bit payload length field. The diagram below shows all possible fields. | |||
{| class="wikitable" style="text-align:center" | |||
|+ Unrolled GSE Header | |||
|- | |||
! width="4%"|bit offset | |||
! colspan="1" width="3%"| 0 | |||
! colspan="1" width="3%"| 1 | |||
! colspan="2" width="6%"| 2-3 | |||
! colspan="4" width="12%"| 4–7 | |||
! colspan="8" width="24%"| 8-15 | |||
! colspan="8" width="24%"| 16-23 | |||
! colspan="8" width="24%"| 24-31 | |||
|- | |||
! 0 | |||
| colspan="1" | Start | |||
| colspan="1" | End | |||
| colspan="2" | Label Type | |||
| colspan="12"| GSE Length | |||
| colspan="8" bgcolor="#CCFFCC"| Fragment ID | |||
| colspan="8" bgcolor="#CCFFCC"| Total Length | |||
|- | |||
! 32 | |||
| colspan="8" bgcolor="#CCFFCC"| Total Length | |||
| colspan="16" bgcolor="#CCFFCC"| Protocol Type | |||
| colspan="8" bgcolor="#CCFFCC"| Label (3 Byte) | |||
|- | |||
! 64 | |||
| colspan="16" bgcolor="#CCFFCC"| Label (3 Byte) | |||
| colspan="16" bgcolor="#AADDBB"| Label (6 Byte) | |||
|- | |||
! 96 | |||
| colspan="8" bgcolor="#AADDBB"| Label (6 Byte) | |||
| colspan="24" bgcolor="#FFBBBB"| [[ULE]] Extension Headers (Optional) | |||
|- | |||
! ... | |||
| colspan="24" bgcolor="#FFBBBB"| ... | |||
| colspan="8" | Data | |||
|- | |||
! ... | |||
| colspan="32"| <br />Data<br /> | |||
|} | |||
=== Fragmentation and Reassembly === | |||
The basic mechanism of GSE payload fragmentation uses the Start and End Flags, where the Start flag indicates the beginning of a payload frame, and the End flag indicates its end. This is shown in the diagram below. | |||
{| class="wikitable" style="text-align:center" | |||
|+ Fragmentation Principle | |||
|- | |||
! width="10%" | Start | |||
! width="10%" | End | |||
! width="80%" | GSE Packet Content | |||
|- | |||
| 1 | |||
| 0 | |||
| style="text-align:left" | Total payload size / Protocol type / Payload start | |||
|- | |||
| 0 | |||
| 0 | |||
| style="text-align:left" | Payload continuation | |||
|- | |||
| 0 | |||
| 1 | |||
| style="text-align:left" | Payload end / CRC-32 | |||
|- | |||
|} | |||
On [[DVB-S2]], [[DVB-T2]], and [[DVB-C2]] the ACM/VCM modes may cause the Base Band frames to vary in size depending on the transmission conditions. Hence there may be situations where the first fragments of a payload frame have been sent, but the encapsulator is forced to set aside the current payload frame, and start working on a new one. This may e.g. occur when large fragments have been prepared while transmission conditions were fine, but suddenly the conditions deteriorate, and only small Base Band frames are available. | |||
This is when the '''Fragment ID''' field becomes important. It is a short-term identification of the payload frame. Whenever the encapsulator needs to move on to the next payload frame, without having finished transmitting the previous one, it uses the next available Fragment ID. That way, up to 256 payload frames can be "kept open" at any time. The decapsulator uses the Fragment ID to pick the reassembly buffer in which to store the fragment. | |||
=== GSE addresses === | |||
The "Label Type" (LT) bits determine how the GSE packet address is encoded according to the following table: | |||
{| class="wikitable" style="text-align:center" | |||
|+ Addressing Mode | |||
|- | |||
! width="10%" | LT bits | |||
! width="80%" | Addressing mode | |||
|- | |||
| 00 | |||
| style="text-align:left" | Indicates that a 6 bytes label is present and shall be used for filtering. | |||
|- | |||
| 01 | |||
| style="text-align:left" | Indicates that a 3 bytes label is present and shall be used for filtering. | |||
|- | |||
| 10 | |||
| style="text-align:left" | No label present. All receivers shall process this packet. | |||
|- | |||
| 11 | |||
| style="text-align:left" | Label re-use: no label is present; the label is the same as the previous GSE packet in the same base band frame. LT=11 shall not be used for the first GSE packet in a base band frame. | |||
|- | |||
|} | |||
=== CRC-32 Trailer === | |||
Each GSE Packet containing the last fragment for a payload frame, carries a [[Cyclic redundancy check|CRC-32 checksum]] over the payload frame. The checksum is used to detect loss of intermediate fragments. | |||
The checksum is a 32 bit value calculated according to the generator polynomial represented by 0x104C11DB7: | |||
<math>y = x^{32} + x^{26} + x^{23} + x^{22} + x^{16} + x^{12} + x^{11} + x^{10} + x^{8} + x^{7} + x^{5} + x^{4} + x^{2} + x^{1} + x^{0}</math> | |||
If the last fragment of a paylod frame is lost, the decapsulator can not directly detect that fact. It never sees the GSE frame with the End flag set and containing the CRC-32. For this situation, the decapsulator must choose a suitable time-out based on the data-rate and application. | |||
== GSE Implementations == | |||
=== Products Supporting GSE === | |||
Since GSE packets are directly inserted into base-band frames of the | |||
modulation scheme, GSE products come in the form of "GSE Routers" or | |||
"GSE Modems", which - from the outside - act very much like a DSL | |||
Router or DSL Modem used by consumers. More generically these devices | |||
are also referred to as "GSE Encapsulators". These products have a standard | |||
IP network interface (most often [[Ethernet]] or a similar [[LAN]] | |||
interface) to collect IP traffic which is to be forwarded over the | |||
uni-directional link on the other end. To optimise the packaging into | |||
base-band frames, these devices typically generate complete base-band | |||
frames with the GSE packets as payload, which are then transferred to | |||
the [[DVB-S2]], [[DVB-T2]] or [[DVB-C2]] modulator through a second | |||
interface. | |||
Here is a (very likely incomplete) list of GSE en- and decapsulators: | |||
* [http://www.newtec.eu/ Newtec] | |||
** [http://www.newtec.eu/products/professional-equipment/elevation/modems/ip-satellite-modem-el470/ EL470 IP Satellite Modem] | |||
** [http://www.newtec.eu/products/professional-equipment/elevation/demodulators/ip-satellite-demodulator-el970/ EL970 IP Satellite Demodulator] | |||
* [http://www.work-microwave.de/ WORK Microwave GmbH] | |||
** [http://www.work-microwave.de/dvb-s_s2.html#modems Challenge Series Satellite High Speed DVB-S2 IP Modem SK-IP] | |||
* [http://www.gcs-salzburg.at/ gcs Global Communication & Services GmbH] | |||
** [http://www.gcs-salzburg.at/products/products_transmit.html.en ODG200 IP/DVB-S2 Encapsulator/Modulator with ACM support] | |||
** [http://www.gcs-salzburg.at/products/products_receive.html.en BSR200 IP/DVB-S2 Receiver with ACM support] | |||
* [http://www.advantechwireless.com/ Advantech Wireless Inc.] | |||
** [http://www.advantechwireless.com/catalogue/products/amt75e-dvb-ss2-high-speed-broadcast-modem-2/ AMT 75e DVB-S/S2 High Speed Broadcast Modem] | |||
* [http://www.comtechefdata.com/ Comtech EF Data Corporation] | |||
** [http://www.comtechefdata.com/products/Advanced-VSAT-Series/pcdm-840.asp CDM-840 Remote Router] | |||
* [http://www.transplaneta.com/ K.S.Transplaneta Ltd.] | |||
** [http://www.transplaneta.com/products/ip-encapsulator dpi4502 DVB2 (S2/T2/C2) compliant IPv4 / IPv6 Encapsulator] | |||
* [http://dveo.com/ Computer Modules, Inc.] | |||
** [http://dveo.com/broadcast-systems/ip-over-dvb-encapsulator.shtml DVB Rocket™/S2] | |||
=== GSE-based IP Service Offerings === | |||
There are many IP-over-satellite service offerings, including for | |||
instance [[ASTRA2Connect]] from [[SES S.A.|SES]] or [[Tooway]] from | |||
[[Eutelsat]]. Little detail is however known about the protocols used | |||
since the receivers are provided as part of the service by the | |||
operators and very little technical detail is disclosed. | |||
== References == | |||
<!--- See http://en.wikipedia.org/wiki/Wikipedia:Footnotes on how to create references using <ref></ref> tags which will then appear here automatically --> | |||
{{Reflist}} | |||
== External links == | |||
* [http://www.dvb.org/technology/standards/index.xml#multiplexing Obtain GSE Standard and Guidelines from DVB free of charge] | |||
* [http://www.dvb.org/technology/fact_sheets/DVB-GSE-Fact-Sheet.0709.pdf DVB Fact Sheet on GSE] | |||
* [http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=30265 GSE project home page at [[ESA]]] | |||
* [http://launchpad.net/libgse/ Opensource implementation of GSE] | |||
[[Category:Articles created via the Article Wizard]] | |||
[[Category:Television technology]] | |||
[[Category:Link protocols]] |
Latest revision as of 23:37, 6 January 2014
Nice meet up with you, I'm Ardell Labarbera but I never really liked that name. Illinois is your biggest I love most. The job I've been occupying countless soft drinks is a librarian but soon We are on personalized. As a girl what I like is to play baseball but i don't maintain the time fairly recently. See what's new in her website here: http://devolro.com/armoring
Feel free to visit my web page - supercar Generic Stream Encapsulation, or GSE for short, is a Data link layer protocol defined by DVB. GSE provides means to carry packet oriented protocols, like for example IP, on top of uni-directional physical layers like e.g. DVB-S2, DVB-T2 and DVB-C2.
GSE provides additional features beyond the pure carriage of IP datagrams that increase the protocol flexibility and applicability. Some key GSE functions/characteristics are:
- Support for multi-protocol encapsulation (IPv4, IPv6, MPEG, ATM, Ethernet, 802.1pQ VLANs, etc.)
- Transparency to network layer functions, including IP encryption and IP header compression.
- Support of several addressing modes. In addition to the 6-byte MAC address (including multicast and unicast), it supports a MAC address-less mode, and an optional 3-byte address mode.
- A mechanism for fragmenting IP datagrams or other network layer packets over Base Band frames to support ACM/VCM.
- Support for hardware filtering.
- Extensibility: additional link protocols can be included through specific protocol type values (e.g. Layer 2 security, IP Header Compression, etc.).
Protocol Outline
The protocol specification has been published as ETSI TS 102 606.[1] An accompanying implementation guidelines document has been published as ETSI TS 102 771.[2]
IP datagrams, Ethernet Frames, or other network layer packets are encapsulated in one or more GSE Packets. The encapsulation process adds control information such as the network protocol type and address label, and provides an overall integrity check when needed.
The payload frame may be encapsulated in a single GSE Packet or sliced into fragments and encapsulated in several GSE Packets. GSE Packets have in general variable length, in order to match the input IP traffic with minimum overhead.
GSE Packets may be sent in different Base Band frames, not necessarily consecutive or with the same transmission parameters (modulation format, coding rate). No constraint on the GSE Packet position within the Base Band frame is assumed. However, GSE Packets may not be reordered between the encapsulator and the de-encapsulator. In general, a Base Band frame can contain more than a single GSE Packet. Base Band frames may have fixed, or variable length.
GSE does not provide a mechanism for integrity check of single GSE Packet. A CRC-32 is only appended to the last fragment of a fragmented payload to verify the correctness of the reassembly operation. GSE relies on the physical layer being able to ensure the required error detection and/or correction probability.[3]
GSE Header
The GSE Packet header is highly dynamic and provides for many options. The minimum header is two bytes, comprising three flags fields, and a 12-bit payload length field. The diagram below shows all possible fields.
bit offset | 0 | 1 | 2-3 | 4–7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Start | End | Label Type | GSE Length | Fragment ID | Total Length | ||||||||||||||||||||||||||
32 | Total Length | Protocol Type | Label (3 Byte) | |||||||||||||||||||||||||||||
64 | Label (3 Byte) | Label (6 Byte) | ||||||||||||||||||||||||||||||
96 | Label (6 Byte) | ULE Extension Headers (Optional) | ||||||||||||||||||||||||||||||
... | ... | Data | ||||||||||||||||||||||||||||||
... | Data |
Fragmentation and Reassembly
The basic mechanism of GSE payload fragmentation uses the Start and End Flags, where the Start flag indicates the beginning of a payload frame, and the End flag indicates its end. This is shown in the diagram below.
Start | End | GSE Packet Content |
---|---|---|
1 | 0 | Total payload size / Protocol type / Payload start |
0 | 0 | Payload continuation |
0 | 1 | Payload end / CRC-32 |
On DVB-S2, DVB-T2, and DVB-C2 the ACM/VCM modes may cause the Base Band frames to vary in size depending on the transmission conditions. Hence there may be situations where the first fragments of a payload frame have been sent, but the encapsulator is forced to set aside the current payload frame, and start working on a new one. This may e.g. occur when large fragments have been prepared while transmission conditions were fine, but suddenly the conditions deteriorate, and only small Base Band frames are available.
This is when the Fragment ID field becomes important. It is a short-term identification of the payload frame. Whenever the encapsulator needs to move on to the next payload frame, without having finished transmitting the previous one, it uses the next available Fragment ID. That way, up to 256 payload frames can be "kept open" at any time. The decapsulator uses the Fragment ID to pick the reassembly buffer in which to store the fragment.
GSE addresses
The "Label Type" (LT) bits determine how the GSE packet address is encoded according to the following table:
LT bits | Addressing mode |
---|---|
00 | Indicates that a 6 bytes label is present and shall be used for filtering. |
01 | Indicates that a 3 bytes label is present and shall be used for filtering. |
10 | No label present. All receivers shall process this packet. |
11 | Label re-use: no label is present; the label is the same as the previous GSE packet in the same base band frame. LT=11 shall not be used for the first GSE packet in a base band frame. |
CRC-32 Trailer
Each GSE Packet containing the last fragment for a payload frame, carries a CRC-32 checksum over the payload frame. The checksum is used to detect loss of intermediate fragments.
The checksum is a 32 bit value calculated according to the generator polynomial represented by 0x104C11DB7:
If the last fragment of a paylod frame is lost, the decapsulator can not directly detect that fact. It never sees the GSE frame with the End flag set and containing the CRC-32. For this situation, the decapsulator must choose a suitable time-out based on the data-rate and application.
GSE Implementations
Products Supporting GSE
Since GSE packets are directly inserted into base-band frames of the modulation scheme, GSE products come in the form of "GSE Routers" or "GSE Modems", which - from the outside - act very much like a DSL Router or DSL Modem used by consumers. More generically these devices are also referred to as "GSE Encapsulators". These products have a standard IP network interface (most often Ethernet or a similar LAN interface) to collect IP traffic which is to be forwarded over the uni-directional link on the other end. To optimise the packaging into base-band frames, these devices typically generate complete base-band frames with the GSE packets as payload, which are then transferred to the DVB-S2, DVB-T2 or DVB-C2 modulator through a second interface.
Here is a (very likely incomplete) list of GSE en- and decapsulators:
- Newtec
- WORK Microwave GmbH
- gcs Global Communication & Services GmbH
- Advantech Wireless Inc.
- Comtech EF Data Corporation
- K.S.Transplaneta Ltd.
- Computer Modules, Inc.
GSE-based IP Service Offerings
There are many IP-over-satellite service offerings, including for instance ASTRA2Connect from SES or Tooway from Eutelsat. Little detail is however known about the protocols used since the receivers are provided as part of the service by the operators and very little technical detail is disclosed.
References
43 year old Petroleum Engineer Harry from Deep River, usually spends time with hobbies and interests like renting movies, property developers in singapore new condominium and vehicle racing. Constantly enjoys going to destinations like Camino Real de Tierra Adentro.