[c-nsp] TDM over IP

[Piper, James]

We evaluated TDM over Packet Transport for our internal use and found it
to perform well. Here are the results...


- Platforms Evaluated
Synchronous Digital Hierarchy (SDH) (as a performance baseline)
Asynchronous Transfer Mode (ATM)
Virtual Bridged Local Area Networks (VLAN) incorporating Cisco
Rapid-PVST
Internet Protocol (IP) with Open Shortest Path First (OSPF) Routing
Multiprotocol Label Switching (MPLS) Layer 3 VPNs

- Test Environment
W&G PFA30 / PFA35 used to connect to E1 "Test Port" of the System Under
Test (SUT)
Simulated network load was applied to the SUT at incremental levels as
necessary

- Tests Conducted
Quality of Service
Bit Errors
Latency
Voice Quality
Service Restoration

- Interfaces Tested
Unstructured E1
Direct PABX interconnection (E1)
n x 64Kbps, synchronous serial (9.6 / 19.2 Kbps), asynchronous serial
(9.6 / 19.2 Kbps), PABX extension*

* Only for SDH and ATM tests as the MUX was redeployed as it was
required elsewhere

- Test Results

- Quality of Service
All platforms were capable of providing a variety of levels of service
thus enabling high priority flows to continue in the presence of large
amounts [to the point of saturation] of lower priority flows. 

- Bit Errors
All platforms were capable of transporting the encapsulated TDM flows
without any errors under near and over saturation conditions.

- Latency
The measured one-way latency for each platform is given below (in
milliseconds):
SDH		0.2 
ATM		1.6 (varies within defined limits)
VLAN		3.6 / 4.4 *
IP / OSPF	3.6 / 4.6 *
MPLS		3.6 / 4.1 *
* For the RAD IPMux / Cisco 3825 respectively.

- Synchronisation
In order to reconstruct the TDM stream:
the ATM requires an explicit clock (either directly sent, externally
input or reconstructed) - highly sensitive to clocking configuration
RAD IPMux and Cisco 3825 construct a clock using adaptive techniques -
longer latency but more robust

- Voice Quality
The quality of the voice calls carried over the various platforms could
not be distinguished from the SDH platform baseline using subjective
listening tests.*

* The MPLS platform could not be tested as the PABX was redeployed as it
was required elsewhere

- Service Restoration
The measured service restoration time for each platform is given below
(in seconds):
SDH		~ 1
ATM		~ 30 
VLAN		~ 9 	(<200 ms network convergence) 
IP / OSPF	~ 2-3	(<200 ms network convergence) 
MPLS		~ 1-3	(<200 ms network convergence) 


Hope that helps in your evaluation...

James.


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
alaerte.vidali at nsn.com
Sent: Wednesday, 15 August 2007 22:11 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] TDM over IP

 Hi,

Have you used it?

I followed draft and Cisco implementation. Now looking for field
problems related to clock.

Tks.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/




This e-mail and any attachments may contain confidential information that is intended solely for the use of the intended recipient and may be subject to copyright. If you receive this e-mail in error, please notify the sender immediately and delete the e-mail and its attachments from your system. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. Any opinion expressed in this e-mail and any attachments is not an opinion of RailCorp unless stated or apparent from its content. RailCorp is not responsible for any unauthorised alterations to this e-mail or any attachments. RailCorp will not incur any liability resulting directly or indirectly as a result of the recipient accessing any of the attached files that may contain a virus.