AM

01
8:
:4
10
07
20
e,
Generic Framing Procedure (GFP)

un
0J
,3
ay
rd
tu
Technology White Paper
Sa
on
o
ca
ica
un

Steve Gorshe
om

Principal Engineer
lec
Te
de
o
ut
tit
ns

Issue 2.0: April, 2005

fI
so

PMC-2041083
re
Pi

2005 PMC-Sierra, Inc.

ao
Jo
by
ed
oad
nl
ow
 Generic Framing Procedure (GFP)
Technology White Paper

Abstract

AM
Generic Framing Procedure (GFP) was developed to allow efficient transport of packet data

01
through SONET/SDH networks, making use of the new virtual concatenation and LCAS

8:
technologies for creating flexible-sized transport channels. Although a competing approach,

:4
explored by some start-up carriers, attempted to use a pure packet network (e.g., an Ethernet

10
WAN), the conversion from a SONET/SDH backbone network to an Ethernet backbone would
have been cost-prohibitive and would not have provided the desired integrated OAM&P

07
capabilities. GFP technology allowed efficient packet transport within the existing SONET/SDH

20
backbone and, thus, is very attractive to carriers.

e,
This white paper details the GFP technology in depth, as it is currently not covered in any

un
existing textbooks.

0J
,3
ay
About the Author
rd
tu
Steve Gorshe, Ph.D. is a Principal Engineer in the Product Research Group and oversees ICs for
Sa
SONET, optical transmission and access systems.
on

Currently Steve is a senior member of the IEEE and co-editor for the IEEE Communications
o

magazines Broadband Access Series. He is the chief editor for the ANSI T1X1 Subcommittee,
ca

which is responsible for SONET and optical network interface standards. He is a recent recipient
ica

of the Committee T1 Alvin Lai Outstanding Achievement Award for his standards work and has
been a technical editor for T1.105, T1.105.01, T1.105.02, and T1.105.07 within the SONET
un

standard series as well as the ITU-T G.7041 (GFP) G.7043 (Virtual concatenation of PDH
om

signals), G.8040 (GFP mapping into PDH signals), and G.8011.1 (Ethernet Private Line Service)
recommendations. He has 26 patents issued or pending and several published papers.
lec
Te
de

Revision History
o
ut

Issue No. Issue Date Details of Change

tit

2 April 2005 Enhanced and updated with new material developed over the last few
ns

years.
fI

1 July 2004 Document created

so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 1
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

Contents

AM
Abstract.............................................................................................................................. 1

01
About the Author............................................................................................................... 1

8:
:4
Revision History................................................................................................................ 1

10
Contents............................................................................................................................. 2
List of Figures ................................................................................................................... 3

07
20
List of Tables ..................................................................................................................... 4
Preface ............................................................................................................................... 5

e,
un
1 Introduction ............................................................................................................... 6

0J
1.1 GFP background................................................................................................. 6

,3
2 GFP frame structure.................................................................................................. 7

ay
3 Frame mapped GFP (GFP-F) .................................................................................... 9

rd
4 Transparent GFP (GFP-T) ....................................................................................... 13
5 tu
Performance Considerations and Client Management Frames ......................... 20
Sa
6 Error handling considerations............................................................................... 21
on

7 Conclusions............................................................................................................. 22
o

8 References ............................................................................................................... 23
ca

9 Notes ........................................................................................................................ 25
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 2
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

List of Figures

AM
Figure 1 GFP frame structure ......................................................................................... 7

01
8:
Figure 2 Example client data mappings into GFP-F ....................................................... 9

:4
10
Figure 3 64B/65B block code structure......................................................................... 14

07
Figure 4 Example of mapping client data and control characters into a
64B/65B code ................................................................................................. 15

20
e,
Figure 5 GFP-T superblock structure............................................................................ 16

un
Figure 6 Construction of the GFP-T frame.................................................................... 17

0J
Figure 7 Example of 65B_PAD insertion ...................................................................... 18

,3
ay
Figure 8 Sub-rate GFP-T example for Fibre Channel................................................... 19

rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 3
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

List of Tables

AM
Table 1 List of client payloads mapped into GFP-F (accepted and proposed) ........... 10

01
8:
Table 2 List of client payloads mapped into GFP-T..................................................... 13

:4
10
Table 3 Virtually concatenated channel sizes for various transparent GFP
clients 17

07
20
e,
un
0J
,3
ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 4
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

Preface

AM
The goal is to provide an overview of GFP for a reader who is unfamiliar with this technology.

01
To this end, a brief introduction is provided that includes the motivations that led to the

8:
development of the GFP standard. The remainder of the white paper presents various aspects of

:4
the GFP frame structure, the mapping of client data frame or signals into GFP, and GFP

10
performance or performance monitoring considerations.

07
The information in this white paper has also been adapted to form part of the following textbook:

20
M. Elanti, S. Gorshe, L. Raman, and W. Grover, Next Generation Transport Networks Data,
Management, and Control Plane Technologies, Springer, 2005.

e,
un
0J
,3
ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 5
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

1 Introduction

AM
GFP was developed to allow efficient transport of packet data through SONET/SDH networks,

01
making use of the new virtual concatenation and LCAS technologies for creating flexible-sized

8:
transport channels. A competing approach that was explored by some start-up carriers was to use

:4
a pure packet network (e.g., an Ethernet WAN). The conversion from a SONET/SDH backbone

10
network to an Ethernet backbone would not only have been cost prohibitive, but data networks
such as Ethernet typically have not provided the integrated Operations, Administration,

07
Maintenance and Provisioning (OAM&P) capabilities that have made SONET/SDH so valuable

20
to carriers. A technology such as GFP that allowed efficient packet transport within the existing
SONET/SDH backbone was thus very attractive. This white paper covers the GFP technology in

e,
depth, as it is currently not covered in any existing textbooks.

un
0J
1.1 GFP background

,3
GFP was originally born in T1X1 Technical Subcommittee to address some limitations of ATM

ay
and Packet over SONET (PoS). Subsequently, in order to expedite international agreement it was

rd
decided to have the International Telecommunication Union -Telecommunication Standardization
tu
Sector (IUT-T) publish the final standard. GFP is now specified in ITU-T Recommendation
Sa
G.7041.
on

As described in PMC-Sierras white paper, A tutorial on SONET/SDH (PMC-2030895), ATM

suffers from bandwidth inefficiency due to the amount of cell overhead relative to payload
o
ca

capacity. Another perceived drawback to ATM is that ATM implementations typically include a
great detail of complexity that is not required for relatively simple packet data interconnections
ica

(e.g., the ATM signaling protocols). The drawbacks to PoS are its non-deterministic bandwidth
un

requirements and its requirement that the client data packets be mapped into the IETF Point-to-
Point Protocol (PPP) and HDLC for Layer 2. The first drawback is a consequence of the
om

requirement that escape characters be added for each client data byte that looks like an HDLC
lec

control character. In the worst case (a situation that could potentially be created by a malicious
user), the byte-stuffed HDLC packet payload field could be twice as long as the original payload.
Te

The requirement to map into PPP is a distinct drawback if a carrier wants to offer a simple
Ethernet extension. Here, the Ethernet MAC frame would need to be terminated so that the client
de

data could be re-mapped into PPP with HDLC and a new Ethernet MAC frame generated on the
o

other end of the PoS link. Despite the drawbacks, with over 90% of the data transported through
ut

the public WAN originating and/or terminating as Ethernet at the customer premises, Ethernet
tit

extension is a naturally desirable service for the carriers to provide.

ns

GFP allows the simple, efficient transport of a variety of data signals through SONET/SDH,
fI

asynchronous/PDH, and G.709 OTN networks. The protocol and its capabilities are explained in
so

Section 2.
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 6
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

2 GFP frame structure

AM
The basic structure of a GFP frame is illustrated in Figure 1. The four-byte Core header consists

01
of a 16-bit Payload Length Indicator (PLI) with a CRC-16 to protect the PLI. The PLI is the

8:
binary count of the number of bytes in that GFP frames payload field. The Core header is the

:4
key to eliminating the bandwidth expansion problem of PoS. Rather than relying on a special

10
character for frame delimiting, the GFP receiver begins the framing process by looking for a 16-
bit field that is followed by a correct CRC-16 for that field. When such a 32-bit pattern is found,

07
it is very likely to be the Core header at the beginning of a GFP frame, as the probability of such a

20
pattern randomly occurring in the client data is 2-32. The GFP receiver then uses the PLI
information to determine where the end of the GFP frame is. The next Core header will occur

e,
immediately after the end of this current frame, so if another valid 32-bit pattern is found in that

un
location, the receiver can be sure that it has acquired framing for the GFP stream. The CRC-16 is

0J
adequate to provide a simple, single error correction capability for the PLI, which increases the
robustness of the GFP framing. (In contrast, an error in an HDLC start/end flag has no error

,3
correction, which makes HDLC framing more vulnerable to transmission errors.)

ay
rd
Figure 1 GFP frame structure
tu
Sa
16-bit PAYLOAD
on

LENGTH INDICATOR

cHEC
o

(CRC-16)
ca

CORE
ica

HEADER PTI PFI EXI

UPI
TYPE HEADER
un

(4 BYTES)
CRC-16
om

PAYLOAD OPTIONAL
HEADERS EXTENSION
lec

HEADER
(0-60 BYTES)
PAYLOAD
Te

AREA
de

CLIENT
o

PAYLOAD
ut

INFORMATION
tit

FIELD
ns
fI
so
re

OPTIONAL
Pi

PAYLOAD FCS
(CRC-32)
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 7
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

The GFP payload area consists of payload header information, a payload field that contains the

AM
client data, and can optionally contain a CRC-32 over the payload field. The payload headers are
broken down into two types. The payload Type header is used in all GFP frames except Idle

01
frames, and consists of 2 bytes of overhead information protected by a CRC-16. If additional
payload overhead information is needed (e.g., a channel identifier to identify different GFP

8:
connections when GFP frames from different sources are frame-multiplexed together), then an

:4
Extension may also be used. Specifically, the Type header contains a Payload Type Indicator

10
(PTI), an indication of whether the optional payload frame check sequence is included in the
payload field (PFI), an indication of what type of Extension header, if any, is present (EXI), and a

07
User Payload type indicator (UPI). The only PTI types identified so far are client data frames and

20
client management frames (CMFs). For the client data frames, the UPI indicates the type of
payload that is mapped into the GFP frame, and whether that mapping is frame-based or

e,
transparent. The only Extension header defined at this time is the Linear Extension header, which

un
consists of an 8-bit channel identification field, an 8-bit spare/reserved field, and a CRC-16 over

0J
the header. Other Extension headers are under consideration that would potentially expand the
identification field so that flows within channels could be identified.

,3
ay
Any idle time between GFP frames carrying client data is filled with GFP Idle frames. A GFP

rd
Idle frame consists of only a Core header with a PLI=0.
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 8
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

3 Frame mapped GFP (GFP-F)

AM
The initial GFP work focused on GFP-F. The basic concept is to take a client frame (typically a

01
Layer 2 frame), remove its unnecessary overhead (e.g., frame delimiting characters or preamble),

8:
and then simply place the remainder of the client data frame into the GFP Payload Field. Hence,

:4
there is a one-to-one mapping between client data frames and GFP-F frames. An example of the

10
Ethernet mapping is shown in Figure 2(a). The specific bit alignments between the client data,
the GFP-F frame, and the SONET/SDH payload are illustrated in the PMC-Sierra white paper [4].

07
20
Figure 2 Example client data mappings into GFP-F

e,
un
Client data frame

0J
Bit #
Octets
1 2 3 4 5 6 7 8

,3
7 Preamble

ay
1 frame start delimiter GFP frame
6

rd
Destination Addr. (DA)
Bit #
6
2
Source Addr. (SA)
Length/Type
tu 1 2 3 4 5 6 7 8
Octets
Sa
PLI 2
MAC client data
cHEC 2
on

Pad Type 2
FCS tHEC 2
4
o
ca

GFP Extension Header 0-60

a) Ethernet mapping
ica

1 Flag
un

1 HDLC Address
1 HDLC Control
om

GFP payload
2 PPP Type
PPP information
lec

Pad
Te

pFCS* 4
4 HDLC FCS
de

b) PPP/HDLC mapping
* The pFCS is only used for
o

those client data frames

ut

4 Label stack entry that do not have their own

tit

Other label stack FCS (e.g., MPLS).

Nx4
entries (optional)
ns
fI

Payload
so

c) MPLS PDU mapping

re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 9
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

Note that for the Ethernet example of Figure 2(a), it is assumed that the optional payload FCS
(pFCS) is not used.1 When the client data frame is known to have its own frame FCS, the GFP

AM
payload FCS is somewhat redundant since a GFP-F demapper will typically have the capability to

01
examine the client data FCS. The GFP payload FCS would only be used if the client data frame
either had no FCS of its own or a weaker FCS (e.g., a CRC-16).

8:
:4
The simplicity of the GFP-F mapping is a key to GFPs flexibility. While most of the initial focus

10
on GFP-F was for carrying Ethernet payloads, there is growing interest in using GFP-F for other
payloads. As a result, there have been several new mappings proposed. The current mappings

07
into GFP-F are listed in Table 1.

20
e,
Table 1 List of client payloads mapped into GFP-F (accepted and proposed)

un
GFP-F client payload type UPI value <7:0>

0J
(PTI = 000)

,3
Ethernet 0000 0001
PPP 0000 0010

ay
Multiple Access Protocol over SDH (MAPOS) 0000 1000

rd
IEEE 802.17 Resilient Packet Ring 0000 1010
Fibre Channel FC-BBW
tu 0000 1011
Sa
MPLS direct mapping 0000 1101
on

MPLS (multicast) 0000 1110

o

IS-IS 0000 1111

ca

IPv4 0001 0000

ica

IPv6 0001 0001

PPP direct mapping (note)
un

HDLC (note)
om

1111 0000
lec

Reserved for proprietary use. through

1111 1110
Te

Note:
de

A proposal under active consideration is to have a PPP mapping that omits the HDLC header
o

and replace the HDLC FCS with a GFP pFCS in order to simplify processing and improve
ut

efficiency. As part of this discussion, there has been a proposal to add a generic mapping for
tit

any HDLC-framed client.

ns
fI
so
re
Pi
ao
Jo

1
by

In fact, ITU-T Recommendation G.8012 (2004), Ethernet UNI and Ethernet NNI specifies that the GFP
pFCS is not used when Ethernet is carried in GFP-F.
ed
oad

PMC-2041083 (2.0) 10
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

A PPP mapping was part of the original G.7041 standard. (See [15] for the complete definition of

AM
PPP.) As seen in Figure 2(b), this mapping includes the HDLC-like framing overhead specified
in IETF RFC 1662 (PPP in HDLC-like Framing), to be consistent with the PPP over

01
SONET/SDH (PoS) mapping (see [4]). In PoS, the HDLC flags are also retained so that the
HDLC framing can be used for frame delineation. The HDLC Address and Control bytes are

8:
defined in RFC 1662 to carry 1111 1111 and 0000 0011, respectively, so for the GFP mapping, the

:4
HDLC header contains no useful information. It is possible to use a PPP Link Configuration

10
Protocol (LCP) optional procedure to remove the HDLC header and replace the PPP type field
with a 1-2 byte PPP protocol field. There is also a proposal under active consideration to have an

07
optimized PPP mapping into GFP-F that always removes the HDLC header and FCS, and uses

20
the GFP pFCS for error detection. At the same time, there has been discussion about whether
there are enough applications to justify a generic HDLC into GFP-F mapping. At the time of this

e,
printing, these topics are on the G.7041 Living List for further study.

un
0J
GFP-F was originally defined as a Layer 1 (1.5) transport encapsulation mechanism for carrying
Layer 2 frames. It was appreciated at the time of its development that the existence of the PTI

,3
and UPI fields along with the channel identification field in the linear Extension Header gave

ay
GFP a rudimentary set of Layer 2 type capabilities. There had been some reluctance to exploit (or

rd
enhance) these features since there was general agreement that GFP should not be ballooned in
tu
complexity to become a full switching layer similar to ATM.2 On the other hand, it made sense to
Sa
exploit these capabilities to improve network bandwidth efficiency.
on

Recently, some of these GFP Layer 2like capabilities have been exploited for Multiprotocol
Label-Switching (MPLS) frame transport (see [20], [21], and [22]). MPLS adds a header to a
o

client data packet that contains a label field to identify what is called a forwarding equivalency
ca

class (FEC). MPLS label-switched routers (LSRs) use these labels to route packets through the
ica

MPLS network. All packets sharing the same label value are then treated in the same manner by
un

a LSR. The MPLS labels are not global, but are assigned with local significance between two
adjacent LSRs. IP or IS-IS frames are typically used to communicate the information required to
om

establish the MPLS label assignments among MPLS network nodes and the hop-by-hop routes
that will be taken for packets with each MPLS label3. MPLS, which is nominally somewhere
lec

between a Layer 3 and Layer 2 protocol, typically also uses a Layer 2 such as PPP. The Layer 2
Te

protocol provides a protocol identifier field that identifies its payload as being either MPLS or IP
(or other protocol) frames and an error check over the frame. At the request of multiple carriers, a
de
o
ut
tit

2
While some have seen particular advantages to being able to send GFP frames along a pre-provisioned
ns

route based on the ID fields in an Extension header, no one wanted to create the equivalent of an ATM
switched virtual circuit (SVC) network with its own signaling protocol, etc. One of the proposals on the
fI

current G.7041 Living List is a new linear Extension Header with an expanded address (flow ID) field and
so

other fields similar to an MPLS header for this pre-provisioned routing. The intention was to allow
re

mapping MPLS header information into the GFP frame to allow the transport provider to route frames
without having to go up to the MPLS layer. It would also allow simultaneous routing of non-MPLS
Pi

packets on the same link. The future of this proposal is uncertain.

ao

3
The Label Distribution Protocol (LDP) and Resource Reservation Protocol for Traffic Engineering
Jo

(RSVP_TE) are the two protocols outlined in IETF RFCs 3031 and 3270, respectively, for communicating
by

the label assignments among MPLS LSRs. Other, non-IP-based protocols (e.g., IS-IS) have also been used
by some vendors and networks.
ed
oad

PMC-2041083 (2.0) 11
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

direct mapping of MPLS into GFP with no Layer 2 protocol overhead bytes was added, as shown

AM
in Figure 2(c). These carriers look to MPLS as a key technology for their core networks. At the
same time, they are concerned about bandwidth efficiency and about reducing the number of

01
layers/protocols that need to be provisioned and administered in their networks. The GFP
PTI/UPI codes identify the MPLS payload, and the GFP pFCS provides the frame error check.

8:
To complement direct MPLS mapping, direct mappings into GFP-F were also added for IP (IPv4

:4
and IPv6) and IS-IS in order to carry the MPLS control plane information. These mappings are

10
essentially the same as the MPLS mapping (i.e., they use the GFP pFCS for their error detection).
With the addition of these mappings, Layer 2 can become a null layer when MPLS is carried over

07
GFP. It should be noted that although direct IP mappings into GFP-F were primarily added to

20
support MPLS control plane traffic, they could also be used as a generic mapping for IP networks.
Some carriers are considering this possibility.

e,
un
0J
,3
ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 12
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

4 Transparent GFP (GFP-T)

AM
Several important data protocols use the 8B/10B line code at the physical layer. The protocols

01
and their associated UPI codes are shown in Table 2. Fibre Channel, Fibre Connection (FICON),

8:
and Enterprise System Connection (ESCON) are commonly used in modern storage area

:4
networks (SANs) and Digital Video Broadcast Asynchronous Serial Interface (DVB-ASI) is

10
popular for video distribution. The 8B/10B line code maps the 28 possible 8-bit byte values into
one or two of the 210 possible 10-bit values. One goal of this mapping is to maintain a running

07
balance between the number of 1s and 0s that are transmitted. Since only a limited number of

20
10B characters can have five 1s and five 0s, a given 8-bit data value is mapped into two different
10B values, each with a complementary number of 1s relative to the other. The difference in this

e,
running 0/1 balance at the end of each transmitted 8B/10B character is referred to as the running

un
disparity, and it is used to choose which of the two potential 10B values is used for next 8B data

0J
value to be transmitted. Each of the above protocols exploits the fact that there are leftover 10B
characters that can be used as control codes (e.g., to indicate the start and end of a data frame or

,3
to trigger some type of link initialization). For some protocols, a control code flags the beginning

ay
of a sequence of characters that communicate control information. Such sequences are called

rd
primitive sequences.
tu
Sa
Table 2 List of client payloads mapped into GFP-T
on

GFP-T client payload type UPI value <7:0>

(PTI = 000)
o
ca

Fibre Channel 0000 0011

FICON 0000 0100
ica

ESCON 0000 0101

un

Gbit Ethernet 0000 0110

om

DVB-ASI 0000 1001

Asynchronous Fibre Channel (see note) 0000 1100
lec

Note:
Te

de

Asynchronous Fibre Channel is asynchronous in the sense that the transport container is not
required to have as much capacity as the Fibre Channel interface.
o
ut

If the frames from these protocols were carried with GFP-F, the 8B/10B control code information
tit

would be lost. Another consideration for the SAN protocols is that they are typically very
ns

sensitive to transmission delay (latency) between the two SAN nodes. The one drawback to using
fI

the Core header with its PLI for GFP-F mappings is that an entire client data frame must be
so

buffered prior to transmitting the GFP-F frame in order to determine the required PLI value for
that frame. In most applications, these issues are not a concern. For these 8B/10B-encoded
re

clients, however, the control code transparency and latency issues can become important. A
Pi

tribute to the versatility (generic-ness) of the GFP protocol is that a variation of the protocol
ao

was developed that resolved these transparency and latency issues while providing a significant
transmission bandwidth savings over what would be required to send a stream of the native
Jo

8B/10B characters. Due to its transparency to 8B/10B codes, this GFP mapping came to be
by

called transparent GFP (GFP-T).

ed
oad

PMC-2041083 (2.0) 13
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

The desire for both transmission bandwidth efficiency and the transparent communication of the

AM
control codes was realized by transcoding the character stream into a new block code. The first
step in the GFP-T mapping process is to decode the 8B/10B characters into their original 8-bit

01
data values or the associated control characters. These data and control characters are then re-
encoded into a 64B/65B code. Each 64B/65B code carries the information of eight of the 8B/10B

8:
characters. For data characters, the original 8-bit data values are mapped directly into the payload

:4
bytes of the 64B/65B codes. The 8B/10B control codes are re-encoded and mapped into their

10
own bytes. The details of the 64B/65B code construction are illustrated in Figure 3. The first bit
of the 65B block indicates whether there were any 10B control codes among the 8 characters

07
encoded into that 64B/65B code. If control codes are present, they are placed in the first byte(s)

20
of the 64B/65B code payload. Since there are 12 or fewer control codes used for any 8B/10B
client, a 4-bit code is adequate to represent them. A 3-bit address indicates where the control

e,
code occurred in the client character stream relative to the other characters encoded into that

un
64B/65B block. The MSB of a control code byte indicates whether this is the last control code in

0J
that 64B/65B block or whether the next byte also contains a control code. Figure 4 gives an
example of the mapping of data and control characters (designated as D and K characters,

,3
respectively) into a 64B/65B code.

ay
rd
Figure 3 64B/65B block code structure
tu
Sa
Input 64-Bit (8-Octet) Field
Client Flag
Characters Bit
on

Octet 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7

o

All data 0 D1 D2 D3 D4 D5 D6 D7 D8
ca

7 data, 1 0 aaa C1 D1 D2 D3 D4 D5 D6 D7
ica

1 control
6 data, 1 1 aaa C1 0 bbb C2 D1 D2 D3 D4 D5 D6
un

2 control
om

5 data, 1 1 aaa C1 1 bbb C2 0 ccc C3 D1 D2 D3 D4 D5

3 control
lec

4 data, 1 1 aaa C1 1 bbb C2 1 ccc C3 0 ddd C4 D1 D2 D3 D4

Te

4 control
3 data, 1 1 aaa C1 1 bbb C2 1 ccc C3 1 ddd C4 0 eee C5 D1 D2 D3
de

5 control
o

2 data, 1 1 aaa C1 1 bbb C2 1 ccc C3 1 ddd C4 1 eee C5 0 fff C6 D1 D2

ut

6 control
tit

1 data, 1 1 aaa C1 1 bbb C2 1 ccc C3 1 ddd C4 1 eee C5 1 fff C6 0 ggg C7 D1

ns

7 control
fI

8 control 1 1 aaa C1 1 bbb C2 1 ccc C3 1 ddd C4 1 eee C5 1 fff C6 1 ggg C7 0 hhh C8

so

Legend:
re

Leading bit in a control octet (LCC) = 1 if there are more control octets and = 0 if this payload octet
Pi

contains the last control octet in that block

aaa = 3-bit representation of the 1st control codes original position (1st Control Code Locator)
ao

bbb = 3-bit representation of the 2nd control codes original position (2nd Control Code Locator)
Jo

hhh = 3-bit representation of the 8th control codes original position (8th Control Code Locator)
by

Ci = 4-bit representation of the ith control code (Control Code Indicator)

Di = 8-bit representation of the ith data value in order of transmission
ed
oad

PMC-2041083 (2.0) 14
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

Figure 4 Example of mapping client data and control characters into a 64B/65B code

AM
Octet # 000 001 010 011 100 101 110 111

01
Client Byte
D1 K1 D2 D3 D4 K2 D5 D6
Stream

8:
:4
10
07
Octet # L 000 001 010 011 100 101 110 111

20
65B Code
Stream
1 1,001,C1 0,101,C2 D1 D2 D3 D4 D5 D6

e,
un
D = client data byte L = Leading 64B/65B bit
K = control character P = 65B_PAD character

0J
,3
The 64B/65B codes have two drawbacks, however. The first is that the 65-bit code length would
prevent a stream of 64B/65B characters from being byte-aligned with the SONET payload bytes.

ay
Byte alignment, which is a feature of all the other SONET/SDH payload mappings, has the

rd
advantages of allowing direct payload data byte observability within the SONET/SDH stream and
tu
of allowing the use of parallel data path implementations. Parallel data paths within devices and
Sa
systems allow lower device/system clock rates. The lower clock rates in turn allow the use of
more power-efficient technology such as CMOS. The second drawback of the 64B/65B code is
on

its relative lack of error detection capability. (Error considerations are treated in greater detail
below.) Both of these drawbacks were addressed by the combining of eight 64B/65B codes into a
o
ca

superblock with an appended error check. The superblock structure is illustrated in Figure 5. The
payload data bytes of the eight constituent 64B/65B codes are placed into the superblock in
ica

transmission order, with the eight leading (flag) bits of these codes grouped together in a trailing
un

byte. Two more trailing bytes are then added as a CRC-16 error check code over the information
in that superblock.
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 15
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

Figure 5 GFP-T superblock structure

AM
Superblock

01
8:
1 2 3 4 5 6 7 8
Byte-Aligned Superblock

:4
1

10
2 Octet 1,1
3 Octet 1,2

07
4
codes Octet 1,3

20
j 5

e,
6

un
7 Octet 8,7

0J
8 Octet 8,8

,3
L1 L2 L3 L4 L5 L6 L7 L8

ay
Flag 8 bytes C1 C2 C3 C4 C5 C6 C7 C8
bits k

rd
C9 C10 C11 C12 C13 C14 C15 C16
tu
Sa
on

where: Octet j, k is the kth octet of the jth 64B/65B code in the superblock
o

Lj is the leading (Flag) bit jth 64B/65B code in the superblock

ca

Ci is the ith error control bit

ica

The final step in the GFP-T mapping is to insert an integer number of superblocks into a GFP
un

frame. The process of going from the 64B/65B code to a GFP frame is illustrated in Figure 6.
om

The GFP-T frame is identical to a GFP-F frame except for the specific PTI and UPI values that
are used in the Type header. Since GFP-T has CRC-16 error checks per superblock, the payload
lec

FCS is typically not used. The number of superblocks that are grouped into a GFP-T frame is a
Te

function of the difference between the client data rate, the channel rate of the SONET/SDH
channel, and the amount of spare bandwidth that is desired for client management frames. The
de

minimum number of superblocks for various clients is shown in Table 3. The details for
calculations regarding the number of superblocks and the resulting spare bandwidth are shown in
o

Corrigendum 1 of G.7041.
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 16
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

Figure 6 Construction of the GFP-T frame

AM
64B/65B code block

01
8:
:4
10
Leading
Code leading
bit 8 x 64B/65B blocks
bits

07
repositioned
into a trailing

20
byte

e,
un
... ... CRC-16

0J
,3
ay
rd
Core and Superblock (8 x 64B/65B codes + CRC-16)
Payload
tu
Sa
Headers
on
o
ca
ica

GFP-T Frame with 4 superblocks

un
om

Table 3 Virtually concatenated channel sizes for various transparent GFP clients
Nominal Minimum Minimum Worst/ Best- Best case
lec

Native Virtually- Nominal Number of case client

(Unencoded) Concatenated Transport Superblocks Residual management
Te

Client Client Signal Transport Channel per GFP Overhead payload

Signal Bandwidth Channel Size Bandwidth Frame Bandwidth1 bandwidth2
de

ESCON 160 Mbit/s STS-1-4v / 193.536 1 5.11 Mbit/s / 6.76 Mbit/s

o

VC-3-4v Mbit/s 24.8 Mbit/s

ut
tit

Fibre 850 Mbit/s STS-3c-6v / 898.56 13 412 Kbit/s / 2.415 Mbit/s

Channel Mbit/s 85.82 Mbit/s
ns

VC-4-6v
Gbit 1.0 Gbit/s STS-3c-7v / 1.04832 95 281 Kbit/s / 376.5 kbit/s
fI

Ethernet Gbit/s 1.138 Mbit/s

so

VC-4-7v

NOTES
re
Pi

1. The worst-case residual bandwidth occurs when the minimum number of superblocks is used
ao

per GFP frame. The best case occurs for the value of N that allows exactly one Client
Jo

Management frame per GFP data frame. A 160-bit Client Management frame was assumed
for the best case (with a CRC-32). For both cases, it was assumed that no Extension headers
by

were used.
ed
oad

PMC-2041083 (2.0) 17
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

2. The best-case client management payload bandwidth assumes 8 payload bytes per Client

AM
Management frame and the best-case residual overhead bandwidth conditions.

01
3. Fibre Channel also supports rates of 425, 1700, and 3400 Mbit/s (unencoded). The
SONET/SDH channel size scales linearly for these rates, and the minimum number of

8:
superblocks is 13 for all cases.

:4
10
Latency reduction was another consideration for GFP-T. Since GFP-T encapsulates a number of
client data characters rather than a whole client data frame there is no implied correlation between

07
the boundaries of the GFP-T frames and the client data frames. As a result, it would appear that

20
the GFP frame PLI value could be pre-determined, thus eliminating the need to buffer an entire
GFP frame of data prior to transmitting it. The problem, however, is that the SONET channel

e,
necessarily has a slightly higher bandwidth than is needed to carry the client data in the GFP-T

un
stream. The client signal and the SONET/SDH VCAT channel rates required to carry the full

0J
client signal rate are also shown in Table 3. The higher bandwidth of the transmission channel
means that the ingress buffer at the GFP-T mapper will periodically underflow as the mapper

,3
extracts bytes at a somewhat higher rate than the client data stream supplies them. Unless

ay
additional buffering (with its associated latency) was added at the mapper, the underflow situation

rd
would be a problem if the GFP frame were already being transmitted. In order to avoid this
tu
additional latency, a special 64B/65B control character was defined as a 65B_PAD that is inserted
Sa
into a 64B/65B block code whenever the mapper ingress buffer approaches an underflow
threshold. As illustrated in Figure 7, the 65B_PAD character is inserted into the 64B/65B code in
on

exactly the same manner as if an 8B/10B control code had been received in the client data stream.
The GFP-T demapper recognizes this character as dummy padding and discards it.
o
ca
ica

Figure 7 Example of 65B_PAD insertion

un

Octet # 000 001 010 011 100 101 110 111

om

Client Byte buffer

D1 K1 D2 underflow D3 K2 D4 D5
Stream
lec
Te
de

Octet # L 000 001 010 011 100 101 110 111

o

65B Code
1 1,001,C1 1,011,P1 0,101,C2 D1 D2 D3 D4 D5
ut

Stream
tit

D = client data byte L = Leading 64B/65B bit

ns

K = control character P = 65B_PAD character

fI
so

It is typically not cost effective for a customer to subscribe to a full-rate channel through the
WAN (see Table 3). There are often idle periods between data packets such that the actual
re

average client data rate is a fraction of the full rate. In order to allow a sub-rate connection while
Pi

still preserving transparency to 8B/10B control codes, Committee T11, working with ITU-T
ao

SG15, has included an asynchronous, sub-rate GFP-T option as part of their new FC-BB-3
standard. The idea, illustrated in Figure 8, is to have a circuit between the full-rate client signal
Jo

interface and the GFP-T mapper. This circuit removes idle characters from the full-rate stream
by

and outputs a sub-rate 8B/10B encoded stream to the GFP-T mapper. Similarly, a circuit inserts
idle characters into the sub-rate stream output from the GFP-T demapper in order to create the
ed
oad

PMC-2041083 (2.0) 18
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

full-rate egress stream. The sub-rate would correspond to the desired WAN channel rate (e.g.,

AM
DS3 or STS-3). Due to the need to buffer client packets for the process of removing the idle
characters, there is an increased latency with sub-rate GFP-T over that of full-rate GFP-T. The

01
latency of sub-rate GFP-T is still typically less than that required for a GFP-F mapping.

8:
:4
Figure 8 Sub-rate GFP-T example for Fibre Channel

10
Full-rate WAN Full-rate
Sub-rate Sub-rate
Fibre channel Fibre

07
8B/10B 8B/10B
Channel (e.g., DS3, Channel
stream stream

20
interface Idle STS-1-2v, Idle interface
(8B/10B) character STS-3c) character (8B/10B)

e,
removal/ GFP-T GFP-T insertion /
mapper demapper

un
rate rate
adaptation adaptation

0J
,3
ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 19
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

5 Performance Considerations and Client Management

AM
Frames

01
8:
At the time of writing, the OAM aspects of GFP are being defined. The GFP demapper can check

:4
such parameters as errors detected in any of the GFP headers, a mismatch from the expected

10
values in the payload Type (or Extension) header, errors in the payload field (if the optional GFP
payload FCS is used), and loss of GFP frame synchronization. These faults are reported to the

07
network management system by the NE containing the GFP demapper. Some carriers have
indicated a desire to perform single-ended performance monitoring similar to SONET/SDH

20
paths/trails; i.e., have the far end report its performance parameters so that each end knows both

e,
the parameters that it calculates directly and the parameters calculated by the far end. If this

un
capability is adopted for GFP, the demapper reports will be sent in GFP Client Management
Frames. CMFs use a different PTI value and their own set of UPI values, but are otherwise

0J
identical to the GFP client data frames. The one application that is currently standardized for

,3
CMFs is the client-signal-fail indication that is discussed in the next section.

ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 20
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

6 Error handling considerations

AM
Transmission errors can occur on the client data stream either outside or within the SONET/SDH

01
network. GFP-F and GFP-T handle these errors and faults differently due to the manner in which

8:
they perform the encapsulation process.

:4
10
Client frame delimiting is part of the GFP-F mapping process, and a typical part of frame
delimiting is checking the client data frames frame check sequence. If this check is bad, the GFP

07
mapper discards that client data frame rather than encapsulating it. Similarly, if the GFP-F

20
demapper receives a GFP frame with a bad check sequence in the any of the GFP headers, the
GFP payload FCS (if it is being used), or the client data frame itself, that client data frame is

e,
discarded.

un
0J
GFP-T focuses on the character level rather than the frame level. Since a limited number of 10-
bit values are used for 8B/10B codes, and since the running disparity is updated with each

,3
character, transmission errors can typically be detected in the 8B/10B stream. When the GFP-T

ay
mapper detects either an illegal 8B/10B character or a running disparity error, it encodes the

rd
offending character as a special 10B_ERR control character in the 64B/65B code. When the
tu
GFP-T demapper decodes the 64B/65B code it encodes the 10B_ERR code into a particular
illegal 8B/10B character so that the client receiver will be aware of the error.
Sa
on

Most of the redundant information that makes error detection possible is removed when the
8B/10B characters are transcoded into the GFP-T 64B/65B codes. The 64B/65B codes are
o

particular vulnerable to errors in the leading (flag) bit or the last control code indicator bits if
ca

control codes are present. Errors in these particular bits can cause the GFP-T demapper to
ica

misinterpret multiple data/control characters, which could in turn create a burst error condition
that is beyond the ability of the client frame check sequence (typically a CRC-32) to detect. The
un

CRC-16 code that was added to each superblock provides a strong triple error detection and
om

(optional) single error correction capability. When the GFP-T demapper sees a bad CRC-16 for a
superblock, it treats all 64 client characters in that superblock as if they had been received as
lec

10B_ERR codes. (Single errors can be simply corrected if that option is used.)
Te

NOTE The self-synchronous scrambler that is used on the GFP payload field inherently
de

multiplies the transmission errors by creating a duplicate error 43 bits after the original error.
This error multiplication would weaken the performance of each of the existing standard CRC-16
o
ut

codes. As a result, a new CRC-16 was developed for the GFP-T superblock that preserved its
tit

error detection and correction capability in the presence of the descrambler, and was optimized
for this specific block length. The interested reader can see [16] or [17] for more details.
ns
fI

In the case of a client signal failure prior to the GFP mapper, both the GFP-F and GFP-T mappers
so

send a periodic client signal fail (CSF) frame to the GFP demapper. This signal failure could be
the complete loss of the incoming signal or the loss of character synchronization for those clients
re

using a character-oriented line code. The CSF message is sent in a Client Management Frame
Pi

every 100 ms to 1000 ms. The action taken by a GFP demapper is client specific. In the case of
ao

GFP-T, the output 8B/10B stream will contain the same characters used to indicate a bad received
Jo

8B/10B character at the mapper. (Note that some client signals have other options that could be
used in the situation.)
by
ed
oad

PMC-2041083 (2.0) 21
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

7 Conclusions

AM
01
8:
As data services increase in importance and volume through the public wide area networks, it has

:4
become important to adapt the existing SONET/SDH infrastructure to carry this traffic. GFP is

10
one of the key enabling technologies for this adaptation. GFP provides a simple, flexible data
encapsulation mechanism with a very robust frame delineation mechanism and a deterministic

07
overhead bandwidth. The flexibility of GFP is already apparent from the number of client data
signal and data frame mappings that have been defined for GFP. These mappings range from

20
Layer 2 data frames, to Layer 3 packets, to Layer 1 character-oriented data streams. These factors

e,
have lead to GFP gaining broad global acceptance as the preferred data encapsulation mechanism

un
for transport networks.

0J
PMC-Sierra is a world leader in ICs supporting Ethernet mapping into SONET/SDH signals. The

,3
Arrow 2xGE (PM5397), which was the first commercially-available IC supporting GFP, maps
two Gigabit Ethernet streams into an OC-48/STM-16. The Arrow 24xFE (PM5329) maps 24

ay
10/100M Ethernet streams into an OC-12/STM-4 using GFP with either high or low order virtual

rd
concatenation. Arrow 8xFE (PM5333) provides the same functionality as the Arrow 24xFE for
tu
eight 10/100M Ethernet channels. The ADM-622 (PM5337) provides the functions of an
Sa
add/drop multiplexer on a single chip, including the ability to map a single Gigabit Ethernet or up
to eight 10/100M Ethernet streams into an OC-12/STM-4 with GFP.
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 22
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

8 References

AM
01
8:
[1] ITU-T Recommendation G.7041/Y.1303 (2001), Generic Framing Procedure.

:4
10
[2] M. Elanti, S. Gorshe, L. Raman, and W. Grover, Next Generation Transport Networks Data,
Management, and Control Plane Technologies, Springer, 2005.

07
[3] T1.105.02-2001 Synchronous Optical Network (SONET) Payload Mappings

20
e,
[4] S. Gorshe, A Tutorial on SONET/SDH Technology White Paper, PMC-Sierra, PMC-2030895

un
[5] ITU-T Recommendation G.707 (1996), Synchronous Digital Hierarchy Bit Rates.

0J
,3
[6] ITU-T Recommendation G.8040 (2004), GFP frame mapping into Plesiochronous Digital Hierarchy
(PDH)

ay
rd
[7] IEEE Standard 802.3-2002, Information Technology Telecommunications and Information
tu
Exchange Between Systems LAN/MAN Specific Requirements Part 3: Carrier Sense Multiple
Sa
Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.
on

[8] ANSI X3.230-1994, Fibre Channel Physical and Signaling Interface (FC-PH).
o

[9] ANSI X3.296-1997, Information Technology Single-Byte Command Code Sets CONnection
ca

(SBCON) Architecture.
ica
un

[10] ANSI INCITS 342-2001, Information Technology Fibre Channel Backbone (FC-BB).
om

[11] ANSI INCITS 372-2003, Information Technology Fibre Channel Backbone (FC-BB-2).
lec

[12] ETSI (CENELEC): EN 50083-9 (1998), Cable distribution systems for television, sound signals and
Te

interactive multimedia signals; Part 9: Interfaces for CATV/SMATV Headends and Similar
Professional Equipment for DVB/MPEG-2 transport streams (DVB Blue Book A010), Annex B,
de

Asynchronous Serial Interface.

o
ut

[13] ISO/IEC 3309:1993, Information Technology Telecommunications and information exchange

tit

between systems High-level data link control (HDLC) procedures Frame structure.
ns

[14] IETF RFC 1662, July 1994 PPP in HDLC-like Framing, W. Simpson - editor
fI
so

[15] IETF RFC 1661, July 1994 Point-to-Point Protocol (PPP), W. Simpson - editor
re

[16] S. Gorshe and T. Wilson, Transparent Generic Framing Procedure: A Protocol for Efficient
Pi

Transport of Block-Coded Data Through the SONET/SDH Network, IEEE Communications

ao

Magazine, May 2002, pp. 88-95

Jo

[17] S. Gorshe, CRC-16 Polynomials Optimized for Applications Using Self-Synchronous Scramblers,
by

Proc. of IEEE ICC2002, pp. 2791-2795

ed
oad

PMC-2041083 (2.0) 23
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

[18] ITU-T Recommendation G.8012 (2004), Ethernet UNI and Ethernet NNI

AM
[19] ITU-T Recommendation G.7043 (2004), Virtual Concatenation of Plesiochronous Digital Hierarchy

01
(PDH) signals

8:
[20] IETF RFC 3031, January 2001 Multiprotocol label switching architecture

:4
10
[21] IETF RFC 3032, January 2001 MPLS label stack encoding

07
[22] IETF RFC 3270, May 2002 Multi-Protocol Label Switching (MPLS) support of Differentiated

20
Services

e,
[23] ANSI INCITS xxx-20044, Information Technology Fibre Channel Backbone (FC-BB-3)

un
0J
,3
ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit

4
ns

This standard was in the process of formal approval at the time of publishing, so the number was not
available.
fI
so
re
Pi
ao
Jo
by
ed
oad

PMC-2041083 (2.0) 24
nl

2005 PMC-Sierra, Inc.

ow
 Generic Framing Procedure (GFP)
Technology White Paper

9 Notes

AM
01
8:
:4
10
07
20
e,
un
0J
,3
ay
rd
tu
Sa
on
o
ca
ica
un
om
lec
Te
de
o
ut
tit
ns
fI
so
re
Pi

25
ao
Jo

Head Office: To order documentation, All product documentation is Copyright

PMC-Sierra, Inc. send email to: available on our web site at: PMC-Sierra, Inc. 2005.
100-2700 Production Way document@pmc-sierra.com http://www.pmc-sierra.com/
by

Burnaby, B.C. V5A 4X1 or contact the head office, http://www.pmc- PMC-2041083 (2.0)
Canada Attn: Document Coordinator sierra.com/processors/
ed

Tel: 604.415.6000 http://www.pmc-sierra.com/serdes/

Fax: 604.415.6200 All rights reserved.
ad

For corporate information,

send email to:
o

mailto:info@pmc-sierra.com
nl
ow