EE 6364

Generic Framing Procedure (GFP)

- Overview
- GFP Frame Structure
- Functions Performed by GFP Payload Independent
Aspects
- Frame Mapped GFP & Transparent GFP
- Virtual Concatenation (VC) of SONET/SDH
- Link Capacity Adjustment Scheme (LCAS)

DCW 1
EE 6364

Overview of Generic Framing Procedure (GFP)

Since SONET has extensive management capabilities and is widely
deployed by the carriers in their networks, Generic Framing
Procedure (GFP) was developed to allow efficient and reliable
transport of data through SONET networks.
Defined by ITU-T G.7041, GFP provides a simple adaptation scheme
that allows mapping of variable length, higher-layer client data over a
SONET network. The client data can be frame oriented (e.g., IP/PPP
or Ethernet frames) or continuous bit rate block-code oriented (e.g.,
fiber channel, fiber connection (FICON), Enterprise System
Connection (ESCON)).
The GFP stack is as following:

Ethernet IP/PPP Fibre Channel FICON ESCON Gb Ethernet

Payload Dependent Aspects

GFP
Payload Independent Aspects

SONET/SDH OTN (G.709)

GFP frames are transported over SONET/SDH or optical transport

network (OTN) defined in ITU-T G.709.
The payload independent aspects cover functions, such as GFP
framing, GFP frame delineation, data link synchronization and
scrambling, client PDU multiplexing, and performance monitoring.
The payload dependent aspects perform functions that may vary
according to the client payload. The functions performed include
mapping of the client payload into the GFP payload, client specific
performance monitoring, and management.
GFP supports many different types of client payload.

DCW 2
EE 6364

GFP Frame Structure

There are two different types of GFP frames: GFP client frames and
GFP control frames. They use the same frame structure.
The GFP frame structure is as follows:
Bytes

Payload Length Indicator 2

Core
Header
Core HEC (cHEC) 2
PTI PFI EXI
Payload Type 2
UPI

Payload Type HEC 2

Header

Extension Header (optional)

0-60

Payload

Payload FCS 0 or 4

A GFP frame consists of two parts: core header and the payload
area. The payload area consists of payload header, payload and
payload FCS.
The core header consists of:
• Payload Length Indicator (PLI): Indicate the length of the
payload area. The value of PLI ranges from 4 to 65,535.
• Core Header Error Control (cHEC).

DCW 3
EE 6364

The payload area consists of three parts: payload header, payload

and payload frame check sequence (FCS). The payload header
has a variable length from 4 to 64 bytes.
The payload header consists of:
• Payload Type Identifier (PTI): A 3-bit subfield identifies the
type of payload: client data or client management.
• Payload FCS Indicator (PFI): A 1-bit subfield indicates the
presence of the payload FCS.
• Extension Header Identifier (EXI): A 4-bit subfield identifies
the type of extension header.
• User Payload Identifier (UPI): A 8-bit field identifies the type
of user payload.
• Type Header Error Control (tHEC): Two bytes.
• Extension Header: 0-60 bytes.
The length of the payload ranges from zero (0) to 65,535-length of
payload header.
The 4-byte payload FCS may or may not be present.
How the client data is carried in the GFP payload field is the
function of the payload dependent aspects.
The following table lists some their client payload types and their
UPI values.
GFP Client Data Type UPI Value
Ethernet 0000 0001 GFP-F
PPP 0000 0010 GFP-F
MPLS Direct Mapping 0000 1101 GFP-F
IP v4 0001 0000 GFP-F
IP v6 0001 0001 GFP-F
Fiber Channel 0000 0011 GFP-T
FICON 0000 0100 GFP-T
ESCON 0000 0101 GFP-T
Gigabit Ethernet 0000 0110 GFP-T

DCW 4
EE 6364

Functions Performed by Payload Independent

Aspects
GFP payload independent aspects perform the following functions:
Frame Delineation:
Frame delineation of GFP frames is done using cHEC. The
procedure is identical to the cell delineation procedure used in ATM
cell delineation.
Multiplexing:
The payload independent aspects of GFP also perform multiplexing
of the GFP frames on a frame-by-frame basis. There are two kinds of
frames: client data frames and client management frames. When no
frames are available, GFP inserts idle frames in order to maintain a
continuous bit flow. The idle GFP frame is a GFP frame consisting
only of the GFP core header, with the PLI and cHEC fields set to 0.
Header and Payload Scrambling:
The core header is always scrambled to ensure high bit transmission
density when transmitting idle GFP frames. Payload is also
scrambled.
Management.

DCW 5
EE 6364

Frame Mapped GFP and Transparent GFP

One of the functions performed by the payload dependent aspects is
to carry the client data into the payload field of the GFP frame.
The client data can be carried in GFP frames using two modes:
frame-mapped GFP (GFP-F) or transparent GFP (GFP-T).
Frame-mapped GFP is applicable to packet data type. A client data
frame is mapped into the payload field of a GFP frame. The following
shows the mapping of client Ethernet and PPP frames into the GFP
payload. Only the shaded fields are carried in the payload filed.
Bytes
7 Preamble
1 Start Frame Delimiter
Bytes
6 Destination Address
Core Header 4
6 Source Address
2 Length/Type
Ethernet Payload Header 4-64
Data

Pad

4 FCS

Bytes Payload
1 Flag

1 Address

1 Control

PPP 2 Protocol

Data

Payload FCS 4
4 FCS

Note that GFP payload FCS is only needed if the client data frame
does not have the FCS field.

DCW 6
EE 6364

The following illustrates a GFP-F frame:

PLI Payload Client PDU FCS

cHEC
header (IP/PPP, IP, Ethernet, etc) (optional)
(2 bytes) (2 bytes)
(4 bytes) (0-65,531 bytes) (4 bytes)
GFP GFP GFP
core payload payload
header area FCS

The transparent GFP (GFP-T) is used to transport continuous bit-

rate, 8B/10B block-coded client data and control information carried
by the network. Examples of this type of networks are fiber channel,
FICON, ESCON, and Gigabit Ethernet.
GFP-T transports client data as a stream of characters.
1. The 8B/10B characters of the client data are first decoded into
their original data or control codeword values.
2. The decoded characters are then mapped into 64B/65B block
coding. Each 64B/65B code carries the information of eight of
the 8B/10B characters. For data characters, the original 8-bit
data values are mapped directly into the payload bytes of the
64B/65B codes. The 8B/10B control codes are re-encoded and
mapped into their own bytes. A bit in the 65-bit code is used to
indicate whether the 65-bit block contains only data or whether
control characters are included. If control codes1 are present,
they are placed in the first byte(s) of the 64B/65B code payload.
A 3-bit address indicates where the control code occurred in the
client character stream relative to the other characters encoded
into that 64B/65B block. The MSB of a control code byte
indicates whether this is the last control code in that 64B/65B
block or whether the next byte also contains a control code.
3. Eight consecutive 65-bit blocks are grouped together into a
single super block.
4. N super blocks make up a single GFP-T frame.

1
Since there are 12 or fewer control codes used for any 8B/10B codes, a 4-bit code is
adequate to represent them.

DCW 7
EE 6364

The following figure illustrates the 64B/65B block code structure:

Client Flag 64-bit (8-octet) Field
Data bit
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet Octet 7 Octet 8
6
All Data 0 D1 D2 D3 D4 D5 D6 D7 D8
7 data, 1 0aaaC1 D1 D2 D3 D4 D5 D6 D7
1 control
6 data, 1 1aaaC1 0bbbC2 D1 D2 D3 D4 D5 D6
2 control
5 data, 1 1aaaC1 1bbbC2 0cccC3 D1 D2 D3 D4 D5
3 control
4 data, 1 1aaaC1 1bbbC2 1cccC3 0dddC4 D1 D2 D3 D4
4 control
3 data, 1 1aaaC1 1bbbC2 1cccC3 1dddC4 0eeeC5 D1 D2 D3
5 control
2 data, 1 1aaaC1 1bbbC2 1cccC3 1dddC4 1eeeC5 0fffC6 D1 D2
6 control
1 data, 1 1aaaC1 1bbbC2 1cccC3 1dddC4 1eeeC5 1fffC6 0gggC7 D1
7 control
8 control 1 1aaaC1 1bbbC2 1cccC3 1dddC4 1eeeC5 1fffC6 1gggC7 0hhhC8

Where
Flag bit = 1, if there is at least one control code
aaa – hhh = 3-bit representation of the original position of the
control code
Ci = 4-bit representation of the ith control code
Di = 8-bit representation of the ith client data

The following figure shows an example of GFP-T mapping:

Position
000 001 010 011 100 101 110 111
Octet #
Byte
D1 D2 K1 K2 D3 D4 K3 D5
Stream

Flag
Octet # 000 001 010 011 100 101 110 111
Bit
65B Code
Stream 1 1,010,C1 1,011,C2 0,110,C3 D1 D2 D3 D4 D5

GFP-T reduces the 25% 8B/10B overhead. It also reduces latency.

DCW 8
EE 6364

Virtual Concatenation
Virtual concatenation (VC) is a SONET/SDH procedure that maps an
incoming traffic stream into a number of individual sub-rate
SONET/SDH payloads. It is an inverse multiplexing procedure.
VC, specified in ITU-T G.707/Y.1332, provides a technique that
allows SONET/SDH channels to be grouped in an arbitrary manner. It
creates right-sized channels over the transport layer for an efficient
use of bandwidth. VC can be deployed over SONET/SDH or OTN
networks, thus it can be classified as transport layer independent
technology.
VC breaks the bandwidth into smaller individual containers that are
grouped logically. The members of the channel can be routed
independently through the network without the knowledge that the
traffic is virtually concatenated. This is one of the advantages of VC:
the ability to deploy VC on the existing SONET/SDH infrastructure
with a simple upgrade of the end points. All intelligence to handle VC
is located at the end points of the connections. The efficient use of
the network achieved by using VC allows recovering of stranded
bandwidth in the SONET/SDH network.
In contrast, arbitrary contiguous concatenation allows the creation of
custom sized bandwidth but the network needs to treat this bandwidth
as a single entity throughout the network that requires all the
intermediate nodes to be upgraded in order to accommodate the new
contiguous “custom sized” pipe. Such a requirement makes the use
of this technique impractical.

DCW 9
EE 6364

Link Capacity Adjustment Scheme (LCAS)

In the traditional SONET/SDH networks, changing the capacity of a
channel is quite a time consuming and expensive procedure. The link
needs to be brought down (thus interrupting traffic), changing the
capacity, and then re-starting traffic again.
Link Capacity Adjustment Scheme (LCAS), specified in ITU-T
G.7042, is a method to dynamically increase or decrease the
bandwidth of virtual concatenated containers. LCAS is a two-way
handshake signaling protocol. Synchronization of changes in the
capacity of the transmitter and the receiver is achieved by a control
packet sequence of H4 Path overhead bytes.
LCAS allows on-demand increase or decrease of the bandwidth of
the virtual concatenated group in a hitless manner. LCAS is also able
to temporarily remove failed members from the virtual concatenation
group. A failed member will automatically cause a decrease of the
bandwidth and after repair the bandwidth will increase again in a
hitless fashion. Together with diverse routing this provides
survivability of data traffic without requiring excess protection
bandwidth allocation.

DCW 10