1 / 14

Everything about TDMoIP

Everything about TDMoIP. PWE3 – 52 nd IETF 12 December 2001. P B X. P B X. CO SWITCH. CO SWITCH. Classic Telephony. Access Network. Core (Backbone) Network. analog lines. The telephony system has two main parts: Access network (analog, T1/E1, AAL1/2)

kylee
Télécharger la présentation

Everything about TDMoIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EverythingaboutTDMoIP PWE3 – 52nd IETF 12 December 2001

  2. P B X P B X CO SWITCH CO SWITCH Classic Telephony Access Network Core (Backbone) Network analog lines The telephony system has two main parts: • Access network (analog, T1/E1, AAL1/2) • Backbone network (SONET/SDH) SONET/SDH NETWORK T1/E1 extensions Synchronous Non-packet network T1/E1 or AAL1/2

  3. P B X P B X TDMoIP Access Network Packet Network analog lines The TDMoIP approach replaces the core with a packet (IP or MPLS) network The access networks and their protocols remain ! Packet Network T1/E1 extensions T1/E1 or AAL1/2 draft-anavi-tdmoip

  4. CO SWITCH Packet network SONET/SDH NETWORK SONET/SDH NETWORK SONET/SDH CEP Circuit Emulationover Packet interconnects different SONET/SDH networks The packet network becomes a carrier’s carrier draft-ietf-pwe3-sonet

  5. IP network GW GW CO SWITCH SONET/SDH NETWORK GW DSLAM IAD Related (but different) Applications VoIP connects individual users over IP networks replacing all signaling with new protocols VoDSL connects users over DSL connections using VoATM technologies

  6. Functionality What needs to be transported from end to end? • Voice (telephony quality, low delay, echo-less) • Tones (for dialing, PIN, etc.) • Fax and modem transmissions • Signaling (there are 1000s of PSTN features!) • Timing “timeslots” … … T1/E1 frame CAS signaling bits SYNC TSn TS1 TS3 TS2 (1 byte) Note: Various proposed extensions to RTP that multiplexed voice sessions are not applicable since they only handled the voice!

  7. 24 or 32 bytes T1/E1 frame UDP IP RTP? Why isn’t it easy? Why don’t we simply encapsulate the T1/E1 frame? Because a single lost packet would cause service interruption • CAS signaling uses a superframe (16/24 frames) • superframe integrity must be respected Because we want to efficiently handle fractional T1/E1 Because we want a latency vs. efficiency trade-off

  8. I have an idea! Those problems can be solved by: • adding a packet sequence number • adding a pointer to the next superframe boundary • only sending timeslots in use • allowing multiple frames per packet ptr seqnum (with CRC) T1/E1 frames (only timeslots in use) UDP/IP for example @ 7 TS1 TS2 TS5 TS7 TS1 TS2 TS5 TS7 Good idea! That is precisely AAL1 !

  9. Why isn’t that enough? AAL1 is inefficient if the timeslots • are “hard-wired”, and • not always in use Although we can configure which timeslots are used we can not change this configuration in real-time! To allow dynamic allocation of timeslots we can use AAL2 AAL2 buffers each timeslot and encapsulates it in a “minicell”

  10. Isn’t this just ATM? AAL1 and AAL2 are adaptation protocols originally designed to massage data into a format that can readily use As we have shown, they are natural candidates for any application which needs to multiplex timeslots For TDMoIP we do not put the AAL1/2 into ATM cells (no 5 byte header) Rather we put the AAL1/2 directly into a UDP/IP packet So, NO, this is NOT ATM But it can easily interwork with ATM access networks!

  11. What about RTP? RTP is not a channel multiplexing protocol, so this issue is orthogonal to that of the previous slides RTP can be used to transport timing across IP networks It does this by providing: • a 16 bit sequence number • 1 32 bit timestamp at the expense of 12 additional overhead bytes per packet Accurate timing is important in telephony and IP networks add jitter Don’t we need RTP?

  12. When RTP is not needed RTP adds significant overhead – can we get away without it? In many TDMoIP applications all end-user equipment have access to accurate (stratum 3?) “station clocks” So timing info need not be distributed over the IP network! Even when adaptive (FLL/PLL) timing recovery is needed the RTP timestamp does not improve accuracy as compared with a sequence number since E1/T1 frames are sent at a precisely periodic rate as determined by the transmitting station clock!

  13. TDMoIP frame structure IP header (5*4bytes) UDP header * (2*4bytes) Optional RTP header (3*4bytes) TDMoIP header ** (4bytes) TDMoIP payload * The UDP source port number is used as a bundle identifier ** The TDMoIP is essentially the header defined in Martini et al Notes

  14. Further Advantages HDLC support • CCS signaling can be delivered Simple implementation • Processing for single T1/E1 performed by embedded CPU • Large system price-per-channel is extremely low • No “fork-lift” upgrade needed Field Proven Technology • 1500 units in the field • Over 5000 T1/E1 trunks Municipal networks, school districts, business parks, etc.

More Related