Traffic Engineering and Network Management System for QoS...

8
KNOM Review, Vol. 7, No. 1, August 2004 1 Traffic Engineering and Network Management System for QoS-Guaranteed DiffServ Provisioning 1 Young-Tak Kim Department of Information & Communication Engineering, Graduate School, Yeungnam University [email protected] Abstract This paper proposes an integrated traffic engineering and management system for DiffServ-over-MPLS services in Next Generation Internet (NGI). Using the proposed traffic engineering functions for DiffServ- over-MPLS network, the Internet service provider (ISP) can easily configure Diffserv-over-MPLS traffic flows among customer’s distributed sites, and can provide guaranteed end-to-end QoS by controlling the virtual topology of MPLS tunnel LSPs which are configured by MPLS traffic engineering. We explain the requirements and overall operations of the DiffServ-over-MPLS traffic engineering, the architecture of MPLS network management system, and its detailed functions for network configuration, MPLS E-LSP establishment, performance management, fault management, and MPLS-based VPN. This paper also provides the experimental results and performance analysis of the proposed traffic engineering and management system that configured and managed a sample DiffServ-over-MPLS network with Cisco MPLS routers. Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated service (DiffServ) 1 This research was supported by the Academic Research Support Program of Yeungnam University in 2001. 1. Introduction The major goal of Internet traffic engineering is to facilitate efficient and reliable network operations for high throughput while simultaneously maximizing network resource utilization with optimized network performance [1,2]. Two most promising schemes for the efficient traffic engineering of Next Generation Internet are differentiated service (DiffServ) [3] and MPLS traffic engineering [4]. The two schemes have been proposed and developed individually, but can be applied as an integrated scheme[5]. The DiffServ traffic engineering provides microscopic flow control for each service type with relatively differentiated priority or weight, while the MPLS traffic engineering provides macroscopic traffic control for the aggregated traffic flows. Recently DiffServ-over MPLS TE has been studied in IETF that allows end-to-end QoS to end users as well as ISPs by using multiple LSP (label switched path) in parallel [2,5,6]. However, the detail mechanism for flow control of the aggregated traffic has not been matured yet. Especially, the integrated operation of the traffic engineering functions in DiffServ and MPLS has not been studied sufficiently. In order to accomplish the objectives of traffic engineering, we must consider the service level agreement (SLA), Internet traffic engineering with DiffServ which manages the micro-flow of each service class, and the DiffServ-over-MPLS traffic engineering with traffic & QoS parameters that manages the MPLS LSP for the aggregated flow of one or more DiffServ class-types. In service level specification, the objective QoS parameters of the requested traffic flow should be specified, and the specification must be contracted between the service user and the network service provider. ITU-T recommendation Y.1541 provides a good example of the service level specification [7]. Actually, the DiffServ technology has been developed to provide differentiated quality-of-service (QoS) according to the user’s requirements and necessity [3,5,6]. The main focus of the differentiated service provisioning is to protect the premium service traffic under the network congestion by giving relatively higher forwarding priority than other usual best-effort traffic. For each differentiated service, Per-Hop-Behavior (PHB) is specified at each IP router, and the differentiated services are specified by multiple parameters, such as the source/destination address, service type, and protocol identifier. 64 different classes with distinct DiffServ Code Points (DSCP) are defined with 6- bit field. In order to simplify the classification of DiffServ, a set of DiffServ classes is defined as a class-type where the classes in the same class-type possess the common aggregate maximum and minimum bandwidth requirements to guarantee the required performance level. The DiffServ class-types that are proposed in IETF can be grouped into 4 categories: network control traffic (NCT), expedited forwarding (EF), assured forwarding (AF), and best-effort forwarding (BEF). The mapping of DiffServ class-types into MPLS LSP (Label Switched Path) can be implemented in either E-LSP (Exp-inferred-LSP) [6] or L-LSP (Label-only-inferred

Transcript of Traffic Engineering and Network Management System for QoS...

Page 1: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

1

Traffic Engineering and Network Management System for QoS-Guaranteed

DiffServ Provisioning1 Young-Tak Kim

Department of Information & Communication Engineering, Graduate School, Yeungnam University

[email protected]

Abstract This paper proposes an integrated traffic engineering and management system for DiffServ-over-MPLS services in Next Generation Internet (NGI). Using the proposed traffic engineering functions for DiffServ-over-MPLS network, the Internet service provider (ISP) can easily configure Diffserv-over-MPLS traffic flows among customer’s distributed sites, and can provide guaranteed end-to-end QoS by controlling the virtual topology of MPLS tunnel LSPs which are configured by MPLS traffic engineering. We explain the requirements and overall operations of the DiffServ-over-MPLS traffic engineering, the architecture of MPLS network management system, and its detailed functions for network configuration, MPLS E-LSP establishment, performance management, fault management, and MPLS-based VPN. This paper also provides the experimental results and performance analysis of the proposed traffic engineering and management system that configured and managed a sample DiffServ-over-MPLS network with Cisco MPLS routers.

Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated service (DiffServ)

1 This research was supported by the Academic Research Support Program of Yeungnam University in 2001.

1. Introduction

The major goal of Internet traffic engineering is to facilitate efficient and reliable network operations for high throughput while simultaneously maximizing network resource utilization with optimized network performance [1,2]. Two most promising schemes for the efficient traffic engineering of Next Generation Internet are differentiated service (DiffServ) [3] and MPLS traffic engineering [4]. The two schemes have been proposed and developed individually, but can be applied as an integrated scheme[5]. The DiffServ traffic engineering provides microscopic flow control for each service type with relatively differentiated priority or weight, while the MPLS traffic engineering provides macroscopic traffic control for the aggregated traffic flows. Recently DiffServ-over MPLS TE has been studied in IETF that allows end-to-end QoS to end users as well as ISPs by using multiple LSP (label switched path) in parallel [2,5,6]. However, the detail mechanism for flow control of the aggregated traffic has not been matured yet. Especially, the integrated operation of the traffic engineering functions in DiffServ and MPLS has not been studied sufficiently.

In order to accomplish the objectives of traffic engineering, we must consider the service level agreement (SLA), Internet traffic engineering with DiffServ which manages the micro-flow of each service class, and the DiffServ-over-MPLS traffic engineering with traffic & QoS parameters that manages the MPLS LSP for the aggregated flow of one or more DiffServ class-types.

In service level specification, the objective QoS parameters of the requested traffic flow should be specified, and the specification must be contracted between the service user and the network service provider. ITU-T recommendation Y.1541 provides a good example of the service level specification [7]. Actually, the DiffServ technology has been developed to provide differentiated quality-of-service (QoS) according to the user’s requirements and necessity [3,5,6]. The main focus of the differentiated service provisioning is to protect the premium service traffic under the network congestion by giving relatively higher forwarding priority than other usual best-effort traffic. For each differentiated service, Per-Hop-Behavior (PHB) is specified at each IP router, and the differentiated services are specified by multiple parameters, such as the source/destination address, service type, and protocol identifier. 64 different classes with distinct DiffServ Code Points (DSCP) are defined with 6-bit field.

In order to simplify the classification of DiffServ, a set of DiffServ classes is defined as a class-type where the classes in the same class-type possess the common aggregate maximum and minimum bandwidth requirements to guarantee the required performance level. The DiffServ class-types that are proposed in IETF can be grouped into 4 categories: network control traffic (NCT), expedited forwarding (EF), assured forwarding (AF), and best-effort forwarding (BEF).

The mapping of DiffServ class-types into MPLS LSP (Label Switched Path) can be implemented in either E-LSP (Exp-inferred-LSP) [6] or L-LSP (Label-only-inferred

Page 2: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

2

LSPs) model. In E-LSP model, an MPLS LSP can transport multiple class-types (ordered aggregates), and the EXP field of the MPLS Shim header conveys the PHB to be applied to the packet at each LSR; the PHB conveys both information about the packet scheduling treatment and its drop precedence. In L-LSP model, each LSP only transports a single class-type, so the packet treatment is inferred exclusively from the packet label value, while the packet drop precedence is conveyed in the EXP field of the MPLS shim header.

In order to provide DiffServ-over-MPLS services, two fundamental functionalities are essential: (i) MPLS signaling for DiffServ-aware-ELSP establishment which is interoperable across multiple MPLS LSRs from various vendors, and (ii) network management system (NMS) to coordinate MPLS routers and autonomous systems along the end-to-end path that may cross multiple administration boundaries. Currently, two kinds of MPLS signaling protocols (i.e. LDP and RSVP-TE) are standardized and implemented. The interoperability between these two MPLS signaling protocols is under construction, and recently the basic LSP establishment function has been tested for interoperability [8].

For efficient resource managements and load balancing of MPLS network for DiffServ-over-MPLS services across multiple domains, a network management system (NMS) for DiffServ-aware-LER and core MPLS LSRs are essential. The NMS for DiffServ-over-MPLS network will also complement the immature MPLS signaling for DiffServ-over-MPLS traffic engineering and the difficulties in interworking among LSRs from different vendors.

In order to support the configuration, operation and management of DiffServ-over-MPLS services across multiple domain networks, the NMS must provide management capabilities of network configuration, DiffServ-over-MPLS LSP connection establishment, performance monitoring and analysis, fault management, and VPN service management. In the MPLS network configuration management, the NMS should be able to discover the installed MPLS LSRs, their node addresses, port configurations, link types and neighbor nodes through the ports. The previously established LSP must also be verified. By the MPLS network configuration management functions, the physical topology can be obtained.

The MPLS LSP connection management function supports the establishment, modification and release of the LSPs for DiffServ-over-MPLS services and traffic trunks that aggregate multiple user packet flows among clients sites. Constraint-based routing for guaranteed QoS provisioning must be used in the LSP establishment pahse. The established LSPs must be continuously monitored by the performance management function to verify the assured bandwidth and throughput. Two points measurement for end-to-end performance monitoring and one-point measurement for throughput should be provided. Any severely degraded performance compared to the agreed performance level must be treated promptly to guarantee the QoS.

Any link or node failure may cause massive data loss and severe performance degradation in the provided

services. So, each LSP should be protected in 1+1, 1:1, 1:N or M:N protection configuration according to the predefined requirement. If there is any link or node failure, the affected LSP must be quickly notified, the user traffic must be rerouted through the backup LSP, and a new backup LSP must be prepared. All these fault-related tasks are arranged by the fault management function.

Several management scheme or management systems for MPLS networks and DiffServ alone have been proposed and commercially available [9-13], but the network management functions for DiffServ-over-MPLS are not fully supported yet. We will briefly explain the existing NMS for MPLS network in section 2 as related work.

In this paper we propose an integrated traffic engineering and management system, called DoumiMan (DiffServ-over-universal-MPLS Internet Manager), for DiffServ-over-MPLS services in the Next Generation Internet. Using the proposed DoumiMan, the Internet service provider (ISP) can configure DiffServ-over-MPLS traffic tunnels among customers’ sites, and can provide guaranteed end-to-end QoS by controlling the virtual topology of MPLS tunnel LSPs which are configured by MPLS traffic engineering.

This paper is organized as follows. In section 2, the related work on the NMS for MPLS networks, DiffServ, and DiffServ-over-MPLS networks are briefly explained and analyzed. In section 3, the overall architecture and the implementation details of the proposed NMS for DiffServ-over-MPLS network are explained. We evaluate the proposed system in section 4, and finally we conclude in section 5. 2. Related Work

The standardizations of DiffServ-over-MPLS traffic engineering have been pursued mainly in IETF [2-6]. Several MPLS network management scheme have been proposed and some NMSs are commercially available [9-13], but the functions for the DiffServ-over-MPLS are not fully supported yet. In this section we overview some example NMSs for MPLS network and DiffServ services.

RATES (Routing and Traffic Engineering Server) was developed for MPLS traffic engineering [9]. It consists of a policy and flow database, a browser-based interface for policy definition and entering resource provisioning requests, and a Common Open Policy Service protocol server-client implementation for communicating paths and resource information to edge routers. RATES uses the OSPF topology database for dynamically obtaining link state information. RATES can set up bandwidth-guaranteed label-switched paths (LSPs) between specified ingress-egress pairs. RATES also supports restoration of LSPs with a restoration-capable online routing algorithm. RATES, however, does not support DiffServ and does not provide performance measurement and analysis functions.

Wandl’s IP/MPLSView is a tool for the network administers, performance management teams and IP/MPLS network control personnel to optimize time- and cost-savings, network bandwidth and network resources efficiently and productively [10]. It operates in a multi-

Page 3: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

3

layer, multi-vendor, multi-protocol environment, supporting the IP/MPLS configuration/performance management, network planning, VPN management, extensive report generation with fully web-enabled user interfaces. Wandl’s IP/MPLSView supports differentiated services (DiffServ) and VPN model as an additional feature.

EURESCOM’s DISCMAN project [11] studied the service models and architectures of differentiated services, building blocks for DiffServ framework, such as PHB strategies, network control, measurement and charging techniques, and traffic engineering of DiffServ. DISCMAN provides various test and analysis results of DiffServ and MPLS-based DiffServ, but it does not provide its own management system functionality.

Sheer Networks’ Broadband Operating Supervisor (BOS) [12] supports multi-layer (physical, ATM, Ethernet/VLAN, IP, MPLS, VPN) topology auto-discovery, realtime fault intelligence and root-cause isolation, GUI-based surveillance, service path tracing, service provisioning and activation, event correlation and service impact analysis, and IP-VPN service management. SheerBOS does not supports DiffServ-over-MPLS services and traffic engineering.

ETRI (Electronic Telecommunication Research Institute) developed Wise<TE> [13] that is a traffic engineering server for a large-scale MPLS-based IP network which addresses TE requirements, such as the measurement, characterization, modeling and control of Internet traffic. Wise<TE> does not supports DiffServ-over-MPLS services.

Cisco MPLS Tunnel Builder [14] is a web-based graphical application that simplifies visualization, configuration and management of MPLS tunnels on a network using MPLS TE. It integrates the configuration of Cisco MPLS TE features (e.g. auto-route, auto-bandwidth, DiffServ-aware Traffic Engineering, Fast Reroute) into single management tool. It also provides the functionality to compute and configure fast reroute paths for network elements (node, links or shared risk link groups) that will assure bandwidth availability, even during an element failure within the network. In the DiffServ-aware Traffic Engineering of Cisco MPLS Tunnel Builder, it is not clear whether it can support ELSP that can support multiple class-types with individual traffic parameters for each class-type in the ELSP.

For MPLS/BGP VPN management, Cisco developed VPN Solution Center [15]. It only supports layer 3 VPN with VRF (VPN routing and forwarding) table configurations, and does not support layer 2 MPLS VPN with DiffServ-aware-MPLS traffic engineering among client sites. 3. Design and Implementation of TE for QoS-

guaranteed DiffServ Provisioning 3.1 MPLS network configuration management

The first step in MPLS network configuration management is the automatic discovery of installed network resources, such as MPLS LSRs, ports of each LSR,

links between ports, neighbors of each node. DoumiMan provides automatic discovery of MPLS network resources, IP routers and VPN configuration by using CLI (command line interface) of Cisco routers [16]. Figure 1 shows the procedure of auto-discovery of physical topology, and its related managed object (MO). In the resource auto discovery procedure, the Cisco Discovery Protocol (CDP) is used to find and check the neighbor routers, and from the pivot IP router, all neighbor routers are searched.

Figure 1. Resource Auto Discovery (RAD) DoumiMan also supports the configuration

management functions, such as MPLS LSR configuration, port configuration and operational parameter setting for traffic engineering. Also, it supports the configuration of VPN/VPLS. The managed objects (MOs) for physical node, port, physical link, MPLS LSR, MPLS VPN, and MPLS TE LSP have been designed with object-oriented classes. Figure 2 shows some example MOs of DiffServ-over-MPLS traffic engineering.

Figure 2. Example MOs of DiffServ-over-MPLS

Traffic Engineering

7204_Fㅗ

7204_Gㅗ

① show run, show ip vrf, ….

②VRF Info, route-map, LSP Info….

Pivot Router

③ show cdp entry*

④Neighbor Info

⑤ show run, show ip vrf, …

⑥VRF Info, route-map, LSP Info….

⑦ show cdp entry*

⑧Neighbor Info

⑨ show run, show ip vrf, …

7204_H

PE

PE

core

NMS

(b) Physical Network MO

(a) Procedure of auto-discovery for information of physical topology

7204_Fㅗ

7204_Gㅗ

① show run, show ip vrf, ….

②VRF Info, route-map, LSP Info….

Pivot Router

③ show cdp entry*

④Neighbor Info

⑤ show run, show ip vrf, …

⑥VRF Info, route-map, LSP Info….

⑦ show cdp entry*

⑧Neighbor Info

⑨ show run, show ip vrf, …

7204_H

PE

PE

core

NMS

7204_Fㅗ

7204_Gㅗ

① show run, show ip vrf, ….

②VRF Info, route-map, LSP Info….

Pivot Router

③ show cdp entry*

④Neighbor Info

⑤ show run, show ip vrf, …

⑥VRF Info, route-map, LSP Info….

⑦ show cdp entry*

⑧Neighbor Info

⑨ show run, show ip vrf, …

7204_H

PE

PE

core

NMS

(b) Physical Network MO

(a) Procedure of auto-discovery for information of physical topology

Page 4: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

4

In DoumiMan, various GUI components are used to support user-friendly configuration of network, link, port and node systems. The physical topology of the network is displayed and the operator can configure the administrative state of LSRs, ports and traffic engineering trunk LSPs. Figure 3 shows some examples of GUI-based configuration management functions for physical layer network, MPLS layer network, and VPN/VPLS layer network. Operator can handle each layer network with user-friendly designed GUI functions.

Figure 3. Configuration Management Function

3.2 DiffServ-over-MPLS LSP connection management

The connection management function determines the operational parameters of DiffServ-over-MPLS LSP according to the requested QoS by SLA (service level agreement), and establishes E-LSP that contains multiple class-types for each aggregated traffic flow. Connection management function also establishes the backup LSP for the working LSP. Table 1 shows example traffic parameters for 8 differentiated services [17]. At ingress LER, the parameters of DiffServ are configured, and at each intermediate LSRs through which the LSP is routed, the traffic parameters of the DiffServ-aware-ELSP for the aggregated packet flow are configured by the DoumiMan.

In order to guarantee the requested QoS, constraint-based shortest path first (CSPF) routing module has been implemented that uses multiple traffic parameters in the calculation of the shortest path. Currently, the requested CIR (committed information rate), end-to-end packet transfer delay and SRLG (shared risk link group) are used as major constraints in the CSPF routing. For CSPF routing, the link status information of each TE-LSP (traffic engineering label switched path) is collected and managed as a Link State Data Base (LSDB). The link status information of each TE-LSP includes current available bandwidth, current utilization ratio, physical distance, propagation delay, and link bit error. At each connection admission control (CAC) for a LSP establishment, the link in LSDB is checked whether it can provide enough resource for the constraints of the requested LSP, and a result truncated LSDB is created, and used in the calculation of shortest path for the requested LSP.

Table 1. DiffServ Class-type and Performance Objectives Class-type Objective Example E-to-E

Delay Jitter PacketLossRatio

BandwidthBurstiness

NCT1/NCT0

Minimized error high priority

RIP, OSPF, BGP-4

150 msec U 10-3 CIR, Bc,

Be

EF Jitter sensitive real-time high

interaction VoIP 150

msec 50

msec 10-3 CIR, Bc, Be

AF4Jitter sensitive real-time high

interaction

Video conference

400 msec

50 msec 10-3 CIR, Bc,

Be

AF3 Transaction data interactive

Terminal session

Custom app

400 msec U 10-3 CIR, Bc,

Be

AF2 Transaction data Data base Web

400 msec U 10-3 CIR, Bc,

Be

AF1 Low loss bulk data

FTP E-mail 1 sec U 10-3 CIR, Bc,

Be

BE Best effort Best effort service U U 10-3 U

(Note: CIR: Committed Information Rate; Bc: Committed Burst Size, Be: Excess Burst Size)

The working LSP and backup LSP are configured with SRLG-disjoint route to provide better fault restoration capability. Once a working LSP is selected, the physical links of the route of working LSP are removed from the truncated LSDB, and another shortest path is selected for SRLG-disjoint backup LSP.

In DoumiMan, GUI-based connection management function supports the operator to set the required QoS parameters for up to 8 class-types in an E-LSP, the traffic parameters, resource color and setup/hold priority of the ELSP. Figure 4 shows the GUI for connection management [17].

Figure 4. Connection Management Function 3.3 DiffServ-over-MPLS performance management

The packet delivery performance of each DiffServ-aware-LSP must be continuously monitored and analyzed to check whether the QoS is properly provided according to service quality of the agreed SLA. The performance monitoring of the traffic throughputs of a port or an LSP can be specified using user friendly GUI modules [17]. The monitored traffic throughputs are continuously analyzed to determine whether some per-subscribed QoS is not

Page 5: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

5

provided. If not, the resource allocation of the LSP is re-adjusted to guarantee the required service quality. Especially, the utilization of each TE-LSP is analyzed to provide load balancing of the overall transport network. Also, the measured performance data are stored as performance log data for later analysis, and also displayed in GUI graphs.

If the provided performance level becomes severely deteriorated, the LSP must be re-adjusted to enhance the QoS provisioning. Figure 5 shows an example GUI of the performance monitoring of specified LSPs.

Figure 5. Performance Management Function

3.4 MPLS fault management

For each working LSP, the operator can specify the restoration strategy, such as 1:1, 1+1, 1:N or M:N. The backup LSP from ingress LSR to egress LSR is usually specified to be SRLG (Shared Risk Link Group)-disjoint from the working LSP. When a link/node fault is detected, the affected LSPs are promptly rerouted by either the pre-configured backup LSPs or by the reroute command from NMS [18].

In order to utilize the fast rerouting capability of specific MPLS LSR, the fault management module provides several optional configuration functions for fast restoration. For example, DoumiMan supports link protections with Cisco router’s fast restoration functions that can reroute within 50 msec at link/node failure.

When a link/node failure occurs, the SNMP trap handler receives the notification message. According to the configuration of fault management strategy, the DoumiMan redirects the packet flows from the ingress LSR to egress LSR through the backup LSP, or enable the routers to process the built-in fast protection switching. Also abnormal conditions and link/node failures are recorded in fault management log database. Figure 6 shows an example event reporting GUI for fault occurrence with its root cause [18].

Figure 6. Fault Management GUI 3.5 MPLS VPN management

In VPN management of DoumiMan, the auto-discovery of previously configured VPN topology, VRF (VPN Routing and Forwarding), connectivity of CE (customer edge) and PE (provider edge) is provided [16]. By GUI interface of VPN management, VPN sites can be added. DoumiMan also supports the establishment of traffic engineering tunnels among PE to configure MPLS VPN topology. Figure 7 shows the VPN management GUI example.

Figure 7. VPN Management GUI

4. Design and Implementation

DoumiMan has been designed and implemented in

object-oriented programming with Microsoft C++ and Java GUI. The main specific feature of DoumiMan is layered network management with easily expandable class design of network nodes and links.

4.1 Layered Network Management

As illustrated in Figure 8, DoumiMan defines 4 layer networks according to the protocol layer and their functionality: IP layer network, MPLS layer network, physical layer network and VPN layer network. In IP layer network, the end-to-end IP packet delivery performance and connectivity are managed. Also, the IP routers and network links among IP routers are managed.

In MPLS layer network, the traffic engineering (TE) trunks among provider edge (PE) routers are managed to provide virtual network topology with optimized network

Clear

Alarm Log GUI

GO To Map

SN Severity Date Time Address Trap Type Event Type Interface Type Status

X

1 Critical 2003-04-14 17:48:12.109 165.229.167.201 LinkDown EquipmentAlarm POS4/0 down

2 Critical 2003-04-14 17:51:16.150 10.0.0.6 LinkDown EquipmentAlarm Tunnel100 down

3 Critical 2003-04-14 17:51:16.169 165.229.167.201 LinkDown EquipmentAlarm Tunnel200 down

4 Critical 2003-04-14 17:52:12.109 10.0.0.6 LinkDown EquipmentAlarm POS2/0 down

5 Indeterminate 2003-04-14 17:52:12.145 165.229.167.201 Specific Ccommunication.. … …

6 Indeterminate 2003-04-14 17:53:15.45 165.229.167.201 Specific Ccommunication.. … …

7 Critical 2003-04-14 17:54:12.67 165.229.167.201 LinkDown EquipmentAlarm Serail1/2 down

8 Critical 2003-04-14 17:54:16.150 165.229.167.201 LinkDown EquipmentAlarm VRF1 down

9 Cleared 2003-04-14 17:55: 6.169 165.229.167.201 LinkUp EquipmentAlarm POS4/0 up

10 Cleared 2003-04-14 17:55: 6.129 10.0.0.6 LinkUp EquipmentAlarm Tunnel100 up

11 Cleared 2003-04-14 17:56: 2.145 165.229.167.201 LinkUp EquipmentAlarm . Tunnel200 up

12 Cleared 2003-04-14 17:56: 2.169 165.229.167.201 LinkUp EquipmentAlarm . POS2/0 up

Filter Save ExitPing TestClear

Alarm Log GUI

GO To Map

SN Severity Date Time Address Trap Type Event Type Interface Type Status

X

1 Critical 2003-04-14 17:48:12.109 165.229.167.201 LinkDown EquipmentAlarm POS4/0 down

2 Critical 2003-04-14 17:51:16.150 10.0.0.6 LinkDown EquipmentAlarm Tunnel100 down

3 Critical 2003-04-14 17:51:16.169 165.229.167.201 LinkDown EquipmentAlarm Tunnel200 down

4 Critical 2003-04-14 17:52:12.109 10.0.0.6 LinkDown EquipmentAlarm POS2/0 down

5 Indeterminate 2003-04-14 17:52:12.145 165.229.167.201 Specific Ccommunication.. … …

6 Indeterminate 2003-04-14 17:53:15.45 165.229.167.201 Specific Ccommunication.. … …

7 Critical 2003-04-14 17:54:12.67 165.229.167.201 LinkDown EquipmentAlarm Serail1/2 down

8 Critical 2003-04-14 17:54:16.150 165.229.167.201 LinkDown EquipmentAlarm VRF1 down

9 Cleared 2003-04-14 17:55: 6.169 165.229.167.201 LinkUp EquipmentAlarm POS4/0 up

10 Cleared 2003-04-14 17:55: 6.129 10.0.0.6 LinkUp EquipmentAlarm Tunnel100 up

11 Cleared 2003-04-14 17:56: 2.145 165.229.167.201 LinkUp EquipmentAlarm . Tunnel200 up

12 Cleared 2003-04-14 17:56: 2.169 165.229.167.201 LinkUp EquipmentAlarm . POS2/0 up

Filter Save ExitPing Test

Page 6: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

6

resource utilization. Also, the DiffServ-aware-MPLS LSPs are established and maintained to provide user requested differentiated services across MPLS network.

Figure 8. Class Definitions for Layered Network

Management

In physical layer network, the network nodes, ports of each node, links between ports and hosts are managed. The

physical connectivity among nodes and hosts are automatically discovered and shown in GUI for network operator. Network operator can configure or update the attributes of each node, port, link, and control the usage of network resources by enabling or disabling the administrative operation state.

In VPN layer network, the configuration and management of MPLS/BGP VPNs are supported. The traffic engineering trunks among PE (provider edge) routers and the VRF (VPN routing and forwarding) tables are configured by the VPN layer network management functions. Currently the layer 3 (L3) VPN configuration and management functions are supported. Figure 8 shows the layered network management concept in DoumiMan. 4.2 Object-oriented design for extensibility

In practical telecommunication network, many different types of nodes, ports and links from various vendors are installed. For example, the MPLS layer network can be configured with MPLS routers from Cisco, Juniper, Alcatel, Riverstone and Avichi [8]. As a result, the network management system must be designed and implemented to be easily expanded to include new types or versions of the layer network nodes. One of the major concerns in the extensibility is the differences of command line interface (CLI) for each vendor or version.

In DoumiMan, we designed the generic class for MPLS

IPRouter

MPLSLSR

IPConnectivity

TELSPDiffServELSP

IPMPLSRouter

Router

Link

IPNetwork

MPLSLSP

IPSubnetwork

MPLSNetwork

1 0..*1 0..*

PhysicalNetwork

FaultManagerHandler

PhysicalNode

PMHandlerForPort

Port

PMHandlerForLSP

PhysicalLayer

Network

MPLSLayer

Network

IP Subnetwork& VPNNetwork

IPRouter

MPLSLSR

IPConnectivity

TELSPDiffServELSP

IPMPLSRouter

Router

Link

IPNetwork

MPLSLSP

IPSubnetwork

MPLSNetwork

1 0..*1 0..*

PhysicalNetwork

FaultManagerHandler

PhysicalNode

PMHandlerForPort

Port

PMHandlerForLSP

PhysicalLayer

Network

MPLSLayer

Network

IP Subnetwork& VPNNetwork

Figure 9. MO Class Designs for Extensibility

Page 7: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

7

layer network, MPLS LSR, port and link, with carefully designed inheritance hierarchy. The differences of command line interface can be easily handled by implementing the abstract methods of the interface functions of the MOs of MPLS LSR, IP Router and physical node for the newly included node type or version. Figure 9 shows the class definitions with extensibility for different node types and versions. 4.3 Distributed Processing of Network Management

Functions The architecture of network management system

should be designed to support distributed processing for the management of a large scale network. Currently, DoumiMan supports IIOP/CORBA-based distributed processing, and XML-based interactions between Java GUI modules and the core management functional blocks.

The core management functional modules are implemented for each IP subnetwork as an EMS (element management system), and multiple EMSs are used to manage a large scale IP network that is distributed over a wide area. The EMS for each subnetwork interacts with each other to establish an DiffServ-aware-ELSP across multiple autonomous systems. IIOP/CORBA is used to implement the interactions among EMSs.

Java GUI modules can be located remotely from the core EMS functional blocks for each access of operators. Usually the core EMS modules are installed at high-performance computer servers, while the GUI modules are installed on a personal computer of the network operator. The interconnection among the GUI modules and the core NMS/EMS modules have been implemented with XML to provide flexible encoding/decoding of the parameters defined at the GUI interface. 5. Conclusions

In this paper, we proposed an integrated traffic engineering and management system for DiffServ-over-MPLS services in Next Generation Internet, called DoumiMan (DiffServ-over-universal-MPLS Internet Manager). Using the proposed DoumiMan for DiffServ-over-MPLS network, the Internet service provider (ISP) can easily control Diffserv-over-MPLS traffic flows among customers’ sites, and can provide guaranteed end-to-end QoS by controlling the virtual topology of MPLS tunnel LSPs which are configured by MPLS traffic engineering.

We explained the requirements and overall architecture of the DiffServ-over-MPLS traffic engineering and management system, and the detailed functions for network configuration, MPLS E-LSP establishment, performance management, fault management, and MPLS/BGP-based VPN. The proposed DoumiMan provides management functions for MPLS network configuration, DiffServ-over-MPLS LSP connection management, performance management, fault management and MPLS VPN management.

Throughout the design and implementation of DoumiMan, the efficient network management with layer networking architecture and extensibility has been emphasized. DoumiMan defines 4 layer networks

according to the protocol layers, such as physical layer, MPLS layer, VPN layer and IP sublayer, In DoumiMan we designed the generic classes for MPLS layer network, MPLS LSR, LSP, port, link with well-defined inheritance hierarchy. Because of this carefully designed MO classes, any new node type or version from various vendors can easily included.

In this paper, we also provided experimental results and performance analysis of the proposed traffic engineering and management system that configured and managed a sample DiffServ-over-MPLS network with Cisco MPLS routers. We verified the guaranteed QoS provisioning of DiffServ-aware-MPLS, the performance monitoring of a LSP or a port, the protection switching of LSP or link at link/port failure.

DoumiMan currently supports traffic engineering and management functions for Cisco IP/MPLS routers. Currently, it is under development to support Juniper IP/MPLS routers. Further expansions are required to support various IP/MPLS routers from various vendors. References [1] Xipeng Xiao et al., “Traffic Engineering with MPLS

in the Internet,” IEEE Network, March/April 2000, pp. 28 ~ 33.

[2] RFC 2702, Requirements for Traffic Engineering over MPLS, Awduche et al., September 1999.

[3] RFC 2475, An Architecture of Differentiated Services, S. Blake et al., December 1998.

[4] RFC 3031, Multiprotocol Label Switch Architecture, E. Rosen, A. Viswanathan, R. Callon, Jan. 2001.

[5] RFC 3270, Mutiprotocol Label Switching (MPLS) support of Differentiated Services, April 2002.

[6] IETF Draft, “MPLS Support of Differentiated Services using E-LSP,” S. Ganti et. al, April 2001.

[7] ITU-T Rec. Y.1541, Network Performance Objectives for IP-based Services, May 2002.

[8] MPLS Forum Super Demo 2002 – Test Plan & Results. [9] Petri Aukia et al., “RATES: A Server for MPLS

Traffic Engineering,” IEEE Network Magazine, Mar./Apr. 2000.

[10] Wandal IP/MPLSView, http://www.wandl.com/html/mplsview/MPLSview_new.cfm.

[11] Differentiated Services – Network Configuration and Management (DISCMAN), EURESCOM, 2000.

[12] Sheer Broadband Operating Supervisor (BOS), Sheer Networks, http://www.sheernetworks.com/solutions/overview.shtml.

[13] TS Choi, SH Yoon, HS Chung, CH Kim, JS Park, BJ Lee, TS Jeong, “Wise<TE>: Traffic Engineering Server for a Large-scale MPLS-based IP Networks,” NOMS2002, April 2002.pp. 251 ~ 264.

[14] Cisco MPLS Tunnel Builder Pro, http://www.cisco.com/en/US/products/sw/netmgtsw/ps4731/prod_technical_reference09186a0080107b3a.html.

[15] Cisco VPN Solution Center 2.2, http://www.cisco.com/en/US/products/sw/netmgtsw/p

Page 8: Traffic Engineering and Network Management System for QoS ...mail.apnoms.org/knom/knom-review/v7n1/1.pdf · Key words: traffic engineering, QoS-guaranteed service provisioning, differentiated

KNOM Review, Vol. 7, No. 1, August 2004

8

s2327/. [16] Hyungwoo Choi, Young-Tak Kim, “Configuration

Management for MPLS/VPN,” Proceedings of KNOM2003, May, 2003, pp. 270 ~ 278.

[17] Hyoseong Kim, Ryung-min Kim, Young-Tak Kim, “Management of DiffServ-aware-ELSP for guaranteed QoS provisioning,” Proceedings of KNOM2003, May, 2003, pp. 229 ~ 238.

[18] Seong-Jin Lim, Young-Tak Kim, “Object-oriented Fault Management System for Multiple Link Failure Recovery in MPLS Networks,” Proceedings of KNOM2003, May, 2003, pp. 179 ~ 188.

Young-Tak Kim graduated Yeung-Nam Univ. in Feb. 1984, and received Master Degree and Ph.D. from KAIST (Korea Advanced Institute of Science and Technology) in 1986 and 1990, respectively. He joined Korea Telecom (KT) in March 1990, where he had researched and developed the ATM Metropolitan Area Network

(MAN) Switching System, and the networking technologies of the ATM Highway for Korean Information Infrastructure.

Currently he is a professor of “School of Electrical Engineering and Computer Science.” He has performed many research projects in the area of “High-speed Telecommunications Networking” and “Network Operations and Management,” including the development of TMN/GDMO agent platform and the development of network simulator for ATM transit networking with OP-NET. Currently he is the project manager of government supported “A Study on the QoS-guaranteed Traffic Engineering and Multimedia Service Platform in the Broadband Convergence Network (BcN).” The Ministry of Information and Communication of Korea is supporting 700,000 USD each year during August 2003 to July 2007.

He had been joined in the design and implementation of NIST (National Institute of Standard and Technology) GMPLS Simulator during his Sabbatical (February 1, 2001 ~ January 31, 2002).

His research interests include QoS-guaranteed traffic engineering technologies for Next Generation Internet (NGI), and Programmable Network Interface with Active Networking Technologies. Young-Tak Kim is member of IEEE Communication Society, KICS (Korea Institute of Communication Society), KISS (Korea Information Society), KIPS (Korea Information Processing Society), and Korea Multimedia Society. He has served as an Organization Committee of APNOMS (Asia Pacific Network Operations and Management Symposium) and IEEE NOMS2004 (Network Operations and Management Symposium in 2004, Seoul).