Generic Mapping Procedure. White Paper

Transcription

1 White Paper

2 Introduction Recent enhancements to the OTN address the growing need to provide a transport layer for packet and data oriented networks. These enhancements have included defi nition of new rates in the OTN hierarchy like ODU0 for GbE and Fibre Channel-100, ODU2e for 10GbE and FC-1200, and ODU/OTU4 for 100GbE. In addition, ODUfl ex has been introduced for transport of Constant Bit Rate (CBR) clients with rates above 2.5Gbit/s and for GFP encapsulated packet fl ows. These new additions have resulted in client/server mapping scenarios that require more rate adaptation range than are addressed with the Asynchronous Mapping Procedure (AMP) or the Bit-synchronous Mapping Procedure (BMP). As a consequence, the Generic Mapping Procedure (GMP) has been defi ned to provide the ability to map any client signal into any server regardless of their rate differences, provided the server is faster. While similar in fundamental concepts to AMP, the specifi cs of GMP differ signifi cantly in both its stuffi ng algorithm and in its signalling. The mapping/multiplexing scenarios under which AMP or BMP were specifi ed remain unchanged, while GMP is specifi ed for the many new scenarios that require greater adaptation range. Mapping and Multiplexing In the OTN, an ODUk server may contain a single, non-otn client or it may contain multiple lower rate ODUjs. In the former case, a client is mapped into the entire server and in the latter the server payload is subdivided into tributary slots, and each lower rate ODUj is mapped into a Tributary Unit, or ODTU, that occupies one or more tributary slots. The ODTUs are then multiplexed into the higher rate ODUk. In both cases, the mapping procedure used must address any granularity and rate differences. Constant Bit Rate clients are transparently mapped into an ODUk and no explicit word delineation is required. Consequently, sets of consecutive bits of the client are mapped based on the word size of the server. When mapping lower rate ODUjs into ODTUs, however, sets of bytes of the ODUj are mapped into the same number of bytes of the ODTU. When a single client is mapped into an ODUk, two possibilities exist for rate adaptation. First, it is possible to lock the server rate to the client rate such that no explicit adaptation is required. Second, the server rate can be independent from the client rate requiring a mechanism that allows some server word locations to carry either data or stuff as necessary. In the case of ODUj to ODUk multiplexing, the ODTU rates are derived from the ODUk and so can not be locked to each individual ODUj. Thus, a rate adaptation mechanism is always required. Bit-synchronous Mapping Procedure The simplest mapping mechanism involves no rate adaptation and can be used if the server rate is explicitly derived from the client rate. This is the case for the BMP. When using BMP to map a client into ODUk, the server granularity is always one byte. Consequently, 8 consecutive bits of the client are placed in each payload byte of the server. Every server payload byte always carries client data. 2

3 Asynchronous Mapping Procedure As the name suggests, AMP is a mechanism that maps a client into a server when the two rates are asynchronous or independent. In these scenarios, both the client and server have equivalent nominal bit rates but each has some tolerance. As a result, it is possible for the client rate to be higher than the server or the server rate to be higher than the client in any given instance. To accommodate this, AMP has both negative and positive justifi cation capabilities. Figure 1 shows the details of CBR client mapping into OPUk (which is payload carrying portion of an ODUk server) with AMP. With the exception of the Positive Justifi cation Opportunity (PJO) byte at Row 4, Column 17, and some fi xed stuff columns in some cases, the entire OPUk Payload area is always populated with client data. Then, on a frame by frame basis, the Negative Justifi cation Opportunity (NJO) byte and the PJO byte may or may not be populated depending on the relative bit rates of the client and the OPUk. The nominal rate of the OPUk payload, including the PJO byte is equal to the nominal rate of the CBR client. Column Row RES JC1 RES JC2 RES JC3 PSI NJO PJO OPUk OH or NJO/PJO / Signalling OPUk Payload Figure 1: AMP Detail for CBR client to OPUk mapping When the client rate is slower than the OPUk payload rate, the NJO byte will never carry data and the PJO byte will periodically not carry data. When the client rate is greater than the OPUk payload rate, the PJO byte will always carry data and the NJO byte will periodically carry data. In each frame, the least signifi cant 2 bits of the Justifi cation Control bytes (JC1, 2, 3) indicate the usage of NJO and PJO for that frame. It is also possible that the client and server are at exactly the same rate when using AMP. When this occurs, the PJO byte will always carry data and the NJO byte will never carry data. This corresponds exactly to the server payload usage with BMP mapping. To be compatible with AMP and to enable a single demapper to be used for either procedure, the JC1/2/3 byte positions, while not required to signal anything in BMP, are permanently set to the AMP values that signals data in PJO and stuff in NJO. The use of NJO and PJO bytes accommodates a modest rate tolerance between the CBR client and the ODUk server payload. For SDH clients, the rate tolerance is ±20ppm and the rate tolerance for the ODUk is also ±20ppm which is within the justifi cation range of AMP. 3

4 AMP is also used for lower rate ODUj to higher rate ODUk Multiplexing for some combinations of ODUj/k (e.g. ODU1 into ODU2 or ODU3). In these cases, there are actually two PJO bytes due to the nominal rate differences, but the purpose is still to manage a ±20ppm client into a ±20ppm server where the nominal rates are very close. Evolution of GMP With the defi nition of ODU4 as the 100G server for 100GE and lower rate ODU clients, and ODUfl ex as an any rate client into servers greater than 10G, nominal client rates are no longer always close to that of their server. In addition, new CBR clients that are not close to 1.25 or 2.5 Gbit/s like STM-4 and FC-200 have been defi ned to be mapped into ODU0 and ODU1. These new characteristics require an adaptation mechanism with many possible stuff bytes per server payload frame to accommodate both the rate differences and wider client bit rate tolerances of up to ±100ppm for some new clients. Two proposals were advanced within the ITU for a mapping procedure that would satisfy these requirements. One was an adaptation of AMP and one was a new mechanism that utilizes a fl exible data/ stuff distribution algorithm. The AMP based proposal built on the approach used for mapping STM-64 into OPU2 and STM-256 into OPU3 where fi xed stuff columns are used to reduce the OPUk payload to a rate close to the client rate. To support this for any possible client/server pair, the number and location of fi xed stuff columns are determined based on a simple algorithm. Then, the fi ner adaptation adjustments to accommodate bit rate tolerances are managed with an AMP mechanism using up to 7 Justifi cation Opportunity bytes. As with AMP, the use of these bytes each frame are signalled in the JC1/2/3 bytes. The other proposal took a different approach with the goal of achieving the best possible distribution of data and stuff throughout the server frame. In this case, any payload word can be data or stuff depending on the overall ratio of data to payload. A formula based on the current payload position, the total number of client data words and the total number of payload words determines whether each payload position is populated with client data or stuff. To perform this calculation at the demapper, the client data word count must be signalled rather than just the usage of predefi ned justifi cation locations. The latter proposal, using a Sigma/Delta algorithm for data/stuff distribution, was ultimately adopted by the ITU as the Generic Mapping Procedure due to its perceived fl exibility and superior client jitter performance. GMP Details The formula governing the Sigma/Delta algorithm is as follows; Content of each Payload position is : if (Payload position x data byte count) mod (P Server ) < data word count : if (Payload position x data byte count) mod (P Server ) data word count PServer = total # of word positions in server frame payload Payload word position = 1..P Server In each case of mapping, P Server is always known and fi xed. Similarly, the Payload position being evaluated is also inherently known. The fi nal variable, the data word count, changes from frame to frame to match the rate of the client being mapped. For each frame, the appropriate count is determined by the mapper and signalled in the OPUk overhead to the demapper using the JC1/2/3 bytes. The count being signalled is 14 bits, to support the payload bytes in an OPUk frame, and spans both JC1 and JC2. To ensure robustness at the receiver in the presence of bit errors, JC3 contains a CRC-8 which allows 4

5 error detection and certain amount of error correction. There is also an encoding for count increments or decrements and a state machine at the receiver is used to manage the values received and protect against bit errors. It is important to note that the demapper requires the count before the fi rst payload position occurs, so it has to be determined and signalled in the previous frame. Figure 2 shows an example of the data/stuff distribution achieved by the Sigma/Delta algorithm where the word size is one byte. Over any continuous set of payload words, the ratio of data to stuff is the same as it is over the entire frame. Column Row JC4 JC1 2 JC5 JC2 3 JC6 JC3 4 PSI RES Remainder OPUk OH word count (for next frame) OPUk Payload Figure 2: Sigma/Delta based GMP Also shown in this diagram is the usage of the OPUk overhead bytes. As mentioned, JC1/2/3 carries the count of data words, which is actually for the next frame. In addition, to meet jitter requirements for some mappings, an indication of the partial word remainder of client data not mapped is required. This is provided as another count in JC4/5/6, but at a granularity less than the word size. For example, STM-4 is mapped into OPU0 with a word size of 8 bits, so the count in JC1/2/3 is a byte count. Then, the granularity required for the remainder is 1 bit, so the remainder count in JC4/5/6 is a bit count in the range of 0 to 7. The word size used for GMP is based on the server being used. The lowest granularity of 8 bits is used when mapping a non-otn client into a 1.25Gbit/s OPU0 or multiplexing an ODU0 into a single 1.25Gbit/s Tributary Slot of a higher speed OPUk (k=2,3,4). For larger OPUk servers, the mapping granularity is essentially 8 bits per 1.25Gbit/s of server rate. When mapping 100GE into OPU4, a 640 bit granularity is used. This is intended to align with wider data buses used in silicon for higher data rate solutions. Conclusion The recent enhancements to OTN to provide effi cient data transport have outstripped the ability of AMP to provide a suitably fl exible mapping mechanism. AMP and BMP retain their existing roles, but GMP has been introduced to handle the new combinations of client and server rates. With its ability to handle any client rate into any server rate, GMP also promises to support clients and servers yet to be defi ned. 5

6 Notice EXAR Corporation reserves the right to make changes to the products contained in this publication in order to improve design, performance or reliability. EXAR Corporation assumes no responsibility for the use of any circuits described herein, conveys no license under any patent or other right, and makes no representation that the circuits are free of patent infringement. Charts and schedules contained here in are only for illustration purposes and may vary depending upon a user s specifi c application. While the information in this publication has been carefully checked; no responsibility, however, is assumed for inaccuracies. EXAR Corporation does not recommend the use of any of its products in life support applications where the failure or malfunction of the product can reasonably be expected to cause failure of the life support system or to signifi cantly affect its safety or effectiveness. Products are not authorized for use in such applications unless EXAR Corporation receives, in writing, assurances to its satisfaction that: (a) the risk of injury or damage has been minimized; (b) the user assumes all such risks; (c) potential liability of EXAR Corporation is adequately protected under the circumstances. Copyright 2011 EXAR Corporation White Paper: September 2011 Reproduction, in part or whole, without the prior written consent of EXAR Corporation is prohibited.