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.

    working

    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://hubpages.com/privacy-policy#gdpr

    Show Details
    Necessary
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
    Features
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Marketing
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Statistics
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)