ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Handling Bandwidth Fragmentation: OTN way

Updated on April 6, 2013

1. Introduction

SONET/SDH networks are most widespread today. These networks were established keeping in mind only the voice (TDM) traffic. With the advent of data services and the constraints on OPEX and CAPEX to build new infrastructure, technologies were built to support data services over SONET/SDH networks. For some time voice and data could coexist on the same network. But now data seems to override voice in terms of volumes many folds. As a matter of fact voice seems to flow through packets only thus causing the incredible growth is bandwidth demands. Convergence of voice, data and video is putting tremendous pressure on the existing infrastructure. On account of operator’s willingness to use existing infrastructure more efficiently rather than having any further expenditure on CAPEX pushed researchers/engineers to come out with novel ways to handle BF in traditional SONET/SDH networks. But none of the algorithms could provide 100% guarantee of bandwidth defragmentation in either hitless way or without using any extra resources.

This incessant growth in the bandwidth requirements and limitations of traditional SONET/SDH networks to support data services efficiently beyond a limit manifested in the development of OTN standard. Though it may take good amount of time for OTN to overwhelmingly replace SONET/SDH, any new investments in optical CAPEX and OPEX will be done in OTN based networks only.

However big or small OTN network may come out to be, handling BF will still be a concern for all the network operators. As BF is observed over a period of time which impact revenues over a long run, every network operator would like to understand the panacea offered by OTN for handling BF before they decide to invest in OTN networks.

2. Limitations of SONET/SDH standards

Following are some of the shortcomings of SONET/SDH when it comes to bandwidth profiling

Contiguous Concatenation

Time slots for the standard SONET/SDH granularities (STS1, STS3, STS12, STS48, STS192) for TDM applications are contiguously concatenated. Virtual Concatenation which obviates the requirement of contiguous concatenation is typically used for data services only. Hence if an operator wants to modify a virtually concatenated circuit used for carrying data services into a TDM circuit of equal bandwidth, BF issues will still be lingering

SONET Bandwidth Profile with Conteguous Concatenation
SONET Bandwidth Profile with Conteguous Concatenation

Time Slot Alignment

Time slot assignment for standard SONET/SDH granularities needs to follow mod n rule. It means that STS 1 can take any time slot. STS3 needs to start at time slots numbered at multiple of 3. STS12 needs to start at time slots numbered at multiple of 12 and so on and so forth. It manifests that only having contiguous availability of time slot is not sufficient, modularity of the granularity also needs to be taken into consideration while allocating bandwidth.

SONET Bandwidth Profile with Time Slot Alignment
SONET Bandwidth Profile with Time Slot Alignment

3. OTN Way

A possible panacea for the constraints mentioned in section 3 would be to allow selecting time slots from the unoccupied ones at the time of allocating the bandwidth rather than imposing the rules of contiguous concatenation and mod n. This is what OTN standard allows thus obviating any possibility of BF at any time. Hence if the transport pipe has the bandwidth available, no service request would be denied.

ODTU Definition

ODTU is the tributary entity which contributes towards a multiplexed higher order ODU. There are 2 types of ODTU’s


  • ODTUjk ((j,k): {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, ODTU13 and ODTU23) in which an ODUj signal is mapped into ODUk via the asynchronous mapping procedure (AMP). In this scheme, the underlying multiplexing structure of higher order ODU is homogeneous. Following diagram depicts the multiplexed structure for ODTU12

ODTU12 with ODU1 tributary slots
ODTU12 with ODU1 tributary slots
ODTU12 with ODU0 tributary slots
ODTU12 with ODU0 tributary slots
  • ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a lower order ODU (ODU0,ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is mapped into ODUk via the generic mapping procedure (GMP). In this scheme, the underlying multiplexing structure of higher order ODU can be non-homogeneous. Following diagram depicts a potential multiplexed structure for ODTU2.ts

ODTU2.ts with ODU0 tributary slots
ODTU2.ts with ODU0 tributary slots

Note: Hence forth, we shall consider ODTU12 and ODTU2.ts for all the demonstrations.

Multiplexing ODTU12 into OPU2

Multiplexing a single ODTU12 into OPU2 will require either one ODU1 tributary time slot or 2 ODU0 tributary time slots. Mapping ODTU12 into OPU2 using ODU1 timeslot is straightforward as it will be one to one mapping between each ODTU12 and ODU1 timeslot.


From BF perspective, it makes more sense to study ODTU12 mapping into OPU2 using ODU0 timeslots.


Single ODTU12 mapping into OPU2 will occupy 2 ODU0 timeslots out of the available 8 within ODU2 frame. But unlike SONET/SDH, these timeslots need not be adjacent. This is accomplished by explicitly mentioning the ODU0 time slots occupied by ODTU12 within OPU2 frame.

ODTU12 is allotted ODU0 slot 1 and 4
ODTU12 is allotted ODU0 slot 1 and 4

A byte of the ODTU12 signal is mapped into a byte of one of two OPU2 1.25G TS #1,4 payload areas. A byte of the ODTU12 overhead is mapped into a TSOH byte within column 16 of the OPU2 1.25G TS #1, 4.


Following figure depicts the payload mapping of ODTU12 payload to OPU2 1.25G TS #1, 4 payloads.

mapping of ODTU12 payload to OPU2 1.25G TS #1, 4 payloads
mapping of ODTU12 payload to OPU2 1.25G TS #1, 4 payloads

Odd columns of ODUT12 payload are mapped into OPU2 1.25G TS #1 payload and even columns are mapped into OPU2 1.25G TS #4 payload.

mapping of ODTU12 overhead to OPU2 1.25G TS #1, 4 TSOH’s
mapping of ODTU12 overhead to OPU2 1.25G TS #1, 4 TSOH’s

JOH: Justification Overhead

TSOH: Tributary Slot Overhead


Any further bandwidth requirements for ODTU12 will be met in the similar fashion. This ensures that bandwidth allocation is not subjected to either contiguous concatenation or mod n rule thus obviating any probability of BF.


ODTU2.ts mapping into OPU2 1.25G tributary slots

ODTUk.ts permits the underlying multiplexing structure of ODUk to be heterogeneous. It means we can have a combination of lower order ODUk’s such as ODU0, ODU1 etc. provisioned within single ODUk.

An OPU2 has 8 ODU0 timeslots. To configure an ODU1 and an ODU0 we will need 3 ODU0 time slots. Let us assume that we allocate time slots #1 and #4 for ODU1 configuration and time slot #5 for ODU0 configuration

Following figure depicts ODU1 payload mapping into 2 ODU0 time slots out of available 8 under ODTU2.ts scheme.

ODU1 payload mapping into 2 ODU0 time slots out of available 8 under ODTU2.ts scheme.
ODU1 payload mapping into 2 ODU0 time slots out of available 8 under ODTU2.ts scheme.

Following figure depicts ODTU overhead mapping into 2 ODU0 time slots out of available 8 under ODTU2.ts scheme. Under ODTU2.ts scheme with 1.25G tributaries, there is a 6 byte long overhead which is copied in row 1, 2 an 3 of column 15 and 16 of the last time slot allocated to this ODTU. Assuming time slot 4 is the last time slot, 6 bytes of ODTU overhead will be copied in the column 15 and 16 of time slot 4.

ODTU Overhead
ODTU Overhead

The remaining OPU2 TSOH bytes are reserved for future international standardization.

Once ODU1 is allocated we are left with 6 unallocated time slots. Following figure depicts ODU0 payload mapping into 1 ODU0 time slot out of available 6 under ODTU2.ts scheme.

ODU0 payload mapping into 1 ODU0 time slot
ODU0 payload mapping into 1 ODU0 time slot

Following figure depicts ODU0 overhead mapping into 1 ODU0 time slot out of available 6 under ODTU2.ts scheme

ODU0 Overhead
ODU0 Overhead

In ODTUk.ts scheme too there are no restrictions of contiguous concatenations and mod n

Summary

In the OTN standard following advantages of OTN over SONET/SDH are mentioned


  • Switching scalability
  • Transparent transport of client signals
  • Higher levels of Tandem connection monitoring
  • Enhanced FEC

Somehow standards don’t mention the 5th advantage i.e. OTN by virtue of standard itself obviates any bandwidth fragmentation. This advantage in itself is sufficient to reckon with. BF is avoided by putting lots of flexibility on the selection of time slots while allocating the bandwidth. Unlike SONET/SDH, OTN puts no restrictions of contiguous allocation or mod n while allocating the bandwidth.

Comments

    0 of 8192 characters used
    Post Comment

    No comments yet.

    Click to Rate This Article