[c-nsp] TDM over IP

[alaerte.vidali at nsn.com]

Thanks a lot James,

We are considering 2 options:

-3825 with NM-CEM-4TE1 module
-7609 with SPA-24CHT1-CE-ATM (SIP-400 required) 

Does your test use one of these modules?

Best Regards,
Alaerte


-----Original Message-----
From: ext Piper, James [mailto:James.Piper at railcorp.nsw.gov.au] 
Sent: Thursday, August 16, 2007 2:13 AM
To: Vidali Alaerte (NSN - BR/Rio de Janeiro); cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] TDM over IP


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.