mcgraw hill wireless data demystified phần 8 potx

Chapter 16: Packet-over-SONET/SDH Specification sense that the latter is focused on wireless data transport only (Ether- net directly over fiber is currently the interface of choice) for metro-area applications. In contrast, besides wireless data applications, the hybrid services support TDM applications as well, and can be used in both MAN and WAN scenarios. NOTE The channel identifier field in GFP linear frame structure can be used to distinguish 256 data streams within a single SONET/SDH path (see Fig. 16-6). 3 391 Metro/access network SONET/SDH Main frame Router OC-1/3/12 FICON/ ESCON GBE Path switching (PSW) Virtual concatenation PKTSW OC-48 LCAS GFP TGFP GFP: Generic Framing Procedure TGFP: Transparent GFP LCAS: Link Capacity Adjustment Scheme (b) Next-generation SONET/SDH DOS node DOS node DOS node DOS node DOS node Private network Private network Shared bandwidth (e.g., STS-3c-10v) ISP ISP TDM bandwidth Data services - Flexible and efficient bandwidth application (a) Figure 16-5 A DOS node: (a) an example of network architecture using DOS; (b) func- tional architecture; (c) hardware archi- tecture. 392 Part 3: Installing and Deploying Data Networks Figure 16-5b shows a typical functional architecture of a DoS node. The node provides transport interfaces, such as legacy SONET/SDH, ESCON/FICON, and GbE, for a wide range of applications. The DoS node uses virtual concatenation and GFP as enablers to efficiently pack wireless application data into SONET/SDH frames. It also uses LCAS to regulate the amount of bandwidth assigned to transport the client wire- less data. DoS nodes are designed to provide a wide variety of line interfaces so that new services can be launched without deployment of new nodes. STM switch Transport node Tributary STM IF STM IF STM IF Packet IF Packet IF Packet switch OC-3 OC-3 OC-12 DS3 Ether MAC IP PPP IP PPP IP L2 detect destination search Scheduling shaping Packet SW Aggregate OC-48 STM Packet F L2 MAC IP (c) Figure 16-5 (Continued) Payload header 4B 4B2B 2B 2B1B 1B Extension header Core header Type Type HEC CID Spare Payload information field Payload FCS Figure 16-6 The GFP linear frame structure. Chapter 16: Packet-over-SONET/SDH Specification New line interface cards are installed as need arises. Interfaces for a data center (ESCON, FICON, Fibre Channel) and digital video (DVB- ASI) are also utilized. Figure 16-5c illustrates the hardware architec- ture of a DoS node with Layer 1 ⁄2 hybrid switch capability. The node is composed of the following modules. Switch modules: STM switch Packet switch Aggregate interface cards: OC-48/STM-16 OC-192/STM-64 OC-768/STM-256 Tributary interface cards: Ethernet (10M/100M/1G) Fibre Channel, ESCON/FICON DVB-ASI (video interface) POS (OC-3/STM-1, OC-12/STM-4, OC-48/STM-16) ATM (OC-3/STM-1, OC-12/STM-4, OC-48/STM-16) TDM (OC-3/STM-1, OC-12/STM-4, OC-48/STM-16, DS1, DS3, etc.) 3 Node-to-node trunks are terminated on an aggregate interface card. On the receiver side of the aggregate interface, TDM traffic continues to be switched to either the tributary interface cards or aggregate interface cards, while the data traffic on virtually concatenated channels is routed to the packet switch. The packet switch performs termination of virtually concatenated payloads to produce GFP streams at the switch input ports. At the output ports of the packet switch, the virtual concatenation func- tion maps the GFP streams into virtually concatenated payloads, which are sent to the STM switch. The packet switch performs the switching of GFP frames between ports, some connected to tributary interface cards and the rest to aggregate interface cards, through the STM switch. At the tributary interface card, GFP frames are terminated to extract the origi- nal data stream, which is then mapped to the appropriate Layer 1 and 2 protocols. In the wireless data transmission direction, the incoming Layer 1 and 2 protocols are terminated, and wireless data streams are encapsulated into GFP frames at the tributary interface cards. If the line interface card happens to have several ports, the GFP frames from the various ports are aggregated and sent to the packet switch. The packet switch then switches GFP frames, maps the frames into virtually concatenated payloads, and sends them to the aggregate interface cards. 393 394 Part 3: Installing and Deploying Data Networks GFP Point-to-Point Frame Application The structure of a GFP linear (point-to-point) frame is depicted in Fig. 16-6. 3 A typical application of a GFP linear frame is point-to-point connection and concentration. For example, data streams from multiple tributary interface cards can be aggregated into a same aggregate interface card. The 8-bit channel identifier (CID) in the GFP extension header is used to indicate one of 256 data streams. If the available bandwidth of the aggre- gate interface is below the sum of peak traffic of all data streams, statisti- cal multiplexing is introduced to achieve concentration. The optional payload FCS field in the GFP frame can be used for per- formance monitoring of an end-to-end GFP path. The area covered by FCS is the payload information field only, which contains the wireless user data. Therefore, at intermediate nodes, recalculation of FCS is not necessary, so that FCS is retained throughout the path. The end-to-end path monitoring can be used for path quality management as well as for triggering protection mechanisms. SAN Interconnection by Transparent GFP SAN deployment for disaster recovery applications has recently received a lot of attention. This application requires direct connection of SAN inter- faces to a WAN in an efficient manner. The conventional method for supporting this application is to simply assign one wavelength to each SAN interface. This method is inefficient in terms of bandwidth usage because the SAN bit rate is generally much less than the wavelength modulation rate. Better efficiency is achieved by mul- tiplexing several SAN signals into a SONET/SDH-modulated wavelength. Transparent GFP (TGFP) allows transparent transport and multiplexing of 8B/10B clients such as Fibre Channel, ESCON, FICON, and DVB-ASI (digital video), as mentioned earlier. Transparency means that wireless data and clock rate received at the TGFP ingress node can be recovered at the egress node over a SONET/SDH network. TGFP can be seen as a kind of sublambda technique for 8B/10B interfaces over SONET/SDH (see Fig. 16-7). 3 An additional benefit of this solution is that TGFP provides 6.25 to 16.25 percent bandwidth reduction from the original 10B rate. Table 16-1 shows typical VC path capacity required for SAN client transparent transmission. 3 Finally, let’s look at why generic framing procedure (GFP) is a new standard that has been developed to overcome wireless data transport inefficiencies or deficiencies with the existing ATM and packet over SONET/SDH protocols. Transparent GFP is an extension to GFP devel- Chapter 16: Packet-over-SONET/SDH Specification oped to provide efficient low-latency support for high-speed WAN appli- cations including storage-area networks. Rather than handle wireless data on a frame-by-frame (packet-by-packet) basis, TGFP handles block- coded (8B/10B) character streams. The next part of the chapter describes the GFP protocol along with technical considerations and applications for transparent GFP. Transparent Generic Framing Procedure Several important high-speed LAN protocols use a Layer 1 block code in order to communicate both wireless data and control information. The most common block code is the 8B/10B line code used for Gigabit Ethernet, 395 Data center A Data center A Data center B Data center B WDM conv WDM conv WDM conv WDM conv WDM conv WDM conv TGFP ingress TGFP egress Conventional method 1 wavelength 1 wavelength 1 wavelength 1 wavelength 8B/10B clients over TGFP over SONET/SDH SONET/SDH Fibre Channel ESCON GbE Fibre Channel ESCON GbE Fibre Channel ESCON GbE Fibre Channel ESCON GbE Figure 16-7 Application of TGFP. Protocol 10B-Based Rate, Mbps 8B-Based Rate, Mbps VC Path Size ESCON 200 160 STS-1-4v DVB-ASI 270 216 STS-3c-2v Fibre Channel, 1062.5 850 STS-3c-6v FICON GbE 1250 1000 STS-3c-7v Infiniband 2500 2000 STS-3c-14v TABLE 16-1 Bandwidth Reduction by Use of TGFP 396 Part 3: Installing and Deploying Data Networks ESCON, SBCON, Fibre Channel, FICON, and Infiniband, which have become increasingly important with the growing popularity of storage- area networks (SANs). Since both client wireless data bytes and data source-to-sink control information are encoded into the 8B/10B codes, efficient transport of these protocols through a public transport network such as synchronous optical network/synchronous digital hierarchy (SONET/SDH) or the optical transport network (OTN) requires trans- porting both the wireless data and the 8B/10B control code information. The 8B/10B coding, however, adds a 25 percent wireless data bandwidth expansion that is undesirable in the transport network. The previously available protocols for LAN transport through SONET/ SDH networks were asynchronous transfer mode (ATM) and packet over SONET/SDH (POS). ATM is relatively inefficient from a bandwidth uti- lization standpoint and typically requires a much more complex adaptation process than GFP. POS requires terminating the client signal’s Layer 2 pro- tocol and remapping the signal into Point-to-Point Protocol (PPP) over HDLC, which suffers from a nondeterministic bandwidth expansion dis- cussed previously on bandwidth considerations. Also, neither ATM nor POS supports the transparent transport of the 8B/10B control characters. In order to overcome the shortcomings of ATM and POS, GFP standardiza- tion began in the American National Standards Institute (ANSI) accredited T1X1 subcommittee, which chose to work with the International Telecom- munication Union—Telecommunication Standardization Sector (ITU-T) on the final version of the standard, which has been published by the ITU-T. The transparent version of GFP has been optimized for transparently car- rying block-coded client signals (both the data and the 8B/10B control codes) with minimal latency. This part of the chapter begins with a description of the transparent GFP protocol, followed by some special con- siderations such as bandwidth, error control, and client management. Potential extensions to the transparent GFP protocol are then also briefly discussed. Transparent GFP Description: General GFP Overview The basic GFP frame structure is shown in Fig. 16-8. 4 Protocols such as HDLC that rely on specific wireless data patterns for frame delimiting or control information require a nondeterministic amount of bandwidth because of the need for additional escape bits or characters adjacent to the payload strings or bytes that mimic these reserved characters. The amount of expansion is thus data pattern–dependent. In the extreme case, if the client payload data consist entirely of data emulating these reserved characters, byte-stuffed HDLC protocols like POS require nearly twice the Chapter 16: Packet-over-SONET/SDH Specification bandwidth to transmit the packet than if the payload did not contain such characters. GFP avoids this problem by using information in its core header for frame delimitation. Specifically, the GFP core header consists of a two- octet-long field that specifies the length of the GFP frame’s payload area in octets, and a cyclic redundancy check (CRC-16) error check code over this length field. The framer looks for a 32-bit pattern that has the proper zero CRC remainder and then confirms that this is the correct frame alignment by verifying that another valid 32-bit sequence exists immediately after the current frame ends, as specified by the length field. Since no special characters are used for framing, there are no forbidden payload values that require escape characters. NOTE CRC-16 also provides robustness by allowing single error correction on the core header once frame alignment has been acquired. In frame-mapped GFP (GFP-F), a single client data frame [an IP packet or Ethernet medium access control (MAC) frame] is mapped into a single GFP frame. For transparent GFP, however, a fixed number of client charac- ters are mapped into a GFP frame of predetermined length. Hence, the payload length is typically variable for frame-mapped GFP and static for transparent GFP. One of the primary advantages of TGFP over GFP-F is that TGFP supports the transparent transport of 8B/10B control characters as well as wireless data characters. In addition, GFP-F typically incurs the 397 Core header Payload area 16-bit payload length indicator cHEC (CRC-16) Client payload field Payload headers (4-64 bytes) Type (4 bytes) Extension (0-60 bytes) Optional payload FCS (CRC-32) Figure 16-8 GFP frame format. 398 Part 3: Installing and Deploying Data Networks latency associated with buffering an entire client data frame at the ingress to the GFP mapper. As discussed next, TGFP requires only a few bytes of mapper/demapper latency. This lower latency is a critical issue for SAN protocols, which are very sensitive to transmission delay. NOTE GFP-F is best suited to applications where latency is less impor- tant than bandwidth efficiency. For example, if the client signal is lightly loaded, GFP-F allows mapping the packets into a smaller transport chan- nel or potentially frame multiplexing them into a shared channel with GFP frames from other client signals. Alternatively, GFP-F could make use of the link capacity adjustment scheme (G.7042) for handling client signals that experience temporary changes to their required bandwidth. Transparent GFP 64B/65B Block Coding The 8B/10B line code maps the 2 8 ϭ 256 possible data values into the 2 10 ϭ 1024 value 10-bit code space such that the running number of ones and zeros transmitted on the line (the running disparity) remains bal- anced over very short intervals. Twelve of the 10-bit codes are reserved for use as control codes that may be used by the wireless data source to signal control information to the wireless data sink. The first step of TGFP encoding in the source adaptation process is to decode the client 8B/10B codes into control codes and 8-bit data values. Eight of these decoded characters are then mapped into the 8 payload bytes of a 64B/65B code. The leading (flag) bit of the 64B/65B code indicates whether there are any control codes present in that 64B/65B code (with flag ϭ 1 indicating the presence of a control code). The 64B/65B block structure for various numbers of control codes is illustrated in Fig. 16-9. 4 Control codes are placed in the leading bytes of the 64B/65B block as illustrated in Fig. 16-9. A control code byte consists of a bit to indicate whether this byte contains the last control code in that 64B/65B block (ϭ 0 if it is the last), a 3-bit address (aaa−hhh) indicating the original location of that control code in the wireless client data stream relative to the other characters mapped into that 64B/65B block, and a 4-bit code (Cn) representing the control code. Since there are only 12 defined 8B/10B control codes, 4 bits are adequate to represent them. One of the remaining 4-bit codes is used to communicate that an illegal 8B/10B character has been received by the GFP source adaptation process so that the GFP receiver can output an equivalent illegal 8B/10B character to the client signal sink. Figure 16-10 illustrates mapping of control and wireless data octets in the 64B/65B block. 4 Aligning the 64B/65B payload bytes with the SONET/SDH/OTN pay- load bytes simplifies parallel wireless data path implementations, in 399 Input client characters Flag bit Octet 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 D1 0 All data D2 D3 D4 D5 D6 D7 D8 0 aaa C11 7 data, 1 control D1 D2 D3 D4 D5 D6 D7 1 aaa C1 1 6 data, 2 control 0 bbb C2 D1 D2 D3 D4 D5 D6 1 aaa C1 1 5 data, 3 control 1 bbb C2 0 ccc C3 D1 D2 D3 D4 D5 1 aaa C11 4 data, 4 control 1 bbb C2 1 ccc C3 0 ddd C4 D1 D2 D3 D4 1 aaa C1 1 3 data, 5 control 1 bbb C2 1 ccc C3 1 ddd C4 0 eee C5 D1 D2 D3 1 aaa C11 2 data, 6 control 1 bbb C2 1 ccc C3 1 ddd C4 1 eee C5 0 fff C6 D1 D2 1 aaa C1 1 1 data, 7 control 1 bbb C2 1 ccc C3 1 ddd C4 1 eee C5 1 fff C6 0 ggg C7 D1 1 aaa C1 1 8 data 1 bbb C2 1 ccc C3 1 ddd C4 1 eee C5 1 fff C6 1 ggg C7 0 hhh C8 64-bit (8-octet) field Legend: – Leading bit in a control octet (LCC) = 1 if there are more control octets and = 0 if this pa yload octet contains the last control octet in that block – aaa = 3-bit representation of the first control code’s or iginal position (first control code locator) – bbb = 3-bit representation of the second control code’ s original position (second control code locator) . . . – hhh = 3-bit representation of the eighth control codes or iginal position (eighth control code locator) –Ci = 4-bit representation of the i th control code (control code indicator) –Di = 8-bit representation of the i th data value in order of transmission Figure 16-9 The 64B/65B block code structure. 400 Part 3: Installing and Deploying Data Networks addition to increasing the payload data observability within the SONET/SDH stream. In order to achieve this alignment, a group of eight 64B/65B codes are combined into a superblock. The superblock structure, as shown in Fig. 16-11, takes the leading flag bits of the eight constituent 64B/65B codes and groups them into a trailing byte followed by a CRC-16 over the bits of that superblock. 4 CRC-16 is discussed fur- ther in the section “Error Control Considerations,” below. Transport Bandwidth Considerations TGFP channel sizes are chosen to accommodate the wireless client data stream under worst-case clock tolerance conditions (for the slowest end of the transport clock and fastest end of the client clock tolerance). In the case of SONET/SDH, while TGFP can be carried over contiguously con- catenated channels, it will typically be carried over virtually concatenated signals. The concept of virtual concatenation is one in which multiple SONET synchronous payload envelopes (SPEs) are grouped together with SDH virtual containers (VCs) to form a higher-bandwidth pipe between the endpoints of the virtually concatenated path. Octet # 000 D1 001 K1 010 D2 011 D3 100 D4 101 K2 110 D5 111 D6 Client byte stream Octet # 000 1.001.C1 L 1 001 0.101.C2 010 D1 011 D2 100 D3 101 D4 110 D5 111 D6 65B code stream Octet # 000 D1 001 K1 010 D2 011 Buffer underflow 100 D3 101 K2 110 D4 111 D5 Client byte stream Octet # 000 1.001.C1 L 1 001 0.011.P1 010 0.101.C2 011 D1 100 D2 101 D3 110 D4 111 D5 65B code stream D = Client data byte K = Control character L = Leading 64B/65B bit P = 65B_PAD character (a) (b) Figure 16-10 Examples of mapping a client byte stream into a 64B/65B block: (a) with con- trol and wireless data bytes; (b) including 65B_PAD insertion. [...]... M = 4 and M 0.2 M =8 M = 16 ជ∞ 0.1 1 1 10 100 1000 C (Mbps/sector) WirelessMAN: Air Interface for Broadband Wireless Access IEEE Standard 80 2.16-2001, completed in October 2001 and published on April 8, 2002, defines the WirelessMAN air interface specification for wireless data metropolitan-area networks (MANs) The completion of this standard heralds the entry of broadband wireless data access as a major... self-synchronous scrambler Data in Data out Dn D2 xn + 1 scrambler D1 Data in Data out D1 D2 Dn xn + 1 descrambler 406 Part 3: Installing and Deploying Data Networks Transparent GFP Client Management Frames CMFs have the same structure as GFP wireless client data frames, but are denoted by the payload type code PTI ϭ 100 in the GFP payload header Like GFP wireless client data frames, CMFs have a core... and Implementation, CRC Press, 2002 17 Wireless Data CHAPTER Access Implementation Methods Copyright 2003 by The McGraw- Hill Companies, Inc Click Here for Terms of Use 410 Part 3: Installing and Deploying Data Networks The explosive growth of both the wireless industry and the Internet is creating a huge market opportunity for the implementation of wireless data access methods Limited Internet access,... contain increasing values (which would always be the case for a legal block) Wireless data erroneously converted into control codes could cause the truncation of a wireless client data frame, which in turn can cause error detection problems for the wireless client data, since there is a possibility of the truncated wireless client data frame appearing to have a correct CRC value A similar situation occurs... with WirelessMAN technology bringing the network to a building, users inside the building will connect to it with conventional in-building networks such as, for data, Ethernet (IEEE Standard 420 Part 3: Installing and Deploying Data Networks 80 2.3) or wireless data LANs (IEEE Standard 80 2.11) However, the fundamental design of the standard may eventually allow for the efficient extension of the WirelessMAN... concentrate large amounts of capacity at very localized spots Thus, in the age of wireless data, user data rate surges again as an important metric Because of the logarithmic relationship between the capacity of a wireless data link and the signal-to-interference-and-noise ratio (SINR) at the receiver, trying to increase the wireless data rate by simply transmitting more power is extremely costly Furthermore,... Communications Magazine, 445 Hoes Lane, Piscataway, NJ 088 55, 2002 4 Steven S Gorshe and Trevor Wilson, “Transparent Generic Framing Procedure (GFP): A Protocol for Efficient Transport of Block-Coded Data through SONET/SDH Networks,” IEEE Communications Magazine, 445 Hoes Lane, Piscataway, NJ 088 55, 2002 5 John R Vacca, i-mode Crash Course, McGraw- Hill, 2001 6 John R Vacca, High-Speed Cisco Networks:... currently defined through IEEE Standard 80 2.16, a wireless data MAN provides network access to buildings through exterior antennas communicating with central radio base stations (BSs) The wireless data MAN offers an alternative to cabled access networks, such as fiber-optic links, coaxial systems using cable modems, and digital subscriber line (DSL) links Because wireless data systems have the capacity to... fast data transfers In fact, as shown in this chapter, traditional wireless data technologies are not very well suited to meet the demanding requirements of providing very high data rates with the ubiquity, mobility, and portability characteristic of cellular systems Increased use of antenna arrays appears to be the only means of enabling the types of data rates and capacities needed for wireless data. .. enterprises The 80 2.16 Working Group Development of IEEE Standard 80 2.16 and the included WirelessMAN air interface, along with associated standards and amendments, is the responsibility of IEEE Working Group 80 2.16 on Broadband Wireless Access (BWA) Standards (http://WirelessMAN.org) The Working Group’s initial interest was the 10- to 66-GHz range The 2- to 11-GHz amendment project that led to IEEE 80 2.16a . (24 .8 Mbps) 6.76 Mbps Fibre Channel 85 0 Mbps STS-3c-6v /VC-4-6v 89 8.56 Mbps 13 4.12 kbps (85 .82 Mbps) 2.415 Mbps Gigabit Ethernet 1.0 Gbps STS-3c-7v /VC-4-7v 1.0 483 2 Gbps 95 281 kbps (1.1 38 Mbps). communicate both wireless data and control information. The most common block code is the 8B/10B line code used for Gigabit Ethernet, 395 Data center A Data center A Data center B Data center B WDM conv WDM conv WDM conv WDM conv WDM conv WDM conv TGFP ingress TGFP egress Conventional. network (OTN) requires trans- porting both the wireless data and the 8B/10B control code information. The 8B/10B coding, however, adds a 25 percent wireless data bandwidth expansion that is undesirable