Understanding Virtual Concatenation and Link Capacity Adjustment Scheme in SONET/SDH

Optimizing Ethernet transport over existing infrastructure for profitable delivery of broadband services

Asis Mukhopadhyay Technical Leader (STS) TranSwitch Corporation

Robert Schwaber Product Marketing Manager TranSwitch Corporation

Bert Klaps Sr. Member Technical Staff (SMTS) TranSwitch Corporation

William Todd Technical Director, Systems Solutions TranSwitch Corporation

ervice providers face a major issue in determining the best approach for handling the high volumes of Ethernet traffic generated by the proliferation of network access applications. Depending on the requirements of LAN, WAN, or MAN applications, there are a number of approaches that may be used for Ethernet data transport. This paper outlines the advantages and methodologies of Virtual Concatenation (VCAT or VC) and Link Capacity Adjustment Scheme (LCAS), which define the method of transport commonly used in Ethernet over SONET/SDH (EOS) applications, as well as for other data transmission services.

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services
The Fundamentals of Virtual Concatenation
SONET/SDH networks can transport various client signals at different rates over a flexible synchronous optical hierarchy. The payload capacity of the basic STS-1/STM-0 signal may consist of independent Low-Order tributaries Virtual Tributaries (VTs) in SONET or Tributary Units (TUs) in SDH that transport lower-rate services. Alternatively, higher-rate OC-N SONET/SDH signals can be built with N units of the basic STS-1/STM-0. Concatenation may be used to transport payloads that exceed standard payload container capacity (VC-3). For High-Order paths (STS-1/AU-3 and above), concatenation may be either contiguous or virtual. The contiguous concatenation method uses a pointer containing a 'concatenation indicator', with component STS-1 signals identical in phase and transported together as one entity; for example, the 149.76 Mbps STS-3C container. With Virtual Concatenation, the payload is divided over multiple STS1/STS-3c signals that may travel along different physical routes. Because contiguous concatenations were not popular for Low-Order containers, such as TU-3/TU-2/TU-12/TU-11 (SDH) or VT6/VT2/VT1.5 (SONET), aggregating these containers for high payload rates requires Virtual Concatenation. Figure 1 shows the capacity of Virtually Concatenated tributaries in SONET and SDH, respectively. High-Order
Container Columns Maximum Containers 'n' per Group Min Bandwidth per Group Mbps 1.600000 2.176000 3.328000 6.784000 48.384000 48.384000 149.760000 Max Bandwidth Granularity per Group Mbps Mbps

VCAT groups the payload of different signals at 48.384 Mbps or 149.760 Mbps, and Low-Order VCAT groups the payload of different VTS/TUS at lower rates, such as 1.600 Mbps or 2.176 Mbps. Bandwidth usage can be improved by accommodating different bit rates 10 Mbps, 100 Mbps, 1 Gbps, and 10 Gbps for Ethernet LAN services in appropriately sized VCAT payloads. By using different containers, voice and data can be sent over the same transport structure. The most popular containers for this purpose are VC-11, VC-12, VC-3 and VC-4. Unlike contiguous concatenation, which requires functionality at each intermediate network element as well as at the path termination equipment, VCAT requires functionality only at the terminations. Therefore, introducing VCAT capability necessitates equipment upgrades only at the ends of the path, thereby avoiding the expense of replacing legacy equipment at intermediate nodes.

Virtual Concatenation of Multiple Paths

Virtual Concatenation is a Management-Plane-oriented protocol. VCAT of multiple paths requires using the Control/Management Plane to establish a link between a Source End (So) and a Sink End (Sk) for a Virtually Concatenated Group (VCG). The Management Plane identifies the VCG members, assigns a physical path for each of them and tracks the intermediate Sub-Network Connection (SNC) switching. The So of the VCG then uses the link to pass a Path Overhead (POH) byte to the Sk. The byte conveys information about the relative phase difference between each arrivingmember of the CG and indicates the physical delay incurred during transit. By delivering the sequence number of each member, the POH byte also informs the Sk of that member's position in the original order of VCG members at the So. Virtual Concatenation is defined in ITU-T Recommendation G.707, Section 11 and in ANSI T1.105-2001. Designers have the option of using LCAS to achieve hitless

SONET N ame

SDH Name

Notes

Low - Order Containers VT-1.5 VC-11 VT-2 VC-12 VT-3 --VT-6 VC-2 High - Order Containers --TU-3/VC-3 STS-1 SPE AU-3/VC3 STS-3c SPE AU-4/VC4

3 4 6 12 84 84 260

64 64 64 64 256 256 256

102.400000 139.264000 212.992000 434.176000

1.600000 2.176000 3.328000 6.784000

1,3 1,3 1,3 1,3 2,4 2 2

12386.304000 48.384000 12386.304000 48.384000 38388.560000 149.760000

Notes: 1) Number of containers li mited by 6 bit field in K4 bit 2 mul tiframe struc ture. 2) Number of containers li mited by 8 bit field in H4 byte mult iframe struct ure. 3) TU pointer and TU-POH bytes exc luded 4) The TU-3/VC-3 Container is a low order entity in terms of its position in t he SDH hierarchy but i s handled much the same as an A U-3/VC-3 for VC & LCAS due t o its si ze and struc ture

Figure 1: Virtual Container Size Chart

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

Recommendation G.707, Section 11 and in ANSI T1.1052001. Designers have the option of using LCAS to achieve hitless adjustment of the payload allocated to VCGs. Doing so enables members to be added to or removed from a VCG as capacity requirements increase or decrease or as link failure conditions occur. The ITU-T G.7042 recommendation defines the LCAS scheme.

Driving Forces Behind VCAT and LCAS

The primary drivers behind Virtual Concatenation include scalability, efficiency, compatibility and resiliency. The popularity of this methodology is due to the real benefits afforded both network providers and end users. Prior to the emergence of Virtual Concatenation, the available container sizes for data transmission were limited to a few possibilities (STS-1, STS-3c, STS-12c, Synchronous Payload Envelopes (SPES) serve as examples of typical North American containers). Intermediate container sizes (STS-6c, STS-9c) were never popular and, typically, Low-Order (LO) containers were not used for data transport. With the creation of Virtual Concatenation there is now a greater range of flexibility in sizing the containers to meet the requirements of the data payload. Containers of nx VT-1.5 (Figure 2), nx STS-1 and nx STS-3C are all now possible, accommodating applications between 1.6 Mbps and 38 Gbps. This scalability, combined with flexibility of container

selection, permits efficient use of bandwidth and avoids creation of unusable 'islands' of bandwidth, improving the efficiency of provisioning. Compatibility of the network is maximized since the network core is already capable of transporting the containers in question. It is sufficient to install the VCAT hardware at the points of termination and provision the routing through the network core. The multiframe structure used in the Virtual Concatenation process permits inverse multiplexing of large payloads into groups of several small containers, routing individual containers of a VCG across diverse geographical routes to reach the destination. There they are recombined after compensating for the differential delay incurred in transmission. Link Capacity Adjustment Scheme builds on Virtual Concatenation principles to provide dynamic bandwidth control. A system must first use VCAT for LCAS to apply. Using LCAS, the bandwidth of a service may be programmed to change over time without impairments (no data loss). The benefits of this are increased flexibility and efficiency of the network and greater reliability. Bandwidth supplied may be scheduled to match clients' workload requirements. Should failures occur on individual containers in a group, the size of the group can be reduced temporarily instead of taking the entire group out of service. Once the defect is repaired, the group size can be restored in a 'hitless' manner. Nodes providing LCAS service will inter-work with non-LCAS nodes by reverting to a non-LCAS mode of operation. These attributes make LCAS a very attractive service for both providers and customers. The example of an LCAS system shown in Figure 3 would require a dynamic Operations System (OS).
00:00
SONET Terminal With VT1.5 Virtual Conc. 10 Mbps

SONET Terminal With VT1.5 Virtual Conc. 10 Mbps SONET OC-3 1 STS-1 SPE #1 2 3

Traditional SONET VT X-Connect SONET OC-3 2 STS-1 SPE #1 3 STS-1 SPE #2 1 STS-1 SPE #3 STS-1 SPE #3

SONET Terminal With VT1.5 Virtual Conc. 10 Mbps

06:00

12:00

18:00

00:00
SONET Terminal With VT1.5 Virtual Conc. 10 Mbps

SONET OC-3

STS-1 SPE #2

1.6Mbps 1.6Mbps 1.6Mbps 1.6Mbps

1.6Mbps 1.6Mbps

1.6Mbps 1.6Mbps 1.6Mbps

1.6Mbps

Figure 2: Virtually Concatenated Application

Total BW = 6.4 Mbps Heavy Use: File backup

Total BW = 3.2 Mbps Normal Use: Morning

Total BW = 4.8 Mbps Increased Use: Afternoon

Total BW = 1.6 Mbps Light use: Evening

Figure 3: Potential LCAS Application

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

As noted earlier, Virtual Concatenation and Link Capacity Adjustment Scheme are Management-Plane-oriented processes (Figure 4). Virtual Concatenation of multiple paths
Management Plane

basic 125-microsecond STS-1 frame structure used in North American SONET and its respective overhead.
Synchronous Payload Envelope (SPE) 87 Columns Transport Overhead
Section Overhead A1
Framing

POH
J1
Trace

Payload
INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO INFO

A2
Framing

J0/Z0
STS-1#/Trace

... ... ... ... ... ... ... ... ...

INFO INFO INFO INFO INFO INFO INFO INFO INFO

INFO INFO INFO INFO INFO INFO INFO INFO INFO

INFO INFO INFO INFO INFO INFO INFO INFO INFO

Source End Provisioning

Intermediate Network Element Provisioning

B1
BIP-8

E1
Orderwire

F1
User

B3
BIP-8

D1
Datacom

D2
Datacom

D3
Datacom

C2
Signal-label

Sink End Provisioning

Line Overhead

H1
Pointer

H2
Pointer

H3
Pointer Action

G1
Path Status

B2
BIP-8

K1
APS

K2
APS

F2
User

So
Source End

NE NE

NE NE
Transport Plane Sink End

Sk

D4
Datacom

D5
Datacom

D6
Datacom

H4
Multi Frame

D7
Datacom

D8
Datacom

D9
Datacom

F3/Z3
User

D10
Datacom

D11

D12 E2
Orderwire

K3/Z4
APS

Datacom Datacom

S1/Z1 M0/M1
Sync. Msg. FEBE

N1/Z5
Tandem Con.

Figure 4: Management Plane View

involves creation of a link with a Source End (So) and a Sink End (Sk) for the Virtually Concatenated Group (VCG), identifying members of the VCG and assigning the physical path for each member. Path Overhead (POH) bytes are used by the So in all the constituent members to pass information to the Sk regarding the relative phase difference between arriving members of the VCG and the sequence number of each arriving member. The Sink End requires suitably-sized memory for buffering of all arriving members of a VCG. LCAS is an optional method for hitlessly adjusting the payload allocated to VCGs and uses control packets carried in the Path Overhead information of the VCG members. Bandwidth adjustments are initiated by the Network Management System (NMS) by forwarding a request to the LCAS Controller (LCASC) located at the So and all affected Sk nodes. The LCASC will synchronize the adjustment request by generating the appropriate control packets and monitoring responses from the Sks.

Key Overhead related to Virtual Concatenation and Link Capacity Adjustment Scheme

Figure 5: STS-1 Frame Structure and Overhead Bytes

This structure provides the basis for all SONET/SDH transmission formats from STS-1 (51.84 Mbps) through STS768 (39.813 Gbps). In ITU-T terminology, the equivalent SDH rates are numbered STM-0 through STM-256. Path Overhead bytes for all SONET SPE structures, and for SDH SPE structures of VC-4, AU-4/VC-3 and AU-3/VC-3 are as shown in this figure, with those bytes relevant to discussions of Virtual Concatenation and LCAS highlighted. For High-Order Concatenation, the key overhead bytes are C2 and H4. SONET/SDH uses a signal Label to identify the type of payload being carried in a container. At the HigherOrder level, the C2 byte is used for this purpose. The remaining byte crucial to Higher- Order Virtual concatenation and LCAS is H4. The H4 byte multiframe sequence concept commonly used for T1 and E1 tributary mapping has been expanded from a simple multiframe sequence of four frames (500 microseconds) to a twotiered multiframe structure of 4096 frames total (512 milliseconds) for Virtual Concatenation applications. We will examine this process in detail shortly. For Lower-Order Concatenation, the key overhead bytes are

Understanding the VCAT and LCAS Processes

An understanding of the Virtual Concatenation and LCAS processes begins with a short review of the SONET/SDH frame structures and overhead bytes. Figure 5 shows the

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

V5 and K4. These are highlighted in Figure 6. There will be

90 Columns

A1

TOH A2

C1/J0

POH J1

125 usec.

H1

H2

H3 H4

28 Columns V1 V1 Data Data Data Data

Stuff R R R

28 Columns V5 V5 Data Data Data Data

Stuff R R R

28 Columns Data Data Data Data Data Data

Value 00H 01H 02H 03H 04H 05H 12H 13H 14H 15H

C2 Byte Pay load Identifiers Payload Type Value Payload Type Unequipped 16H HDLC Packet Over SONET mapping Reserved (Do not use after 10/2000) 17H Simple Data Link Mapping w/Self Sy nc Scrambl er VTG/T UG Structure 18H HDLC/LAPS s ignal Mapping Locked VT/TU mode (no longer used) 19H Simple Data Link Mapping w/Set-Res et Scrambler Async hronous DS3/E3 M apping 1AH 10G Ethernet mapping Mapping Under Development 1BH GFP Mapping Async hronous DS4NA/E 4 Mapping CFH Reserved (Prev HDLC/PPP) ATM Cell Mapping E1H-FCH Reserved for National Use MAN DQDB Mapping FEH FE - O.181 Test S ignal Mapping Async hronous FDDI Mapping FFH VC-AIS

A1

A2

C1/J0

J1

H1

H2

H3 H4

V2 Data Data

V2 Data Data

R R R

J2 Data Data

J2 Data Data

R R R

Data Data Data

Data Data Data

Figure 7: C2 Byte Signal Label Definitions

H4 Byte Concatenation Multiframe Structure (w/o LCAS) Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7

A1

A2

C1/J0

J1

H1

H2

H3 H4

V3 Data Data

V3 Data Data

R R R

N2/Z6 Data Data

N2/Z6 Data Data

R R R

Data Data Data

Data Data Data

Bit 1

Bit 8

1st Multiframe Indicator MFI1 Reserved ("0000") Sequence Indicator (Bits 1-4) Sequence Indicator (Bits 5-8) 2nd Multiframe Indicator M FI2 bits 1-4 2nd Multiframe Indicator M FI2 bits 5-8 Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Reserved ("0000") Sequence Indicator (Bi ts 1-4) Sequence Indicator (Bi ts 5-8) 2nd Multiframe Indicator M FI2 bits 1-4 2nd Multiframe Indicator M FI2 bits 5-8 Reserved ("0000") 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

A1

A2

C1/J0

J1

H1

H2

H3 H4

V4 Data Data

V4 Data Data

R R R

K4/Z7 Data Data

K4/Z7 Data Data

R R R

Data Data Data

Data Data Data

Key Overhead related to Virtual Concatenation and Link Capacity Adjustment Scheme
* Note in this example H1H2 =620AH and V1V2 = 6C4EH

Figure 6: Typical 500 Microsecond Multiframe Structure Showing VT POH Bytes

one set of overhead bytes for each container. V5 is a multifunction byte with several fields defined including a 3-bit Signal Label for identifying the payload type. Since eight possibilities are too restrictive, one code has been reserved as an extension code and additional payload types will be defined using the K4 byte. In addition, the K4 byte contains the remaining hooks for Low-Order VCAT and LCAS processing.

1st 2nd Multiframe Multiframe Number Number 13 N-1 14 15 0 1 2 3 4 5 6 7 N 8 9 10 11 12 13 14 15 0 N+1 1 2

2 msec. Multiframe period

256 MFI1 Multiframes total

Notes: 1) MFI1 range 0-15, repeating 2) MFI2 range 0-255, repeating 3) Total Multiframe length = 4096 frames (512 millisec onds). 4) Sequence Indicator range 0-255, eac h sequence uses s eparate path

Figure 8: 512-Millisecond Multiframe H4 ByteStructure

for STS- 1, VC-3 and STS-3c/VC-4 container groups. The MFI-1 multiframe is a continuously repeating structure containing sixteen 125-microsecond frames. It utilizes bits 58 of the H4 byte and provides a sequential count of 0-F (4bits). This gives MFI-1 a 2- millisecond period. The frame count is used to indicate the purpose of information in bits 1-4 of the H4 byte: + Frame 0 contains MFI-2 count bits 1-4 + Frame 1 contains MFI-2 count bits 5-8 + Frame 14 contains Sequence Indicator bits 1-4 + Frame 15 contains Sequence Indicator bits 5-8 + Remaining Frames (2-13) are reserved (set to 0H) MFI-2 contains a repeating sequential count of 00-FFH (8bits), giving it a length of 256 MFI-1 frames or a total length of 4096 frames and a 512-millisecond period.

High-Order Virtual Concatenation

The table in Figure 7 shows all payload types currently supported. Not all payloads will use Virtual Concatenation; those which are candidates for VCAT processing are highlighted in the figure, including the popular Ethernet mapping containers. The multiframe structure of the H4byte is shown in Figure 8. This figure illustrates the two-tier multiframe structure used

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

The frame number is used to compensate for wide propagation delay variations and realign data frames at the destination. All members of a group will receive the same frame number for frames transmitted simultaneously. Containers received at the destination with differing frame numbers will need realignment. The sequence number will be assigned uniquely to each member of a group and may have a range of 00-FFH. It is used to identify member position of a path signal within a VCG for proper multiplexing of recovered data at the destination. The sequence number of a given member will be the same for each frame.

these bits in conjunction, a 512- millisecond multiframe is constructed for the purpose of transporting payloads across the network and reconstructing them at the destination (Sink End). The details of the functionality of K4 bits 1 and 2 are shown in Figure 10 and Figure 11, respectively.
(K4) byte details: K4 Byte, Bit 1 same with or without LCAS

Extended LO Sig. Label Vir. Concat.

K4 1 Byte (1/500 microseconds) 2

APS
3

APS
4

ERDI
5

ERDI
6

ERDI
7

Data Link
8

1 0

2 1

3 1

4 1

5 1

6 1

7 1

8 1

9 1

10 11 12 13 14 15 1 0

16 17 18 19 20 0

21 22 23 24 25 26 27 28 29 R R R R R R R R R

30 31 R R

32 R

MFAS

Extended Signal Label

MSB (bit 12-15) 0000 0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 LSB (bit 16-19) 0000 0111 1000 1001 1010 1011 1100 1101 1110 1110 1111

Reserved

32-Frame Multiframe (16 millisecond period)

Hex Code 00H 07H 08H 09H 0AH 0BH 0CH 0DH 0EH FEH FFH

INTER PRETATI ON Reserved Mapping Under Development ATM Mapping HDLC/PPP Mapping HDLC/LAPS Mapping Virtually Concat enated Test Signal per O.181 Flexible Topology Data Link mapping Spare Reserved

Low-Order Virtual Concatenation

The process for Lower-Order concatenation is similar, though the mechanics differ somewhat. In this case, there is insufficient space in the V5 overhead byte to define all payload types in the normal Signal Label field (Figure 9). The '101' code is used to designate an Extended Signal Label for all additional types specified using bit 1 in the K4 byte.
V5 BYTE RFI-V 4 5
Note: The Multiframe phases for Bit #1 and Bit #2 are aligned

Figure 10: K4 Byte, Bit 1 Usage

Figure 10 shows the details of the K4 byte, bit 1 as related to Virtually Concatenated applications. Bit 1 establishes a 32-bit multiframe period 16 milliseconds in length. Note that one bit of this sequence is received every 500 microseconds. Bits 1 through 11 of this structure create a framing pattern used to validate information contained in both bit 1 and bit 2 of K4 for extended applications. Bits 12-19 are used to define the Extended Signal Label (payload type). Bit 20 is always set to 0. The remaining bits are reserved for future use (set to 0). It should be noted that the usage of bit 1 will be the same for both LCAS and non-LCAS Virtual Concatenation operations. Figure 11 shows the details of K4 byte, bit 2 operation. Bit 2 uses a 32-frame multiframe period of 16 milliseconds in length running in parallel to that created by bit 1. The first 5 bits contain a frame count (00-1FH) which runs continuously for a total period of 512 milliseconds. As in HO VCAT applications, the frame number is used for differential delay compensation and the sequence number is

BIP-2 1 2

REI-V 3

Signal Label 6 7

RDI-V 8

Signal Label: Used to identify the signal type: 000 - Unequipped 001 - Equipped - non specific 010 - Asynchronous Mapping 011 - Bit Synchronous Mapping (no longer used) 100 - Byte Synchronous Mapping (TU11 or TU12) 101 - Extended Signal Label for Virtual Concatenation Applications See K4/Z7 byte for extensions 110 - Test Signal (0.181) (ITU) 111 - VC AIS (ITU)

Figure 9: V5 Byte Signal Label

The K4/Z7 byte has several defined fields which are used for different purposes. The first two bits are used for Extended Signal Label and Lower-Order Virtual Concatenation. Using

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

used to identify the member position of a path signal within a VCG for proper multiplexing of recovered data at the destination.
(K4) byte details: K4 Byte, Bit 2 w/o LCAS Extended LO Sig. Label Vir. Concat. K4 1 Byte (1/500 microseconds) 2 APS 3 APS 4 ERDI 5 ERDI 6 ERDI 7 Data Link 8

Sequence Indicator Field (SQ), a Control Field (CTRL), a Group Identification bit (GID), and a Cyclic Redundancy Check (CRC) field. In the return direction (Sink to Source), the key information contained in control packets consists of a Member Status Field (MST), a Re-Sequence Acknowledge bit (RS-ACK) and a CRC field. LCAS procedures include Addition of a Member to a VCG, Deletion of a Member, Temporary Removal of a Member, and Recovery from Temporary Removal. Again, all activity is initiated by the Network Management System and managed locally by the LCAS Controller. To add a member to a VCG, the Source sends a CTRL=ADD. Multiple members may be added in one sequence of commands. The first member to respond with MST = OK is allocated the next higher SQ number. The former high SQ number is given a CTRL= NORM. The new high SQ number is given a CTRL= EOS. The new member will carry payload in the frame following the frame containing the CRC for the packet with the NORM/EOS CTRL command for that member. When members are deleted from a VCG, remaining members may require renumbering. If the highest SQ number is deleted, the next highest number has its CTRL=EOS. If any other member is deleted, the sequence number of all remaining members is adjusted. Members may be removed temporarily from a VCG when problems occur. When the Source detects a MST=FAIL for a particular member from the Sink, that member is removed from the VCG. The Source will replace either a CTRL=NORM or a CTRL=EOS with a CTRL=DNU, and the Sink will discontinue processing payload for a member upon receiving a CTRL= DNU. When the problem is resolved, the Source will receive a MST=OK for the corrected member, and that member is reconnected to the VCG. The Source will replace the CTRL=DNU with either a CTRL=NORM or a CTRL=EOS and the Sink will resume processing payload for a member

10 11 12 13 14 15

16 17 18 19 20

21 22 23 24 25 26 27 28 29

30 31

32

Frame
(16 msec.)

Sequence Indicator

RESERVED

Count 32-Frame Multiframe (512 millisecond period) 32-Frame Multiframe (16 millisecond period)

Frame Count = 0-31 Sequence Indicator = 0-63 Each Sequence number uses a separate path

Figure 11: K4 Byte, Bit 2 Usage

Link Capacity Adjustment Scheme

Link Capacity Adjustment Scheme is a companion to Virtual Concatenation and provides a real time control mechanism to increase/decrease capacity of a Virtually Concatenated Group without incurring hits to active traffic. Bandwidth needs of an application may be 'trimmed' as required via control packets. Member links experiencing failures may be removed from a group, temporarily reducing the bandwidth but not disabling the link. The Network Management System is responsible for creating, destroying and managing all VCGs. Control packets are used to synchronize changes in link capacity and are sent from Source to Sink and from Sink to Source. The control packets transmit commands and describe the status of the link. Changes are sent in advance so the receiver may anticipate the new configuration. Key information in forward direction control packets (Source to Sink) includes Multiframe Indicator Field(s) (MFI), a

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

upon receiving these commands. Subsequent container frames will contain data as payload. High-Order LCAS is built upon High-Order Virtual Concatenation. To accomplish this, some bits in the H4 byte previously defined as 'Reserved' will take on the functionality of the LCAS control packets. Figure 12 shows the H4 byte structure for HO LCAS systems. Please note that it is backward-compatible with non - LCAS Virtual Concatenation systems. An LCAS control packet is defined as beginning in MFI- 1 frame #8 and ending in frame #7 of the subsequent MFI-1 multiframe. The additional nibbles defined are shaded:
+ + + + + + +

H4 512 msec. Multiframe Parameters: Frame Indicator: A combination of the 1st and 2nd Multiframe counters (0-4095) Sequence Indicator: Number to identify each member in the VCG (0-255) CTRL: LCAS Control Word (per table) GID: Group Identification Bit (PRBS = 215 - 1). Member Status: The status report of individual members of the VCG (per table) RS-ACK: Re-sequence Acknowledge bit CRC-8: Eight bit CRC check for fast acceptance of Virtual Concatenation OH. CRC polynomial = X8 + X2 + X +1
LCAS CONTROL WORDS Command Remarks FIXED ADD NORM EOS IDLE DNU Fixed bandwidth Mode (non-LCAS) This member is about to be added t o group Normal Transmission End of Sequence and Normal Tran smission This member is not part of the group or is about to be added Do not use (the payload). The Sink side reported FAIL stat us.
2nd Multiftame frame number 0,32,64,96,128,160,192, 224 1,33,65,97,129,161,193, 225 30,62,94,126,158,190,222, 254 31,63,95,127,159,191,223, 255 240 244 248 0 4 8 12 241 245 249 VCG Member Status Member number 1 5 9 13 242 246 250 2 6 10 14 243 247 251 3 7 11 15 Member Status Multiframe

Value 0000 0001 0010 0011 0101 1111

At Initiation of a VCG all source members send CTRL = IDLE

Member Status (8 bits) RS-ACK (1 bit) Reserved (12 bits) CTRL (4 bits) GID (1 bit) Reserved (8 bits) CRC-8 (8 bits)

Figure 13: Details of HO CTRL and Member Status

Low-Order LCAS is built upon Low-Order Virtual Concatenation. To accomplish this, some bits in the multiframe sequence bit 2 of the K4 byte previously defined as 'Reserved' will take on the functionality of the LCAS control packets. Details are shown in Figure 14.
(K4) byte details: K4 Byte, Bit 2 w/LCAS: Extended LO Sig. Label Vir. Concat. APS
3

APS
4

ERDI
5

ERDI
6

ERDI
7

Data Link
8

Bit 1

H4 Byte Concatenati on Multiframe Struct ure (w/LCAS) Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7

Bit 8

H4 Byte 512 msec. Multiframe Structure

1st Multiframe Indicat or MFI1 Reserved ("0000") 1 1 0 1 Sequence Indicator (Bit s 1-4) 1 1 1 0 Sequence Indicator (Bit s 5-8) 1 1 1 1 2nd Multiframe Indicator MFI2 bit s 1-4 0 0 0 0 2nd Multiframe Indicator MFI2 bit s 5-8 0 0 0 1 CTRL 0 0 1 0 0 0 0 GID 0 0 1 1 Reserved ("0000") 0 1 0 0 Reserved ("0000") 0 1 0 1 CRC-8/1 CRC-8/2 CRC-8/3 CRC-8/4 0 1 1 0 CRC-8/5 CRC-8/6 CRC-8/7 CRC-8/8 0 1 1 1 MEMBER STATU S (MST) 1 0 0 0 MEMBER STATU S (MST) 1 0 0 1 0 0 0 RS-ACK 1 0 1 0 Reserved ("0000") 1 0 1 1 Reserved ("0000") 1 1 0 0 Reserved ("0000") 1 1 0 1 Sequence Indicator (Bit s 1-4) 1 1 1 0 Sequence Indicator (Bit s 5-8) 1 1 1 1 2nd Multiframe Indicator MFI2 bit s 1-4 0 0 0 0 2nd Multiframe Indicator MFI2 bit s 5-8 0 0 0 1 CTRL 0 0 1 0 0 0 0 GID 0 0 1 1 Reserved ("0000") 0 1 0 0 Reserved ("0000") 0 1 0 1 CRC-8/1 CRC-8/2 CRC-8/3 CRC-8/4 0 1 1 0 CRC-8/5 CRC-8/6 CRC-8/7 CRC-8/8 0 1 1 1 MEMBER STATU S (MST) 1 0 0 0 Notes: 1) MFI1 range 0-15, repeating 2) MFI2 range 0-255, repeating 3) Total Multiframe length = 4096 frames (512 milliseconds ). 4) GID is one bit of PRBS 2^15-1. All m embers of VCG will carry t he same value of GID.

High Order Control Packet

1st 2nd Multiframe Multiframe Number Number 13 N-1 14 15 0 1 2 3 4 5 6 7 N 8 9 10 11 12 13 14 15 0 1 2 3 4 N+1 5 6 7 8

K4 1 Byte (1/500 microseconds)

32-Frame Multiframe (512 millisecond period)

Low Order Control Packet

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

Frame Count
(16 msec.)

Sequence Indicator 0-63

CTRL

2 msec. MFI1 Multiframe period

0-31
Value 0000 0001 0010 0011 0101 LCAS CONTROL WORDS Command Remarks FIXED ADD NORM EOS IDLE DNU Fixed bandwidth Mode (non-LCAS) This member is about to be added t o group Normal Transmission End of Sequence and Normal Tran smission This member is not part of the group or is about to be added Do not use (the payload). The Sink side reported FAIL stat us.

G I D

SPARE

R S A C K
Frame Number 0,8,16,24 1,9,17,25 2,10,18,26 3,11,19,27 4,12,20,28 5,13,21,29 6,14,22,30 7,15,23,31

Member Status

CRC-3

32-Frame Multiframe 16 millisecond period

Member Number 0 8 16 24 32 40 48 56 1 9 17 25 33 41 49 57 2 10 18 26 34 42 50 58 3 11 19 27 35 43 51 59 4 12 20 28 36 44 52 60 5 13 21 29 37 45 53 61 6 14 22 30 38 46 54 62 7 15 23 Member 31 Status 39 Multiframe 47 55 63

256 Multiframes total

1111

At Initiation of a VCG all source members send CTRL = IDLE

Figure 14: K4 Bit 2 Structure for Low-Order LCAS

Figure 12: H4 Byte Structure for High-Order LCAS

A CRC-8 is used to validate the control packet at the Sink End for immediate acceptance of changes, facilitating the synchronization of Source and Sink. Figure 13 shows the details of CTRL and MST fields.

Inter-Working Between LCAS and Non-LCAS Systems

Situations may arise where equipment supporting LCAS may be installed in networks where other equipment supports Virtual Concatenation alone. The LCAS layer has been designed in such a way as to facilitate inter-working of the two

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

types of equipment. To permit this operation, non-LCAS receivers will ignore all bits except the MFI and SQ number. The non-LCAS Sk always returns MST=OK. An LCAS receiver will recognize a signal from a non-LCAS transmitter (CTRL=00H and CRC-8=00H) and ignore all bytes except for MFI and SQ number, thereby reverting to a non-LCAS mode of operation.

It should be noted in this example that no changes will occur with respect to the first member throughout the entire process. Similarly, for larger groups, 'ADD' changes will only affect the last active member of the existing group and the new members being added.
Typical LCAS Scenario: Add (2) Members to a group of 2 Mem #1 (Norm)
Add

Mem #2 (EOS) Sk

Mem #a (new) Sk

NMS

Command

LCASC

Sk

VC-12 LCAS Examples

As a graphic illustration, let us examine LCAS in action. We will look at two cases: normal bandwidth increase and decrease operations using VCGs made up of TU-12/VC-12s. To be sure, other scenarios exist, but a look at these two cases will give the reader reasonable insight into the workings of this service. We should keep in mind that the tributary containers in the VCG may be routed over different geographical routes and may incur various delays. Similarly, the TUS used in the return path may be subject to different delay characteristics. The LCAS process assumes that the VCAT process it is built upon will compensate for the delays and reconstruct the payload from its tributary containers.

Note 1 Note 2 Note 3 CTRL = ADD Note 4 Note 5 Note 6 Note 7 Note 8 Note 9 RS-ACK Inverted
Member 1 CTRL SQ MST Initial Condition NMS Issues Add Comm and So (a) sends CTRL = ADD and SQ=n; So (a+1) sends CTRL = ADD and SQ = n+1 Sk (a) send MST = OK t o So So (n-1) sends CTRL = NORM; So (a) sends CTRL = EOS and SQ = n 6 7 8 So (a+1) sends CTRL = EOS 9 RS-Ack Bit Inv erted NORM 0 OK NORM 1 OK NORM 2 OK EOS 3 OK RS-Ack Bit Inv erted Sk (a+1) send MST = OK to So So (a) sends CTRL = NORM; NORM 0 OK NORM 1 OK NORM 2 OK EOS 3 OK NORM NORM 0 0 OK OK NORM NORM 1 1 OK OK EOS EOS 2 2 OK OK ADD ADD 3 3 OK OK NORM NORM NORM NORM NORM 0 0 0 0 0 OK OK OK OK OK Member 2 SQ MST 1 1 1 1 1 OK OK OK OK OK Member a (new) CTRL SQ MST IDLE IDLE ADD ADD EOS >1 >1 2 2 2 FAIL FAIL FAIL OK OK Member a+1 (new) CTRL SQ MST IDLE IDLE ADD ADD ADD >1 >1 3 3 3 FAIL FAIL FAIL FAIL FAIL

CTRL = ADD
Connectivity Check Connectivity Check

MST = OK CTRL = NORM RS-ACK Inverted CTRL = NORM CTRL = EOS

MST = OK CTRL = EOS

Note 1 2 3 4 5

CTRL EOS EOS EOS EOS NORM

Figure 15: Adding Bandwidth to a VCG using LCAS

The NMS initiates the activity by notifying the LCASC and the Sks to be added that the change will occur. The LCASC takes over and executes the ADD command by sending control packets to the two new members with SQ# =2 to one member, SQ# =3 to the other, and CTRL= ADD to both. In the example, member a is #2 and a+1" is #3. These two members, in turn, reply back with a report of their status. The first to reply back to the So with a MST = OK will be added to the group as #2 and be given a CTRL of EOS. Meanwhile, the member previously receiving an EOS will now receive a CTRL = NORM. At this point, the group consists of three active members and is carrying a payload of 6.528 Mbps. Subsequently, the So receives the MST = OK from member 'a+1' and this member is added to the group when the So sends CTRL = NORM to 'a' and a CTRL = EOS to 'a+1'. RSACK Signals are returned from Sink to Source to acknowledge sequence adjustments.

Addition of Bandwidth in a VCG

In this example we have a total of four TU-12/VC-12 tributaries providing an LCAS service link between two nodes in the network. In our initial condition we find that our group has two or idle members, giving us a forward direction bandwidth of 4.352 Mbps. The NMS will initiate an Add operation to bring the remaining two containers on line and double the bandwidth. The LCAS Controller at the So will then orchestrate the remainder of the process (Figure 15). In an addition operation, new members will be added to the end of the sequence. At the outset, the first member of our group is carrying a SQ# = 0 and a CTRL = NORM. The second member carries an SQ# = 1 and a CTRL = EOS to indicate that it is the last member of the sequence. Remaining members of the group receive an SQ# >1 and a CTRL + IDLE to signify that they are not in use.

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

We have now adjusted the bandwidth to our desired level of 8.704 Mbps. (see Figure 16). This change has been effected in a hitless manner. Had the responses from the idle members returned to the So in reverse order, 'a+1' would have been assigned SQ# = 2 and 'a' would have been made the EOS with an SQ# = 3.
Initial Condition: Note 1
V1 V5 V1 V5 V2 J2 V2 J2 V2 J2 V3 N2 V3 N2 V3 N2 V4 K4 V4 K4 V4 K4 CTRL=IDLE, SQ>1 CTRL=IDLE, SQ>1 CTRL=EOS, SQ=1 CTRL=NORM, SQ=0 V1 V5 V1 V5 V2 J2 V2 J2 V2 J2 V3 N2 V3 N2 V3 N2 V4 K4 V4 K4 V4 K4 CTRL=IDLE, SQ>1 CTRL=EOS, SQ=2 CTRL=NORM, SQ=1 CTRL=NORM, SQ=0 V3 N2 V2 J2 V1 V5 V1 V5 V4 K4 V4 K4 CTRL=NORM, SQ=2 CTRL=NORM, SQ=1 CTRL=NORM, SQ=0 V4 K4 V3 N2 V4 K4 V3 N2 V4 K4 CTRL=EOS, SQ=3 V3 N2 V2 J2 V1 V5 V1 V5 V1 V5 V2 J2 V2 J2 V2 J2 V3 N2 V3 N2 V1 V5 V1 V5 V2 J2 V1 V5

The third member carries an SQ# = 2 and a CTRL = NORM. The fourth member carries an SQ# = 3 and a CTRL = EOS. The total initial bandwidth is 8.704 Mbps.
Typical LCAS Scenario: Delete Members #2 & #3 of 4 Mem #1 NMS
Note 1 Note 2 Note 3 Note 4 Note 5 Note 6 Note 7 CTRL = IDLE SQ=2 CTRL = IDLE SQ=3 CTRL = EOS SQ=1
Decrease Command

Mem #2 Sk

Mem #3 Sk

Mem #4 Sk

LCASC

Sk

Increment 2: Note 7

MST = FAIL MST = FAIL MST = OK RS-Ack Inverted

Note 1 2 3 Initial Condition NMS Issues DecComm and to So LCASC So (2) sends CTRL = IDLE and SQ>1; So (3) sends CTRL = IDLE and SQ >1 So (4) sends SQ=1 4 Sk (unwanted) sends MS T= FAIL Sk (unwanted) sends RA-A ck bit inverted Sk (unwanted) sends MS T= FAIL 5 Sk (unwanted) sends RA-A ck bit inverted 6 7 Sk (unwanted) sends MS T= FAIL Sk (unwanted) sends RA-A ck bit inverted NMS Issues DecComm and to SkEs

Member 1 CTRL SQ MST NORM NORM NORM 0 0 0 OK OK OK

CTRL NORM NORM IDLE

Member 2 SQ MST 1 1 2 OK OK OK

Member 3 CTRL SQ MST NORM NORM IDLE 2 2 3 OK OK OK

CTRL EOS EOS EOS

Member 4 SQ MST 3 3 1 OK OK OK

BW= 4.352 Mbps

BW= 8.704 Mbps

NORM

OK

IDLE

FAIL

IDLE

OK

EOS

OK

NORM

OK

IDLE

FAIL

IDLE

FAIL

EOS

OK

Increment 1: Note 5
V4 K4

NORM NORM

0 0

OK OK

IDLE IDLE

2 2

FAIL FAIL

IDLE IDLE

3 3

FAIL FAIL

EOS EOS

1 1

OK OK

BW= 6.528 Mbps

Figure 17: Reduction of Bandwidth Example using LCAS Figure 16: LCAS ADD Example using TU-12 containers
The NMS initiates the activity by notifying the So LCASC to cut two members from the group (Figure 17). The LCASC takes over and executes the Decrease command by sending control packets to the members it wishes to remove with SQ# >1, and CTRL =IDLE to both while at the same time sending a
Initial Condition: Note 1
V1 V5 V1 V5 V2 J2 V2 J2 V2 J2 V3 N2 V3 N2 V3 N2 V4 K4 V4 K4 V4 K4 CTRL=EOS, SQ=3 CTRL=NORM, SQ=2 CTRL=NORM, SQ=1 CTRL=NORM, SQ=0 V4 K4 V4 K4 V4 K4 V3 N2 V4 K4 CTRL=EOS, SQ=1 CTRL=IDLE, SQ>1 CTRL=IDLE, SQ > 1 CTRL=NORM, SQ=0 V3 N2 V4 K4 V3 N2 V2 J2 V3 N2 V2 J2 V1 V5 V1 V5 V1 V5 V1 V5 V1 V5

Inter-Working Between LCAS and Non-LCAS Systems

In this example we will perform the inverse process we just went through. In the previous example, we established a working VCG consisting of four active TU-12/VC-12 members. Now we will decrease the group to a size of two VC- 12S by removing the two members from the middle of the group. While a group is normally added to at the end of an existing sequence and the size of the group will be increased in stages, a decrease operation may take out any members from the group and they may be removed simultaneously. In our example we will reduce the bandwidth by half, removing the two members in the center of the sequence. In this case, we start with an orderly group as follows: The first member of our group is carrying an SQ# = 0 and a CT RL = NORM. The second member carries an SQ# = 1 and a CTRL = NORM.

Decrease: Note 3

V1 V5 V2 J2 V2 J2

V2 J2

V3 N2

BW= 8.704 Mbps

BW= 4.352 Mbps

Note: All receiving members will cease processing member payload upon receiving an CTRL = IDLE code.

Figure 18: LCAS Decrease Example in a TU-12 VCG

CTRL = EOS and an SQ# = 1 to the fourth member of the

10

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services
References:
group. As in the previous case, no changes are made to the first member of the group throughout the process. An Sk will stop processing payload for the container in question immediately upon receiving a CTRL = IDLE. In this way multiple containers may be dropped simultaneously. The last container in the group will respond with an RS-ACK to accept the sequence change and our final payload bandwidth will be 4.352 Mbps (Figure 18). The Decrease command issued to the Sk LCASC is done in case de-provisioning of the containers is desired once they are removed from the group.
! ITU-T G.707/Y.1322, October 2000, Network Node Interface for SDH. ITU-T G.7042/Y.1305, Nov. 2001, Link Capacity Adjustment Scheme (LCAS) for Virtual Concatenated Signals ANSI T1.105-2001, January 2001 "Ethernet-over-SONET Tutorial: Part 1", Chohan, H., Mukhopadhyay, A., and Schwaber, R., CommsDesign.com, April 18, 2002. "Ethernet-over-SONET Tutorial: Part 2", Chohan, H., Mukhopadhyay, A., and Schwaber, R., CommsDesign.com, April 25, 2002. Efficient Ethernet Data Transport over SONET/SDH Using Virtual Concatenation, Mugica, D., Terradillos, E., and Areizaga, E., International Conference on Emerging Telecommunications Technologies and Applications (ICETA 2001) Kosice, Slovakia, October 2001.

! !

Conclusion
Virtual Concatenation and Link Capacity Adjustment Scheme greatly enhance the data transport capabilities of SONET and SDH, facilitating the extension of LAN/WAN applications on a global basis and offering improved efficiency, flexibility and reliability to benefit network providers and customers alike. With the information provided in this paper, a reader versed in SONET/SDH will gain an understanding of these enhanced data transport methods and an appreciation for the power they bring to the field of communications.

11

Understanding VirtualOptimizing Concatenation and Link Capacity Adjustment Scheme in SONET/SDH Ethernet transport over existing infrastructure for profitable delivery of broadband services

www.transwitch.com

TranSwitch Corporation 3 Enterprise Drive Shelton, CT 06484

Copyright 2003 CMP Media, LLC TranSwitch Corporation and TranSwitch Corporation products and terms referenced herein are either trademarks or registered trademarks of TranSwitch Corporation. TranSwitch Corp., Shelton, CT is an ISO 9001:2000 registered company