T REC G.7041 201908 I!Amd1!PDF E
T REC G.7041 201908 I!Amd1!PDF E
T REC G.7041 201908 I!Amd1!PDF E
ITU-T G.7041/Y.1303
TELECOMMUNICATION Amendment 1
STANDARDIZATION SECTOR
OF ITU (08/2019)
Amendment 1
Summary
Recommendation ITU-T G.7041/Y.1303 defines a generic framing procedure (GFP) to delineate
octet-aligned, variable-length payloads from higher-level client signals for subsequent mapping into
octet-synchronous paths, such as those defined in Recommendations ITU-T G.707/Y.1322,
ITU-T G.8040/Y.1340 and ITU-T G.709/Y.1331. This Recommendation defines:
– frame formats for protocol data units (PDUs) transferred between GFP initiation and
termination points;
– the mapping procedure for the client signals into GFP;
– responses to certain defect conditions.
This edition adds the information from Amendment 1 (2012), Amendment 2 (2012) and Amendment 3
(2015) to Recommendation ITU-T G.7041 (2011), in addition to new material and text enhancements
from contributions to the February 2016 meeting.
Corrigendum 1 replaces a mistakenly expanded abbreviation with the correct terminology. It also
provides some minor editorial clean-up.
Amendment 1 contains edits to enhance the clarity of the client bit numbering for the GFP-F mappings,
especially the synchronization status message (SSM) bit numbering in clause 7.11. It also includes
editorial corrections to labelling in four additional figures.
History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T G.7041/Y.1303 2001-12-14 15 11.1002/1000/5644
1.1 ITU-T G.7041/Y.1303 (2001) Amd. 1 2002-06-13 15 11.1002/1000/6062
1.2 ITU-T G.7041/Y.1303 (2001) Cor. 1 2003-03-16 15 11.1002/1000/6285
1.3 ITU-T G.7041/Y.1303 (2001) Amd. 2 2003-03-16 15 11.1002/1000/6284
2.0 ITU-T G.7041/Y.1303 2003-12-14 15 11.1002/1000/7082
2.1 ITU-T G.7041/Y.1303 (2003) Amd. 1 2004-10-07 15 11.1002/1000/7352
2.2 ITU-T G.7041/Y.1303 (2003) Amd. 2 2004-06-13 15 11.1002/1000/7353
2.3 ITU-T G.7041/Y.1303 (2003) Cor. 1 2005-01-13 15 11.1002/1000/7476
* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/
11830-en.
Keywords
Generic framing procedure, optical transport network, synchronous digital hierarchy.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other
obligatory language such as "must" and the negative equivalents are used to express requirements. The use of
such words does not suggest that compliance with the Recommendation is required of any party.
ITU 2019
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.
G.7041-Y.1303(11)_F01
Bridge or switch or router function in TNE Data layer network Bridge or switch or router function in TNE
C C'
In the frame-mapped adaptation mode, the client/GFP adaptation function may operate at the data
link layer (or higher layer) of the client signal. Client PDU visibility is required. This visibility is
obtained when the client PDUs are received from either the data layer network [e.g., Internet protocol
(IP) router fabric or Ethernet switch fabric (C/C' in Figure 2)] or, e.g., a bridge, switch or router
function in a transport network element (TNE). In the latter case, the client PDUs are received via,
e.g., an Ethernet interface (A/A' in Figure 2).
Amendment 1
Editorial note: This is a complete-text publication. Modifications introduced by this amendment are shown in
revision marks relative to Recommendation ITU-T G.7041/Y.1303 (2016) plus its Corrigendum 1 (2018).
1 Scope
This Recommendation defines a generic framing procedure (GFP) to encapsulate variable-length
payload of various client signals for subsequent transport over synchronous digital hierarchy (SDH),
plesiochronous digital hierarchy (PDH) and optical transport network (OTN) networks as defined in
[ITU-T G.707], [ITU-T G.8040] and [ITU-T G.709]. This Recommendation defines the:
– frame formats for protocol data units (PDUs) transferred between GFP initiation and
termination points;
– mapping procedure for the client signals into GFP.
The framing procedure described in this Recommendation can be applied to both the encapsulation
of entire client frames (frame-mapped GFP), in which a single client frame is mapped into a single
GFP frame, and to character-mapped transport (transparent GFP), in which a number of client data
characters are mapped into efficient block codes for transport within a GFP frame.
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published. The reference to a document within this
Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T G.707] Recommendation ITU-T G.707/Y.1322 (2007), Network node interface
for the synchronous digital hierarchy (SDH).
[ITU-T G.709] Recommendation ITU-T G.709/Y.1331 (2016), Interfaces for the optical
transport network (OTN).
[ITU-T G.781] Recommendation ITU-T G.781 (2008), Synchronization layer functions.
[ITU-T G.783] Recommendation ITU-T G.783 (2006), Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks.
[ITU-T G.798] Recommendation ITU-T G.798 (2012), Characteristics of optical
transport network hierarchy equipment functional blocks.
[ITU-T G.806] Recommendation ITU-T G.806 (2012), Characteristics of transport
equipment – Description methodology and generic functionality.
[ITU-T G.8021] Recommendation ITU-T G.8021/Y.1341 (2016), Characteristics of
Ethernet transport network equipment functional blocks.
5 Conventions
Transmission order: The order of transmission of information in all the figures in this
Recommendation is first from left to right and then from top to bottom. Within each byte, the most
significant bit (MSB) is transmitted first. The MSB is shown at the left of all the figures.
Undefined field values: The default value for any undefined header fields is 0, unless otherwise
stated.
1 PLI <15:08>
2 PLI <7:00>
3 cHEC <15:08>
4 cHEC <7:00>
5
6 Payload header X = 4 to 64
7
8
9
Payload
. information
field
. 0 to 65535 - X
.
. Payload FCS
(optional) 4
n
Practical GFP maximum transmission unit (MTU) sizes for the GFP payload area are application
specific. An implementation should support transmission and reception of GFP frames with GFP
payload areas of at least 2 000 octets. By prior arrangement, consenting GFP implementations may
use other MTU values. Implementations supporting frame-mapped fibre channel (FC) should support
GFP payload areas of at least 2 156 octets.
6.1.2.1 Payload header
The payload header is a variable-length area, 4 to 64 octets long, intended to support data link
management procedures specific to the higher-layer client signal. The structure of the GFP payload
header is illustrated in Figure 6-4. The area contains two mandatory fields, the type and the type
header error check (tHEC) fields, and a variable number of additional payload header fields. This
group of additional payload header fields is referred to as the extension header. The presence of the
extension header, and its format, and the presence of the optional pFCS are specified by the type field.
The tHEC protects the integrity of the type field.
5
Type 2
6
7
tHEC 2
8
9
. Extension
header 0 to 60
. field
.
n eHEC 2
An implementation shall support reception of a GFP frame with a payload header of any length in the
range 4 to 64 octets.
6.1.2.1.1 GFP type field
The GFP type field is a mandatory two-octet field of the payload header that indicates the content and
format of the GFP payload information field (see clause 6.1.2.2). The type field distinguishes between
GFP frame types and between different services in a multi-service environment. As shown in
Figure 6-5, the type field consists of a payload type identifier (PTI), a pFCS indicator (PFI), an
extension header identifier (EXI) and a user payload identifier (UPI).
Octet transmission order
15 14 13 12 11 10 9 8 Bit number
5 PTI PFI EXI
6 UPI
7 6 5 4 3 2 1 0 Bit number
The interpretation of the UPI field for PTI values different from 000 or 100 is for further study.
Sample type field values are illustrated in Appendix II.
6.1.2.1.1.1 Payload type identifier
This 3-bit subfield of the type field identifies the type of GFP client frame. Three kinds of client
frames are currently defined, user data frames (PTI = 000), CMFs (PTI = 100) and management
communication frames (PTI = 101). PTI codepoints are given in Table 6-1.
5 Type <15:08>
6 Type <7:00>
7 tHEC <15:08>
8 tHEC <7:00>
Figure 6-6 – Payload header for a GFP frame with a null extension header
6.1.2.1.3.2 Extension header for a linear frame
The payload header for a linear (point-to-point) frame with an extension header, shown in Figure 6-7,
is intended for scenarios where there are several independent links requiring aggregation on to a single
transport path.
Octet transmission order
5 Type <15:08>
6 Type <7:00>
7 tHEC <15:08>
8 tHEC <7:00>
9 CIDe <7:00>
10 Spare <7:00>
11 eHEC <15:08>
12 eHEC <7:00>
pFCS <31:24>
pFCS <23:16>
pFCS <15:08>
pFCS <7:00>
G.7041-Y.1303(11)_F6-9
All octets in the GFP payload area are scrambled using a 1 + x43 self-synchronous scrambler.
Scrambling is done in network bit order.
At the source adaptation process, scrambling is enabled starting at the first transmitted octet after the
cHEC field, and is disabled after the last transmitted octet of the GFP frame. When the scrambler or
descrambler is disabled, its state is retained. Hence, the scrambler or descrambler state at the
beginning of a GFP frame payload area will thus be the last 43 payload area bits of the GFP frame
transmitted in that channel immediately prior to the current GFP frame.
The activation of the sink adaptation process descrambler also depends on the present state of the
cHEC check algorithm:
a) in the HUNT and PRESYNC states, the descrambler is disabled;
b) in the SYNC state, the descrambler is enabled only for the octets between the cHEC field and
the end of the candidate GFP frame.
NOTE – The GFP sink adaptation process can reliably forward GFP frames to the higher-layer entity only
when the sink adaptation process is in the SYNC state.
6.1.3 GFP client frames
Two types of GFP client frames are currently defined, client data and client management. GFP client
data frames are used to transport data from the client signal. GFP CMFs are used to transport
information associated with the management of the client signal or GFP connection.
1
Length 2
2
Core header
3
cHEC 2
4
5 PTI PFI EXI
2
6 UPI
Payload header
7
tHEC 2
8
Extension
9 -66 0-58
header
Extension header
+1 (optional)
eHEC 2
+2
+3
+4
+5
+6
n Payload area
+7
+8
+9
+n
+n+1
+n+2 FCS
4
+n+3 (optional)
+n+4
For use as a GFP CMF, the PFI shall be set as required depending on whether FCS is enabled
[note that the use of FCS in GFP CMFs reduces the amount of spare bandwidth (SBW) that can be
used for such frames]. The extension header indicator (EXI) shall be set as required depending on
whether the extension header is employed (note that the use of an extension header in the GFP CMF
will significantly reduce the amount of SBW that can be used for such frames).
The UPI defines the use of the GFP CMF payload. In this way, the GFP CMF may be used for multiple
purposes. Table 6-4 defines the GFP CMF payload uses.
1 00 (B6) hex
2 00 (AB) hex
3 00 (31) hex
4 00 (E0) hex
Client management
Idle insert
Frame multiplex Octet streams
to/from payload
mapping
Octet streams to
client-specific
.
sink adaptation .
.
processes
Payload descrambler
Client management
Core header check
Idle termination
Frame demultiplex
G.7041-Y.1303(11)_F6-12
Virtual
PRESYNC framers PRESYNC
(cHEC ID) (up to M) (cHECMD)
.. ..
. Incorrect .
cHEC
PRESYNC PRESYNC
(cHEC11 ) (cHECM1) Delta
consecutive
correct cHECs
Correct Correct
cHEC cHEC
Incorrect HEC
HUNT (multi-bit-errors) SYNC
Octet-by-octet Frame-by-frame
(error correction disabled) (error correction enabled)
G.7041-Y.1303(11)_F6-13
Robustness against false delineation in the re-synchronization process depends on the value of
DELTA. A value of DELTA = 1 is suggested.
Frame delineation acquisition speed can be improved by the implementation of multiple "virtual
framers", whereby the GFP process remains in the HUNT state and a separate PRESYNC sub-state
is spawned for each candidate GFP frame detected in the incoming octet stream, as depicted in
Figure 6-13.
6.3.1.2 Frame delineation alternative using both the core and type headers
An alternative algorithm uses both the core and type headers, as illustrated in Figure 6-14. This
algorithm can be advantageous for high-speed interfaces that are typically protected by FEC and
where circuit implementations often use wide data bus structures. The state machine works similarly
to that shown in Figure 6-13, except for the PRESYNC state operation. That operation works as
follows:
Figure 6-14 – GFP frame delineation state diagram using cHEC and tHEC
NOTE – The choice between the frame delineation algorithm alternatives is left to the implementer and shall
not be a provisional option. Equipment developed prior to the 2012 version of this Recommendation used the
frame delineation algorithm method based on only using the core header. Equipment developed subsequently
may use either alternative.
6.3.2 Frame multiplexing
GFP frames from multiple ports and multiple client types are multiplexed on a frame-by-frame basis.
The choice of scheduling algorithms is outside the scope of this Recommendation.
When there are no other GFP frames available for transmission, GFP idle frames shall be inserted,
thus providing a continuous stream of frames for mapping into an octet-aligned physical layer.
6.3.3 Client signal fail and defect indications
GFP provides a generic mechanism for a GFP client-specific source adaptation process to propagate
indications of a client signal fail (CSF) or a local or remote client defect to the far-end GFP
client-specific sink-adaptation process on detection of the condition.
6.3.3.1 Client signal fail indication
Detection rules for CSF events are, by definition, client-specific (see clauses 7 and 8). Upon detection,
a GFP source adaptation process should generate a CMF (PTI = 100). The PFI subfield is set to 0
(no payload information field FCS) and the EXI subfield is set to the appropriate extension header
type as applicable. The two types of CSF use the following UPI field values:
– loss of client signal (UPI = 0000 0001);
– loss of client character synchronization (UPI = 0000 0010).
1 Note that neither loss of client signal nor loss of client synchronization are considered "explicit" client fault
indications, since they are detected by the GFP client-specific source adaptation process.
Figure 6-15 – Examples of a reverse defect indication of a client link fault status indication
Figure 6-16 – Examples of a forward defect indication of a client link fault status indication
For instance, in Figure 6-15, the native client link fault status indication at transport node NE B is
received by the GFP source adaptation process, mapped into a CMF RDI and then forwarded to the
GFP sink adaptation process in transport node NE C. At NE C, the CMF RDI is extracted, mapped
back into native client link fault status indication and regenerated in the port towards the near-end
client NE D. Similarly, in Figure 6-16, the native client link fault status indication at transport node
NE C is forwarded to the GFP source adaptation process, mapped into a CMF FDI client link fault
status and then forwarded to the GFP sink process in transport node NE B. At NE B, the CMF FDI is
extracted, mapped into the native client link fault status indication and regenerated back in the port
toward NE A.
Note that processing of native client link fault status indications and its mapping into a GFP CMF for
client link fault status indication can be based solely on near-end client link fault status information.
6.3.3.3 Client defect clear indications
In addition to the implicit defect clearance mechanisms in clause 6.3.3, GFP also provides an explicit
event-driven mechanism to help expedite clearance of native client link fault conditions called the
client defect clear indication (DCI).
Clearance rules for native client link fault events are client-specific.
Upon detection of the native client link fault clearance event condition, the GFP client-specific source
adaptation process may send a DCI signal to the GFP client-specific sink adaptation process.
Upon detection of a TSF event or a GFP loss of frame delineation event, the GFP sink adaptation
process generates a GFP SSF indication to its client-specific sink adaptation processes. These failure
events are cleared as soon as the GFP process regains link synchronization.
Upon detection of CSF events other than a far-end CSF indication, the GFP client-specific sink
adaptation processes should take client-specific (as well as server-specific) actions to deal with those
failure events.
1 2 3 4 5 6 7 8 Bits 1 2 3 4 5 6 7 8 Bits
1 Address
1 Control
2 PPP type
GFP
PPP information payload
(Pad)
4 Frame check sequence (FCS)
1 2 3 4 5 6 7 8 Bits 1 2 3 4 5 6 7 8 Bits
1 2 3 4 5 6 7 8 Bits 1 2 3 4 5 6 7 8 Bits
Figure 7-3 – PPP/HDLC and GFP frame relationships (with PPP's ACFC configuration
option)
GFP
N RPR frame payload
Octets
Bits MSB LSB 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 Bits 1 2 3 4 5 6 7 8 Bits
7.7 Direct mapping of IP and OSI network layer PDUs into GFP-F frames
The direct mapping of IPv4, IPv6 and open systems interconnection (OSI) network layer PDUs into
GFP is intended for applications that wish to transport IP/OSI PDUs directly over SDH containers.
The IPv4 PDU [IETF RFC 791], IPv6 PDU [IETF RFC 2460], CLNP PDU [ITU-T X.233], end
system-to-intermediate system (ES-IS) PDU [ISO 9542] and intermediate system-to-intermediate
system (IS-IS) PDU [ISO/IEC 10589] contain one or more client-specific header entry and a client
payload information field. All octets in the client PDU are placed in the payload information field of
a GFP-F frame. Both octet alignment and bit identification within octets are maintained within the
GFP-F PDU.
The GFP pFCS is required and is computed as specified in clause 6.1.2.2.1.1 and inserted in the pFCS
field. The PFI field is set to 1. This relationship between the IPv4, IPv6 or OSI network layer PDUs
and GFP-F frame is illustrated in Figure 7-7.
2 PLI
2 cHEC
2 Type
2 tHEC
Figure 7-7 – IPv4/IPv6/OSI network layer PDUs and GFP frame relationships
16 RS code (optional)
1 2 3 4 5 6 7 8 Bits 1 2 3 4 5 6 7 8 Bits
MAC
Reconcilliation
XGMII
PCS
PMA
PMD
10GBase-R
The physical coding sublayer (PCS) is described in clause 49.2 of [IEEE 802.3], including the
delimiting of data frames and ordered sets.
7.9.2 GFP-F encapsulation
As shown in [IEEE 802.3] Figure 46-3, the Ethernet data stream at the XGMII consists of:
<inter-frame><preamble><sfd><data><efd>. For the purposes of these mappings, the client data
frames include the <preamble><sfd><data> information, and the ordered sets include specific
information carried in the <inter-frame> characters. The mapping of both client data frames and
ordered sets into GFP-F frames is described in this clause. Each GFP-F frame uses the core header
and type header. The GFP type field is shown in Figure 6-5. The UPI field indicates data or ordered
sets. The rest of the fields are static:
– PTI = 000 (client data)
– PFI = 0 (no FCS)
– EXI = 0000 (null extension header)
The functional model of the mapping is illustrated in Figure 7-10. EthPP represents the Ethernet PDU
with its preamble and EthOS represents the Ethernet ordered set information. Note that there is no
Ethernet MAC termination function. Consequently, since no error checking is performed on the
Ethernet MAC frames, errored MAC frames are forwarded at both the ingress and egress to the GFP
adaptation functions.
NOTE 1 – Since no MAC function exists at the GFP source or sink, Ethernet auto-negotiation is performed
between Ethernet terminals across the GFP link rather than between the Ethernet terminal and the GFP
source/sink equipment.
OTH network
Figure 7-10 – Functional model for mapping 10GBASE-R information into the ODUk
NOTE 2 – The Ethernet control codes such as idle, error and the reserved codes are not transferred.
At the egress from the GFP sink adaptation process, the IEEE 802.3 rules shall be observed in the
reconstituted Ethernet data stream, including the appropriate insertion of IFG characters.
7.9.2.1 Client data frame encapsulation
Unlike the Ethernet frame mapping specified in clause 7.1, this mapping includes the Ethernet frame
preamble information in the GFP-F payload area along with the client Ethernet data frame.
See Figure 7-11. As specified in clause 46.2 of [IEEE 802.3], the preamble consists of seven octets
beginning with the /S/ (start) control character and followed by the start of frame delimiter (SFD)
character. Since the /S/ control character is always present at the beginning of the preamble, as shown
in Figure 7-11, it is mapped as a fixed value of 0x55 when it is inserted into the GFP-F frame. The
SFD character is included, however, to ensure there is no ambiguity regarding the beginning of the
client data frame. Specifically, the six preamble octets and the SFD are pre-pended to the Ethernet
data frame in their network octet transmission order. Consistent with the Ethernet data mapping into
GFP, the bit order of each octet is mapped such that preamble/SFD octet bit 7 corresponds to GFP
octet bit 1 and preamble/SFD octet bit 0 corresponds to GFP octet bit 8.
Figure 7-11 – Ethernet client data frame and preamble mapping into GFP-F
7.9.2.2 Ordered set encapsulation
The 10 Gbit Ethernet ordered set is defined in clause 49.2.4 of [IEEE 802.3]. An ordered set consists
of four octets, beginning with a special character (/O/) followed by three data octets. Each ordered
set is mapped into its own GFP-F frame, as shown in Figure 7-12. The first octet of the ordered set
has the four MSBs set to all-zeros and the four LSBs equal to the O code. This way both sequence
ordered sets (O code = 0000) and signal ordered sets (O code = 1111) can be transferred. The next
three octets contain the three data bytes of the ordered set. The ordered set octets are mapped into the
GFP payload area in network octet transmission order. Consistent with the Ethernet data mapping
into GFP, the bit order of each octet is mapped such that ordered set octet bit 7 corresponds to GFP
octet bit 1 and ordered set octet bit 0 corresponds to GFP octet bit 8.
GFP frame
Bit # Octets
1 2 3 4 5 6 7 8
Payload length (PLI) 2
Core header
Ethernet ordered set cHEC 2
Octets Bit # Payload type info. 2
Type header
1 2 3 4 5 6 7 8 tHEC 2
G.7041-Y.1303(11)_F7-12
In order to support enhanced clocks and new functionality, an extension to the extended SSM is
defined in Figure 7-14. The contents of the extended QL TLV SSM are defined in clause 11.3.1.3 of
[ITU-T G.8264]. The Extended SSM frame includes the 20-byte extended QL TLV field after the
SSM octet, and may optionally include other TLVs as they are defined in the future. Consistent with
[ITU-T G.8264] and [IEEE 802.3], on an octet-by-octet bases, bits 0 and 7 of a TLV the extended
SSM correspond to bits 8 and 1 in the GFP frame.
16-bit payload
length indicator
Core header cHEC
(CRC-16)
16-bit payload
Payload header type field
(4-64 bytes) tHEC
Payload (CRC-16)
Payload area
information Extension
field header
(0-58 bytes) Optional
eHEC
[N´((8´65B)+ 16)] (CRC-16)
Optional payload
FCS
(CRC-32)
For example, if there is a single 64B/65B control character in a block, and it was originally located
between 8B/10B data codewords D2 and D3, the first octet of the 64B/65B block will contain
0.010.C1. The LCC value of 0 indicates that this 64B/65B control character is the last one in that
block and the value of aaa = 010 indicates C1's location between D2 and D3. At the demapper, the
64B/65B data characters are remapped as 8-bit data octets and then encoded back into the 8B/10B
data codewords. For 64B/65B control characters, the four-bit control code indicators are remapped
into the appropriate 8B/10B control codewords with their positions within the original character
stream restored based on the three-bit control code locator.
8.1.1.1 10B_ERR code
Certain client signal defects may produce 8B/10B codewords on ingress to the GFP source adaptation
process that cannot be recognized by the 64B/65B adaptation process (e.g., a CSF, an illegal 8/10B
codeword or a legal codeword with an RD error, see clause 8.2). A special 64B/65B control character,
the 10B_ERR code, is provided to convey such "unrecognized 8B/10B codeword" client signal
defects.
When reconstructing the client signal on egress from the transport network, it is recommended that
received 10B_ERR codes be typically recoded by the demapper into an invalid transmission character
of either 001111 0001 (RD–) or 110000 1110 (RD+) (fixed, illegal 8B/10B codewords with neutral
disparity, containing a transition within both the first three bits and last three bits of the codeword),
depending on RD (see clause 8.2.3 for other client-specific RD considerations). Although the actual
value of the unrecognized 8B/10B codeword is not retained, the occurrence and location of the client
signal defect are preserved.
Figure 8-3 – Superblock structure for mapping 64B/65B code components into the GFP frame
NOTE – To minimize latency, the transparent GFP mapper can begin transmitting data as soon as the first
64B/65B code in the group has been formed rather than waiting for the entire superblock to be formed.
Assuming no pFCS and a null extension header, the resulting GFP frame is {N × [(65 × 8) + 16] +
(8 × 8)} bits long, where N is the number of superblocks in the GFP frame. The value of N depends
on the base, uncoded rate of the client signal and on the transport channel capacity. Suggested SDH
This appendix presents some examples of functional models for GFP applications. In the absence of
layer network architectures for data layer networks (e.g., IP and Ethernet), the models presented are
for illustration purposes only.
GFP can be deployed in transport NEs (e.g., SDH) and in data NEs (e.g., IP, Ethernet).
In the former case, a physical data interface (Ethernet or storage area network type) is provided as a
tributary interface port on the transport NE. If the physical data signal is an 8B/10B coded signal, it
can be transported through the transport network as a transparent stream using GFP-T mapping
(Figure I.1). If only a part of the physical interface bandwidth is carrying traffic and only this traffic
is to be transported through the transport network, the physical data interface signal is terminated,
data PDUs are extracted and forwarded via GFP-F mapping over a VC-m-Xv, VC-n, VC-n-Xc or
VC-n-Xv signal (Figure I.2).
In the latter case, GFP processing is performed between the IP router (Ethernet switch) fabric and
the, e.g., STM-N interface port functions (Figures I.3 and I.4). The FC tributary interface port using
FC-BBW_SONET and GFP-F mapping in an SDH NE is shown in Figure I.5.
Ethernet MAC
EthS/EthP Ethernet path Bridge or switch function
frame extraction
t = Ethernet (10BASE)
Fast Ethernet (100BASE) PHY-t VC-n signal
GigEthernet (1000BASE) or X VC-n signals
10GigEthernet (10GBASE)
Ethernet
switch
fabric Sn[-Xv] VC-n path termination
or VC-n-Xv path termination
FC MAC
FC-BBW_SONET FC MAC extraction
extraction/delineation n FC-1/FC-2
/FC-2 (from FC-BBW_SONET)
(from FC-1)
– FC-BBW_SONET frames
– FC-PHY line (de)coding Sn[-X]/FC-BBW encapsulated in GPP-F
– Clock/data recovery PHY-FC/FC-1 (GFP-F) – GFP frame stream mapped
in VC-n/VC-n-xV
PHY-FC (FC-0) PHY-FC Sn[-X]
VC-n/VC-n-Xv path
e.g., 1G, 2G, 4G
termination
and 10G FC
The core header is XORed with the DC Barker code, the rest of the GFP frame is unchanged.
Byte Field Value (hex) Comment
1 PLI[15:8] B6 ; 00 XOR B6
2 PLI[7:0] E3 ; 48 XOR AB
3 cHEC[15:8] F8 ; C9 XOR 31
4 cHEC[7:0] 2C ; CC XOR E0
5 ...
The following example shows the calculation of the cHEC for PLI[15:0] = 0x0048. The polynomial
is G(x) = x16 + x12 + x5 + 1. The PLI is shifted into the CRC-16 calculator with PLI[15:8] first, then
PLI[7:0], MSB first for each octet.
x15 ... x0
0000000000000000 CRC-16 initial state
Input bit 1 0001000000100001 CRC-16 after input bit
0 0010000001000010
0 0100000010000100
1 1001000100101001
0 0011001001110011
0 0110010011100110
0 1100100111001100
Transmit the CRC-16 starting from x15 gives the GFP octets cHEC[15:0] = 0xC9CC.
The GFP frame is input to the x43+1 scrambler in network bit order (MSB first). Starting with the first
byte of the TYPE field (the core header is not scrambled):
Bit #1 TYPE[15]
Bit #2 TYPE[14]
Bit #3 TYPE[13]
...
The core header is XORed with the DC Barker code, the rest of the GFP frame is unchanged.
Byte Field Value (hex) Comment
1 PLI[15:8] B6 ; 00 XOR B6
2 PLI[7:0] 8F ; 24 XOR AB
3 cHEC[15:8] 55 ; 64 XOR 31
4 cHEC[7:0] 06 ; E6 XOR E0
5 ...
IV.1 Introduction
In GFP-T, there is an integer number (N) of 536-bit superblocks in a client data frame. The value of
N must be chosen so that the efficiency of the client data bits relative to the GFP frame overhead bits
allows enough bandwidth to transport the client data signal. The value of N can be chosen to allow
enough additional SBW in the channel for the transport of CMFs and MCFs. The minimum values of
N are shown here as a function of the various overhead bits and the number of CMFs (CMFs) or
MCFs that are allowed to be transmitted between successive GFP-T client data frames.
This appendix shows the transport bandwidth requirements for client data over Ethernet over GFP
over a synchronous optical network (SONET) as a function of the Ethernet MAC rate, the client
payload field length, whether the network has inserted a VLAN tag, and whether the GFP pFCS is
used. This information is shown in Tables V.1 to V.4.
NOTE – The MAC bit rate in Tables V.1 to V.3 is the actual bit rate of the Ethernet MAC frames after the
removal of the 12-byte IPG plus 7-byte preamble + 1-byte SFD. In other words, MAC bit rate = (Ethernet
interface rate) (No. of bits in the MAC frame)/(No. of bits in the MAC frame + 12-byte IPG + 7-byte preamble
+ 1-byte SFD). The calculations in Table V.4 are the same, except that the 10 Gbit Ethernet uses a 5-byte
minimum IPG instead of 12 bytes.
Table V.1 – Maximum (un)tagged MAC bit rate per "10 Mbit/s" MAC server signal
Payload bit rate (nominal bit rate for Ethernet)
MAC bit rate (kbit/s), throughput (%) relative to maximum MAC bit rate
MAC-
GFP- VLAN VC- VC- VC-12- VC-
size 10Base-T Throughput Throughput Throughput Throughput
FCS tag 11-6v 11-7v 4v 12-5v
(bytes)
0 0 64 7 619 8 533 112.0 9 956 131 7 737 101.5 9 671 127
0 0 128 8 649 9 055 104.5 10 541 122 8 192 94.7 10 240 118
0 0 256 9 275 9 309 100.4 10 861 117 8 440 91.0 10 550 114
0 0 512 9 624 9 452 98.2 11 028 115 8 570 89.0 10 713 111
0 0 1 024 9 808 9 526 97.1 11 113 113 8 637 88.1 10 796 110
0 0 1 518 9 870 9 550 96.8 11 141 113 8 658 87.7 10 823 110
0 0 9 618 9 979 9 592 96.1 11 191 112 8 697 87.1 10 871 109
0 1 64 7 727 8 589 111.2 10 021 130 7 788 100.8 9 735 126
0 1 128 8 684 9 051 104.2 10 560 122 8 207 94.5 10 258 118
0 1 256 9 286 9 313 100.3 10 866 117 8 444 90.9 10 555 114
0 1 512 9 627 9 453 98.2 11 029 115 8 571 89.0 10 714 111
0 1 1 024 9 809 9 526 97.1 11 114 113 8 637 88.0 10 796 110
0 1 1 518 9 870 9 550 96.8 11 141 113 8 658 87.7 10 823 110
0 1 9 618 9 979 9 592 96.1 11 191 112 8 697 87.1 10 871 109
NOTE 1 – GFP-FCS; no = 0, yes = 1. VLAN tag; value gives the number of VLAN tags (no VLAN tag = 0).
NOTE 2 – Encapsulation overhead; 20 bytes for physical Ethernet interface (7-byte preamble, 1-byte SFD and 12-byte
minimum IPG). 8-byte encapsulation overhead for GFP without GFP-FCS and 12-byte encapsulation overhead for GFP
with GFP-FCS.
MAC bit rate (kbit/s), throughput (%) relative to maximum MAC bit rate
Table V.3 – Maximum (un)tagged MAC bit rate per "1 Gbit/s" MAC server signal
Payload bit rate (nominal bit rate for Ethernet)
MAC bit rate (kbit/s), throughput (%) relative to maximum MAC bit rate
Ethernet defines a number a PHY-specific signals to indicate local and remote defects. These signals
fall into two broad categories that are useful to communicate across the GFP-F link: remote defect
indications and FDIs.
Tables VI.1 and VI.2 summarize these PHY-specific signals, the conditions under which they are
inserted and the PHY layer responses to receiving them. The information in these tables is provided
for information only. [IEEE 802.3] is the standard for the complete specification of these signals.
GFP RDI frames are sent in response to the remote defect signals of Table VI.1, and GFP FDI frames
are sent in response to the local defect signals of Table VI.2.
While the normal application of ODUflex for GFP-F mapped client signals is to provide a sub-rate
or VLAN service, it is instructive to examine the Ethernet packet throughput available for various
ODUflex sizes.
The sizes of ODUflex for various tributary slot sizes are shown in Table VII.1.
[b-ITU-T G.823] Recommendation ITU-T G.823 (2000), The control of jitter and wander
within digital networks which are based on the 2048 kbit/s hierarchy.
[b-ITU-T V.41] Recommendation ITU-T V.41 (1988), Code-independent error-control
system.
[b-ITU-T G-Sup.43] Supplement ITU-T G-Sup.43 (2011), Transport of IEEE 10GBASE-R in
optical transport networks (OTN).
Series D Tariff and accounting principles and international telecommunication/ICT economic and
policy issues
Series E Overall network operation, telephone service, service operation and human factors
Series J Cable networks and transmission of television, sound programme and other multimedia
signals
Series K Protection against interference
Series L Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation
and protection of cables and other elements of outside plant
Printed in Switzerland
Geneva, 2019