Course Outline
1) Introduction 2) Background - Ethernet 3) Background HDLC 4) Background - PPP 5) Background - SONET/SDH 6) VCAT 7) LCAS 8) POS (PPP over SONET/SDH RFC 1619/2615) 9) LAPS 10) GFP 11) Alternatives
Introduction
Motivation
Assume that you are a traditional operator
You have an extensive SONET/SDH network This network has cost you Millions-Billions to build This network is highly reliable Your staff is well trained to maintain it You may have not yet reached Return On Investment It supports the service that brings the most revenue voice It supports the service with the highest margin leased lines
Ethernet handoff
SONET RING
A D M
I W F
Ethernet Switch
You can try to convince these customers to use leased lines The customer converts traffic into T1/E1 (e.g. by using frame relay)
You can supply this service now The major expense is for the customer (who needs FRAD, CSU/DSU, etc.) Leased lines are profitable
But this only worked before the new competitors appeared You will probably lose these customers !
Option 3: ATM
Ethernet Switch A T M A D M
SONET RING
A D M
A T M
Ethernet Switch
You can offer ATM service The customer converts traffic into ATM (AAL5) You can supply this service now ATM is a well-known technology ATM is a reliable and high-quality service ATM maps efficiently onto SONET/SDH You may even be able to perform the conversion at your POP
(but Ethernet is notoriously hard to transport over distances)
But ATM has its disadvantages ATM has high overhead but you can only charge for user BW ATM is an additional network
you will have to train and pay new staff maintain another operations center ATM usually carries IP, not native Ethernet traffic
Y(J)S EoS Slide 7
Option 4: EoS
Ethernet Switch I W F SONET RING
I W F
Ethernet Switch
A new choice is Ethernet over SONET/SDH (EoS) The customers Ethernet traffic is transported directly by SONET/SDH You build on your existing network You transport native Ethernet neednt route at network edges maintain all Ethernet features New SONET/SDH features make EoS highly efficient But EoS and related protocols are new technologies You may need to upgrade existing equipment Market hasnt yet stabilized on one technology
Worlds Apart
SONET/SDH is presently the most prevalent transport infrastructure Ethernet is by far the most popular user data interface So we need efficient methods for carrying Ethernet over SONET But Ethernet
comes in bursty frames (packets) uses basic rates of 10, 100, 1000 Mbps
While SONET/SDH
is constant bit rate is designed for various rates such as 1.6, 2.176, 6.784 Mbps
G.709
G.7041 G.7042
OTN
GFP LCAS for SDH
G.7043
X.85 X.86
Background
Ethernet
Ethernet frame
For our purposes, Ethernet is any layer 2 protocol using 1 of the following frame formats :
64 1518 B
DA (6B) SA (6B) T/L (2B) data (0-1500B) pad (0-46) FCS (4B)
68 1522 B
DA(6B) SA(6B) VT(2B) VLAN(2B) T/L(2B)
data (0-1500B)
pad(0-46)
FCS(4B)
Minimum frame is 64 bytes Maximum payload was 1500 bytes and maximum frame was 1522 bytes 802.3as lengthened maximum frame to 2000 bytes Various physical layer modulations and framing Rates : 10 Mbps, 100 Mbps, 1 Gbps, 10 Gbps,
Background
HDLC
We can convert a sequence of packets into a bit stream by using an idle code
packet 1 packet 2 packet 3 packet 4
packet 1
packet 2
packet 3
packet 4
But the flag must not appear in valid data! If we have access to the physical layer we can mark there (violations) Otherwise (we only access bits) we must disallow the idle code by replacing it with something else
HDLC flags
ISO developed High level Data Link C based on IBMs SDLC HDLC inputs packets of bytes HDLC uses hex 7E as its idle code (flag) 01111110 So an idle HDLC stream repeats 7E
01111110 01111110 01111110 packet 1 01111110 01111110 01111110 packet 2 01111110 01111110 01111110 01111110 packet 3 01111110
Whenever the encoder sees 5 successive 1s it appends a 0 thus there are never 6 successive 1s in the data
When the decoder sees 5 successive 1s : If the next bit is a 0 it is deleted If the next bit is a 1 then this is the closing flag Notes:
bit stream length is no longer necessarily divisible by 8 bit stream length is not a priori predictable worst case expansion is 20% encoding/decoding is easy in HW, hard in SW
Optionally other codes (e.g. some under hex 20) can be escaped Second byte is original with 6th bit complemented (xor with hex 20) e.g. ^Q = hex 11 7D 31 ^S = hex 13 7D 33
When the receiver sees 7D xx It replaces it with the original byte (complementing 6th bit) Notes:
bit stream remains byte oriented length expansion is typically about 1%, but can range from 0 to 100% !
(there is also a consistent overhead algorithm but not in use)
encoding/decoding is easy in SW
Y(J)S EoS Slide 19
HDLC framing
HDLC frame is bounded by flags, and has a particular structure
flag (8) address (0/8/16) ctrl (8/16)
data
Many variants (SDLC, ISO, LAPB, LAPD, LAPF, LAPS, SS7, PPP-HDLC, Cisco-HDLC, etc) Address: There may be no address (e.g. SS7 HDLC) SDLC always had 8 bit addresses ISO 3309 HDLC has structured multibyte address SAPI C/R EA EA
Service Access Point Identifier (MSB of SAPI =1 may indicate broadcast/multicast) EA=1 means 8 bit, EA=0 means extended address C/R=1 for commands, C/R=0 for responses The single byte hex FF is recognized as the broadcast address
Y(J)S EoS Slide 20
HDLC control
HDLC networks can be configured: Balanced all stations have equal responsibility Unbalanced primary and one or more secondary stations
and HDLC can operate : Best effort (datagram) uses Un-numbered (U) frames Reliable (Asynchronous Balanced Mode) uses frames with sequence numbers in control field Information (I) frames (data + acknowledgement) Supervisory (S) frames (only acknowledgement)
The various frame types are indicated by the control field which varies widely between different protocols
HDLC FCS
HDLC uses a Frame Check Sequence to detect errors The FCS is implemented as a shift-register
CRC-16 CRC-32
X16 + X12 + X5 + 1 X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 + X2 + X + 1
Some HDLC-based protocols require 32 bit FCS others allow 16 bit but recommend 32 bit FCS
Background
PPP
over full-duplex, point-to-point data links for example: short lines, leased lines, dial-up modems
PPP may be used to connect hosts to routers, and routers to routers
encapsulation method for (multiprotocol) datagrams Link Control Protocol for establishing, configuring, and testing data-link connections Network Control Protocols for establishing and configuring different network-layer protocols
PPP is a suite containing many protocols ML-PPP, PPPoE, BAP, BCP, IPCP,
Y(J)S EoS Slide 24
information
padding
Encapsulation enables demuxing of different network-layer protocols Only 1 field needs to be examined for protocol determination Protocol field obeys ISO 3309 rules: protocol value must be odd (for EA=1)
if 16-bit, then the LSB of first byte must be zero (for EA=0)
PPP protocol values managed by IANA (http://www.iana.org/assignments/ppp-numbers)
address
FF
ctrl
03
protocol
(8/16b)
information
padding
(optional)
FCS
(16/32b)
flag
7E
When using PPP over synchronous links we use HDLC-like framing 1 byte Broadcast address is used by default (users may define alternative address) Synchronous Link may be bit-oriented or byte-oriented Basic PPP encapsulation is extended by 8 bytes Bit stuffing or byte stuffing allowed Escape mechanism allows transparent transfer of control data (e.g. ^S/^Q) enables removal of spurious control data (inserted by intermediate boxes)
address
FF
ctrl
03
protocol
(8/16b)
information
padding
(optional)
FCS
(16/32b)
flag
7E
X.85
flag
7E
address
04
ctrl
03
SAPI
(16b)
IP Packet
FCS
(32b)
flag
7E
Background
SONET/SDH
SONET architecture
ADM
Path Termination Line Termination
regenerator
Section Termination
ADM
Line Termination Path Termination
path
line section
line section
line protected multiplexed SONET payload section physical link between adjacent elements
Each layer has its own overhead to support needed functionality SDH terminology
Y(J)S EoS Slide 29
9 rows
Synchronous Transfer Signals are bit-signals (OC are optical)
Each STS-1 frame is 90 columns * 9 rows = 810 bytes There are 8000 STS-1 frames per second so each byte represents 64 kbps (each column is 576 kbps) Thus the basic STS-1 rate is 51.840 Mbps
Y(J)S EoS Slide 30
9 rows
Synchronous Transport Modules are the bit-signals for SDH Each STM-1 frame is 270 columns * 9 rows = 2430 bytes There are 8000 STM-1 frames per second Thus the basic STM-1 rate is 155.520 Mbps 3 times the STS-1 rate!
Y(J)S EoS Slide 31
SONET/SDH rates
SONET STS-1 STS-3 STS-12 STS-48 STS-192 STM-1 STM-4 STM-16 STM-64 SDH columns 90 270 1080 4320 17280 rate 51.84M 155.52M 622.080M 2488.32M 9953.28M
SDH rates increase by factors of 4 each time STS/STM signals can carry PDH tributaries, for example:
STS-1 can carry 1 T3 or 28 T1s or 1 E3 or 21 E1s STM-1 can carry 3 E3s or 63 E1s or 3 T3s or 84 T1s
Y(J)S EoS Slide 32
SONET/SDH tributaries
SONET STS-1 STS-3 STS-12 STS-48 STS-192 STM-1 STM-4 STM-16 STM-64 SDH T1 28 84 336 1344 5376 T3 1 3 12 48 192 E1 21 63 252 1008 4032 E3 1 3 12 48 1 4 16 E4
192 64
9 rows
6 rows
Section overhead is 3 rows * 3 columns = 9 bytes = 576 kbps framing, performance monitoring, management Line overhead is 6 rows * 3 columns = 18 bytes = 1152 kbps protection switching, line maintenance, mux/concat, SPE pointer SPE is 9 rows * 87 columns = 783 bytes = 50.112 Mbps
Similarly, STM-1 has 9 (different) columns of transport overhead ! RS overhead is 3 rows * 9 columns Pointer overhead is 1 row * 9 columns MS overhead is 5 rows * 9 columns SPE is 9 rows * 87 columns
Y(J)S EoS Slide 35
Scrambling
SONET/SDH receivers recover clock based on incoming signal Insufficient number of 0-1 transitions causes degradation of clock performance In order to guarantee sufficient transitions, SONET/SDH employ a scrambler
All data except first row of section overhead is scrambled Scrambler is 7 bit self-synchronizing X7 + X6 + 1 Scrambler is initialized with ones
A short scrambler is sufficient for voice data but NOT for data which may contain long stretches of zeros When sending data an additional payload scrambler is used
modern standards use 43 bit X43 + 1 run continuously on ATM payload bytes (suspended for 5 bytes of cell tax) run continuously on HDLC payloads
Xn Z-43
Yn = Xn + Yn-43
2 bytes in the line overhead point to the STS path overhead POH pointer (floating) allows frequency/phase compensation (after re-arranging) POH is one column of 9 rows (9 bytes = 576 kbps)
Y(J)S EoS Slide 37
Path overhead
C2 (hex) J1 B3 C2 G1 F2 H4 F3 K3 N1 Payload type unequipped nonspecific LOP (TUG) E3/T3 E4 ATM PoS RFC 1662
POH is responsible for path performance monitoring status (including of mapped payloads) trace 2 bytes are of particular interest to us:
00 01 02 04 12 13 16
18
1A 1B CF
LAPS X.85
10G Ethernet GFP PoS - RFC1619
Y(J)S EoS Slide 38
POH
STS-1 HOP
1 30 59 87
We are left with 84 columns = 756 bytes = 48.384 Mbps for payload
This is enough for a E3 (34.368M) or a T3 (44.736M)
LOP
1 30 59 87
VTG
1 2 3 4 5 6 7
To carry lower rate payloads, divide 84 available columns into 7 * 12 interleaved columns, i.e. 7 Virtual Tributary (VT) groups VT group is 12 columns of 9 rows, i.e. 108 bytes or 6.912 Mbps VT group is composed of VT(s)
There are different types of VT in order to carry different types of payload all VTs in VT group must be of the same type
LOP
VT 3
VT 6 STS-1 VC-2 VC-3 VC-3
6
12
HOP
STS-1
STS-3c
VC-4
149.760 E4
(139.264)
Payload capacity
VT1.5/VC-11 has 3 columns = 27 bytes = 1.728 Mbps but 2 bytes are used for overhead
VCAT
Virtual Concatenation
Concatenation
Payloads that dont fit into standard VT/VC sizes can be accommodated by concatenating of several VTs / VCs
Concatenation
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 n or VC-4-Nc : N=4n only STS-Nc : N=3 * 4 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 EoS Slide 45
STS-3
270 columns
9 rows
STS-3c
Y(J)S EoS Slide 46
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
Virtual Concatenation
H4
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)
Y(J)S EoS Slide 48
in VC-4 X 21 C 142.464
So we have many permissible rates 1.600, 2.176, 3.200, 4.352, 4.800, 6.400, 6.528, 6.784, 8.000,
in STS-1
X 28 C 44.800
X 21 C 45.696 X 14 C 46.592 X 7 C 47.448
in STS-3c X 64 C 102.400 VT2-Xv in STS-1 in STS-3c X 63 C 137.088 VT3-Xv in STS-1 in STS-3c X 42 C 139.776 VT6-Xv in STS-1
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 EoS Slide 50
Efficiency comparison
rate 10 w/o VCAT STS-1 efficiency 21% with VCAT VT2-5v VC-12-5v 100 STS-3c VC-4 1000 STS-48c VC-4-16c 42% 67% STS-1-2v VC-3-2v STS-3c-7v VC-4-7v 95% 100% efficiency 92%
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)
each E1
time
Y(J)S EoS Slide 52
frames of an E1
TS0
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
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
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 EoS Slide 55
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 LOS 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 EoS Slide 56
LCAS
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 EoS Slide 58
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
Y(J)S EoS Slide 59
POH
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 EoS Slide 60
H4 format
MFI2 bits 1-4 MFI2 bits 5-8 CTRL 0 0 GID 0 0 0 0 0 0 CRC-8 bits 1-4 CRC-8 bits 5-8 MST bits more MST bits 0 0 RS-ACK 0 0 0 0 0 0 0 0 0 SQ bits 1-4 SQ bits 5-8 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 MFI1 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
reserved fields
0 0 0
16 frame multiframe
reserved fields
0 0 0 0
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
VLI format
MFI2 bits 1-4 MFI2 bits 5-8 CTRL 0 0 GID 0 0 0 0 0 0 CRC-8 bits 1-4 CRC-8 bits 5-8 MST bits more MST bits 0 0 RS-ACK 0 0 0 0 0 0 0 0 0 0 0 0 SQ 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 MFI1 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
reserved fields
0 0 0
16 frame multiframe
reserved fields
0 0 0 0 0
Initial state:
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 EoS Slide 64
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
Y(J)S EoS Slide 65
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
Y(J)S EoS Slide 66
PoS architecture
IP PPP HDLC SONET/SDH
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
Y(J)S EoS Slide 69
IP
Ethernet
Ethernet is a LAN technology last 100m 10s of hosts IP is a WAN technology data transported in native IP different L2 technologies for last segment
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
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
LAPS
LAPS
Built on series of ITU LAPx HDLC-based protocols Use ISO HDLC format
IP X.86
LLC MAC
IP
LLC MAC LAPS SDH
IP
LLC MAC
X.85
flag
7E
address
(16b)
ctrl
03
SAPI
(16b)
IP Packet
FCS
(32b)
flag
7E
MAC
reconciliation
MII/GMII
X.86
LAPS
rate adaptation
SDH
Similar to X.85 (IP over SDH using LAPS) but transports the entire Ethernet frame
flag
7E
address
(16b)
ctrl
03
SAPI
FE01
Ethernet frame
DA SA T/L INFO PAD FCS
FCS
(32b)
flag
7E
Y(J)S EoS Slide 78
LAPS drawbacks
Only IP or Ethernet payloads Single bit errors (e.g. in flags) may cause misalignment
GFP architecture
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 GFP generically encapsulates client (e.g. IP, Ethernet) onto transport network (e.g. SONET/SDH, OTN)
Ethernet
IP
HDLC
other
GFP client specific part GFP common part PDH SDH OTN other
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
Y(J)S EoS Slide 81
core header
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 payload is scrambled like PoS
payload area
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 (4b) User Payload Identifier (8b) values for Ethernet, IP, PPP, FC, RPR, MPLS, etc.
GFP modes
GFP-F - frame mapped GFP Good for PDU-based protocols (Ethernet, IP, MPLS) or HDLC-based ones (PPP)
GFP-T
Main application Storage Area Networks (SAN) SANs use 8B/10B line code and are very delay sensitive 8B/10B line code maps each of the 256 values of the 8-bit input
into 1 or 2 different 10 bit words Maintains a running 0-1 balance and when encoding an input with 2 possibilities, it chooses the one that improves the balance spare 10b symbols are used as control codes (e.g. start/end of frame) 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!) GFP-T maps 8B/10B line code into 64B/65B block code
GFP-F
Client packet/frame without un-needed overhead (e.g. flags, preamble, etc) is placed in GFP payload field Interface is at link layer More BW efficient than GFP-T since idle periods are filtered out preambles, frame-start, etc are also not transported GFP-F must know the client protocol in order to detect frames Can mux different client protocols on a frame to frame basis If the client protocol has a good FCS, dont need to use GFPs FCS GFP-F is used for EoS Either IP in PPP or native Ethernet can be used
GFP advantages
Supports multiple protocols (not just Ethernet and IP) For Ethernet, GFP can transparently transport entire frame
Alternatives
Copper technologies
OAM
Y(J)S EoS Slide 90
Ethernet PWs
Customer Edge (CE) Customer Edge (CE) Customer Edge Provider Edge (PE)
Ethernet
MPLS network
Provider Edge
Customer Edge
(CE) Customer Edge (CE)
Ethernet frame (with or w/o FCS)
Y(J)S EoS Slide 93
(PE)
Ethernet
PseudoWires (PWs)
PW label
PWE control word
(CE)
MPLS label stack