The virtual containers of the SDH have fixed sizes. These virtual containers are important for the transport of Ethernet frames over the SDH network:
It is difficult to fit the Ethernet traffic into one of these virtual containers. For many applications the containers, or contiguously concatenated virtual containers, such as VC-4-4c (600 Mbit/s) for example, are either too small or too big. This is known as the granularity problem.
Virtual concatenation is a mechanism by which a number of independent VCs can be used to carry a single payload. This way, the granularity problem is solved.
The following table shows the possible payload sizes, and the virtual containers that are used for the transport.
Payload |
Virtual containers |
Concatenation |
---|---|---|
2 Mbit/s |
1 × VC-12 |
VC-12 |
4 Mbit/s |
2 × VC-12 |
VC-12-2v |
6 Mbit/s |
3 × VC-12 |
VC-12-3v |
8 Mbit/s |
4 × VC-12 |
VC-12-4v |
10 Mbit/s |
5 × VC-12 |
VC-12-5v |
50 Mbit/s |
1 × VC-3 |
VC-3 |
100 Mbit/s |
2 × VC-3 |
VC-3-2v |
Virtual concatenation can be used for the transport of payloads that do not fit efficiently into the standard set of virtual containers (VCs).
Virtual concatenation splits the contiguous bandwidth into individual VCs, transports these VCs separately over the SDH network, and recombines them to a contiguous signal at the path termination. An important aspect of virtual concatenation is that it only needs to be supported at the end nodes (i.e. at the TransLAN® cards that interface with the end-customer's LAN). The rest of the network simply transports the separate channels.
As an example, the following figure shows the virtual concatenation of 5 × VC-12:
The 10 Mbit/s payload is put into a VC-12–5v, i.e. into a virtual concatenation group (VCG) consisting of 5 virtually concatenated VC-12s. These VC-12s can travel the network independently, and do not have to follow the same route. At the endpoint, the VC-12–5v is reassembled, and the payload is extracted.
Due to the different propagation delay of the VCs a differential delay occurs between the individual VCs. This differential delay has to be compensated and the individual VCs have to be re-aligned for access to the contiguous payload area.
The TransLAN® re-alignment process covers at least a differential delay of 32 ms.
LCAS is an extension of virtual concatenation that allows dynamic changes in the number of channels in a connection. In case channels are added or removed by management actions this will happen without loosing any customer traffic.
LCAS allows a bandwidth service with scalable throughput in normal operation mode. In case of failure the connection will not be dropped completely but only the affected channel(s). The remaining channels will continue carrying traffic. LCAS provides automatic decrease of bandwidth in case of link failure and re-establishment after link recovery.
In case only one end supports (or has turned on) the LCAS protocol, the side that does support LCAS adapts automatically to the restrictions that are dictated by the non-supporting end, i.e. the entire link behaves as a link that does not support in-service bandwidth adaptations.
Alcatel-Lucent – Proprietary
Use pursuant to applicable agreements