Four-fiber Bidirectional Line Switched Ring 4F-BLSR

42 SONETSDH AND THE GENERIC FRAME PROCEDURE GFP Payload header Payload Payload FCS Payload type Payload type Type HEC Type HEC 0-60 Bytes of extension header PTI UPI PFI EXI Figure 2.25 The GFP payload structure. length between 4 bytes and 64 bytes see Figure 2.25. The following fields have been defined: • Payload type : A mandatory 2-byte field that indicates the content and format of the payload. The following subfields have been defined within the payload type: ◦ Payload type identifier PTI: A 3-bit subfield that identifies the type of client frame i.e., client data frame and client management frame. ◦ Payload FCS indicator PFI: A 1-bit subfield that indicates the presence or absence of the optional payload FCS. ◦ Extension header identifier EXI: A 4-bit subfield that identifies the type of exten- sion header. ◦ User payload identifier UPI: An 8-bit field that identifies the type of payload. Defined UPI values for client data frames include: Frame-mapped Ethernet Frame-mapped PPP including IP and MPLS Transparent-mapped Fiber Channel Transparent-mapped FICON Transparent-mapped ESCON Transparent-mapped Gigabit Ethernet GbE • Type head error control type HEC or tHEC : A 2-byte field that protects the payload header. It carries the FCS obtained using standard CRC-16. As with the core HEC, it enables both single-error correction and multiple-error detection. • Extension headers : A flexible mechanism for header extension is supported in order to facilitate adaptation of GFP to diverse transport mechanisms. The payload contains a GFP frame. It is a variable-length area ranging from 0 bytes to 65,535 bytes, minus the size of the payload header and if present the size of the payload FCS. Finally, the GFP payload FCS consists of an optional 4-byte FCS generated using CRC-32.

2.7.2 GFP Client-independent Functions

GFP supports the following basic procedures, which are common to all payloads: frame delineation, frame multiplexing, header and payload scrambling, and client management. Frame delineation checks the GFP frames to make sure they are extracted correctly from the bit stream that SONETSDH delivers to the GFP client-independent layer. It is DATA OVER SONETSDH DOS 43 a simple procedure that makes sure that the beginning of each GFP frame is correctly identified. This procedure is identical to the cell delineation procedure used in ATM see Section 3.4.1, and it uses the core HEC. Frame multiplexing is used by GFP to multiplex client data frames and client man- agement frames on a frame-by-frame basis. Client data frames have priority over client management frames. When no frames are available, GFP inserts idle frames in order to maintain a continuous bit flow. The GFP idle frame is a special 4-byte GFP control frame, consisting only of the GFP core header with the payload length indicator and the core HEC fields, set to 0. The core header is always scrambled to ensure high bit transmission density when trans- mitting idle GFP frames. Payload scrambling is done using a 1 + x 43 self-synchronous scrambler. As in ATM, scrambling is enabled starting at the first transmitted byte after the cHEC field, and disabled after the last transmitted byte of the GFP frame. Client management provides a generic mechanism to propagate client-specific infor- mation, such as performance monitoring and OAM information.

2.7.3 GFP Client-dependent Functions

The client data can be carried in GFP frames using one of the following two adapta- tion modes: frame-mapped GFP GFP-F or transparent-mapped GFP GFP-T. Frame- mapped GFP is applicable to most packet data types, and transparent-mapped GFP is applicable to 8B10B coded signals. In frame-mapped GFP, each received client-frame is mapped in its entirety in a single GFP payload. Examples of such client frames include Ethernet MAC frames, PPPIP packets, and HDLC-framed PDUs. The transparent-mapped GFP mode is used to transport continuous bit-rate, 8B10B block-coded client data and control information carried by networks, such as fiber chan- nel, ESCON, FICON, and Gigabit Ethernet. Note that in the 8B10B encoding scheme, each group of eight bits is coded by a 10-bit code. Coding groups of bits is known as block-coding. Rather than transporting data on a frame-by-frame basis, the GFP transparent-mapped mode transports data as a stream of characters. Specifically, the indi- vidual characters are decoded from their client 8B10B block codes and then mapped into periodic fixed-length GFP frames using 64B65B block coding. Specifically, the 10-bit codes are first decoded into their original data or control codeword value, and then the decoded characters are mapped into 64B65B codes. A bit in the 65-bit code is used to indicate whether the 65-bit block contains only data or whether control characters are also included. Eight consecutive 65-bit blocks are grouped together into a single super block , and N super blocks make up a single GFP frame. This procedure reduces the 25 overhead introduced by the 8B10B block-coding; plus, it reduces latency, which is important for storage-related applications.

2.8 DATA OVER SONETSDH DOS

The data over SONETSDH DoS network architecture provides a mechanism for the efficient transport of integrated data services. The following are some of the features of DoS: • It provides flexible bandwidth assignment with a 50-Mbps granularity. • No modifications are required of the intermediate nodes. 44 SONETSDH AND THE GENERIC FRAME PROCEDURE GFP • Using GFP, it provides an efficient framing scheme with a small overhead. • It can accommodate IP packets, Ethernet frames, and constant bit rate data and control information carried by fiber channel, ESCON, and FICON. In particular, it provides an effective mechanism to transport GbE, which has recently been widely deployed in wide area networks WAN . • Coexistence of the traditional voice services and the new data services in the same SONETSDH frame. • Network management through the SONETSDH existing and quality-proven network management. DoS uses three technologies: generic framing procedure GFP, virtual concatenation, and link capacity adjustment scheme LCAS. These technologies have been standardized by ITU-T. GFP was described in detail above in Section 2.7. Below, we describe the other two technologies: virtual concatenation and LCAS.

2.8.1 Virtual Concatenation

Virtual concatenation is a SONETSDH procedure that maps an incoming traffic stream into a number of individual subrate payloads. That is, payloads with a bandwidth less than the bandwidth of a SONETSDH link. The subrate payloads are switched through the SONETSDH network independently of each other. As an example, let us consider the case of transporting a GbE traffic stream over SONET. According to the SONET specifications, an OC-48c 2.488 Gbps has to be used in order to accommodate the GbE traffic at full speed. However, about 1.488 Gbps of the OC-48c will go unused. Alternatively, we can use an OC-12c 622 Mbps, but this will require appropriately reducing the speed of GbE. The best solution is to use an OC-21c 1.088 Gbps, since this is the SONET payload with a bandwidth that is close to the speed of GbE. However, this payload is not feasible since it has not been implemented in SONET equipment. It will take a major investment to develop this new payload and deploy it into the SONET equipment. Virtual concatenation provides an efficient and economic solution to this problem. With virtual concatenation, seven independent OC-3c 155 Mbps subrate payloads can be used to carry the GbE traffic. These seven payloads provide a total payload with 1.088 Gbps bandwidth. The incoming GbE stream is split into seven substreams, and each substream is mapped onto one of the seven OC-3c payloads. These payloads are then switched through the SONET network as individual payloads without the intermediate nodes being aware of their relationship. Virtual concatenation is only required to be implemented at the originating node where the incoming traffic is demultiplexed into the seven subrate payloads and at the terminating node, where the payloads are multiplexed back to the original stream. The seven payloads might not necessarily be contiguous within the same OC-N payload. Also, they do not have to be transmitted within the same SONET fiber. That is, if the SONETSDH network consists of nodes that are interconnected with f fibers, then each of these seven payloads can be transmitted over any of the f fibers. As we saw in Section 2.3.3, when transporting IP packets over SONETSDH PoS, the entire SONETSDH payload has to be dedicated to IP packets. Unlike PoS, virtual concatenation permits the bandwidth of a SONETSDH frame to be divided into several subrate payloads, each of which can carry different type of traffic see Figure 2.26. The