Jump to content

Virtual concatenation: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
mNo edit summary
Tag: repeating characters
Line 30: Line 30:
Each path within a group is approximately 1.5 Mbit/s (VT1.5/VC11) or 2 Mbit/s (VT2/VC12). Bandwidth is allocated using the Z7/K4 byte within the path overhead.
Each path within a group is approximately 1.5 Mbit/s (VT1.5/VC11) or 2 Mbit/s (VT2/VC12). Bandwidth is allocated using the Z7/K4 byte within the path overhead.


Bandwidth is allocated in 2-Mbit/s chunks and therefore low-order VCAT can be used to provision sub-rate traffic across 10/100-Mbit/s Ethernet used in the access network.
Bandwidth is allocated in 2-Mbit/s chunks and therefore low-order VCAT can be used to provision sub-rate traffic across 10/100-Mbit/s Ethernet used in the access network.pppppppppppppppppppp


==Virtual Concatenation Group==
==Virtual Concatenation Group==

Revision as of 09:38, 25 November 2010

Virtual concatenation (VCAT) is an inverse multiplexing technique creating a large capacity payload container distributed over multiple smaller capacity TDM signals. These signals may be transported or routed independently. Virtual concatenation has been defined for SONET/SDH, OTN and PDH path signals.

Alternate SONET/SDH concatenation techniques are contiguous concatenation and arbitrary concatenation.

Variable bit data streaming

Virtual concatenation is considered the primary enhancement to voice optimized SONET/SDH, in order to support the transport of variable bit data streams. Other recent SONET/SDH enhancements include Link Capacity Adjustment Scheme (LCAS), and the Generic Framing Procedure (GFP).

In conjunction with LCAS and GFP, Virtual Concatenation gives the advantage of splitting the required bandwidth equally among a set number of sub paths called Virtual Tributaries (VT).

The Virtual Concatenation is specified in ITU-T Recommendations G.707 (2007)[1] and G.783 (2006)[2].

Virtual Concatenation is used to split Sonet/SDH bandwidth up into right-sized groups. These virtually concatenated groups can be used to support different customers and services and bill accordingly. VCAT works across the existing infrastructure and can significantly increase network utilization by effectively spreading the load across the whole network.

Sonet/SDH is a hierarchical network. At each level, payloads are a concatenation of lower-order payloads. So, for example, an STS192 (10 Gbit/s) payload consists of four OC48 (2.5 Gbit/s) payloads concatenated together.

With VCAT, an STS192 payload could consist of a number of virtually concatenated groups, each with up to 192 non-contiguous STS1 (51 Mbit/s) payloads. Each STS1 within a group may be provisioned over different parts of the network. VCAT supports both high-order paths and low-order tributary paths.

High-Order VCAT

Each path within a group is approximately 51 Mbit/s (STS1/VC3) or 155 Mbit/s (STS3c/VC4). Bandwidth is allocated using the H4 byte within the path overhead.

Bandwidth is allocated in multiples of 51 Mbit/s and therefore high-order VCAT can be used to provision sub-rate traffic across Gigabit Ethernet. This makes high-order VCAT ideal for the metro application.

Low-Order VCAT

Each path within a group is approximately 1.5 Mbit/s (VT1.5/VC11) or 2 Mbit/s (VT2/VC12). Bandwidth is allocated using the Z7/K4 byte within the path overhead.

Bandwidth is allocated in 2-Mbit/s chunks and therefore low-order VCAT can be used to provision sub-rate traffic across 10/100-Mbit/s Ethernet used in the access network.pppppppppppppppppppp

Virtual Concatenation Group

Several Virtual Tributaries, form part of a Virtual Concatenation Group (VCG). The pragmatic use of spawning Virtual Tributaries to transport data across a VCAT enabled network is the fact that in many cases, particularly when the underlying network is relatively congested, then splitting the traffic over several distinct paths allows us to provide lower cost solutions than if we had to find just one path that meets the required capacity. Chances are this splitting of paths will also allow us to find shorter paths to channel our traffic across.

The Virtual Concatenation protocol performs its content delivery through a process called byte-interleaving. For example, given that we wish to provision a Gigabit Ethernet (n, 1Gb/s) service then we would provision it across (7) STS-nc VT’s, where each of the VCG members carry a bandwidth equivalent of V = n/k [bits/second], where in this case n = 1Gb and k = 7. What typically happens is that the data is interleaved such that the first byte is put onto VT1, the second byte is put onto VT2, and so on until the seventh byte is put onto VT7. The process repeats beginning with the eighth byte which is sent out on VT1.

Differential delay

Effectively, this helps a lot with being able to provide services at a lower cost and much faster than contiguous concatenation, it however is intrinsically bound to the problem of differential delay where each path that is created, represented by a VT has a different propagational delay across the network and the difference in these delays is what is known as differential delay (D). The major problem with differential delay is the fact that we require high speed buffers at the receiving node to store incoming information while all paths converge. This buffer space, (B) can be equated to the bandwidth delay product such that B = n * D. So for each Virtually Concatenated connection we would require B bits of buffer space. This need for buffer space eventually increases the network cost, so it is very important to select paths that minimize the differential delay, which is directly proportional to the buffer space required.

Several heuristics based algorithms exist, that attempt to minimize the differential delay to provide a solution. This is not a simple problem to tackle and is referred to mathematically as an NP-complete problem set, for which there exists no known algorithm that finds the optimum solution and terminates in a polynomial time constraint.

References

  1. ^ ITU-T G.707/Y.1322 (01/07), Network node interface for the synchronous digital hierarchy (SDH), 2007
  2. ^ ITU-T G.783 (03/06), Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks, 2006

See also