architecture for tdm circuit emulation

8/3/2019 Architecture for Tdm Circuit Emulation

1/6

ARCHITECTURE FOR TDM CIRCUIT EMULATIONOVER IP IN TACTICAL NETWOR KS0ivind KureQ 2 S , N T N U O.S. Bragstads plass 2E , N-7491 T r ondhe im, N or w a y ,

emai l : okure@ item.ntnu.noandIngvild SortebergBase l ine Comm unica t io ns as , Havegt . 2, N - 2 0 1 0 S t r s m m e n , N o r w a y ,email : [email protected] u t 0vsthusForsvarets forskningsinstitutt (FFI), P.O.hox 25, N-202 7 K jeller, Norw ay,email: [email protected]

TDM circuit emulation over IP (TDMolP) may be used asa migration step towards a full IP solution. Severaldifferent TDMolP architectures exist offering differentdegrees of robustness, service quality guarantees andmanagement. The possible architectures are presented andtheir pr os and cons are discussed.Several tactical TDM based networks use f looding andpruning fo r routing and resource reservations. Weproposea solution based on IP multicast that is efficient andrequires no changes to the existing TDM signaling andmobility handling. The same signaling and routing schemema y be used fo r tactical Voice over IP (VOrP).In TDM nehvorks, resources are reserved during callsetup. Priorities are invoked if there are insufjcientresources available, and one or more lower priori ty callsare released. We discuss different QoS architectures andmechanisms that may be used to support the militarypriority scheme and the stringent delay and lossrequirements of TDMoIP.

INTRODUCTIONMany military tactical networks are based on a TDMinfrastructure (e.g. Eurocom) supporting telephony anddata communications services. The TD M networks do no toffer a very flexible transmission service for data and isdifficult to adjust to changes in com mun ication demands.The motivations fo r IP based tactical networks aretypically cost/perfonn ance, use of COTS technology andthe desire to support the requirements of Network CentricWarfare (NCW). The main argument against using a pure1P infrastructure is that Voice over 1P (VolP) is still animmature technology and requires extensive investmentsboth in the voice network iufras aucture and new terminals,e.g. VolP telephones. Also existing VolP solutions do notsupport the military mobility, priority and rohusmess

requirements. VoIP will even tually be the fav ored solutionfor carrying voice traffic, hut until these requirem ents canbe met a possible solution is to emulate the existing TDMservices over an all-IP infrastructure. This requires smallchanges to the existing telephony services and capitalizeson existing inves tmen ts and at the same time offers aflexible utilization of the network resources. TDM over IP(TDM oIP) is therefore a likely migration solution and maybe deplo yed as part of IP based tactical networks.There is ongoing work within IETF Wo rking Group PWE3(Pseudo Wire Emulation End-to-End) to standardizesolutions for emulation of TDM over packet switchednetworks [l], [2] and [3]. The standardizations work hasconce ntrated its effort on defining the packet encapsulatio nformat for TDM signals. Little effort has been spent onaspects like call routing, signaling and QoS handling.The contributions of this paper are in three areas, 1)evaluation of different TDMolP architectures for tacticaldeployment, 2) the design of protocols for TDMolPsystems, where flooding is used in the propagation ofTD M signaling messages and 3) a discussion ofmechanisms supporting QoS and priority handling. Theresults of the last two areas are also relevant whenintrodu cing VoIP in m ilitary networks.First the problem s related to the use of TD Mo IP in militarynetworks are presented. Then four different architecturesoffering advantages and disadvantage with respect tosupport the m ilitary service requirem ents are discussed. Arouting protocol mirroring the existing flooding basedTDM routing is presented and finally the applicability ofdifferent QoS architectures is discussed based on the needto offer the required functionality and robustness.

PROBLEM STATEMENTThe main reason for deploying TDMoIP in militarynetworks is that it offers a co st-effective migration solutiontowards a pure IP solution.

9210-7803-814&8/03/$17.M(C)2003 EFE.


2/6

Commercial products are available offering encapsulationand de-capsulation of TDM trunks or individual channels.However, direct deployment of existing COTS TDMolPsolutions is not recommended. There are significantdifferences in the service requirements, for example inmilitary networks there is a need to support per callpriority levels and efficient re-affiliation solutions. Alsothere is a huge difference in the operational networkingconditions for private enterprise networks and militarytactical networks. In tactical networks, it can no t beassumed that the network always offers sufficientbandwidth. Therefore, robust mechanisms are required toensure fast response to congestion situations and avoidwasting network resources.

TDM OVER 1P ARCHITECTURESThere are two main architectures, unstructured andstructured TDMoIP. In addition, there are three alternativeways to emulate a structured TDM circuit. The differentmethods are presented and discussed based on their abilityto support the requirements of militaly tactical networks.These requirements are: 1) end-to-end quality of servicetaking into account the need to support different levels ofpriority, 2) support for network and user mobility withoutrequiring manual configuration of network elements and 3)efficient network utilization.The TDMolP functionality may be implemented in theTDM switch itself or as a separate adapter. We have notmade any assumptions regarding the placement of theTDM oIP functionality and view this as an implementationchoice that w ill depend on cost and whether existing TDMswitches can be extended with this new func tionalityA. Unstructured TDM over 1PIn unstructured TDMoIP, the TDM stream is transparentlyencapsulated and transported across the IF' network, e.g.the 1P network is viewed as point-to-point links. The mainadvantages are that the TDM circuit emulation functionsmay be implemented without any understanding of theTDM services and signaling and that it requires nochanges to the TDM network nodes. Silent suppressionmay be supported to offer a better utilization of networkresources. The disadvantages are that the solutionintroduces uncontrollable delay since the TDM signal mustbe packetized and de-packetized at every TDMolP hop.Also there is no way to control that the TDMoIP packetsare not sent over the same links several times resulting inlow network utilization. In a large network, the total end-to-end delay may cause poor voice quality. Congestion inthe IP network will affect entire trunks, causing degradedservice quality for all calls including high priority calls.Therefore, an unstructured TDMoIP solution can notsupport the military priority levels and the architecture isnot discussed further in this paper.

B. Structured TDM over IPStructured mode refers to the case where TDM channelsare individually transported across the 1P network orgrouped depending on their destination.The advantage of the structured mode is that only activechannels are transported across the IP network ensuring avery efficient utilization of network resources. TDMolPpacketization and d e-packetization is only performed once,reducing the end-to-end delay considerably. HandlingTDM channels individually allows channel managementbased on priority and quality of service requirements. Thedisadvantage is additional packet and processing over-heads. If TDM adapters have stringent delay requirements,the number of small packets may become very large.Packet overhead can be reduced by grouping TDMchannels towards the same destination into the samepacket, irrespective of their priority. The disadvantage ofthis scheme is that more high priority traffic is generated.There are three alternative me:thods that might beimplemented to support structured rD Mo lP.

- lK l 0rlracU0naIElm1 TDMlrunkoverIP1 - - - TO M user channels over IPFigure 1:Alternative 1 - structured TDM olP in trunk mocIn the first alternative, individual $channelsare transportedin the same way as in the trunk mode, i.e. along the routedetermined by the TDM routing and packets are relayed ateach TDMoIP adapter, see Figure 1. The advantages ofthis alternative are that the existing TDM routing can beutilized and the TDM samples only experiences onepacketization delay . The disadv.antage is that that theTDMoIP adapter must act likc an application layergateway supporting switching of TDMoIP packets. Thiswill require that the TDMoIP adapter understands theTDM signaling and keeps a forwarding table with themapping between the next T DM hop and IP bop for everyTDM channel. This alternative may also result in largerdelay du e to many hops and less e:fficient utilization of thenetwork resources since TDM samples are not necessarilytransported alo ng the sho rtest 1P route.In the second alternative, the signaling channel is set upaccording to the TDM trunk axchitecture, but th e userchannels are routed directly between the source anddestination TDMoIP adapter, Figure 2. The advantages arethat this minimizes the delay by no t having to route the

922


3/6

TDM voice and data traffic via many TDMoIP adaptersand it still ensures that existing location and mobilityservices are supp orted. There is no need to make extensivechanges to the TDM signaling protocol. The disadvantagesare that since the user and signaling channels are routeddifferently, network failures may cause the TDM serviceto experience an inconsistent network view. Also, theTDM signaling will impose a call admission controlscheme based the link capacity seen from the signalingeven though the 1P network may have available resources,and vise versa the IP network may not have enoughsources while the TDM signaling does not see this andlmits new calls.

- OM signalingchannels over IPTOMuser channel$ ovef IP- -Figure 2: Alternative 2 - structured TDM olP with trunkedsignaling and directly routed u ser channels.In the third alternative, both the signaling and userchannels are routed directly between the source anddestination TDMo IP adapters. The advantages are that theTDM system takes full advantage of the IP least cost(shortest path) routing and fault management and trafficanalysis is made easier. The disadvantage is that it doesnot directly support all existing serv ices and requires moreextensive changes to the signaling and routing to supportlocation and re-affiliation of users. The rest of the paperdiscusses solutions for this alternative.

CALL ROUTINGTactical TDM n etworks often utilize flooding and reversedspanning tree path for call routing. This allows for robustlocation and re-affiliation of terminals an d users at the costof overhead.For TDMoIP, TDM addresses are mapped to 1P addressesand routing of TDM signaling messages in the IP networkis similar to the telephony routing experienced in VolPsystems. Three call routing solutions are presented; 1)TRIP (Telephony Routing in IP), 2 ) use of location'directory servers, and 3) a multicast based solution.A. Telephony Routing in 1P (TRIP)TRIP 141 is standardized by lETF an d is a BGP4-basedinterdomain call routing protocol used to exchangetelephone num ber ranges that are serviced by the differentvoice gateways or localization servers (LS). TRIP is

intended for interconnection of VolP and traditionaltelephony networks. In addition to telephony numberranges, TRIP supports exchange of policy and accountinginformation across adm inistrative bound aries.TRIP may be used to exchange information betweenTDMoIP adapters. This would include telephone numberranges supported and possibly TDM capacity information.The main disadvantage of using TRIP is that mobilityhandling is costly to support; every re-affiliation wouldrequire distribution of explicit routing updates to allTDMolP adapters. The result is increased networkoverhead and large routing tables since aggregating ofrouting information becomes difficult. TRIP requires TCPsessions to be established and maintained. Depending onthe number o f TDMo lP adapters, substantial ov erhead maybe introduced. The advantage of using TRIP is that itsupports a smooth transition towards VoIP, assuming thatVoIP routing w ill be based on TRIP.B. DirectoryIn a directory approach, the mapping between IP addressand TDM addresshumber is maintained by updatingdirectories. When a user moves or a TDMoIP adapterchanges its IP add ress, the directory is updated. A user thatre-affiliates must register at the local directory and theinformation is either distributed to all directory servers orto a master directory server if a hierarchical directorystructure is supported. When establishing a new call, theoriginating TDMo IP adapter queries its local directory forthe 1P address of the TDMolP adapter serving theterminating subscriber. If the local directory holds theinformation, it is given to the originating TDMolP adapterdirectly. If not, the local directory must send a requesteither to the m aster or to all directory servers.The disadvantage of this solution is that it is costly toprovide a reliable and robust directory service. Backupsolutions must be implemented in case of server failuresand robust and efficient replication schem es are required tosupport mobility. Replication may result in large networkoverhead, particularly in the case of many mob ile users.We do not recommend a directory based location servicesince it requires not only the introduction of a directorysystem and its related protocols, hut also additionalfunctions in the TDMoIP adapters to update the directoryand process requests. Finally, we also believe that thissolution is less robust than ou r recommend ed solution.C.Multicast based call routingWe recommend a TDMoIP call routing mirroring theexisting TDM call routing in order to support the exitingTDM m obility scheme. The underlying idea is to emulatethe TDM spanning tree search in the IP network, comb inedwith caching of hints for the location. This can he done

923


4/6

using IP multicast. The strength is that each TDMolPadapter does not need know the address of the otherTDM oIP adap ters in the IP network. All TDMoIP adapterswithin an adm inistratively defined area are members of thesame multicast group. Standard multicast routing protocolsare used to es tablish a distribution tree.When a new call is initiated, the originating TDMoIPadapter checks if it has an entry for this telephone numberin its routing table. The call routing table holds a list ofphone numbers, their associated IP address, outgoinginterface, age, and flags for additional information. If arouting entry does not exist, has timed out, or receives noresponse, the call setup message is sent to the IP multicastaddress and is routed along the multicast tree. The callsetup messages will be processed by all members of themulticast group, and the TDMoIP adapter serving therequested telephone number will respond. The exactprocedure depends on the size and structure of thenetwork.In networks where the so urce and destination alway s havedirect 1P connectivity, the response message contains theterminating TDMolP adapter's IP unicast address. Thisaddress is then added to the originating TD MoIP adapter'srouting table. Multicasting is then essentially an effectiveaddress resolution mechanism .In large multi-dom ain networks, wh ere routing throughTDMoIP adapters or call servers is required, the p rocedureis m ore complex. The TDMoIP adapters may be membersof more than one multicast group offering a bridgingfunction. In this case, an identifier is required to uniquelyidentify a call setup message. This ensures that the samesetup message is not introduced into the same multicastgroup or the same network several times. Typically, theoriginator and a local sequence number are used asidentifier.When the TDMolP adapter receives a call setup message,it checks whether a valid entry already exists in theforward ongoing path table. If not, the address of thesource TD MoIP adap ter and the identifier are stored in thereversed outgoing path table. The call message is thenforwarded to the m ulticast address for the new area, afterthe reversed outgoing path table has been checked to avoidflooding loops. This is repeated by every TDM oIP adaptereach time area borders are crossed. Eventually the correctTDMolP adapter receives the call setup message and aresponse is generated.Th e format of ;he signaling packets m ust be augmentedwith a path metric and the address of the forwardingTDMoIP adapter or call server. As multicast signalingpackets are received, the outgoing reversed path table must

be recalculated to identify the optimal previous hop. ATDM oIP adapter can potentially receive m ultiple co pies ofa signaling message, since there can be many potentialforwarders. The first packet will be forwarded after aconfigurable hold time; the rest will only update thereversed tree. The path cost in the signaling message willnot necessarily be correct since there is always aprobability that a shorter path to the source has beendiscovered after the messag e was forwarded. The holdingtime before the message is forwarded at the boundarybetween two areas represents a trade-off between delay inthe signaling message and the accu racy of the cost metricused. The call setup response message follow s the reversespanning tree generated in the forwarding process.The preferred multicast protocol is primarily a function ofwhether all routers are multicast mabled, and the densityof TDMoIP adapters to routers. Due to the relatively lowamou nt of signaling traffic and an equ al number of senderand receivers, a sh ared tree will be the o ptimal choice fordistribution tree. Multicasting can use scooping to avoidmulticast requests to parts of the network where thebandwidth is very limited. The robustness of the solutionwill depend on the choice of multicast routing protocol.

QUALITY OF SERVICE ARCHITECTURESIn existing tactical TDM netw orks, routing of the signalingmessages and routing of the call follows the same path.This assures that resources are available at each TDM hop.Military TDM services also suppo rt three or four levels ofpriority. To support this functional.ity, he IP network musthe ab le to pre-empt low priority calls and assure that highpriority calls are granted sufficient resources. This sectiondiscusses different methods to guarantee the quality ofservice (QoS) for the TDM traffic in an 1P network.A. IntServ an d DiffServIETF has standardized two m ethods for supporting QoS in1P networks. T he Integrated Services (IntServ) architecture[5] offers per-flow resource reservation and 'admissioncontrol, and uses RSVP (Resource reservation Protocol)for signaling [ 6 ] . RSVP may be textended to support pre-emption and can he used to handle the military priorityscheme. The m ain disadvan tage is that every network nodeis required to hold per-flow state information. This maylead to scalability problems when handling many flowsand is the m ain reason for the lack o f comm ercial interestin IntServ. Another problem with IntServ is that RSVPmessages can not pass through IF'sec devices directly, butrequires functionality as specified in [ll].The D ifferentiated Serv ices (Dift%erv) architecture [7] wasdefined as a respo nse to the IntSetv scalability problems. Itis based on flow aggregation. 1P packets requiring thesame treatment are marked using the Differentiated

924


5/6

Services Code Point (DSCP), a 6-bit encoded field of theDifPjerv (DS) byte in the IP header [8]. DiffServ capablerouters implement packet forwarding behaviors, Per HopBehaviors (PHB), for distinct traffic types based on theDSCP-value. Currently two PHB are standardized,Expedite Forwarding (EF) and Assured Forwarding (AF)[9]. The latter supports four classes and w ithin each classpackets can be assigned three different levels of dropprecedence.The routers realize the different PHB using Active QueueManagement (AQM), a combination of packet schedulingand discard strategies. The discard strategies typically userandom packet discard, e.g. Random Early Detection(RED), spreading the packet loss to several flows in orderto shed load during periods of congestion.B.Explicit Congestion Notification (EC N)EC N [IO] is a mechanism used to control TCP flows andmight be used either alone or together with DiffServ. ECNoffers a method where routers when detecting increasingtraffic load marks packets by setting two of the bits in theTOS/DS field to notify the end system about the networkcongestion. The end system acts upon this by requestingthe TCP sender to slow down. If used with TDMoIP, theTDMoIP adapter must be able to read the ECN field andinitiate a call termination or block all new calls. ECN mayimpose a problem with IP security, since it requires thatthe TOSiDS field is carried transparently across securityboundaries. The main advantage of using ECN is that itoffers a possibility to notify the end systems of networkcongestion before packet loss occurs.

PROPOSED QOS M E C H A N I S M SSince the TDM system has no control of the routing andtraffic load in the IP network, mechanisms are needed toensure that the TDMoIP system responds by reducing theinput load and preve nting additional calls to be establishedwhen the network resources are exhausted.A. Congestion con trol mechanismA standard AF-based DiffServ solution is not suitablesince the existing drop mechanisms (e.g. RED) tends tospread the packet loss to the maximum number of flows.Depending on how TD M reacts to packet loss, the result iseither a prolonged period of reduced subjective quality fo rmany calls or the termination of a larger than requirednum ber of TDM flows. For similar reason s a pure tail-dropmechanism is not an alternative. I f the synchronicity ofTDM traffic was preserved in the network, a tail-dropmarking scheme would focus on the same sequence ofpackets ensuring fast shutdown of the offending flows. Asthe routers disturb the relative sequence, the likelihood isthat a larger num ber of flows will be affected.

We prop ose a DiffServ based architecture with a mo difiedqueue management. The Assured Forwarding PHB is used ,and the call priority is mapped to an AF drop precedence.Th e probabilistic drop mechanism is replaced with acombination of tail-drop and ECN marking of a fixednumber of packets. The TDMoIP adapter reacts to theECN marking by closing down the connections. Thisensures an adaptive load control mechan ism,There is a delay (Round Trip Time + processing) from thefirst m arking until the queue ex periences a reduced load. Ifthe EC N marking is continued in this period, a largernumber of calls than necessary will have been marked fortermination. By marking only a fixed number of packets,we bound the number of flows that are terminated. Afterthe given number of packets has been marked, the queuediscipline reverts to tail-dropping where packets arediscarded if the queue length is above the watermark forthe drop precedence. Tail-drop is activated for aconfigurable period of time, determined by the Rou nd TripTime. to protect the downstream routers from furthercongestion. The ECN mechanism is rearmed after aconfigurable time-out.The network operator can by changing the number ofmarked packets; make a trade-off between responsivenessto overlo ad and utilization of the network.Pre-emption of traffic flows is ensured by mapping theTDM priority levels to the drop precedence levels of theAF-class. If a link receives too much traffic, packetsbelonging to the low priority class are cand idates for beingECN marked and dropped first. This mechanism ensuresthat higher priority calls going through the congestednodes are shielded.B. Admission controlOne inherent problem in the use of DifBerv with AQMan d our proposed solution with ECN marking is the lack ofstability during severe congestion. In TDM, admissioncontrol ensures that new ca lls will be denied wh ile existingcalls are untouched. With the various DiffServ schemes,existing and new calls have the same probability of beingterminated, since flow termination is based on randompacket drop or marking.From a fairness view point this is accep table; long lastingcalls should not always be protected. However, there is asubstantial difference in the stability. Protecting existingcalls ensures that at least established calls are allowed toprogress and terminate naturally. U nder severe congestionrandomly dropping one of the existing calls createsthrashing where nothing is accomplished. Therefore, theproposal must be augmented with an admission controlmechanism.

925


6/6

The objective of call admission should be to avoidthrashing. The simplest solution will be to add a triggerfunction with a refresh timer for blocking new calls in theTDMoIP adapters. Once an adapter experiences a dropfrequency above a limit for a given priority class, it willblock all new calls for that class. It will remain in blockingstate as long as the drop frequency is above the limit plus aconfignrable interval before it starts accepting new callsagain. This is a fair and distributed admission controlscheme that will be used only during severe congestion. Itis timer based to ensure that an adapter will not remainblocked, while other adapters create more traffic on acongested path. It will only affect adapters that generatetraffic on congested paths. The disadvantage is thetemporal uneven distribution of blocked adapters; somemay be blocked while others continue to accept traffic.However, eventually all will cycle through the blockedstate or the network will reach a new stable operatingpoint. This proposed scheme will not be affected by theintroduction of IP security. This is the sole advantagecompared to an IntServ solution.

FUTURE WORKTo evaluate ou r QoS scheme, we have initiated asimulation activity to determine the effectiveness of theadmission control scheme and packet loss both duringlimited network congestions and during massive re-routingcausing extensive congestions. The initial simulationsconfirmed the unsuitability of RED during congestion forTDM calls, while our proposed algorithms were able tolimit congestion in a controlled fashion. However, undersevere congestion there is still some risk that a highpriority packet is lost since buffers are not purged of lowpriority packets. We would also like to compare oursolution with a pure IntServRSVP based solution lookingat bloc king probability an d robustness.

CONCLUSIONSBased on OUT analysis we recommend that a TDMolPsolution for military tactical networks is based on thedirect routing of individual TDM channels. This allowssupport for military priority as well as offers the mostefficient utilization of resources and simplifies networkmanagement since the routing of TDMoIP calls are basedon the IP routing.It is not possible to map a particular TDM address to anassociated IP address. Existing IETF proposals for VoIProuting, e.g. TRIP (Telephony Routing in IP), are notapplicable. Instead, we propose a call routing protocolbased on IP multicast that is efficient and requires nochanges to the existing TD M signaling. The call setupmessages are efficiently flooded to a multicast group witha minimum of state information required. Additionally, a

hint based caching scheme can be odeployed to minimizedelay and overhead even further.Due to low bandwidth and th e need :for efficient utilizationof resources in military tactical networks, TDMoIPrequires support for congestion and call admission control.We recommend a solution based on a combination of ECNand packet dropping. ECN is used. to signal congestionwhile packet drops are monitored in the TDMoIP adaptersand if it increases above a defined threshold, new calls areblocked unless they have higher priority than the existingongoing calls.

ACKNOWLEDGEMENTSWe would like to thanks our colleges at ThalesCommunications AS in Nonvay for valuable input to thediscussions of some of these topics.

REFERENCLS[ I ] A . Vainshtein and YStein (Ed.), Unstructured TDM

Circuit Emulation Ser vice cver Packet SwitchedNetwork (UCESoPSN), Internet Draft

architecture for tdm circuit emulation

Documents