Sonet/Sdh: Yaakov (J) Stein Chief Scientist RAD Data Communications
Sonet/Sdh: Yaakov (J) Stein Chief Scientist RAD Data Communications
Sonet/Sdh: Yaakov (J) Stein Chief Scientist RAD Data Communications
AUG
AUG
C2
C12
C11
TUG-2 VC-2 TU-2
VC-12 TU-12
VC-11 TU-11
STM-0
ATM 2.144 M
E4 139.264 M
ATM 1.6 M
ATM 149.760M
ATM 48.384 M
ATM 6.874M
E3 34.368 M
T3 44.736 M
T2 6.312 M
E1 2.048 M
T1 1.544 M
*
3
*
7
*
3
*
7
*
4
*
3
Y(J)S SONET Slide 65
All SONET mappings
STS-N
STS-3 SPE
STS-3c
STS-1
VT6 SPE
VT2 SPE
VT1.5 SPE
VT6
VT-2
VT1.5
ATM 2.144 M
E4 139.264 M
ATM 1.6 M
ATM 149.760M
ATM 48.384 M
ATM 6.874M
E3 34.368 M
T3 44.736 M
T2 6.312 M
E1 2.048 M
T1 1.544 M
*N
STS-1 SPE
VTG
*
7
pointer processing
*
3
*
4
Y(J)S SONET Slide 66
Tributary mapping types
When mapping tributaries into VCs, PDH-like bit-stuffing is used
For E1 and T1 there are several options
Asynchronous mapping (framing-agnostic)
Bit synchronous mapping
Byte synchronous mapping (time-slot aligned)
E4 into VC-4, E3/T3 into VC-3 are always asynchronous
T1 into VC-11 may be any of the 3
(in byte synchronous the framing bit is placed in the VC overhead)
E1 into VC-12 may be asynchronous or byte synchronous
Y(J)S SONET Slide 67
WAN-PHY (10 GbE in STM-64)
There is a special case where the bit-rates work out relatively well
GbE 10GBASE-R (64B/66B coding) can be directly mapped
into a STM-64 (with contiguous concatenation - see later) without need for GFP
MAC creates "stretched InterPacket Gap" to compensate for rate being < 10G
This is the fastest connection commonly used for Internet traffic
Complication: SDH clock accuracy is 4.6 ppm, GbE accuracy is 20 ppm
64*(270-9) = 16704 columns
J1
63 columns of fixed stuff
10GBASE-W 802.3-2005 Clause 50
Y(J)S SONET Slide 68
Protection
and
Rings
Y(J)S SONET Slide 69
What is protection ?
SONET/SDH need to be highly reliable (five nines)
Down-time should be minimal (less than 50 msec)
So systems must repair themselves (no time for manual intervention)
Upon detection of a failure (dLOS, dLOF, high BER)
the network must reroute traffic (protection switching)
from working channel to protection channel
The Network Element that detects the failure (tail-end NE)
initiates the protection switching
The head-end NE must change forwarding or to send duplicate traffic
Protection switching is unidirectional
Protection switching may be revertive (automatically revert to working channel)
head-end NE tail-end NE
working channel
protection channel
Y(J)S SONET Slide 70
How does it work?
Head-end and tail-end NEs have bridges (muxes)
Head-end and tail-end NEs maintain bidirectional signaling channel
Signaling is contained in K1 and K2 bytes of protection channel
K1 tail-end status and requests
K2 head-end status
head-end bridge tail-end bridge
working channel
protection channel signaling channel
Y(J)S SONET Slide 71
Linear 1+1 protection
Simplest form of protection
Can be at OC-n level (different physical fibers)
or at STM/VC level (called SubNetwork Connection Protection)
or end-to-end path (called trail protection)
Head-end bridge always sends data on both channels
Tail-end chooses channel to use based on BER, dLOS, etc.
No need for signaling
If non-revertive
there is no distinction between working and protection channels
BW utilization is 50%
channel A
channel B
Y(J)S SONET Slide 72
Linear 1:1 protection
Head-end bridge usually sends data on working channel
When tail-end detects failure it signals (using K1) to head-end
Head-end then starts sending data over protection channel
When not in use
protection channel can be used for (discounted) extra traffic
(pre-emptible unprotected traffic)
May be at any layer (only OC-n level protects against fiber cuts)
working channel
protection channel
extra traffic
Y(J)S SONET Slide 73
Linear 1:N protection
In order to save BW
we allocate 1 protection channel for every N working channels
N limited to 14
4 bits in K1 byte from tail-end to head-end
0 protection channel
1-14 working channels
15 extra traffic channel
working channels
protection channel
Y(J)S SONET Slide 74
Two fiber vs. Four-fiber rings
Ring based protection is popular in North America (100K+ rings)
Full protection against physical fiber cuts
Simpler and less expensive than mesh topologies
Protection at line (multiplexed section) or path layer
Four-fiber rings
fully redundant at OC level
can support bidirectional routing at line layer
Two-fiber rings
support unidirectional routing at line layer
2 fibers in opposite directions
Y(J)S SONET Slide 75
Unidirectional vs. bidirectional
Unidirectional routing
working channel B-A same direction (e.g. clockwise) as A-B
management simplicity: A-B and B-A can occupy same timeslots
Inefficient: waste in ring BW and excessive delay in one direction
Bidirectional routing
A-B and B-1 are opposite in direction
both using shortest route
spatial reuse: timeslots can be reused in other sections
A
B
A-B
B-A
A
B
B-A
A-B
C
B-C
C-B
Y(J)S SONET Slide 76
UPSR vs. BLSR (MS-SPRing)
Of all the possible combinations, only a few are in use
Unidirectional Path Switched Rings
protects tributaries
extension of 1+1 to ring topology
Bidirectional Line Switched Rings (two-fiber and four-fiber versions)
called Multiplex Section Shared Protection Ring in SDH
simultaneously protects all tributaries in STM
extension of 1:1 to ring topology
Path switching
Line switching
Two-fiber
Four-fiber
Unidirectional
Bidirectional
UPSR
BLSR
Y(J)S SONET Slide 77
UPSR
Working channel is in one direction
protection channel in the opposite direction
All traffic is added in both directions
decision as to which to use at drop point (no signaling)
Normally non-revertive, so effective two diversity paths
Good match for access networks
1 access resilient ring
less expensive than fiber pair per customer
Inefficient for core networks
no spatial reuse
every signal in every span
in both directions
node needs to continuously monitor
every tributary to be dropped
Y(J)S SONET Slide 78
BLSR
Switch at line level less monitoring
When failure detected tail-end NE signals head-end NE
Works for unidirectional/bidirectional fiber cuts, and NE failures
Two-fiber version
half of OC-N capacity devoted to protection
only half capacity available for traffic
Four-fiber version
full redundant OC-N devoted to protection
twice as many NEs as compared to two-fiber
Example
recovery from unidirectional fiber cut
Y(J)S SONET Slide 79
VCAT
and
LCAS
Y(J)S SONET Slide 80
Concatenation
Payloads that dont fit into standard VT/VC sizes can be accommodated
by concatenating of several VTs / VCs
For example, 10 Mbps doesnt fit into any VT or VC
so w/o concatenation we need to put it into an STS-1 (48.384 Mbps)
the remaining 38.384 Mbps can not be used
We would like to be able to divide the 10 Mbps among
7 VT1.5/VC-11 s = 7
*
1.600 = 11.20 Mbps or
5 VT2/VC-12 s = 5
*
2.176 = 10.88 Mbps
Y(J)S SONET Slide 81
Concatenation (cont.)
There are 2 ways to concatenate X VTs or VCs:
Contiguous Concatenation (G.707 11.1)
HOP STS-Nc (SONET) or VC-4-Nc (SDH)
or LOP 1-7 VC-2-Nc into a VC-3
since has to fit into SONET/SDH payload
only STS-Nc : N=3
*
4
n
or VC-4-Nc : N=4
n
components transported together and in-phase
requires support at intermediate network elements
Virtual Concatenation (VCAT G.707 11.2)
HOP STS-1-Xv or STS-Nc-Xv (SONET) or VC-3/4-Xv (SDH)
or LOP VT-1.5/2/3/6-Xv (SONET) or VC-11/12/2-Xv (SDH)
HOP: X 256 LOP: X 64 (limitation due to bits in header)
payload split over multiple STSs / STMs
fragments may follow different routes
requires support only at path terminations
requires buffering and differential delay alignment
Y(J)S SONET Slide 82
Contiguous Concatenation: STS-3c
270 columns
9
r
o
w
s
9 columns of
section and
line overhead
3 columns of
path overhead
258 columns of SPE
STS-3
270 columns
9
r
o
w
s
9 columns of
section and
line overhead
1 column of
path overhead
260 columns of SPE
STS-3c
258 columns
*
0.576 = 148.608 Mbps
260 columns
*
0.576 = 149.760 Mbps
Y(J)S SONET Slide 83
STS-N vs. STS-Nc
Although both have raw rates of 155.520 Mbps
STS-3c has 2 more columns (1.152Mbps) available
More generally, For STS-Nc gains (N-1) columns
e.g. STS-12c gains 11 columns = 6.336Mbps vis a vis STS-12
STS-48c gains 47 columns = 27.072 Mbps
STS-192c gains 191 columns = 110.016 Mbps !
However, an STS-Nc signal is not as easily separable
when we want to add/drop component signals
Y(J)S SONET Slide 84
Virtual Concatenation
VCAT is an inverse multiplexing mechanism (round-robin)
VCAT members may travel along different routes in SONET/SDH network
Intermediate network elements dont need to know about VCAT
(unlike contiguous concatenation that is handled by all intermediate nodes)
H4
Y(J)S SONET Slide 85
SDH virtually concatenated VCs
So we have many permissible rates
1.600, 2.176, 3.200, 4.352, 4.800, 6.400, 6.528, 6.784, 8.000,
VC Capacity (Mbps) if all members in one VC
VC-11-Xv 1.600, 3.200, 1.600X in VC-3 X 28 C 44.800
in VC-4 X 64 C 102.400
VC-12-Xv 2.176, 4.352, 2.176X in VC-3 X 21 C 45.696
in VC-4 X 63 C 137.088
VC-2-Xv 6.784, 13.568, , 6.784X in VC-3 X 7 C 47.448
in VC-4 X 21 C 142.464
Y(J)S SONET Slide 86
SONET virtually concatenated VTs
VT Capacity (Mbps) If all members in one STS
VT1.5-Xv 1.600, 3.200, 1.600X in STS-1 X 28 C 44.800
in STS-3c X 64 C 102.400
VT2-Xv 2.176, 4.352, 2.176X in STS-1 X 21 C 45.696
in STS-3c X 63 C 137.088
VT3-Xv 3.328, 6.656, 3.328X in STS-1 X 14 C 46.592
in STS-3c X 42 C 139.776
VT6-Xv 6.784, 13.568, 6.784X in STS-1 X 7 C 47.448
in STS-3c X 21 C 142.464
So we have many permissible rates
1.600, 2.176, 3.200, 3.328, 4.352, 4.800, 6.400, 6.528, 6.656, 6.784,
Y(J)S SONET Slide 87
Efficiency comparison
Using VCAT increases efficiency to close to 100% !
rate w/o VCAT efficiency with VCAT efficiency
10 STS-1 21% VT2-5v
VC-12-5v
92%
100 STS-3c
VC-4
67% STS-1-2v
VC-3-2v
100%
1000 STS-48c
VC-4-16c
42% STS-3c-7v
VC-4-7v
95%
Y(J)S SONET Slide 88
PDH VCAT
Recently ITU-T G.7043 expanded VCAT to E1,T1,E3,T3
Enables bonding of up to 16 PDH signals to support higher rates
Only bonding of like PDH signals allowed (e.g. cant mix E1s and T1s)
Multiframe is always per G.704/G.832 (e.g. T1 ESF 24 frames, E1 16 frames)
1 byte per multiframe is VCAT overhead (SQ, MFI, MST, CRC)
Supports LCAS (to be discussed next)
TS0
1
st
frame
of
4 E1s
VCAT
overhead
octet
time
each E1
Y(J)S SONET Slide 89
PDH VCAT overhead octet
There is one VCAT overhead octet per multiframe, so net rate is
T1: (24*24-1=) 575 data bytes per 3 ms. multiframe = 191.666 kB/s
E1: (16*30-1=) 495 data bytes per 2 ms multiframe = 247.5 kB/s
T3 and E3 can also be used
We will show the overhead octet format later
(when using LCAS, the overhead octet is called VLI)
TS0
frames
of an
E1
VCAT
overhead
octet
Y(J)S SONET Slide 90
Delay compensation
802.1ad Ethernet link aggregation cheats
each identifiable flow is restricted to one link
doesnt work if single high-BW flow
VCAT is completely general
works even with a single flow
VCG members may travel over completely separate paths
so the VCAT mechanism must compensate for differential delay
Requirement for over second compensation
Must compensate to the bit level
but since frames have Frame Alignment Signal
the VCAT mechanism only needs to identify individual frames
Y(J)S SONET Slide 91
VCAT buffering
Since VCAT components may take different paths
At egress the members
are no longer in the proper temporal relationship
VCAT path termination function buffers members
and outputs in proper order (relying on POH sequencing)
(up to 512 ms of differential delay can be tolerated)
VCAT defines a multiframe to enable delay compensation
length of multiframe determines delay that can be accommodated
H4 byte in members POH contains :
sequence indicator (identifies component) (number of bits limits X)
MFI multiframe indicator (multiframe sequencing to find differential delay)
Y(J)S SONET Slide 92
Multiframes and superframes
Here is how we compensate for 512 ms of differential delay
512 ms corresponds to a superframe is 4096 TDM frames (4096*0.125m=512m)
For HOP SDH VCAT and PDH VCAT (H4 byte or PDH VCAT overhead)
The basic multiframe is 16 frames
So we need 256 multiframes in a superframe (256*16=4096)
The MultiFrame Indicator is divided into two parts:
MFI1 (4 bits) appears once per frame
and counts from 0 to 15 to sequence the multiframe
MFI2 (8bits) appears once per multiframe
and counts from 0 to 255
For LOP SDH (bit 2 of K4 byte)
a 32 bit frame is built and a 5-bit MFI is dedicated
32 multiframes of 16 ms give the needed 512 ms
Y(J)S SONET Slide 93
Link Capacity Adjustment Scheme
LCAS is defined in G.7042 (also numbered Y.1305)
LCAS extends VCAT by allowing dynamic BW changes
LCAS is a protocol for dynamic adding/removing of VCAT members
hitless BW modification
similar to Link Aggregation Control Protocol for Ethernet links
LCAS is not a control plane or management protocol
it doesnt allocate the members
still need control protocols to perform actual allocation
LCAS is a handshake protocol
it enables the path ends to negotiate the additional / deletion
it guarantees that there will be no loss of data during change
it can determine that a proposed member is ill suited
it allows automatic removal of faulty member
Y(J)S SONET Slide 94
LCAS how does it work?
LCAS is unidirectional (for symmetric BW need to perform twice)
LCAS functions can be initiated by source or sink
LCAS assumes that all VCG members are error-free
LCAS messages are CRC protected
LCAS messages are sent in advance
sink processes messages after differential compensation
message describes link state at time of next message
receiver can switch to new configuration in time
LCAS messages are in the upper nibble of
H4 byte for HOS SONET/SDH
K4 byte for LOS SONET/SDH
VCAT overhead octet for PDH VCAT and LCAS Information
LCAS messages employ redundancy
messages from source to sink are member specific
messages from sink to source are replicated
J1
B3
C2
G1
F2
H4
F3
K3
N1
POH
Y(J)S SONET Slide 95
LCAS control messages
LCAS adds fields to the basic VCAT ones
Fields in messages from source to sink:
MFI MultiFrame Indicator
SQ SeQuence indicator (member ID inside VCAT group)
CTRL ConTRoL (IDLE, being ADDed, NORMal, End of Sequence, Do Not Use)
GID Group Identification (identifies VCAT group)
Fields in messages from sink to source (identical in all members):
MST Member Status (1 bit for each VCG member)
RS-Ack ReSequence Acknowledgement
Fields in both directions
CRC Cyclic Redundancy Code
The precise format depends on the VCAT type (H4, K4, PDH)
Note: for H4 format SQ is 8 bits, so up to 256 VCG members
for PDH SQ is only 4 bits, so up to 16 VCG members
Y(J)S SONET Slide 96
H4 format
MFI2 bits 1-4 0 0 0 0
MFI2 bits 5-8 0 0 0 1
CTRL 0 0 1 0
0 0 0 GID 0 0 1 1
0 0 0 0 0 1 0 0
0 0 0 0 0 1 0 1
CRC-8 bits 1-4 0 1 1 0
CRC-8 bits 5-8 0 1 1 1
MST bits 1 0 0 0
more MST bits 1 0 0 1
0 0 0 RS-ACK 1 0 1 0
0 0 0 0 1 0 1 1
0 0 0 0 1 1 0 0
0 0 0 0 1 1 0 1
SQ bits 1-4 1 1 1 0
SQ bits 5-8 1 1 1 1
1
6
f
r
a
m
e
m
u
l
t
i
f
r
a
m
e
MFI1
r
e
s
e
r
v
e
d
f
i
e
l
d
s
r
e
s
e
r
v
e
d
f
i
e
l
d
s
Y(J)S SONET Slide 97
H4 format some comments
CRC-8 (when using K4 it is CRC-3)
covers the previous 14 frames (not synced on multiframe)
polynomial x
8
+ x
2
+ x + 1
MST
each VCG member carries the status of all members
so we need 256 bits of member status
this is done by muxing MST bits
there are MST bits per multiframe
and 32 multiframes in an MST multiframe
no special sequencing, just MFI2 multiframe mod 32
GID
single bit indentifier
all members of VCG share the same bit
cycles through 2
15
-1 LFSR sequence
different VCGs use different phase offsets of sequence
Y(J)S SONET Slide 98
LCAS adding a member (1)
When more/less BW is needed, we need to add/remove VCAT members
Adding/removing VCAT members first requires provisioning (management)
LCAS handles member sequence numbers assignment
LCAS ensures service is not disrupted
Example: to add a 4
th
member to group 1
Initial state:
Step 1: NMS provisions new member
source sends CTRL=IDLE for new member
sink sends MST=FAIL for new member
GID=g SQ=1 CTRL=NORM
GID=g SQ=2 CTRL=NORM
GID=g SQ=3 CTRL=EOS
GID=g SQ=1 CTRL=NORM
GID=g SQ=2 CTRL=NORM
GID=g SQ=3 CTRL=EOS
GID=g SQ=FF CTRL=IDLE
Y(J)S SONET Slide 99
LCAS adding a member (2)
Step 2: source sends CTRL=ADD and SQ
sink sends MST=OK for new member
if it has been provisioned
if receiving new member OK
if it is able to compensate for delay
otherwise it will send MST=FAIL
and source reports this to NMS
Step 3: source sends CTRL=EOS for new member
new member starts to carry traffic
sink sends RS-ACK
Note 1: several new members may be added at once
Note 2: removing a member is similar
Source puts CTRL=IDLE for member to be removed and stops using it
All member sequence numbers must be adjusted
GID=g SQ=1 CTRL=NORM
GID=g SQ=2 CTRL=NORM
GID=g SQ=3 CTRL=EOS
GID=g SQ=4 CTRL=ADD
GID=g SQ=1 CTRL=NORM
GID=g SQ=2 CTRL=NORM
GID=g SQ=3 CTRL=NORM
GID=g SQ=4 CTRL=EOS
Y(J)S SONET Slide
100
LCAS service preservation
To preserve service integrity if sink detects a failure of a VCAT member
LCAS can temporarily remove member (if service can tolerate BW reduction)
Example: Initial state
Step 1: sink sends MST=FAIL for member 2
source sends CTRL=DNU (special treatment if EoS)
and ceases to use member 2
Note: if EoS fails, renumber to ensure EoS is active
Step 2: sink sends MST=OK indicating defect is cleared
source returns CTRL to NORM
and starts using the member again
Note: if NMS decides to permanently remove the member, proceed as in previous slide
GID=g SQ=1 CTRL=NORM
GID=g SQ=2 CTRL=NORM
GID=g SQ=3 CTRL=NORM
GID=g SQ=4 CTRL=EOS
GID=g SQ=1 CTRL=NORM
GID=g SQ=2 CTRL=DNU
GID=g SQ=3 CTRL=NORM
GID=g SQ=4 CTRL=EOS
Y(J)S SONET Slide
101
Handling
Packet
Data
Y(J)S SONET Slide
102
Packet over SONET
Currently defined in RFC2615 (PPP over SONET) obsoletes RFC1619
SONET/SDH can provide a point-to-point byte-oriented
full-duplex synchronous link
PPP is ideal for data transport over such a link
PoS uses PPP in HDLC framing to provide a byte-oriented interface
to the SONET/SDH infrastructure
POH signal label (C2)
indicates PoS as C2=16 (C2=CF if no scrambler)
Y(J)S SONET Slide
103
PoS architecture
PoS is based on PPP in HDLC framing
Since SONET/SDH is byte oriented, byte stuffing is employed
A special scrambler is used to protect SONET/SDH timing
PoS operates on IP packets
If IP is delivered over Ethernet
the Ethernet is terminated (frame removed)
Ethernet must be reconstituted at the far end
require routers at edges of SONET/SDH network
IP
PPP
HDLC
SONET/SDH
Y(J)S SONET Slide
104
PoS Details
IP packet is encapsulated in PPP
default MTU is 1500 bytes
up to 64,000 bytes allowed if negotiated by PPP
FCS is generated and appended
PPP in HDLC framing with byte stuffing
43 bit scrambler is run over the SPE
byte stream is placed octet-aligned in SPE
(e.g. 149.760 Mbps of STM-1)
HDLC frames may cross SPE boundaries
Y(J)S SONET Slide
105
POS problems
PoS is BW efficient
but POS has its disadvantages
BW must be predetermined
HDLC BW expansion and nondeterminacy
BW allocation is tightly constrained by SONET/SDH capacities
e.g. GBE requires a full OC-48 pipe
POS requires removing the Ethernet headers
so lose RPR, VLAN, 802.1p, multicasting, etc
POS requires IP routers
Y(J)S SONET Slide
106
LAPS
In 2001 ITU-T introduced protocols for transporting packets over SDH
X.85 IP over SDH using LAPS
X.86 Ethernet over LAPS
Built on series of ITU LAPx HDLC-based protocols
Use ISO HDLC format
Implement connectionless byte-oriented protocols over SDH
X.85 is very close to (but not quite) IETF PoS
Y(J)S SONET Slide
107
GFP architecture
A new approach, not based on HDLC
Defined in ITU-T G.7041 (also numbered Y.1303)
originally developed in T1X1 to fix ATM limitations
(like ATM) uses HEC protected frames instead of HDLC
Client may be PDU-oriented (Ethernet MAC, IP)
or block-oriented (GBE, fiber channel)
GFP frames
are octet aligned
contain at most 65,535 bytes
consist of a header + payload area
Any idle time between GFP frames is filled with GFP idle frames
Ethernet IP other
GFP client specific part
GFP common part
SDH OTN other
HDLC
Y(J)S SONET Slide
108
GFP frame structure
Every GFP frame has a 4-byte core header
2 byte Payload Length Indicator
PLI = 01,2,3 are for control frames
2 byte core Header Error Control
X
16
+ X
12
+ X
5
+ 1
entire core header is XORed with B6AB31E0
Idle GFP frames
have PLI=0
have no payload area
Non-idle GFP frames
have 4 bytes in payload area
the payload has its own header
2 payload modes : GFP-F and GFP-T
optionally protect payload with CRC-32
PLI (2B)
cHEC (2B)
payload header
(4-64B)
payload
optional payload
FCS (4B)
core
header
payload
area
Y(J)S SONET Slide
109
GFP payload header
GFP payload header has
type (2B)
type HEC (CRC-16)
extension header (0-60B)
either null or linear extension (payload type muxing)
extension HEC (CRC-16)
type consists of
Payload Type Identifier (3b)
PTI=000 for client data
PTI=100 for client management (OAM dLOS, dLOF)
Payload FCS Indicator (1b)
PFI=1 means there is a payload FCS
Extension Header ID (3b)
User Payload Identifier (8b)
values for Ethernet, IP, PPP, FC, RPR, MPLS, etc.
type (2B)
tHEC (2B)
extension header
(0-60B)
eHEC (2B)
UPI (8b)
PTI (3b) EXI (3b) PFI
Y(J)S SONET Slide
110
GFP modes
GFP-F - frame mapped GFP
Good for PDU-based protocols (Ethernet, IP, MPLS)
or HDLC-based ones (PPP)
Client PDU is placed in GFP payload field
GFP-T transparent GFP
Good for protocols that exploit physical layer capabilities
In particular
8B/10B line code
used in fiber channel, GbE, FICON, ESCON, DVB, etc
Were we to use GFP-F would lose control info, GFP-T is transparent to these codes
Also, GFP-T neednt wait for entire PDU to be received (adding delay!)