Friday, June 05, 2009

What Bandwidth Solution (T1, DS3, OC3) Would You Migrate Toward For A Supply Chain Network .... And Why?

All these access methods are last-mile alternatives with max Bandwidth limitations .... for example: T1=1.5Mpbs, DS3=45pbs, etc.

What you need is a scalable (easily increase Bandwidth for growth), secured (at least as good as layer2 OS equivalent), and flexible (connect various entities that will be part of the SCM). IMHO, I would rather explore what WAN technology would be a better fit, ex MPLS or VPLS than access methods. I truly like the latter because of inherent flexibility, protocol independence, coverage, scalability, security, and yes, flexibility. Some providers may also offer you a Secured Internet gateway option thru the xPLS backbone for ubiquitous connectivity .... and “bring you own internet” connectivity options for smaller B2B links.

First and foremost you must decide the following about the WAN architecture of any supply chain organization .....

* How many locations you would like to connect

* Architecture .... hub and spoke or mesh architecture

* What applications would be run on this network

* Voice, Video, Data .....

- Precisely which applications will be run in case of Data.
- what will be the % each QoS will take, the total of all three should be 100%.
- Voice is the premium level QoS and hence the most expensive as it is a real time communication, followed by video and then data.

* How many users precisely will be using the network at a given point of time at each location.

* What will be the concurrency factor. If you are looking for 100% concurrency or you can manage with lesser concurrency.

* What is the scope of scalability at each location and hub location.

* Will the access to internet also be given to users.

* Internet at central location can help you in implementing and enforcing various security policies of your organisation.

* Do you want to give access to the network resources to a mobile user?

Firstly I would probably consider getting a carrier VPN service for the backbone as this removes many of the capacity planning and management issues. You can then concentrate on the bandwidth required to each of the premises and this can vary depending on the circumstances.

For dimensioning the tail circuits, you need to consider the rate of transactions and the typical size per transaction. From this you should be able to work out bandwidth. If you assume largest transaction size and peak number of transactions then this will give you the peak bandwidth. Add at least 20% to this to be safe (TCP overhead will consume some of this). Also consider the service response required. It may be possible to "smooth" some of the peaks by allowing some transactions to be slightly delayed.

Of course you should, ideally, be working this out for each site over a 2 year period and planning for any growth. Find out from your service provider how quickly upgrades can be made and how much they are... it may be better to put in a bigger pipe on day 1. Where it isn't, keep track of the growth rate and factor in the service provider's upgrade time as well as internal delay caused by business case and budget approvals, PO signoffs, etc. and make sure you order in plenty of time.

The answer to all these questions will help in arriving at the MPLS bandwidth required at each hub and spoke location.

Honestly speaking no organization should ideally try to do this calculation themselves. Instead they can hire a consultant or a telecom service provider to do this activity ..... as they are experts in designing this solution, they can easily decide upon the bandwidth for each location, select suitable router, make redundancy plans, routing the traffic on atlantic or pacific routes, blah blah.

You don't buy telecommunication for the future, its too flexible - you structure your contracts for the future, you configure your network to expand, you buy the services you need.

For help in going through this analysis ... at no cost to ..... I recommend the service available here: MPLS Network Solution

Ideally I also recommend togive the freedom of providing and managing the routers at each location to the Telecom service provider. Then it becomes a managed solution and the service provider can easily monitor your network in event of an outage. They can remotely login into the routers and manage the complete network giving you higher uptimes and SLAs (Service Level Agreements).

The above discussion takes a network centric approach. I also suggest taking an application level approach to determine .....

1) application bandwidth requirements,

2) number of locations,

3) extranet/partners requirements,

4) security requirements,

5) closed network or internet based vpns.

Bandwidth doesn't solve all problems. You need a functional strategy to determine your currently capabilities, identify gaps with the solution today, identify gaps and then decide what it would take to address current and future capabilities, .... and bridge those gaps.

Labels: , , ,


Post a Comment

Links to this post:

Create a Link

<< Home