We used the 3825 with NM-CEM-4TE1 module and also RAD IPMux. Both performed similarly.
James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 16 August 2007 21:59 PM To: Piper, James; [email protected] Subject: RE: [c-nsp] TDM over IP 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:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 2:13 AM To: Vidali Alaerte (NSN - BR/Rio de Janeiro); [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, 15 August 2007 22:11 PM To: [email protected] 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 [email protected] 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. 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
