Ethernet and Sonet are on a crash course. With Ethernet continuing to push its way out of the enterprise into the access and metro sectors, developers of Sonet equipment are being pushed to map Ethernet frames over Sonet/SDH links.
This is the second part in our two-part set on mapping Ethernet frames on Sonet links. In Part 1, we laid out the benefits of mapping Ethernet directly over Sonet (EoS). Additionally, we explored two of the encapsulation techniques-virtual concatenation (VC) and the link capacity adjustment scheme (LCAS).
In this part, we'll continue our discussion of encapsulation techniques, looking at the generic framing protocol (GFP) and link access procedure for SDH (LAPS). Let's start with GFP.
GFP-The Basics
Packet traffic in a multitude of co-existing protocols is expected to dominate the flow of network communications traffic in the foreseeable future. The bulk of data transport will continue to be via Sonet/SDH or subsequently optical transport networks (OTN). Thus, an efficient generic enveloping protocol for adapting multiple types of packet traffic to Sonet/SDH and OTN is needed. The generic framing procedure (GFP) fills this critical need and enables efficient provisioning of these multi-service data connections.
GFP [G.7041] is a generic mechanism for protocol data unit (PDU)-oriented client signal adaptation to enable data mapping into a Sonet/SDH virtual container. This mechanism adapts traffic from higher-layer client signals over an octet-synchronous transport network. GFP is also expected to support the new resilient packet ring (RPR) standard currently being drafted by the IEEE 802.17 study group.
The basic GFP adaptation mechanisms for various client signals, a.k.a. the client/GFP adaptation function, are of two types:
- A PDU-oriented adaptation for client signals such as IP/point-to-point protocol (IP/PPP) or Ethernet media access control (MAC) frames, referred to as frame-mapped GFP.
- A block code-oriented adaptation for 8B/10B encoded clients such as Gigabit Ethernet, fibre channel, fiber connectivity (FICON), or enterprise system connection (ESCON), known as transparent GFP.
Frame-Mapped GFP
In the frame-oriented approach, PDU frames are directly operated on by GFP. This requires frame visibility of the client protocol. The adaptation takes place at the link layer of the client signal.
The GFP framed adaptation function operates on the entire client PDU. Specifically, the complete GFP frame can be mapped into a suitable octet-based transport frame, such as in ANSI T1.105/ITU-T G.707 Sonet/SDH or a G.709 OTN frame. The relationship of the GFP adaptation to the higher-layer client signal and the transport path is shown in Figure 1
Click here for Figure 1
Figure 1: Relationship of GFP adaptation to client signals.
There are several reasons why the GFP frame-mapped mode may be preferred in certain applications. The main purpose of the linear frame multiplexed mode is to feed frames from multiple ports on the PHY in the most bandwidth-efficient manner possible. Generally, PDU-oriented frames have idle times which may be filled with flag characters (PPP/HDLC) or silence (for Ethernet MAC frames the minimum inter-packet gap [IPG] = 96 bit times).
PDU visibility of framed clients is necessary to strip out idle times or IPGs, provide a GFP frame, then pack multiple frames more efficiently into a single virtual container. After stripping all unnecessary bits, different types of PDUs encased in Virtual Containers are fed into a common large pipe. The minimum IPG/idle requirements for frame delineation are ensured at the de-mapping end.
The Gigabit Ethernet, 10/100 Mbps Ethernet, packet over PPP, and packet over simple data link (SDL) protocols are examples of client signals that can be mapped in this manner.
Figure 2 indicates the relationship of the Ethernet frame to the GFP frame as it applies to Ethernet MAC frames.
Click here for Figure 2
Figure 2: Framed Ethernet mapping in GFP.
The Ethernet MAC frame is illustrated in Figure 3. The shaded part is mapped into GFP.
Click here for Figure 3
Figure 3: Ethernet IEEE 802.3 MAC frame
Transparent-Mapped GFP
Transparent-mapped GFP, or simply transparent GFP, constitutes the main mapping mode for all 8B/10B block-coded clients, including Gigabit Ethernet, fibre channel, FICON, and ESCON, among others. This mode is intended primarily to support Storage Area Network (SAN) protocols, another currently expanding application area.
In transparent mapping block-coded client characters are decoded then mapped into a fixed-length GFP frame. The 8B/10B block encoding of individual characters results in a higher timing content in the signal. The encoding also provides a means of error checking during backplane transport via a so-called "disparity check".
The disparity check ensures that the number or zeros and ones in the signal is balanced and effects error control by maintaining a running disparity calculation. This calculation determines the appropriate encoding to be expected (either positive or negative disparity) for the character immediately following.
Individual data and control characters received from the 8B/10B encoded client signal are 8B/10B decoded, then remapped via transparent GFP into a 64B/65B encoded fixed-length frame consisting of multiple fixed-length "super-blocks". The 64B/65B GFP frame is another compressed encoding method that more efficiently uses virtual container bandwidth. This would not be possible if the 10B-coded characters were mapped directly.
One major advantage of 8B/10B block-encoded client signals is that they enable a generic transport mechanism based on "character streaming", For example, characters may be transmitted immediately without waiting to receive an entire client data frame.
Transparent GFP is the method of choice to minimize latencies over the entire mapping/demapping process and provide transparency to block-encoded control codes. However, a disadvantage is that transparent-mapped clients are not easily subjected to quality of service (QoS)-based prioritized services.
GFP Frame Structure
GFP defines two kinds of frames: data frames and control frames. Data frames carry client data, while control frames handle operations and overhead, administration, & maintenance (OA&M) info (refer to G.7041). Figure 4 below illustrates the GFP data frame format and all available fields. Note: for additional details, please check out the G.7041 spec..
Click here for Figure 4
Figure 4: Basic GFP frame format.
The core header supports frame delineation procedures and essential data link operations functions independent of the higher-layer PDUs. It consists of the PDU length indicator (PLI) and a core header error check (cHEC) field. The payload area, on the other hand, consists of a payload header, a payload field, and an optional payload frame check sequence (FCS) field.
The payload header supports data link management procedures specific to the higher layer protocol. It includes a type field, a type header error control (tHEC) field, GFP extension headers, and an extension header error control (eHEC) field. The type field indicates the content of the GFP frame, including the GFP frame format, and the values defined subsequently. The GFP extension header field is different for linear (point-to-point) and ring configurations. In linear configurations it consists of two octets, while in ring configurations it contains 16 octets. The payload field contains the framed PDU.
Composition of Type, Extension Headers
The two type octets described above have the following composition. The GFP payload type identifier (PTI) is a 3-b field that indicates a data frame (PTI = 0) or a management frame (PTI = 4) with other values currently undefined. The GFP payload FCS identifier (PFI) is a 1-b field that indicates use of the optional payload FCS.
The GFP extension header identifier (EXI) is a 4-b field that indicates the type of extension header in use. EXI = 0 implies a null header, EXI = 1 implies a linear frame; and EXI = 2 implies a ring frame. Other values of EXI are currently not defined.
The user payload identifier (UPI) is an 8-b field such that when PTI = 0, it identifies the type of payload and mapping in the data frame, e.g., frame-mapped Ethernet (UPI=1), frame-mapped PPP (UPI=2), transparent fibre channel (UPI=3), transparent FICON (UPI=4), transparent ESCON (UPI=5), transparent Gigabit Ethernet (UPI=6), and frame-mapped multiple access protocol over SDH (MAPOS) (UPI=8).
When PTI = 4, the UPI then defines the management frame type. Currently, only two values are defined: UPI = 1 indicates a client signal fail (CSF) for frame-mapped clients; and UPI = 2 also defines client signal fail but denotes loss of character synchronization for block-coded clients.
The two extension octets consist of a null header extension and a linear extension header. A null header extension implies an extension header and its associated HEC check (eHEC) are not present. A null header extension is generally used in situations when all GFP client data frames are mapped into a single transport path (Sonet/SDH container/virtually concatenated container) and carry a single type of payload, which is demapped at the receiving end to a single physical port/link.
The linear extension header signifies multiple types of payload from multiple ports/links mapped in a frame-wise multiplexed manner into a single transport path. In this case the extension header contains two octets. One octet is the channel ID (CID), which is an 8-b field for a destination port/link ID. The other octet is is unused. Two octets of the eHEC are also required for a linear extension header.
Ethernet over LAPS
The LAPS specification is discussed in ITU-T recommendation X.85/Y.1321 (IP over SDH using LAPS). It is defined as a type of high-level data link controller (HDLC) that includes data link service and protocol specification used in transporting IP packets over SDH networks.
LAPS enables the encapsulation of IPv6, IPv4, PPP, and other higher-layer protocols. Additionally, it is fully compatible with RFC 2615 (PPP over Sonet/SDH) when the address field is set to "11111111".
LAPS provides a point-to-point unacknowledged connectionless service over SDH. ITU-T recommendation X.86 describes the adaptation of Ethernet frames to LAPS for subsequent transport through SDH networks. The relationship between Ethernet, LAPS, and SDH is illustrated in Figure 5.
Click here for Figure 5
Figure 5: Relationship between Ethernet, LAPS, and SDH.
The LAPS frame format for higher-layer protocol encapsulation is shown in Figure 6. The opening and closing flag sequence is "01111110" and is normally transmitted during the time between frames. The address field is a single octet with a value of 0x04, while the control field is also a single octet with a value of 0x03. The source access point identifier (SAPI) field comprises two octets. The LAPS FCS field is a 32-bit string; its computation is described in ITU-T recommendation X.85/Y.1321.
Click here for Figure 6
Figure 6: LAPS frame format.
Why GFP is a Better Option
GP offers several significant advantages when compared to other PDU-oriented framing mechanisms, such as LAPS [ITU-T X.86]. These include:
- GFP is more efficient than LAPS. It has no inflation factor and maintains a fixed overhead almost equal to the minimum overhead in LAPS. Traffic management and QoS control are significantly easier.
- GFP is more robust than LAPS. A single bit-error in the PLI and the cHEC field does not cause loss of alignment, while with LAPS, a single bit-error in the flag causes misalignment. The HEC framing ensures a single bit-error correction in the PLI.
- GFP minimizes system bandwidth requirements. It allows multiple protocols from different ports or links to share the same transport path, resulting in more efficient use of available bandwidth. The mechanism that enables this consists of both common and client-specific elements. The common aspects provide the mechanism that enables GFP frame delineation and apply to all GFP traffic. The client-specific aspects of GFP are contained in the type and extension headers. These elements permit multiplexing of several types of protocols on a frame-by-frame basis, each from a potentially different port.
- GFP supports RPR operation and is inherently more suitable for packet traffic. The newer Sonet/SDH VC and LCAS procesures work much more efficiently with GFP.
Summing it Up
Transporting data traffic efficiently through global communications networks is becoming increasingly important. Corporations also require Ethernet connectivity across MANs and WANs to communicate with their facilities worldwide. A robust adaptation mechanism for EoS, GFP provides an efficient, scalable and unified mode of transport for corporate LAN, SAN, Internet access, and other data transfer applications.
Editor's Note: To view part 1 of this article, Click Here.
References
"Efficient Ethernet Data Transport over Sonet/SDH Using Virtual Concatenation, Mugica, D., Terradillos, E., and Areizaga, E., International Conference on Emerging Telecommunications Technologies and Applications (ICETA 2001) Kosice, Slovakia, October 2001.
ITU-T G.7041/Y.1303, January 2002: Generic Framing Procedure
ANSI T1X1.5/2001/062, January 2001: Revised Draft T105 Sonet Base Standard
ITU-T G.707/Y.1322, October 2000: Network Node Interface for the Synchronous Digital Hierarchy
ITU-T G.709, January 2001: Network Node Interface for Optical Transport Network
ITU-T Recommendation X.85/Y.1321, March 2001: IP over SDH Using LAPS
RFC 2615, 1999: PPP over Sonet/SDH
IEEE 802.3, 1998: CSMA/CD Access Method and Physical Layer Specifications
ITU-T Recommendation X.86, February 2001: Ethernet over LAPS
About the Authors
Harpreet Chohan is manager of customer engineering at TranSwitch Corporation. Harpreet received his MSEE from Imperial College of Science and Technology, University of London, England. He can be reached at chohan@txc.com.
Suvhasis Mukhopadhyay is a technical leader at TranSwitch. Asis holds a BSEE and MSc in Mathematics from Birla Institute of Technology and Science in Pilani, India. He also holds an MSEE from the University of Connecticut. Asis can be reached at asis@txc.com.
Rob Schwaber is product marketing manager for Ethernet/Sonet products at TranSwitch. He has a BS Computer Science from Union College, Schenectady, NY. Rob can be reached at schwaber@txc.com.
