Wise: Traffic Engineering & VPN Manager for A ... - KNOM

Wise: Traffic Engineering & VPN Manager for ALarge-scale MPLS-based IP NetworkTS Choi, SH Yoon, HS Chung, CH Kim, JS Park, BJ Lee, TS JeongInternet Architecture Team, ETRI{choits, shpyoon, chunghs, kimch, jspark, bjlee, tsjeong@etri.re.kr}AbstractAs the Internet is quickly evolving from best-effort networks to a very critical communications infrastructurethat requires higher quality Internet services and the delivery of such communications services becomecompetitive, large-scale NSPs or ISPs have to concern much more on the performance and efficient resourceusages of their networks. This situation naturally leads the providers to seek a possible solution from trafficengineering (TE) methodologies. Also MPLS VPN can take advantage of TE for more reliable and efficientusage of the managed network resources. In this paper, we propose an integrated TE and VPN managementsolution for a large-scale MPLS-based IP autonomous system, which addresses TE and VPN managementrequirements such as the auto-provisioning, measurement, characterization, modeling and control of Internettraffic.1. IntroductionAs the Internet is quickly evolving from best-effortnetworks to a very critical communicationsinfrastructure that requires higher quality Internetservices and the delivery of such communicationsservices become competitive, large-scale NSPs orISPs have to concern much more on theperformance and efficient resource usages of theirnetworks. This situation naturally leads theproviders to seek a possible solution from trafficengineering (TE) methodologies.Although TE has been a part of the everydaynetwork operations for large-scale NSPs and ISPs,they have been depending on legacy TEmechanisms such as IGP metric-based TE andoverlay network approach. The former can solveparts of the TE problems but has some drawbackssuch as “Blame Shifting” problem, lacks ofgranularity and instability. By changing OSPF orISIS cost metrics, a congested flow can be movedinto a newly calculated path. But this shifts theproblem into the new path instead of solving thefundamental congestion problem. Also thissolution doesn’t provide global optimization and,thus, causes instability again. The latter was usedquite often for ATM and frame relay networks buthas problems such as full mesh overhead, cell taxand lack of integration. Besides the abovementioneddrawbacks, traditional TE solutions lackthe capability to meet end-users service qualityrequirements.MPLS was introduced to address theseshortcomings and to provide predictable, reliableand efficient TE solution [1]. Mechanisms such asLabel-based packet forwarding, constraint-basedexplicit path selection and signaling are supposedto solve the problems. Practically speaking,however, the existing MPLS implementationsexposed a number of issues to be resolved. Almosteverything but signaling standard might bedifferent and the obvious result may beunpredictable operations when more than twoheterogeneous products are used in a networkdomain. Online path calculation considers onlyone LSP at a time and causes lack of globaloptimization. Also, since there is no standard wayof defining a traffic trunk, it gives another burdento network administrators to come up with its ownpolicy. Finally, the traffic measurement, analysisand configuration management is purely left up tothe service providers.According to [2], Internet TE is defined asthat aspect of Internet network engineering dealingwith the issue of performance evaluation andperformance optimization of operational IPnetworks. It encompasses the application oftechnology and scientific principles to themeasurement, characterization, modeling andcontrol of Internet traffic. Most of MPLS/BGPVPNs currently deployed depend on LDP-basedtraffic forwarding. This forbids the operators fromtaking full advantage of MPLS-TE capabilities forVPN traffic. MPLS-TE and VPN is a naturalintegration to provide better quality VPN service tocustomers and efficient and reliable usage of themanaged network resources. In this paper, wepropose an integrated TE and VPN management

solution, Wise, for a large-scale MPLSbasedIP autonomous system, which addressesthese requirements. Even though TE is the mosteffective when applied end to end, our initialobjective is for intra-domain and inter-domainissues are left for our future work. Some of thecore functionality in the server is described below.Wise stands for Traffic Engineering andVPN manager for wise Internet service engineering.• LSP/VPN Configuration Management and QuasirealtimeMonitoringWise can provide unified and consistentconfiguration panels for LSP and VPNmanagement, even if the target network iscomprised of heterogeneous routers and switches.Configuration panels are designed to be simple andintuitive, fully compatible with related RFCs, andvarious router OSes. Configured and enforcedLSPs are monitored by quasi-realtime based pollingor notification mechanisms by COPS [3], SNMP[4], or router-specific CLI, and those results arelogged and informed to network administrators viaGUI.• Versatile Views of IP, MPLS, Routing (OSPF andBGP) and VPN TopologyNot only a topological view of IP layer, MPLS androuting protocol specific views are essential fornetwork administrators to efficiently understandand respond to network and routing behaviors. Forthe sake of user’s requirements, MPLS viewscontain several sub-views such as a bandwidthallocation view, an LSP traffic statistics based linkutilization view, a link affinity view, and aforwarding adjacency LSP view. Anotherimportant function of Wise is to rendera view of global routing topology and routingbehaviors. Such views can manifest how thoseprotocols are configured, and along which pathsflows are routed. Since OSPF link-state databaseand BGP path attributes are also analyzed, networkadministrators can diagnose a suspicious routingbehaviors resulted from a misconfiguration.• TE/VPN Policy ManagementNetwork administrators can easily edit, modify,save, enforce, schedule, and withdraw variouspolicies for managing MPLS TE/VPN. During suchprocesses, illogical policy conflicts areautomatically detected and resolved by the server.• IP Traffic Measurement and Analysis for MPLSWise provides traffic measurement andanalysis capability for LSPs and VPN traffic in aquasi-realtime basis, so that network administratorscan easily detect and diagnose LSP and linkutilization, congestion, etc. Besides, when routerssupport flow-based traffic sampling functions,Wise can measure and analyze per-flowtraffic statistics which play a very important rolefor understanding the trend of traffic demandbetween routers, subnets, adjacent ASes and VPNcustomers.• Intelligent Path Computation, Recommendation,and Various SimulationsSince Wise possesses the sameConstraint-based Shortest First (CSPF) algorithm[5], which is being used by most MPLS routers andswitches, it can precompute a path for a given LSPand check its availability before, the LSP is evenenforced to a network. Utilizing this mechanism inconjunction with measured traffic demand and LSPstatistics, Wise can simulate link/nodefailures, and global optimization.This paper is organized as follows. Section 2provides an overview of the server architecture anddesign principles, requirements and decisions.Section 3 describes subsystem details on theirarchitectures and functionality. Ourimplementation experiences are noted in Section 4.Finally, we conclude the work and itemize some ofimportant future research issues.2. System Architecture and Design2.1. Overall System ArchitectureFigure 1 shows a high-level view ofWise architecture. The brieffunctionality description of each functional block isgiven below. The functional details will beexplained in Section 3.TMS DBTrafficMeasurementResultsMeasuredTraffic DataGUITMSCORBACORBASNMPCSI (Common Service Interfaces)RMS DBSNMPPollingResultsConfigurationPackageGlobalConfigPackageTMSAgentCiscoCLICISCORouterRMSRMSAgentJunoscriptClientJuniperRouterMeasurementPackageMiscPackageCORBACORBACOPSAgentACECLIACE2000COPSCORBARATEFigure 1: Overall architecture of WisePSPS DBProxy AgentPIBOSPF/BGP

Wise consists of a CommonService Interface (CSI), a GUI, a policy Server(PS), a resource monitoring server (RMS), a trafficmeasurement & analysis server (TMS), a routingadvisor for traffic engineering (RATE) and a proxyagent. CSI is service interfaces common to allservers. Its functionality includes globalconfigurations, MPLS TE/VPN specificconfigurations, topology management and trafficmeasurement & analysis. These commonfunctionalities are designed as CORBA IDL [6]interfaces to make the system scalable, extensibleand interoperable with other related systems likenetwork management systems (NMSs). Designdetails are described in the section 2.2.PS follows the architecture defined byIETF’s policy framework working group. [7] Ithandles network-wide MPLS TE/VPN policydecisions, policy rule conflict resolution andadmission control for MPLS networks. It usesCOPS protocol to transmit MPLS TE/VPN policyand resource information to/from a proxy agent orCOPS-enabled network devices. It automatescomplex MPLS TE/VPN configuration processesacross the entire managed network domain.Network resource and traffic data aregathered and processed by two servers. RMScollects network resource information such asinterface statistics, topology data and LSPconfiguration information. TMS gathers trafficmeasurement data such as adjacent AS trafficmatrix & prefix traffic matrix and analyzes them.They are stored in RMS & TMS DB respectivelyfor further processing by other servers.RATE performs simulation tasks based onthe monitored, measured and analyzed data.Simulations supported are LSP path availabilitycheck, LSP path modification result analysis,failure scenario and global optimization.Also communication between subsystemsutilizes international and de facto standardprotocols such as COPS, SNMP, CORBA, LDAP[8] and SQL to facilitate interoperability.Integration of these functionality enablesWise to automate policy-based MPLSTE/VPN configurations including traffic trunkidentification and corresponding LSPs provisioningand mapping from a traffic trunk to a VPN, tomonitor, measure and analyze network and trafficbehavior, to maintain optimized network operationsand to provide analyzed data for future capacityplanning.2.2. Design Principles, Requirements andDecisionsThe main design principle of Wise isobject-orientation. With this principle, we canmake our system more scalable, extensible, andinteroperable. Given a target managed network,appropriate object classes and their relationshipmodeling and object instance management providesystem scalability. System components can beadded without modification of the existing system.It also allows smoother integration with othermanagement systems due to the principle of objectorientation.NodeManager 1IpNodeMClassfIpNodeCClassf0..1MplsNodeMClassfMplsNodeCClassfservesVpnManager1nVpnM1 nDsNodeMClassf11NodeOspfNodeClassfDsNodeCClassfTtManager1nTtMn 11BgpNodeClassf0..1IpIfMClassfservesIpIfCClassfMplsIfMClassfLspTunnelManagerIpIfMClassf1 nFigure 2: Object Model for Common Service InterfacesnFigure 2 illustrates a part of CSI interfacesfor managing MPLS topology and measurementdata. It shows required object classes and theirrelationships. All classes specified with a capitalletter C serve for configuration purpose and oneswith a letter M serve for measurement. TtM andLspM implement interfaces to set and retrieverespective measurement data. For example, LspMclass has methods to get LSP statistics of daily,weekly, monthly or yearly basis. Node andInterface classes include associated classificationsclasses based on its type. Node can be an IP node,an MPLS node, an OSPF node or a BGP node.Similarly, an interface can be an IP interface, anMPLS interface, and so on. Although a node or aninterface can be physically the same one, it servesdifferent functions logically depending onsituations.Life cycle of each object is managed by itscorresponding manager class. Servers cancommunicate with these manager classes for themanagement of objects of interests such as creation,modification, deletion, searching for a particularobject, etc. By modeling MPLS configuration andmeasurement functionality into common interfaces,all servers in Wise can access thenInterface1MplsIfSClassfDsIfMClassfMplsIfCClassfnLsp TunnelBgpIfClassfDsIfCClassfOspfIfClassf1 1LspM11SPathnn2..nInterfaceMplsIfMClassf

necessary information if required. This allows oursystem more scalable and extensible.Our design enables representation of varioustopological views such as IP, MPLS, OSPF andBGP. It can also represent measured statistics dataover each topology. For example, IP link statistics,MPLS LSP statistics can be captured overcorresponding logical topologies. This designapproach allows Wise to be easilyextended to add additional functionality such as TEfor optical networks.Besides CSI, all other subsystems are alsodesigned based on object-orientation principle.They are realized using CORBA technology.3. Sub-system Architecture andFunctionality3.1. Policy ServerCSICORBACSI/Other PS or NMSPDMMgmt.ModuleTargetMgmt.ModuleConflictDetectionModuleGUIPolicyProcessingModuleCORBAAdmissionControlModuleCORBADBClientAPIFormat Conversion ModuleCOPS Server ModulePolicy ManagerLDAPClientAPIPolicy Decision ModuleLDAPClientAPICOPSPolicy Target (COPS-enabled or Proxy)LDAP/SQLFigure 3: PS ArchitecturePolicy RepositoryLDAPserverLocalPIB DBBack-End DBPolicy server consists of a policy manager (PM), apolicy decision module (PDM) and a policyrepository (PR). Figure 3 shows details of each submodules. PM interacts with GUI, other PS orNetwork Management System (NMS) and PR. Itreceives a policy rule, checks validity and stores inthe repository. PDM further encodes it into aCOPS message and transfers it into the appropriatepolicy targets and processes any feedback events.The details are described as follows.• PDM Management Module: To handle complexpolicy domain, each policy domain can be dividedinto a number of groups. Each group is managedby a PDM. When there are more than one PDM,this module maintains information on each PDMand finds appropriate PDM when a policy needs tobe enforced.• Conflict Detection Module: Before a policy isenforced, conflict(s) should be checked against theexisting ones. A policy rule is composed ofconditions and actions. This module checks therequested policy’s conditions and verifies that anyactions conflict with the existing ones. There aretwo types of policy conflicts: one with reflectingthe current network state (e.g., available bandwidth,utilization, etc) and one without reflecting it. Theconflict checks for the latter can be performedrelatively easily but ones for the former involveadmission control decisions and other optimizationissues. This module works closely with theadmission control module when an admissioncontrol decision is required.• Admission Control Module: A policy rule can’tbe enforced without understanding underlyingnetwork resource availability. This module checksresource status and returns an admission decisionfor the requested policy rule with the help ofnetwork monitoring, measurement and analysisfunctional blocks. [9]• Target Management Module: One PDM managesone or multiple policy targets. It maintains anumber of connected policy targets into groups.This requirement is essential to provide scalabilityin managing a large-scale network, which typicallyconsists of more than several hundreds of routers.We solve this problem by thread based moduledesign• Policy Processing Module: When a new policyrule is created or an existing rule is modified, thismodule manages its enforcement schedule.• DB and LDAP Client API: It provides an API toread or write into LDAP or Policy InformationBase (PIB) [10] DB repository.• Format Conversion & COPS Server Modules:They encode and decode policy rule(s) into /from aCOPS message and transfer it to/from appropriatepolicy targets.Policy target is a network element where theenforced policy rules are to be installed. Most ofthe current network elements, however, are notfully policy-based management enabled. We needa proxy approach in such a situation. Our policytarget architecture is designed to be flexible enoughto deal with both COPS-enabled network elementsand legacy ones. It provides transparency inmanaging multiple heterogeneous networkelements (NEs) via a NE independent API.Network element specific configuration interfacesare mapped to this common API so that the costand efforts for development and management of thepolicy target can be reduced.

3.2. Resource Monitoring ServerRMS collects network’s physical and routingconfiguration information, performs auto-discoveryof a target network topology and simple resourcestatistic like IP interface In/Out octets. Topology isnot limited to IP layer but includes routing protocolspecific and MPLS layers. MPLS topology isfurther divided into four sub-views: bandwidthallocation view, LSP traffic statistics based linkutilization view, link affinity view and forwardingadjacency LSP view. With such diversetopological views, network administrators canefficiently understand and respond to network androuting behaviors.For network topology auto-discovery, RMSfirst collects system, interface and link informationfrom MIB II [11] via SNMP polling and invokesthe topology builder methods in CSI topologyclasses. This method then triggers in sequencecreation and registration of corresponding nodes,links and interfaces via node and link managerclasses. During this process, various types of nodes,links, and interfaces are identified given theinformation from the system & interface MIBs andother configuration information. For example, aparticular interface of a node can only support plainIP forwarding, MPLS forwarding or both. Foundobjects are created accordingly. Once the initialstep of topology building process is done, itregisters newly discovered nodes and interfacesinto RMS and TMS servers for periodic statisticscollection. Figure 4 illustrates this process via aninteraction diagram and a sample source code,which is a part of the topology builder interfaceimplementation.buildTopology () {NodeRef node =NodeManager::createNode(…);…node->createIpNodeMClassf(…) ;RMS DBnode->createIpNodeCClassf(…);…IpTopology::registerNode(node); // register totopologiesMplsTopology::registerNode(node)…RMSInterface::registerNode(node->getAddress( ), …) // register to RMSLspStatCollector::registerNode(node->getAddress( ), …) // register to TMS…}RMSSNMP Polling EngineFigure 4: RMS ArchitectureSince the various topologies are known afterauto-discovery process, RMS can perform andinitiate statistics monitoring processes such asinterface inOctet/outOctet data and MPLS LSPSNMPRoutersRMSInterfaceClassesCSICORBACORBA Classes forCLI-based pollingCORBAProxyInterfaceClassesTypical C++ ClassesProxy Agentstatistics collection. Not all monitoring can beperformed by SNMP because some MIBs are notsupported by the network device vendors yet. Forinstance, many MPLS related MIBs are notsupported by the most vendors yet. Command lineinterface (CLI)-based monitoring is used as atemporary alternative in such a case.3.3. Traffic Measurement and AnalysisServerTraffic Measurement, characterization and analysisis one of the most important function in trafficengineering. TE can be efficiently realized basedon correctly measured, analyzed and historicaltraffic data. Thus, TMS is the core engine ofWise.Besides polling-based monitoring, TMS alsodepends on other mechanisms to collect andprocess raw measurement data such as cflowd [12],Cisco’s Traffic Matrix System (TMS) [9] andJuniper’s MPLS statistics file [13].The TMS manages three kinds of trafficinformation: prefix matrix, adjacent AS matrix,LSP statistics and CE/PE-to-CE/PE statistics. Theprefix, adjacent AS matrix and CE/PE-to-CE/PEstatistics are collected by cflowd mechanism.Cflowd consists of cflowd mux, cflowd and cflowdcollector. Cflowd mux is responsible for handlingraw data from Netflow-enabled network devicesand making it available to clients on the local host.Cflowd is responsible for maintaining per-inputinterfacetabular data for each device, and passing itback to a central collector. Finally, cflowdcollector retrieves tabular data from instances ofcflowd and writes data in ARTS files [14]. TheTMS uses these tools with minor modification toextract prefix matrices and adjacent AS matrices.LSP statistics are also very important data tobe collected and analyzed. This statistics datacollection is tightly coupled with the networkelement vendors. Some support MIBs and othersonly allow CLI-based access to the data. Thus, wedecided to use currently available method to collectthese data across multi vendor network devices,that is, CLI-based data collection. When relatedMIBs are widely available, Wise caneasily be modified to accommodate MIB-baseddata collection. We also use other network elementspecific mechanisms such as Cisco’s TMS andJuniper’s LSP statistics file selectively for theaccuracy of the data in addition to the CLI-baseddata collection.

TMS DBMeasuredTraffic Data(AS/PrefixMatrix)cflowdCflowd wrapper classescflowdRouterRouterRouterCSITMSInterfaceClassesLSP Statisticsvia CLICORBA Classes forCLI-based pollingCORBACORBAProxyInterfaceClassesTypical C++ Classesh * tTMSProxy Agent1 day2881 week296Figure 5: TMS ArchitectureFigure 5 shows sub-modules of TMS,relationships with other Wise functionalblocks and mechanisms used for interactions.Cflowd directly interacts with routers and CLIbasedcollection is via a proxy agent. The tableillustrates how we process the measured raw data.We store raw data into four tables: day, week,month and year tables. Each table has differentmeasurement intervals from 5 minutes to 1 day.These statistics data is conveyed to its potentialusers (e.g., GUI, PS, etc.) in two different ways.LSP statistics data is a part of M classes in CSI and,therefore, directly written by TMS to CSI’scorresponding M classes such as LspTunnelM andTtM via CORBA when this data is available afterCLI-based polling. Prefix/adjacent AS matrix datais accessed by its users via TMS wrapper classesvia CORBA again. TMS, then, retrieves requesteddata from TMS DB and converts it into CORBAdata types, which is returned as method call returnvalue. We will explain how this data is used andvisualized to network administrators in section 3.5.3.4. Routing Advisor for TrafficEngineeringht5 min30 min2 hour1 month3601 day1 year365RATE performs routing control functions andvarious simulations to assist the networkadministrators for consistent policy provisioning ina managed network domain. The networkadministrators need to know available routingpath(s) for given constraints and network resourcesstatus (e.g., utilization of links) when particularlink’s attribute(s) are modified, a new LSP iscreated or an existing traffic trunk is moved fromone path to another. Also, it is very useful tovisualize what happens when a node or a link fails.1234For a long-term capacity planning purpose, a globalpath optimization simulation in a whole managednetwork domain overcomes the limitation of per-LSP online path calculation.Path availability check functionality enablesefficient way of an LSP setup. Our server residentconstraint-based shortest path (CSPF) algorithmcan be used to compute the availability of the LSPpath with desired constraints before actualenforcement. Server-based CSPF can extend itsscope to add additional constraints besides whatonline CSPF allows. This feature is one of bigadvantages that offline TE server can provide.Path attribute modification simulation allowsthe network managers to see the side effects of themodification such as link utilization changes. Theattribute changes range from simple single attributechange (e.g., affinity value) to an entire path for anLSP tunnel change. This simulation helps thenetwork managers to create a detour route when aparticular link is congested and see the link statechanges in real-time. Since this feature isintegrated with real-time policy-based MPLSconfiguration server, it can serve as a very powerfultool to remove such congested link.Link/Node failure simulation depends ononline protection & recovery mechanism andvisualizes its effects. There are four cases: two forwhether a primary is explicit or dynamic and twofor whether a secondary is explicit or dynamic.Depends on the situation, the simulation can justvisualize the result or calculate a path using serverresident CSPF algorithm and then visualize it.Global optimization simulation is performedby the algorithms that we have developed. Thesepractical algorithm can find near optimal paths thatsatisfy the given traffic demand under constraintssuch as user bandwidth requirement, measuredtraffic volume between an ingress and an egressrouters, maximum hop count, and preferred or notpreferrednode/link list. The mixed integerprogramming formulation also calculates the trafficsplit ratio for the multiple paths. For easyimplementation at network nodes, the split ratio ischosen among discrete values (0.1, 0.2 etc.). Theproposed algorithms are applied to the MPLSnetworks that permit explicit path setup. The pathsand split ratio are calculated off-line, and passed toRATE for explicit label-switched path (LSP) setuprecommendation to network administrators. Formore details, please refer to the paper. [15]3.5. Topology and Traffic View ManagerRMS and TMS collect traffic data and analyzethem into meaningful information as described in

AVPVAVPVLVAVPVthe previous sections. These information can bemuch more useful when they are visualized inorganized manners. Topology and traffic viewmanager does this role. Figure 6 illustrates threedifferent traffic statistics view: an adjacent ASmatrix view, a prefix matrix view and an MPLSstatistics view. The adjacent AS matrix viewrepresents traffic utilization between the managedAS and neighbor ASes in terms of Mbps. Each linkis divided into two parts, each one represents trafficdirection originated from the AS that the link isattached to. And traffic volume is denoted bydifferent colors. The prefix matrix view showssimilar traffic utilization between pairs of networkprefixes of interests. Unlike the AS matrix thatshows inter-domain traffic volume, the prefixmatrix is aimed to provide managed networkdomain internal traffic statistics. Thus, the prefixrepresents AS internal network addresses. Alsoprefix level aggregation is supported to provideflexibility and unnecessary information filtering.The MPLS statistics view shows MPLS layer view.This means that both layer two links and MPLSLSP tunnel links are shown in the same topologydiagram. This helps the network administratorsidentifying which one is a logical MPLS tunnel.The bloon help in the diagram provides thisinformation. It shows whether it is an LSP tunnel,the actual layer 2 path and traffic volume of thatparticular LSP tunnel. Note that the link colorrepresents utilization in percentile not in volume.When more details about the link need to berepresented (e.g., the number of LSPs that belongto this link), table format link details can beretrieved from the corresponding DB.Statistics Window - AS Matrix ViewStatistics View Duration: 2001/05/15 - 2001/06/15Statistics View Name: AS Matrix - My AS to Neighbor ASes+AS610-AS620AS700AS620AS 210AS 200AS220SaveMPLS View - LSP Tunnel StatisticsInter-AS Traffic: MbpsAS230 +100005000-1000500 Seoul100CloseAS600AS240AS510AS500LSP Tunnel Intf: Tae-Suw-Seo,600MbpsHelpKwangjuStatistics Window - Prefix Matrix ViewStatistics View Duration: 2001/05/15 - 2001/06/15Statistics View Name: Prefix Matrix - Intra AS Prefixes+203.251.11/24-Taejon203.177.90/24203.177.70/24203.186.22/24203.186.11/24203.197.15/24Figure 6: Traffic statistics viewBesides these views, a bandwidthreservation view visualizes available/reservedbandwidth on links. Link color (affinity) viewvisualizes links’ colors in a “traffic light” form withSuwonPusanSaveTaegu203.251.100/24203.197.15/24CloseLSP Statistics: %0 ~ 2020 ~ 4040 ~ 6060 ~ 8080 ~ 100203.251.111/24203.254.20/24203.254.25/24Inter-Prefix Traffic: Mbps10005001005010Helpa color palette. Link & tunnel view visualizes L2links in one color & LSP tunnels in another color.4. ImplementationCurrently, we have almost finished prototypeimplementation of Wise based on thedesign principles described in this paper. Thecomplete prototyping will be done by the end of thethird quarter of this year. System development isunderway on Sun solaris platform. MICO [16] isused to implement CORBA interfaces of CSI andother server modules. RMS polling engine andother server internal functionality are implementedin C++ language. COPS is built from the scratchbased on IETF’s COPS-PR specification [17] withC++ language. COPS server and client protocolengine are designed and built with object-orientedmethodology to be scalable for future extension.POSIX thread is used to handle a large number ofmultiple policy target clients and maximize thesystem computation resources. Various traffic dataare stored in relational DB(s) to reduceperformance burden. Although Solaris is thedevelopment OS environment, other OS types suchas Linux and FreeBSD will be supported as well.We use Java for GUI development for the obviousreason, that is, the portability.Figure 7 shows a snapshot of our main GUIinterface. The tree control shown on the left-handside can be used to create, modify and delete MPLSpolicy rules. User-friendly policy rule editingwizards are used for the ease of a configurationprocess. Once the rules are created and stored, youcan enforce the rules either directly into a specificnetwork element of your choice or by a rolecombination.The policy-based networkmanagement architecture by IETF recommendsusing role-based enforcement only but targetspecific one can be practically useful tool bynetwork administrators who know the networktopology well. The topology view canvas on theright-hand side depicts auto-discovered networktopology from various viewpoints such as IP layer,OSPF, BGP and MPLS view. It also shows trafficutilization status in colors. Simulations arevisualized in the separate window to compare theexisting network status with modified view bysimulation.Currently, we have setup a test-bed toevaluate validity of our system. It consists of eightcommercial backbone routers (three 7000 seriesCisco routers and four M series Juniper routers andone MPLS edge router developed by a Koreancompany, RAONET [18]). Various interface typesare supported such as Fast Ethernet, Giga Ethernet,

155 Mbps POS and OC-3 ATM. They are almostfully connected so that we can test diversescenarios. We haven’t started full-scale field testyet but are planning to launch that very soon. Weexpect that some test results can be incorporatedinto our next version of the paper.Figure 7: A Snap Shot of Main GUI5. Conclusion and Future WorkMPLS was proposed as a standard TE solution byIETF to address traditional TE problems butpractical problems during deployment process havebeen identified. In this paper, we proposed apowerful TE server solution, Wise, toovercome these limitations. Yet, we have to addadditional functionality to make it more useful tool.Traffic statistics reporting function is veryimportant in the real operation scenario. CurrentMPLS TE is for a single aggregated class type butQoS-based services require class type aware TE.Wise can be extended to incorporateserver-based DiffServ-aware MPLS TE. [19] Asmentioned in the introduction section, end to endTE is the ultimate goal for true traffic engineering.However, there are many challenges associatedwith this research arena. We will look into thisproblem very carefully. Lastly, optical network isbecoming the choice of the backbone network forlarge-scale service providers. Our next long-termstep is, naturally, to research and develop a solutionfor an optical backbone network based on ourWise architecture.References[1] E. Rosen, A. Viswanathan, R. Callon,“Multiprotocol Label SwitchingArchitecture “, RFC3031, IETF, Jan. 2001.[2] D.O. Awduche, et al., “Overview andPrinciples of Internet Traffic Engineering”,Internet-Draft: draft-ietf-tewg-principles-00.txt, IETF, Feb. 2001.[3] J. Boyle, “The COPS (Common OpenPolicy Service) Protocol”, Internet Draft:draft-ietf-rap-cops-03.txt, 1998.[4] J.D. Case, M. et al., “Simple NetworkManagement Protocol (SNMP)”, RFC1157,IETF, May. 1990.[5] Juniper Network Inc., “Traffic engineeringfor new public network”,http://arachne3.juniper.net/techcenter/techpapers/200004.pdf, April, 2000.[6] OMG, “The Common Object RequestBroker: Archtecture and Specification”,Revision 2.2, Feb. 1998.[7] H. Mahon, et. al, “Requirements for a PolicyManagement System”, Internet-Draft: draftietf-policy-req-02.txt,November 2000.[8] Yeong, W., Howes, T., and S. Kille,"Lightweight Directory Access Protocol",RFC 1777, IETF, March 1995.[9] TMS,http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/tms.htm, Cisco Inc.[10] M. Fine, et al., “Framework PolicyInformation Base”, Internet-Draft: draftietf-rap-frameworkpib-05.txt,IETF, July,2001.[11] K. McCloghrie, M.T. Rose, “ManagementInformation Base for NetworkManagement of TCP/IP-basedinternets:MIB-II”, RFC1213, IETF, March1991.[12] cflowd, http://www.caida.org/tools/

measurement/cflowd/index.[13] Juniper’s stat file,http://www.juniper.net/techpubs/software.html.[14] ARTS++,http://www.caida.org/tools/utilities/arts/.[15] Y. Lee, Y. Seok, Y. Choi, C. Kim, “ExplicitMultipath Traffic Engineering in MPLSNetworks”, submitted to Globecom2001.[16] http://www.mico.org.[17] K. Chan, et. al, “COPS Usage for PolicyProvisioning (COPS-PR) ”, RFC3084,March 2001.[18] http://www.raonet.co.kr[19] Francois Le Faucheur, et al.,“Requirements for support of Diff-ServawareMPLS Traffic Engineering”,Internet-Draft: draft-ietf-tewg-diff-te-reqts-01.txt, IETF, June 2001.관심분야 : MPLS-TE, Traffic Measurement &Analysis, IP Network Simulation정형석1995: 광운대학교 컴퓨터통신석사2000: 광운대학교 컴퓨터통신박사2001-현재: ETRI 인터넷구조팀관심분야: PBNM, MPLS-TE, 망관리, CORBA김창훈1997: 서울대학교 컴퓨터공학학사1999: 서울대학교 컴퓨터공학석사1999.3-현재: ETRI인터넷구조팀 연구원관심분야 : MPLS-TE, IP Routing박정숙2000: 효성가톨릭대학컴퓨터공학 박사1999.3-현재: ETRI 인터넷구조팀연구원관심분야 : Traffic Measurementand Analysis, MPLS-TE최태상1995.12 미주리-캔사스 주립대박사1996.4 ~ 1998: ETRI 멀티미디어통신팀1999 ~ Present: ETRI 인터넷구조팀관심분야:- QoS Management and Traffic Engineering in IPNetworks- Interactive Multimedia Service System- Network, System, and Service Management윤승현1996: 성균관대학교 산업공학박사1997 - 현재: ETRI 인터넷구조팀연구원이병준1996: 서울대학교 컴퓨터공학학사1998: 서울대학교 컴퓨터공학석사2000: 서울대학교 컴퓨터공학박사수료2000-2001: 에슈컴코리아 개발팀장2001.5-현재: ETRI 인터넷구조팀 연구원관심분야 : MPLS, VPN, XML정태수1983.2: 경북대학교 전산학 석사1983.3 ~ 현재: ETRI 인터넷구조팀관심분야:- Internet & Data Networks

- Telecommunication Systems- Network Management