SDH Next Generation

by José M. Caballero
Many carriers are embracing SDH Next Generation because it answers the challenge of transporting data efficiently, without needing to replace the installed equipment base. The only change needed to update the network is to replace the edge nodes.The network is then ready to transport Ethernet, PPP, DVB or SAN frames efficiently using Generic Framing Protocol (GFP), Virtual Concatenation (VCAT) and Link Capacity Adjustment Scheme (LCAS).

International Marketing Dpt.

VCAT, LCAS & GFC

VictoriaCombo NG 2.5G

2

SDH/SONET Next Generation

Table of Contents
1.1 Streaming forces 3 1.2 Legacy and Next Generation SDH 1.3 SDH Services 6 1.3.1 Legacy SDH 6 1.3.1.1 PDH/T-carrier over SDH 6 1.3.1.2 ATM over SDH 7 1.3.1.3 Mapping HDLC-framed signals 8 1.3.1.4 Packet over SDH 8 1.3.2 Next Generation SDH 9 1.4 SDH protocols 10 1.4.1 Path Overhead 10 1.5 Generic Framing Protocol 14 1.5.1 Framed-mapped GFP 16 1.5.2 Transparent GFP 16 1.5.3 GFP in depth 17 1.6 Concatenation 18 1.6.1 Contiguous Concatenation of VC-4 19 1.6.2 Virtual Concatenation 20 1.6.2.1 Higher Order Virtual Concatenation 21 1.6.2.2 Lower Order Virtual Concatenation 23 1.6.3 Testing VCAT 23 1.7 Link Capacity Adjustment Scheme 1.7.1 LCAS applications 26 1.7.1.1 Bandwidth allocation 26 1.7.1.2 Asymmetric configurations 26 1.7.1.3 Network resilience 27 1.7.1.4 Cross-domain operation 27 1.7.2 LCAS protocol 27 1.7.3 LCAS verification 28 26 4

SDH/SONET Next Generation

3

SDH/SONET Next Generation

1.1 STREAMING FORCES The financial and technological cycle of the telecomms industry is forcing manufacturers, carriers, operators and standards organisations to move towards a new network that reduces costs whilst expanding services. The new applications, mostly relying on data packet technology, offer easy implementation and access to applications based on the Internet, Mobile, Multimedia, DVB, SAN, Ethernet or VPN. The architectures are increasingly demanding long haul transport that today can only be provided by SDH/SONET. These technologies have a massive installed base, developed over recent decades. SDH/SONET have now evolved, and are ready to adapt to the new traffic requirements.

PDH Ethernet VPN DVB SAN

MSSP

SDH NG

MSSP

PDH Ethernet VPN DVB SAN

GFC

Mapping in Frames Virtual Containers Transport Bandwidth management Paths, Sections SDH SDH Paths, Sections

GFC VCAT LCAS SDH

Layers Clients

VCAT LCAS SDH

SDH NG

Existing SDH/SONET

SDH NG

Clients

Figure 1.1 Figure 1.1

Next Generation SDH enables operators to provide more data transport services Next increasing SDH enable of installed SDH/SONET base, by adding just the while Generationthe efficiencyoperators to provide new MSSP edge nodes. This means that it will not be necessary to install an overlap network or migrating all the nodes or fiber optics. This reduces the cost per bit delivered, and will attract new customers while keeping legacy services.

4

SDH/SONET Next Generation

1.2 LEGACY AND NEXT GENERATION SDH Telecomms service providers are ready to move Ethernet/IP services from the enterprise to the metropolitan network. On the other hand the Ethernet/IP combination can also gain the long-haul transport advantages of SDH/SONET including resiliency, reliability, scalability, built-in protection, management and rerouting. Next Generation SDH/SONET is offering more than this. Its new nodes, sometime known as Multiservice Provisioning Platforms (MSPP), can offer a combination of data interfaces such as Ethernet, 8B/10B, MPLS or RPR, without removing those for SDH/PDH. In addition, in order to make data transport more efficient, SDH/SONET has adopted a new set of protocols that are being installed on the MSPP nodes. These nodes can be interconnected with the old equipment that is still running.
FRL Services ISDN
xDSL Circuit

Mobile 3G

VoD

VPLS VPN

Telepho

VoIP

Internet

TV SAN

IP
DVB

Protocols

PDH ATM

MPLS

VLAN

10/100/1000 Ethernet HDLC/PPP/LAPS
GFP-F GFP-T

Fibre Channel ESCON FICON

SDH

Contiguous Concatenation
SDH/SONET NG

Virtual Concatenation LCAS

Media

WDM - Dark Fiber - Coax - Wireless - OTN

Figure 1.2

Versatile, flexible and efficient SDH Next Generation

SDH/SONET Next Generation

5

Most of the carriers and operators have been using SDH for several decades, mainly to transport voice and circuit oriented data protocols. Since then, the challenge has always been connectionless data transport. Despite a number of architectures developed to do this (PoS, ATM, etc) none of them were widely accepted by the market. Sometimes it was because of the cost, sometimes the complexity, and sometimes poor efficiency. The drive to SDH Next Generation development was, first, the desire to find one simple encapsulation method that was capable of accommodating any data packet protocols and, secondly, the need to use bandwidth accurately. This meant that a new adaptation protocol layer was required and a new mapping mechanism for controlling bandwidth use. The mechanism must do all of this and keep the reliable SDH transport and its centralised managent.
40 Gbps 10 Gbps 2.5 Gbps 622 Mbps 155 Mbps STM-256 OC-768 STM-64 OC-192 STM-16 OC-48 STM-4 OC-12 STM-1 OC-3/STS-3
x1 AUG-256

STS-768

x1 AU4-256c

STS-768c
x1 AU4-64c

VC4-256c STS-768c SPE VC4-64c STS-192c SPE VC4-16c STS-48c SPE VC4-4c STS-12c SPE VC-4 STS-3c SPE

C-4-256c C-4-64c C-4-16c C-4-4c C-4
x3

AUG-64 STS-192
x4

STS-192c STS-48c

x1 x4 x1 x4 x1

AUG-16 STS-48 AUG-4 STS-12 AUG-1 STS-3

x1 AU4-16c x1

AU4-4c STS-12c AU-4 STS-3c

x1

x3

TUG-3 AU-3 STS-1 VC-3 STS-1 SPE
x7

x1

TU-3

VC-3 C-3

52 Mbps

STM-0 OC-1/STS-1

x1

x7

TUG-2 VT-Group

x1 x3 x4

TU-2 VT-6 TU-12 VT-2 TU-11 VT-1.5

VC-2 VT-6 SPE VC-12 VT-2 SPE VC-11 VT-1.5 SPE

C-2

C-12

Frame transmission Aligning Multiplexing Mapping

Pointer processing SDH Container Group POH addition

C-11

Figure 1.3

SDH and SONET Multiplexing map.

Client Data such as PDH, Ethernet, SAN, DVB, IP, HDLC, etc.

x1

x4

6

SDH/SONET Next Generation

1.3 SDH SERVICES Today’s telecommunications services are based on a diverse combination of technologies such as Ethernet, PDH, IP, SAN, etc (see Figure 1.2). Many of these technologies have always been clients of SDH and others can probably also be when they need to extend their service range to wider areas (see Figure 1.3). For example, channelized networks organised in 64-Kbps circuits (POTS, ISDN, FRL, GSM, FRL) are mapped transparently into SDH synchronous containers in a natural way because all of them (including SDH) are connection-oriented and require constant bit rates. More difficult, or at least more controversial, is data packet transport (Ethernet, IP, DVB, SAN). This is because by their nature they are connectionless, use statistical multiplexing, and can be best-effort technologies. This is the opposite of SDH which is predictable and based on time division multiplexing (TDM).
Table 1.1 Signals and information combinations. SDH STM-0 STM-1 STM-4 STM-16 STM-64 STM-256 SONET Frame STS-1 STS-3 STS-12 STS-48 STS-192 STS-768 SONET Optical OC-1 OC-3 OC-12 OC-48 OC-192 OC-768 Size (Bytes) Rate (Mbps) Acronym Capacity Samples 9x90 9x270 9x1080 9x4320 9x17280 9x69120 51.840 155.520 622.080 2488.320 9953.280 39814.120 52M 155M 622M 2.5G 10G 40G 28DS-1, DS-3, E3, 21E1 84DS-1, 3DS-3, E4, 3E3, 2E3+21E2, E3+42E2, 63E2 4OC-3, 4 STM-1 16OC-3, 16 STM-1 64OC-3, 64 STM-1 256OC-3, 256 STM-1

1.3.1 Legacy SDH PDH/T-carrier over SDH The classic SDH standards defined procedures to transport all circuits (E1, E2, E3, E4, T1, T2, and T3). This way, all former PDH/T-carrier services (ISDN or FRL) are today transported by hybrid PDH/SONET or T-carrier/SONET networks.

Synchronous mapping maintains the original 64-Kbps channel structure during the whole transmission, making it possible to access these channels directly, as bit justification is not needed. This is common in such services as ISDN or FRL, where there are nodes synchronized with the SDH reference clock. Small clock differences are adjusted with pointer movements. Asynchronous mapping is used when PDH and SDH do not share the same clock. Here we need bit-oriented justification to adjust any clock differences

SDH/SONET Next Generation

7

Table 1.2 VC types and capacity. SDH VC-11 VC-12 VC-2 VC-3 VC-4 VC-4-4c VC-4-16c VC-4-64c VC-4-256c SONET VT 1.5 SPE VT 2 SPE VT 6 SPE STS-1 SPE STS-3c SPE STS-12c SPE STS-48c SPE STS-192c SPE STS-768c SPE Bandwidth 1,664 Kbps 2,240 Kbps 6,848 Kbps 48,960 Kbps 150,336 Kbps 601,344 Kbps 2,405,376 Kbps 9,621,504 Kbps 38,486,016 Kbps Payload 1,600 Kbps 2,176 Kbps 6,784 Kbps 48,384 Kbps 149,760 Kbps 599,040 Kbps 2,396,160 Kbps 9,584,640 Kbps 38,338,560 Kbps

between the PDH signal and the SDH container. Due to this, the existing byte structure is lost. This scheme is rather common in POTS and in old plesiochronous circuits. ATM over SDH ATM cells are mapped into containers at different bit rates. The range goes from a few Mbps up to several Gbps, using any concatenation technique (see Section 1.6).
VC-4-Xc
1 J1 B3 C2 G1 F2 H4 F3 K3 9 N1 260X+10

VC-12
V1

V2 R ..... VC-n V3

53 bytes No. of columns = X-1 R = fixed stuff

V4

ATM cell

Figure 1.4

Mapping ATM cells in VC-n and concatenated VC-4-Xc.

ATM cells are mapped by aligning every cell with the structure of virtual or concatenated containers. Since capacity may not be an integer multiple of the ATM cell length (53 bytes), a cell is allowed to cross the container frame boundary (see Figure 1.4). The ATM cell information field (48 bytes) is scrambled before mapping, to guarantee delineation. An ATM cell stream with a data rate that can be mapped is equal to the VC payload capacity (see Table 1.2).

8

SDH/SONET Next Generation

Unfortunately ATM was not accepted by the market to be the solution to carry data protocols on SDH/SONET. Its inherent bandwidth inefficiency, high cost and complexity pushed ATM to specific market niches such as FRL transport, xDSL access and some military and scientific applications. In other words, ATM was accepted by a majority of manufacturers and operator to be as a good mechanism for the IP/Ethernet transport. Mapping HDLC-framed signals HDLC-framed signals are mapped by aligning the byte structure of every frame with the byte structure of the VC. The range also goes from 1.5 Mbps up to several Gbps using concatenation techniques (see Section 1.6). 7Ex HDLC flags are used between frames to fill the buffer, due to the discontinuous arrival of HDLC-framed signals. Since HDLC frames are of variable length, a frame may cross the container boundary.
VC-4-Xc
1 J1 B3 C2 G1 F2 H4 F3 K3 9 N1 IP IP PPP IP IP PPP IP PPP ..... 260X+10 PPP V1

V2 VC-n

R

PPP

IP

V3

‘7Ex‘framer
V4

Columns = X-1 R = fixed stuff

Figure 1.5

Mapping HDLC frames enables IP transport.

Packet over SDH Packet over SDH (PoS) enables core routers to send native IP packets directly over SDH container frames, using point to point protocol (PPP) for framing and bit error detection. The request for comments 2615 (RFC 2615) defines the use of PPP encapsulation over SDH circuits. IP traffic is treated as a serial data stream that travels hop by hop through the network. At each node, IP packets are unwrapped from the PPP frame, destination addresses are examined, routing paths are determined, and, finally, packets are re-wrapped in a new PPP frame and sent on their way (see Figure 1.5). PoS is more reliable and has lower overheads than its alternatives, such as ATM or frame relay encapsulation, but is less flexible and is more applicable to routers

SDH/SONET Next Generation

9

than edge transport. PoS is being shadowed by the emerging NG protocols and GFP in particular. 1.3.2 Next Generation SDH Ethernet, the standard technology for local area networks (LANs), is cheap, easy to use, well-known, and always evolving toward higher rates. Now it is also being considered as a good technology for access and metro networks. Carriers are looking at SDH for routing high volumes of Ethernet traffic to get long haul transport. To make this possible SDH has needed to match the bursty and connectionless nature of Ethernet using a number of protocols:

Generic framing procedure (GFP): defined in ITU-T Rec. G.7041. This is a protocol for mapping any type of data link service, including Ethernet, digital video broadcasting (DVB) and storage area networks1 (SAN). GFP, compared with other framing procedures such as Packet over SDH/SONET or X.86, has a a low overhead that requires less processing analysis. Virtual concatenation (VCAT): defined in ITU-T Rec. G.707, creates right-sized pipes for the traffic, providing some flexibility and high compatibility with legacy SDH installation techniques (see Section 1.6). Link capacity adjustment scheme (LCAS): defined in ITU-T Rec. G.7042, allocates or de-allocates bandwidth units to match data transport requirements, or to implement additional resiliency between two transport point. VCAT can be used without LCAS, but LCAS requires VCAT (see Section 1.7). Ethernet over LAPS: defined in ITU-T X.86. This is an HDLC family protocol, including performance monitoring, remote fault indication, and flow control. However, it calls for contiguous concatenated bandwidth techniques (see Section 1.6) that do not match the bursty nature of Ethernet.

• •

These functions are implemented on the new MSSP nodes which are located at the edges of the network. They interact with the client data packets that are aggregated over the SDH/SONET backplane that continues unchanged. This means that the MSSPs represent the SDH Next Generation embedded in the legacy SDH network.

1.

SAN, as a generic acronym, can include ESCON, FICON and Fiber Channel as well.

10

SDH/SONET Next Generation

1.4 SDH PROTOCOLS The key SDH/SONET feature, when compared with its plesiochronous predecessors, is in the management and monitoring capabilities SDH provides at the transmission layer. These features are based on peer protocols, standardized formats, and overhead fields. Network elements themselves generate a suitable response to management actions, reconfigurations, performance monitoring, failures, or any type of events. Overheads are also a key difference between SDH and its potential successors, based on any combination of gigabit-Ethernet (GbE), dense wavelength division multiplexed (DWDM), and IP protocols. These networks are always said to be more efficient, because they do not support most of these management facilities and, eventually, will not need overheads or protocols to support them. 1.4.1 Path Overhead The POH provides a communication protocol between the two ends of a VC path. Among these protocols are path performance monitoring, error and alarm indications, path protection, signals for maintenance purposes, and multiplex structure indications. There are two categories of virtual container POH (see Figure 1.6): 1. Four-byte path overhead, or VT POH in SONET: This structure is added to C-2, C-12, and C-11 to form a VC-2, VC-12, and VC-11 respectively. The four bytes are not just contiguous, but also part of a multiframe (see Figure 1.6). Nine-byte path overhead, or STS POH in SONET: When this structure is attached to C-4 or TUG-3, it creates a VC-4. It can also be attached to C-3 or TUG-2, in which case it creates a VC-3 (see Figure 1.6) .
Table 1.3 Four-byte path overhead for VC-11, VC-12, VC-2, VC-2-Xc, VT-11, VT-12, and VT-6. Byte V5 Description LP general overhead: Its position is indicated by the TU-n pointer, and it provides path status, performance monitoring, and signal label functions for VC-2, VC-12, and VC-11 paths. This byte enables continuous monitoring of anomalies and defects, and payload composition either at path end or at any point along the trail. LP bit error monitoring: A BIP-2 is calculated by the transmitter over all the bits of the previous VC-n. The calculation includes POH bytes, but excludes V1, V2, V3 (except when used for negative justification), and V4. LP remote error indication (LP-REI): This is set to 1 and sent back toward an LP originator, if one or more bit errors is detected by the BIP-2. LP remote failure indication (LP-RFI), only VC-11: This is set to 1 and sent back if a failure is declared. Otherwise it is cleared (i.e., set to 0).

2.

V5(bit1-2)

V5(bit3) V5(bit4)

SDH/SONET Next Generation

11

Table 1.3 Four-byte path overhead for VC-11, VC-12, VC-2, VC-2-Xc, VT-11, VT-12, and VT-6. Byte Description

V5(bit5-7) LP signal label: This indicates the payload composition. 0x: Unequipped, 1x: Reserved, 2x: Asynchronous, 3x: Bit-synchronous, 4x: Byte-synchronous, 5x: Extended signal label, see K4 bit 1, 6x: Test signal, O.181, 7x: VC-AIS. V5(bit8) LP remote defect indication (LP-RDI): This is set to 1 and sent back towards the trail termination source if a failure condition is detected. J2 LP trace: It carries on a configurable 16 sequence identifier (including a CRC-7 byte) so that the receiving path terminal could continuously verify its connection with the transmitter. N2 LP tandem connection monitoring function (LP-TCM): Bits 1-2: BIP-2 for TC bit error checking; bit 3: fixed to 1, bit 4: incoming AIS indicator (I-AIS), bit 5: indicates errored blocks (TC-REI), bit 6: OEI to indicate errored blocks, bits 7-8: operate as a 76-multiframe string, including access point identifier (TC-APId), TC-RDI, and ODI. K4(bit1) Extended signal label (if V5(bit5-7) are 5x): This is a 32-bit multiframed string. Bits 12 to 19 contain the label. 09x: ATM mapping, 0Ax: HDLC/PPP mapping, 0Bx: HDLC/ LAPS mapping, 0Cx: test signal O.181 mapping, 0Dx: flexible topology data link mapping. LP virtual concatenation: A 32-bit multiframed string (see Figure 1.14). K4(bit2) K4(bit3-4) LP automatic protection switching channel (APS). K4(bit5-7) LP enhanced remote defect indication: Provides enhanced RDI information. 1x: no defect, 2x: payload defect (LP-PLM; loss of cell delineation or LCD), 5x server defects (LP-AIS, TU-LP), 6x: connectivity defects (LP-TIM, LP-UNEQ). K4(bit8) LP data link.

The functionality of the nine-byte POH (see Table 1.4) and the four-byte POH (see Table 1.3) are very similar.

12

SDH/SONET Next Generation

Nine-byte Path Overhead (POH)
SDH SONET

G1:

REI

RDI

E-RDI

Spare

J1 B3 C2 G1 F2 H4 F3 K3 N1 C2:

J1 B3 C2 G1 F2 H4 F3 Z3 Z4

Path trace, message with CRC BIP-8 parity control Signal label (mapping) Path status Path user channel (voice or data) Position and sequence indicator Path user channel (voice or data) Automatic Protection Switch Tandem Connection Monitoring

REI (Remote Error Indication) BIP-8 violation count RDI (Remote Defect Indication) is sent back E-RDI (Enhanced RDI information) (RDI=0) 10: Payload defect (PLM) (RDI=1) 01: Server defect (AIS, LOP), (RDI=1) 10: Connectivity defect (TIM, UNEQ)

N1: Z4:

IEC

TC REI OEI

multiframe TC-API, TC-RDI ODI, reserved

IEC Incoming Error Count, BIP-8 errors in Tandem Conn. TC-REI: Remote Error Indication in a TC subnetwork OEI: Outgoing Error Indication Multiframe: TC-API (Access Point Identifier) (76 frames) TC-RDI (RDI in Tandem Connection) ODI (Outgoing Defect Indication)

H4:
00: Unequipped 01: Reserved 02: TUG 03: Locked TU 04: E3, T3 12: E4 13: ATM 14: DQDB 15: FDDI 16: HDLC/PPP 17: SDL 18: HDLS/LAPS 1A: 10GbEthernet FE: Test Signal

x

x

1

1

x

x

LO Seq

LO Multiframe Sequence xx11xx00: pointer to V1 xx11xx01: pointer to V2 xx11xx10: pointer to V3 xx11xx11: pointer to V4

H4:

MFI2 (frames 0 and 1) Multiframe Indicator 1 SQ (frames 14 and 15) VC-3/4-Xv sequence bit 5-8: MFI1 multiframe indicator (0 to 15) frame 0 bit 1-4 MFI2 MSB Multiframe Indicator 2 frame 1 bit 1-4 MFI2 LSB frame 14 bit 1-4 SQ MSB sequence indicator frame 15 bit 1-4 SQ LSB sequence indicator

K3: Z3:

APS

HODL

Spare

APS: Automatic Protection HODL: Higher Order Data Link

Four-byte Path Overhead (POH)
V5 SDH SONET

V5:

BIP-2

REI

RFI

Signal Label

RDI

V5 J2 N2 K4

V5 J2 Z6 Z7

Path Overhead Path Trace Reserved or TCM Additional Path Overhead

J2 500µs

N2

K4

BIP-2 bit 1: Odd bit parity of the previous VC bit 2: Even bit parity REI (Receive Error Indication) RFI (Remote Failure Indication) VC signal label (mapping) 000 - Unequipped 001 - Reserved 010 - Asynchronous floating 011 - Bit synchronous 100 - Byte synchronous 101 - Extended signal label 110 - Test Signal O.181 111 - VC- AIS RDI (Remote Defect Indication) ESL VC APS E-RDI DL

K4: Z7: N2: Z6:
BIP-2 1
I-AIS TC OEI REI multiframe TC-API, TC-RDI ODI, reserved

BIP2 for Tandem Connection calculated over the VC I-AIS: Incoming AIS TC-REI: Remote Indication Error in a TC subnetwork OEI (Outgoing Error Indication) Multiframe: TC-API (Access Point Identifier) (76 frames) TC-RDI (RDI in Tandem Connection) ODI (Outgoing Defect Indication)

ESL (Extended Signal Label) 32 bits multiframe bits 1-11 Multiframe Alignment bits12-19: 09: ATM 0A: HDLC/PPP 0B: HDLC/LAPS 0C: Concatenated test signal bits 20-32: 0 (reserved for future) VC (Lower Order Virtual Concatenation) APS: Automatic Protection Switching channel E-RDI (Enhanced RDI information) (RDI=0) 010: Payload defect (PLM) (RDI=1) 101: Server defect (AIS, LOP), (RDI=1) 110: Connectivity defect (TIM, UNEQ) DL: Lower Order Data Link

Figure 1.6

Nine-byte path overhead is attached to VC3, VC4, and VC4-Xc. Four-byte path overhead is attached to VC11, VC12, and VC2.

SDH/SONET Next Generation

13

Table 1.4 Nine-byte path overhead for VC-3, VC4, VC-4-Xc, STS-1 SPE, and STS-Xc SPE. Byte J1 Description HP trace: Its position is indicated by the AU-n or the TU-3 pointer. It carries a configurable sequence identifier of 16 or 64 bytes (including a CRC-7 byte), so that the receiving path terminal can continuously verify its connection with the transmitter. HP error monitoring: This is a bit interleaved parity 8 (BIP-8) code using even parity, computed over all bits of the previous VC-3, VC-4, or VC-4-Xc before scrambling. Path signal label: This indicates the composition or mapping of the VC-n. 0x: Unequipped, 01x: Reserved, 02x: TUG structure, 03x: Locked TU-n, 04x: 34-Mbps or 45-Mbps mapping, 12x: 140-Mbps mapping, 13x: ATM mapping, 14x: distributed queue dial bus (DQDB) mapping, 15x: fiber distributed data interface (FDDI) mapping, 16x: HDLC/PPP mapping, 17x: simple data link (SDL) mapping, 18x: Mapping of HDLC/LAPS, 19x: SDL mapping, 1Ax: 10 GbE, 1Bx: GFP mapping, CFx: Obsolete mapping of HDLC/PPP, from E1x to FC: reserved for national use, FEx: test signal O.181. HP status and performance: This byte enables continuous monitoring of anomalies and defects either at path end or at any point along the trail. Bits 1-4: remote error indication (HP-REI) conveys the number of bit errors detected by B3. Bit 5: remote defect indication (HP-RDI), is sent back if a signal failure is detected. Bits 6-7 can be used to provide enhanced RDI information to differentiate between payload defects (HP-PLM), server defects (HP-AIS, LOP), and connectivity defects (HP-TIM, HP-UNEQ). HP user channel: User communication purposes between path terminations. Sequence indication for virtual concatenation, if the payload is not a combination of VC-2, VC-12 or VC11, (see Figure 1.14) Multiframe indicator if the payload is VC-2, VC-12, or VC-11. APS signaling: Allocated for the VC-3/4 protection protocol in case of a failure HP tandem connection monitoring function (HP-TCM): Two options are described in the G.707 (Appendix C and D). Bits 1-4: incoming error count (IEC), bit 5: TC remote error indication (TC-REI), bit 6: outgoing error indication (OEI), bits 7-8: operate in a 76-byte multiframed string including access point identifier (TC-APId), a generic 16-byte identifier, and a remote defect indication (TC-RDI).

B3 C2

G1

F2, F3 H4

K3(bit1-4) N1

K3(bit7-8) HP data communication channel of 16 Kbps.

14

SDH/SONET Next Generation

1.5 GENERIC FRAMING PROTOCOL The Generic Framing Protocol (GFP), defined in ITU-T G.7041, is a mechanism for mapping constant and variable bit rate data into the synchronous SDH/SONET envelopes. GFP support many types of protocols including those used in local area network (LAN) and storage area network (SAN). In any case GFP adds a very low overhead to increase the efficiency of the optical layer. (see Section 1.5) Currently, two modes of client signal adaptation are defined for GFP:

• •

Frame-Mapped GFP (GFP-F), a layer 2 encapsulation PDU-oriented adaptation mode. It is optimized for data packet protocols (e.g. Ethernet, PPP, DVB) that are encapsulated onto variable size frames. Transparent GFP (GFP-T), a layer 1 encapsulation or block-code oriented adaptation mode. It is optimized for protocols using 8B/10B physical layer (e.g. Fiber Channel, ESCON, 1000BASE-T) that are encapsulated onto constant size frames.

GFP could be seen as a method to deploy metropolitan networks, and simultaneously to support mainframes and server storage protocols.
Ethernet
MSPP SDH/SONET MSPP Ethernet

Packets Port 1 Port 2
. . .

Source
STM-n/OC-m

Sink
Port 1 Port 2
. . .

Port n Rx queues GFP mapper
H1H2H3

Port n STM frames
4
H1H2H3

GFP demapper
H1H2H3

Tx Queues

1

3

Submultiplexing

Channel ID

Encapsulation Mapping Multiplexing T r a n s m i s s i o n

Decapsulation Demapping Demultiplexing

Figure 1.7

Data packet aggregation using GFP. Packets are in queues waiting to be mapped onto a TDM channel. At the far-end packets are drop again to a queue and delivered. GFP frame multiplexing and sub multiplexing. The figure shows the encapsulation mechanism and the transport of the GFP frames into VC containers embedded in the STM frames

SDH/SONET Next Generation

15

GFP frame
PLI cHEC (CRC-16)
4 te by s

byte 1 2 3 4 5 6 7 8 9 66

PLI: PDU Length Indicator cHEC: Core HEC protection PTI: Payload type Identifier 000: client data 100: client management PFI: Payload FCS Indicator 1: presence of FCS 0: absence EXI type: Extension Header Identifier 0000: Null 0001: Linear 0010: Ring UPI: User Payload Identifier (PTI=0) 01x: Ethernet (GFP-F) 02x: PPP (GFP-F) 03x: Fiber Channel (GFP-T) 04x: FICON (GFP-T) 05x: ESCON (GFP-T) 06x: Gigabit Ethernet (GFP-T) 08x: MAPOS (GFP-F) 09x: DVB (GFP-T) 0Ax: RPR (GFP-F) 0Bx: Fiber Channel (GFP-F) 0Cx: Async Fiber Channel (GFP-T) tHEC: Type HEC protection EXI: Extension Header Identifier Null EXI Type Linear EXI type tHEC Type tHEC CID Spare eHEC

PTI

Core Header Payload Header
4 es by t

PFI EXI type UPI

scrambled bytes (optional)

tHEC (CRC-16) EXI eHEC (CRC-16)

Extension Header 0-60 bytes (optional) Payload
n by te s

+1 +2

Check Sum (optional)

Payload

0 -4 tes by

+n

pFCS (CRC-32)
+n+4

tHEC: Type HEC protection CID: Channel ID for submultiplexing eHEC: Extension HEC protection Payload: Space for the framed PDU pFCS: Payload FCS

Figure 1.8

GFP frame formats and protocols

16

SDH/SONET Next Generation

1.5.1 Framed-mapped GFP In Frame-mapped GFP (GFP-F) one complete client packet is entirely mapped into one GFP frame. Idle packets are not transmitted resulting in more efficient transport. However, specific mechanisms are required to transport each type of protocol (see Figure 1.9).
Flag Address Control Type Payload Pad FCS LLC/SNAP BBW SoF Flag Pad

GFP
Core Header Payload Header Extension Header Payload

HDSLC/PPPP

Fiber Channel

Header Data CRC EOF Preamble SoF Dest Add Source Add

Check Sum

transported transported

Ethernet

Length LLC Data Pad FCS Extension

Figure 1.9

GFP mapping clients format

GFP-F can be used for Ethernet, PPP/IP and HDLC-like protocols where efficiency and flexibility are important. To perform the encapsulation process it is necessary to receive the complete client packet, but this procedure increases the latency, making GFP-F inappropriate for time-sensitive protocols. 1.5.2 Transparent GFP Transparent GFP (GFP-T) is a protocol-independent encapsulation method in which all client code words are decoded and mapped into fixed-length GFP frames The frames are transmitted immediately without waiting for the entire client data packet to be received. Therefore it is also a Layer 1 transport mechanism because all the client characters are moved to the far-end independently it does not matter if they are information, headers, control or any kind of overhead. GFP-T can adapt multiple protocols using the same hardware as long as they are based on 8B/10B line coding. This line codes are transcoded to 64B/65B and then encapsulated into fixed size GFP-T frames. Everything is transported, including inter-frame gaps that can have flow control characters or any additional information.

SDH/SONET Next Generation

17

GFP-T is very good for isocronic or delay sensitive-protocols, and also for Storage Area Networks (SAN) such as ECON or FICON. This is because it is not necessary to process client frames or to wait for arrival of the complete frame. This advantage is counteracted by lost efficiency, because the source MSPP node still generates traffic when no data is being received from the client.
Table 1.5 Comparison between GFP modes. Byte Protocol transparency Efficiency Isocronic or delay sensitive, protocols Encapsulation protocol level Optimised for Statistical multiplexing of several client signals SAN transport Ethernet transport GFP-F low high no Layer 2 (PDU) Ethernet yes no optimum GFP-T high low yes Layer 1 (Physical) SAN, DVB no yes possible

1.5.3 GFP in depth GFP enables MSPP nodes to offer both TDM and packet-oriented services, managing transmission priorities and discard eligibility. GFP replaces legacy mappings, most of them of proprietary nature. In principal GFP is just an encapsulation procedure but robust and standardised for the transport of packetised data on SDH and OTN as well. GFP uses a HEC-based delineation technique similar to ATM, it therefore does not need bit or byte stuffing. The frame size can be easily set up to a constant length. When using GFP-F mode there is an optional GPF extension Header (eHEC) to be used by each specific protocol such us source/destination address, port numbers, class of service, etc. Among the EXI types - ‘linear’ supports submultiplexing onto a single path, ‘Channel ID’ (CID) enables sub-multiplexing over one VC channel GFP-F mode (see Figure 1.7).

18

SDH/SONET Next Generation

1.6 CONCATENATION Concatenation is the process of summing the bandwidth of X containers (C-i) into a larger container. This provides a bandwidth X times bigger than C-i. It is well indicated for the transport of big payloads requiring a container greater than VC-4, but it is also possible to concatenate low-capacity containers, such as VC-11, VC-12, or VC-2.
Bandwidth requirement Contiguous concatenation
One concatenated payload

1

Virtual concatenation
One concatenated payload

VC4-4c
J1 B3 C2 G1 F2 H4 F3 K3 N1

VC4-3v or STS-9v 2 II
J1 J1B3 J1B3 C2 B3C2 G1 C2 F2 G1 G1 H4 F2 F2 F3 H4 H4 K3 F3 F3 N1 K3 K3N1 N1

One VCG

STS-12c SPE

3 VC members

One Path

622 Mbps

3

SDH

III

Several paths (3 in SDH, or 3x 9 in SONET) 155 Mbps

J1 B3 C2 G1 F2 H4 F3 K3 N1

4

IV

J1 J1B3 J1B3 C2 G1 B3C2 G1 C2 F2 G1 H4 F2 F2 F3 H4 H4 K3 F3 K3 F3 N1 K3N1 N1

Bandwidth delivery (430 Mbps)

Figure 1.10

An example of contiguous concatenation and virtual concatenation. Contiguous concatenation requires support by all the nodes. Virtual concatenation allocates bandwidth more efficiently, and can be supported by legacy installations.

There are two concatenation methods (see Figure 1.10): 1. Contiguous concatenation: which creates big containers that cannot split into smaller pieces during transmission. For this, each NE must have a concatenation functionality. Virtual concatenation: which transports the individual VCs and aggregates them at the end point of the transmission path. For this, concatenation functionality is only needed at the path termination equipment.

2.

SDH/SONET Next Generation

19

STM / STS pointers
AU-3 ptr
1 3

H1 H2 H3 AU-4 ptr
1 3

(STM-0/STS-1)
6 9 1

VC-4-Xc / STS-3Xc SPE
260X 261X

H1 Y
1

Y H2 1
12

1 H3 H3 H3 (STM-1/OC-3)
24 36

AU-4-4c ptr

H1 Y ....... Y AU-4-16c ptr
1

H1 Y ....... Y AU-4-Xc ptr 3X 1 H1 Y ....... Y
Y: 1001SS11 1: All 1s byte

48

J1 B3 H2 1 ....... 1 H3 H3 ....... H3 (STM-4/OC-12) C2 G1 96 144 F2 ....... 1 H3 H3 ....... H3 (STM-16/OC-48) H4 H2 1 F3 6X 9X K3 H2 1 ....... 1 H3 H3 ....... H3 (STM-n/OC-m) N1

R

C-4-Xc or SPE

Justification unit = 3 X bytes

Fixed columns size = X-1

Figure 1.11

Contiguous concatenation: Pointers and containers. A VC-4-Xc (X = 1, 4, 16, 64, 256) structure, where X represents the level. The increment/decrement unit (justification) is 3 X, as it depends on the level: AU-4=3 bytes, AU-4-256c=768 bytes.

1.6.1 Contiguous Concatenation of VC-4 A VC-4-Xc provides a payload area of X containers of C-4 type. It uses the same HO-POH used in VC-4, and with identical functionality. This structure can be transported in an STM-n frame (where n = X). However, other combinations are also possible; for instance, VC-4-4c can be transported in STM-16 and STM-64 frames. Concatenation guarantees the integrity of a bit sequence, because the whole container is transported as a unit across the whole network (see Table 1.6). Obviously, an AU-4-Xc pointer, just like any other AU pointer, indicates the position of J1, which is the first byte of the VC-4-Xc container. The pointer takes the same value as the AU-4 pointer, while the remaining bytes take fixed values equal to Y=1001SS11 to indicate concatenation. Pointer justification is carried out the same way for all the X concatenated AU-4s and X x 3 stuffing bytes (see Figure 1.11). However, contiguous concatenation, today, is more theory than practice, since other alternatives more bandwidth-efficient, such as virtual concatenation, are gaining more importance.

20

SDH/SONET Next Generation

Table 1.6 Contiguous concatenation of VC-4-Xc. X indicates the number of VC-n. SDH VC-4 VC-4-4c VC-4-16c VC-4-64c VC-4-256c SONET STS3c-SPE STS12c-SPE STS48c-SPE STS192c-SPE STS768c-SPE X 1 4 16 64 256 Capacity 149,760 Kbps 599,040 Kbps 2,396,160 Kbps 9,584,640 Kbps 38,338,560 Kbps Justification Unit Transport 3 bytes 12 bytes 48 bytes 192 bytes 768 bytes STM-1/OC-3 STM-4/OC-12 STM-16/OC-48 STM-64/OC-192 STM-256/OC-768

1.6.2 Virtual Concatenation Connectionless and packet-oriented technologies, such as IP or Ethernet, do not match well the bandwidth granularity provided by contiguous concatenation. For example, to implement a transport requirement of 1 Gbps, it would be necessary to allocate a VC4-16c container, which has a 2.4-Gbps capacity. More than double the bandwidth that is needed. (see Table 1.6).
Table 1.7 Capacity of virtually concatenated SDH VC-n-Xv or SONET STS-3Xv SPE. SDH VC-11 VC-12 VC-2 VC-3 VC-4 SONET VT.15 SPE VT2 SPE VT6 SPE STS-1 SPE STS-3c SPE Individual Capacity 1,600 Kbps 2,176 Kbps 6,784 Kbps 48,384 Kbps 149,760 Kbps Number (X) Virtual Capacity 1 to 64 1 to 64 1 to 64 1 to 256 1 to 256 1,600 to 102,400 Kbps 2,176 to 139,264 Kbps 6,784 to 434,176 Kbps 48,384 to 12,386 Kbps 149,760 to 38,338,560 Kbps

Table 1.8 Comparison between Contiguous and Virtual Concatenation efficiency. Service Ethernet Fast Ethernet Gigabit Ethernet Fiber Channel ATM DVB ESCON Bit Rate 10 Mbit/s 100 Mbit/s 1000 Mbit/s 1700 Mbit/s 25 Mbit/s 270 Mbit/s 160 Mbit/s Contiguous Concatenation VC-3 (20%) VC-4 (67%) VC-4-16c (42%) VC-4-16c (42%) VC-3 (50%) VC-4-4c (37%) VC-4-4c (26%) Virtual Concatenation VC-11-7v (89%) VC-3-2v (99%) VC-4-7v (95%) VC-4-12v (90%) VC-11-16c (98%) VC-3-6v (93%) VC-3-4v (83%)

Virtual concatenation (VCAT) is a solution that allows granular increments of bandwidth in single VC-n units. At the MSSP source node VCAT creates a continuous payload equivalent to X times the VC-n units (see Table 1.7). The set of X containers is known virtual container group (VCG) and each individual VC is a

SDH/SONET Next Generation

21

member of the VCG. All the VC members are sent to the MSSP destination node independently, using any available path if necessary. At the destination, all the VC-n are organized, according the indications provided by the H4 or the V5 byte, and finally delivered to the client (see Figure 1.12). Differential delays between VCG member are likely because they are transported individually and may have used different paths with different latencies. Therefore, the destination MSSP must compensate for the different delays before reassembling the payload and delivering the service. Virtual concatenation is required only at edge nodes, and is compatible with legacy SDH networks, despite the fact that they do not support concatenation. To get the full benefit from this, individual containers should be transported by different routes across the network, so if a link or a node fails the connection is only partially affected. This is also a way of providing a resilience service (see Figure 1.12).
MSSP Source node
Mapping, Segmentation

SDH/SONET Network
Transmission

MSSP Destination node
Delay Compensation, Reassembly

t0+250µs t0+125µs VC4-7v t0 A 25%

VCG members

5

5

35%
6

B
5

MFI=i SQ=0..6
55 45

t1 t1-125µs VC4-7v t1-250µs

(1.05 Gbps)

MFI=k+2 (1.05 Gbps) MFI=k+1

VC4-7v

(1.05 Gbps) MFI=k

VC4-7v

X
5 55

MSPP

G

6

MSPP

Y

(1.05 Gbps)

MFI=i (1.05 Gbps)

VC4-7v

MFI=k SQ=0..6 Contiguous Payloads VC Group

40% E
3 3

F

MFI=i-1 (1.05 Gbps) MFI=i-2 VC Group Contiguous Payloads

VC4-7v

VCG members

Figure 1.12

Virtual concatenation uses bandwidth more efficiently. Individual VC-4s can be routed across different paths on the network. If a resource fails, only a part of the bandwidth is affected.

1.6.2.1 Higher Order Virtual Concatenation Higher Order Virtual Concatenation (HO-VCAT) uses X times VC-3 or VC4 containers (VC-3/4-Xv, X = 1 ... 256), providing a payload capacity of X times 48384 or 149760 kbit/s.

3

22

SDH/SONET Next Generation

Contiguous payload

1

1

6·84

1

1

6·84

t

1

1

6·84

C-3-6c
9 9

C-3-6c

......
9

C-3-6c

6 -Segments

6 -Segments

6 -Segments

SEQ=6 MFI=0 .

1
J1 B3 C2 G1 F2 H4 F3 K3 N1

84

EOS SEQ=6 MFI=1 .

1
J1 B3 C2 G1 F2 H4 F3 K3 N1

84

EOS

EOS

..

..

.. SEQ=1 J1 B3 SEQ=0 J1 C2 MFI=0 B3 G1
C2 F2 G1 H4 F2 F3 H4 K3 F3 N1 K3 N1

..

..

..

N1

..

N1

X times VC3 1 1 n·270

X times VC3 2·n·270 3·n·270

X times VC3 4096·n·270

RSOH AU3 ptrs MSOH

RSOH

RSOH

RSOH

STM-n

AU3 ptrs MSOH

STM-n

AU3 ptrs MSOH

STM-n

...

AU3 ptrs MSOH

STM-n

9

..

..

VC-3 VC-3

.. SEQ=1 J1 B3 SEQ=0 J1 C2 MFI=1 B3 G1
C2 F2 G1 H4 F2 F3 H4 K3 F3 N1 K3

VC-3 VC-3

VCG (VC-3-6v)

.. SEQ=1 J1 B3 SEQ=0 J1 C2 MFI=4095 B3 G1
C2 F2 G1 H4 F2 F3 H4 K3 F3 N1 K3

..

..

..

..

VC-3

VC-3

......

SEQ=6 MFI=4095 .

1
J1 B3 C2 G1 F2 H4 F3 K3 N1

84

VC-3

VC-3 VC-3

STM-n
t

MFI=0 SEQ=0
1 1

MFI=1 SEQ=0

MFI=2 SEQ=0

MFI=4095 SEQ=0

MFI=0 SEQ=0

RSOH AU3 ptrs MSOH

RSOH

RSOH

RSOH

STM-n

AU3 ptrs MSOH

STM-n

AU3 ptrs MSOH

STM-n

...

AU3 ptrs MSOH

STM-n

STM-n
t

9

MFI=0 SEQ=1 SEQ=2

MFI=1 SEQ=1

MFI=2 SEQ=1

MFI=4095 SEQ=1

MFI=0 SEQ=1

......
1 1

......

......

......

SEQ=3 SEQ=4 SEQ=5

RSOH AU3 ptrs MSOH

RSOH

RSOH

RSOH

STM-n

AU3 ptrs MSOH

STM-n

AU3 ptrs MSOH

STM-n

...

AU3 ptrs MSOH

STM-n

STM-n
t

9

MFI=0 SEQ=6

125 µs

MFI=1 SEQ=6

250 µs

MFI=2 SEQ=6

375 µs

MFI=4095 SEQ=0...6

512 msSEQ=6

MFI=0

Figure 1.13

Graphical example of virtual concatenation using VC-3-6v (X=6) with graphical representation of sequence (SQ) and multiframe indicator (MFI) coded on H4.

SDH/SONET Next Generation

23

The virtual concatenated container VC-3/4-Xv is mapped in independent VC-3 or VC-4 envelopes that are transported individually through the network. Delays could occur between the individual VCs, this obviously has to be compensated for when the original payload is reassembled (see Figure 1.13). A multiframe mechanism has been implemented in H4 to compensate for differential delays of up to 256ms:

• •

Every individual VC has a H4 multiframe indicator (MFI) that denotes the virtual container they belong to The VC also traces its position X in the virtual container using he SEQ number which is carried in H4. The SEQ is repeated every 16 frames

The H4 POH byte is used for the virtual concatenation-specific sequence and multiframe indication (see Figure 1.14). 1.6.2.2 Lower Order Virtual Concatenation Lower Order Virtual Concatenation LO-VCat. uses X times VC-11, VC12, or VC2 containers (VC-11/12/2-Xv, X = 1 ... 64). A VCG built with V11, VC12 or VC2 members provides a payload of X containers C11, C12 or C4; that is a capacity of X times 1600, 2176 or 6784 kbit/s. VCG members are transported individually through the network, therefore differential delays could occur between the individual components of a VCG, that will be compensated for at the destination node before reassembling the original continuous payload (see Figure 1.12). A multiframe mechanism has been implemented in bit 2 of K4. It includes a sequence number (SQ) and the multiframe indicator (MFI), both enable the reordering of the VCG members. The MSSP destination node will wait until the last member arrives and then will compensate for delays up to 256ms. It is important to note that K4 is a multiframe itself, received every 500µs, then the whole multiframe sequence is repeated every 512 ms. (see Figure 1.14) 1.6.3 Testing VCAT When installing or maintaining VCAT it is important to carry out a number of tests to verify not only the performance of the whole Virtual Concatenation, but also every single member of the VCG. For reassembling the original client data, all the members of the VCG must arrive at the far end, keeping the delay between the first and the last member of a VCG below 256 ms. A missing member prevents the

24

SDH/SONET Next Generation

J1 B3 frame 1 C2 G1 MFI1 5-8bits F2 H4 1-4bits F3 K3 time 0ms N1

Higer Order Path Overhead

multiframe
1 2 3 4 5 6 7 8 9

multiframe
2 256 4096

10 11 12 13 14 15 16 17 18 19 20 21

0000 0001 CTRL 0010 0 0 0 GID 0011 0 0 0 0 0100 0 0 0 0 0101 0110 CRC8 0111 1000 MST 1001 0 0 0 RSA 1010 0 0 0 0 1011 0 0 0 0 1100 0 0 0 0 1101 1110 SQ 1111 0000 MFI2 0001 CTRL 0010 0 0 0 GID 0011 0 0 0 0 0011 4

MFI2

2ms

MFI1: Multiframe indicator part 1 [0...255] MFI: Combination of MFI2-MFI1 [0...4095] MFI2: Multiframe indicator part 2 [0...255] SQ: Sequence Indicator int he VCG [0...255]
125 µs 250 µs J2 375 µs N2 500 µs

V5
Lower Order Path Overhead

K4

K4 bit2 per .5ms) (1bit

multiframe frame 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

K4
bit2
0

MFI

SQ

CTRL

0000

RS-Ack

CTRL

MST

CRC-3
16ms

frame 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 8 25 26 27 28 29 30 31 32 00000 00001 00010 00011 00100 00101 00110 00111 01000 01001 01010 01011 01100 1101 01101 01110 01111 10000 10001 10010 10011 10100 10101 10110 10111 11000 11001 11010 11011 11100 11101 1101 11110 11111

SQ CTRL CRC-3

MFI

0

512ms

MFI: Multiframe Count Indicator [0...31] SQ: Sequence Indicator int he VCG [0...63]

LCAS protocol

CNTRL: Control 0000 FIXED Non-LCAS mode 0001 ADD Member will be added to group 0010 NORM Normal LCAS transmission 0011 EOS End of Sequence, highest member in group 0101 IDLE Member will be removed or not in group 1111 DNU Do Not Use, receive side reported MST FAIL status GID: Group Id. constant value for all members of a VCG. CRC-3: Generated on the K4 over the previous frames. MST: Member Status multiframe, one bit per each VCG member 0 = OK 1 = FAIL RS-Ack: Re-Sequence Acknoledge

Figure 1.14

H4 and K4 codification of Multiframes, Sequence, and LCAS usage. H4 is repeated every 125 µs but note that K4 is part of the LO-PO multiframe repeated every 500 µs, then the multiframe created with 32 times the bit-2 needs 500x32=16ms. The whole sequence of 32 multiframes takes 512 ms to repeat.

SQ
512ms

1110 1111

...

SDH/SONET Next Generation

25

reconstruction of the payload, and if the problem persists causes a fault that would call for the reconfiguration of the VCAT pipe. Additionally, Jitter and Wander on individual paths can cause anomalies (errors) in the transport service. BER, latency, and event tests should verify the capacity of the network to perform the service. The VCAT granularity capacity has to be checked as well, by adding/removing. To verify the reassembly operation it is necessary to use a tester with the capability to insert differential delays in individual members of a VC.

26

SDH/SONET Next Generation

1.7 LINK CAPACITY ADJUSTMENT SCHEME Virtual concatenation provides granularity, but continues using predefined bandwidth allocation, which does not match the variable bit rate patterns and the burst nature of most data networks. The link capacity adjustment scheme (LCAS), standarized by the ITU-T as G.7042, was designed to modify the bandwidth allocation of a VCAT path. LCAS can add and remove members of a VCG, provisioning of more less bandwidth of a live SDH/SONET without affecting the transported data. 1.7.1 LCAS applications 1.7.1.1 Bandwidth allocation LCAS complements VCAT, enabling re-sizing capabilities of a pipe in use. It can also automatically remove a specific VCG member, which is failing; this avoids failure of the complete VCAT connection. A common misunderstanding is that LCAS can automatically adapt the VCG size according the traffic pattern at anytime. That is not exactly true, it would require direct interaction between the LCAS node and the control plane of the network which is not possible.
Normal operation
Path1: 60%
A B A

After breakdown
Path1: 0%
B

VCAT
X G

VCAT
Y

VCAT
X G

100%

VCAT 40% Y LCAS

MSSP
E F

MSSP

LCAS
E F

Path2: 40%

Path2: 40%

Figure 1.15

Diversification strategy between points X and Y using VCAT and LCAS.

1.7.1.2 Asymmetric configurations It is important to note that LCAS is a unidirectional protocol which is executed independently at the two ends. This feature allows the provision of asymmetric bandwidth between two MSSP nodes to configure asymmetric links adapted to customer requirements.

SDH/SONET Next Generation

27

1.7.1.3 Network resilience LCAS is being installed to implement a resilience strategy know as diversification (see Figure 1.15). This method, which in the past has commonly been used, can now be applied also to SDH using VCAT. This will send traffic using several routes (see Section 1.6.2). In the case of a partial failure of one route, LCAS reconfigures the MSSP connection using the live VCG members to continue carrying traffic. In the case of an IP network, router topology would continue to be active but less bandwidth would be available and consequently delay would be increased. However, constant complex configurations and re-configurations between routers are avoided. 1.7.1.4 Cross-domain operation LCAS eliminates slow and inefficient provisioning process of legacy SDH networks. When a service crosses several operators (for example international links) it is necessary to coordinate several configuration centers. By using VCAT with LCAS the configuration is easier. It is also possible to add and remove paths from a route automatically, and in real-time from both sides of the VCAT pipe as they become unavailable and available. 1.7.2 LCAS protocol Between the source and the sink LCAS is executed to monitor member status, to indicate changes on the VCAT bandwidth use, and acknowledge the changes. LCAS is a protocol transported in H4 byte, if HO-VCAT is being used, or in K4, if LO-VCAT is being used, (see Figure 1.14). LCAS is resident in the H4 and in the K4 bytes of the path overhead, the same bytes virtual concatenation (see Figure 1.14) uses for its MFI and SQ numbers. LCAS uses some of the bytes that are not used for MFI and SEQ, leaving some bytes set to 0, reserved for future development. Between the source and the sink LCAS establishes a protocol to control the members of the VCG. Information includes status of each member, CRC to protect the message, acknowledgements from sink to source to indicate that changes have initiated.The LCAS messages are continuously exchanged to implement the protocol: 1. 2. Fixed - LCAS not supported on this VCAT pipe. Add - request to add a new member to the VCG of an existing VCAT channel. If the channel does not exist new channel will be created.

28

SDH/SONET Next Generation

Source
LCAS

Sink

SDH

LCAS

MSPP MFI, SQ, CTRL, GID, CRC MST, RS-Ack, CRC

MSPP

Norm Norm EOS

SQ=0 SQ=1 SQ=2

ADD RS-Ack Norm Norm Norm EOS SQ=0 SQ=1 SQ=2 SQ=3

Figure 1.16

LCAS example - a new member is ADDed to one existing VCG channel to increase the bandwidth of the channel. The network management system orders the source to add this new link to the existing channel

3. 4. 5. 6.

Norm - normal member of a VCG which already part of a VCAT. EOS - End of Sequence, last member of a VCG with the highest SQ number. Idle - this is a container which is not part of a VCG channel. DNU - this member of a VCG channel has to be removed due to a fault detected at the sink side.

Multiple STS-1s can be added to, or removed from a link concurrently to allow for fast resizing (see Figure 1.15). 1.7.3 LCAS verification While virtual concatenation is a simple labelling of individual STS-1s within a channel, LCAS is a two-way handshake protocol LCAS should be tested after VCAT to verify the adjustment capacity of the protocol without producing any event in the transport service. LCAS must be also able to eliminate a member of the VCG if it does not arrive properly, or does not arrive at all. When a capacity adjustment happens the nodes must restore the link with the new capacity in a short time.

SDH/SONET Next Generation

29

Selected Bibliography
[1] [2] [3] [4] [5] [6] [7] [8] [9] Jose Caballero, et al. Installation and Maintenance of SDH/SONET, ATM, xDSL and Synchronisation Networks, Artech House Aug. 2003 IEEE 802.3-2002, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications, March 2002 Enrique Hernández Valencia, “The Generic Framing Procedure (GFP),” IEEE Communications Magazine, May 2002. ISO/IEC 3309 Information Technology - Telecommunications and Information eXchange Between Systems - High-level Data Link Control (HDLC) Procedures - Frame Structure, 1993. ITU-T Rec. X.85/Y.1321, IP over SDH using LAPS, Oct. 2000. ITU-T Rec. G.7041/Y.1303, Generic framing procedure (GPF), Dec. 2003. ITU-T Rec. G.707, Link capacity adjustment scheme (LCAS) for virtual concatenated signals, Oct. 2001, Nov. 2001. ITU-T Rec. G.803, Architecture of transport networks based on the SDH, March 2000. ITU-T Rec. G.841, Types and characteristics of SDH network protection architectures. Oct. 1998.

[10] ITU-T Rec. G.957, Optical interfaces for equipment and systems relating to the SDH, June 1999.

30

SDH/SONET Next Generation

Sign up to vote on this title
UsefulNot useful