MPLS Management using Policies - CiteSeerX

MPLS Management using Policies M. Brunner, J. Quittek C&C Research Laboratories, NEC Europe Ltd. Adenauerplatz 6, 69115 Heidelberg, Germany [brunner|quittek]@ccrle.nec.de Abstract Multi-Protocol Label Switching (MPLS) is in the process of standardization by the Internet Engineering Task Force (IETF). It is regarded as a technology for traffic engineering and QoS in IP-networks. In this paper, we address the management of MPLS networks, which is crucial for large networks. We decided to follow the IETF Policy Framework approach and extended the Common Information Model (CIM) for policies with MPLS specific classes. MPLS introduces the notion of a Label Switched Path (LSP), possibly covering an entire network, which calls for an extension of the IETF Policy Framework into the direction of network and service management issues. We address this by preparing a three-level policy architecture including managing on device, network, and service level using policies. However, the main focus of the paper is the management of MPLS with network-level policies. We describe a prototypical implementation of a policy-based management system for MPLS, operating on network elements represented in a network simulator. Keywords Management of Multi-Protocol Label Switching Networks, MPLS, Policy-Based Management, Network and Service Management, Network Information Modeling.

1

Introduction

Multi-Protocol Label Switching (MPLS) is a new technology to be standardized by the IETF [1]. The technology enables the setup of Label Switched Paths (LSPs) through an IP network. Initially, the idea of IP label switching was to speed up the packet forwarding in routers via simple table lookups instead of longest-matching prefix algorithms. However, in the meantime traffic engineering and QoS in IP networks became the dominant driving force behind MPLS. Assuming the deployment of MPLS, the key question arises: how do we manage large MPLS networks? We decided to apply policy-based management concepts to managing an MPLS network, because we considered this an appropriate way of dealing with large sets of managed elements. Using policy-based management for networks and systems has become very popular since the early work on policies such as [2], [3], and [4]. Nowadays, some commercial products are available, which use some form of policies to configure and control networks. In the IETF there is a Policy Framework Working Group [5], which aims at resolving issues related to policy-driven management of IP networks. It includes the definition of a policy framework and information mod-

To appear in the proceedings of the Seventh International Symposium on Integrated Network Management (IM), Seatle, 2001.

els for DiffServ, IntServ, and IP Devices. The IETF policy framework activities are on one hand limited to DiffServ/IntServ based networks, and on the other mainly dealing with device configuration. In this paper, we propose enhancing the IETF Policy Framework in two directions. First, we incorporate the management of Multi-Protocol Label Switching (MPLS) networks into the framework. MPLS is currently seen as a technology to influence the routing of IP networks in order to engineer the traffic with appropriate tools. QoS services are more easily and more flexible deployed in an IP-based network, because MPLS allows a network manager to pin down a route for an aggregate of flows. However, MPLS per se does not have QoS features nor mechanisms, but MPLS together with Differentiated Services (DiffServ) is the favored approach by the IETF [6] for providing IP QoS. The second enhancement of the policy framework deals with network-level and service-level management in IP networks. Using MPLS networks, the notion of a Label Switched Path (LSP) brings network-level concepts into the framework which have not been dealt with in the device-level policy framework. Furthermore, using traffic engineered networks, new kinds of IP services are possible. E.g., a service guaranteeing low packet loss probability can be offered using MPLS as mechanism to traffic engineer the IP network in a way that traffic is routed around hot spots. However, quantifying the service quality is very difficult. Additionally, having mechanisms for guaranteed services in place, advanced IP services need to be specified, configured, and controlled. We introduce the IETF Policy Framework in Section 2. Section 3 describes our network model including different resource classes and paths. The proposed threelevel policy architecture with a focus on MPLS is discussed in Section 4. An implementation of a prototype together with some example policies is described in Section 5. Section 6 concludes our work on an extension of the IETF policy framework towards MPLS management functionality and network and service management, and critically evaluates the framework.

2

The IETF Policy Framework

The IETF Policy Framework is under development by the IETF Policy Framework working group. The framework consists of Policy Enforcement Points (PEP), Policy Decision Points (PDP), management console, and a directory to store policies together with user/network resource information (see Figure 1). PEPs are basically network elements and the PDP is typically referred to as the Policy Server (PS). The components are linked by the following protocols and languages: •

The Common Open Policy Service (COPS) protocol [7] is used to forward requests from PEPs to the central policy server and to pass back corresponding policy decisions. Furthermore, the COPS protocol provides support for synchronization of policy decisions, support for configuration management with the provisioning extension (COPS-PR) [8], and support for reliability using TCP and keep-alive messages. Note that just recently an initiative to use policies in the SNMP framework has been started in the Configuration Management with SNMP (SNMPconf) working group [9].

•

A Policy Definition Language (PDL) is used to define new policies in terms of policy rules with condition and action lists. What language to use is very controversial, and the IETF has not reached consensus in standardizing a Policy Definition Languages. Basically, each implementation defines its own language.

•

The simple version of the X.500 directory access protocol called Light-Weight Directory Access Protocol (LDAP) is used by the policy server to retrieve information from the repository. Note that any other database may be used, but the working group decided to only provide a mapping of the policy model to a LDAP schema. Mgt Console Policy Decision Engine (PDE)

Directory

PDL, ...

Network Information Model

LDAP Policy Server

Policy Information Model

COPS/SNMPconf PEP

PEP PEP

Figure 1: IETF Policy Framework One of the key issues in the framework is how policy rules are triggered by state transitions or events. A Policy Decision Engine (PDE) is typically used to handle requests. For instance, in COPS for RSVP, the PEP issues a COPS request and the policy server returns a decision on whether to permit or deny the RSVP Path Message. A table of enabled policy rules is traversed at the PDE in order to find the matching rules for a request. The scenario is fairly clear for QoS signaling using the Resource Reservation Protocol (RSVP). RSVP path and reservation messages arriving at an RSVP daemon running on an IP router are converted by a COPS client component into COPS requests and sent to the COPS server component at the policy server. The RSVP-related COPS request will be forwarded to the decision engine which makes a decision based on the applicable rules. A similar scenario can be described for the Differentiated Services approach, where the PDE may be triggered by a request for (initial) configuration issued by network elements. The requests contain a description of the element’s capabilities, which are used in the PDE to decide on the configuration to load to the element. The similarity lies in the entity, which initiates the communication with the policy server. However, in the DiffServ case, the re-configuration of network elements may be triggered by new service level requests (SLS) or an operator manually re-configuring parts of the network. Both scenarios communicate in a push structure different from the RSVP scenario mentioned above. The second issue to be dealt within the policy server is the information model used to represent the policy information as well as network information. The policy

information model is under joint development in the IETF Policy Framework Working Group and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF, see http://www.dmtf.org). Furthermore, an information model for QoS related policies as well as a device model for IntServ/DiffServ capable routers is under development. So far, we only considered single domains. Bringing the framework into a larger context many other issues need to be addressed. In multi-domain environments the framework needs to deal with service requests from different entities (manual or automated); the negotiation of service level agreements has to be supported by the policy server in order to allow or permit a service; etc. In this paper, we assume the automatic service request, but concentrate on MPLS issues in such an environment.

3

Network Model

This section introduces a model of MPLS/DiffServ networks. The policy architecture described in Section 4 and our implementation described in Section 5 are based on this model. MPLS in its original fashion has a limited notion of QoS. However, using MPLS simply for traffic engineering already enables an ISP to provide better quality to its customers than without MPLS. The traffic engineering functionality allows the ISP to pro-actively avoid congestion by explicitly routing traffic away from congestion points. This results in less congestion and therefore a higher quality of service (without any guarantee). On the other hand, an LSP can have QoS properties, which need to be enforced by QoS mechanisms in Label Switched Routers (LSRs). In a recent proposal to support DiffServ over MPLS [6], MPLS is used in conjunction with DiffServ for QoS enforcement. This approach allows a LSR to apply a specified Per-Hop Behavior (PHB) to packets of an LSP. In our work, we slightly simplify the MPLS/DiffServ network model and abstract for management purposes from details of the MPLS/DiffServ (near) standards. Basically, we do not specify PHBs, but use scheduling classes instead1, and map the MPLS resource classes directly to the scheduling classes. A PHB scheduling class is defined in [10] as “A PHB group for which a common constraint is that ordering of at least those packets belonging to the same micro-flow must be preserved.” In practice this often translates to having one queue for a scheduling class, with packets of different drop precedences going into the same queue, and therefore packets of different LSPs may end up in the same queue. The network consists of IP routers with a set of network interfaces. The interface may have MPLS capabilities or just IP forwarding capability. With the term MPLS capabilities we summarize the capability to handle MPLS packets and the existence of an implementation of a signalling protocol. Signalling protocols, such as RSVPTE [11] or CR-LDP [12] mainly perform MPLS label distribution along a Label Switched Path (LSP) and may signal the resource reservation of an LSP. 1

Note that the term scheduling class is different from service class as used later in the paper. The term scheduling class is derived from the term Per-hop Scheduling Class (PSC) used in the DiffServ Terminology [14].

Additionally, the interfaces may have different queues, variable in length and with packet scheduling capabilities or just a FIFO queues. We assume a simple queueing discipline such as tail dropped queues. With that kind of simplification we reduce the large variety of different queueing and scheduling disciplines, which makes the model and its implementation of the prototype much easier. It results in a network model with four different interface/router types, (1) no MPLS, FIFO, (2) no MPLS, N queues, (3) with MPLS, FIFO, and (4) with MPLS, N queues. Note, that this simplification does not appropriately match requirements of the Assured Forwarding Per-Hop Behavior definition (AF PHB) [13]. Building a network with routers able to differentiate the handling of various packets enables a network operator to deploy different scheduling classes. Whether a router is able to perform class-specific packet processing depends on the capabilities of the router. The interface with FIFO buffers may be used only in one scheduling class, whereas interfaces with N buffers may be configured to have up to N scheduling classes. Each scheduling class can be configured to allow a certain share of the available resources. Putting together a network with such kind of routers results in a network, which is divided into different classes conceptually building a separate network for each class (see Figure 2).

Figure 2: Scheduling Classes (shaded) and a Path (dashed) The set of routers with MPLS capabilities are able to handle LSPs, including the setup and tear down of LSPs. In our model, an LSP has a resource class/scheduling class associated, which defines the class an LSP draws resources from. The concept of an LSP allows a network operator to control or even constrain the routing of specific packets. The decision whether the routing is constrained depends on the services provided and on the traffic engineering objectives of an operator. As far as services are concerned, MPLS pins down a route for a traffic flow, which enables an operator (together with appropriate access control) to guarantee a certain quality for a flow. The management system controls the amount of traffic routed over each single path and may reject new requests in order to maintain the quality of granted flows.

4

Logical Three-Level Policy Architecture

Having the network model presented in the last Section in mind, we approach the configuration of such networks with policy-based concepts. We clearly base our

work on the IETF Policy Framework WG [5] and the DMTF work already done so far, and extend it with MPLS and with network and service level policies. Since we need to manage different things at different levels, we propose a threelevel architecture for the policy server. The lowest level is concerned with the device-level configuration, the mid-level deals with the network-wide configurations, and the upper layer handles services. Service-level Policies Network-level Policies Device-level Policies Figure 3: Logical Three-Level Policy Architecture With the three-layered architecture we get a clear separation of different concerns, and a clearer definition of the triggers that drive the policy decision engine. Note that the layering is just logical, each layer may be implemented separately with different means and deployed independent from the other layers. In the following, we focus on MPLS specific configurations and mention DiffServ just briefly, because this issue is already covered by the IETF. Service-specific policies are considered mainly in the area of service requests, but service management related policies are not developed in the IETF nor in this work so far.

4.1 Device Configuration Configuring MPLS/DiffServ routers, mainly consists of configuring the DiffServ part, because MPLS is working network wide. However, the information about capabilities of routers is needed by the policy server, in order to take appropriate/ device-specific decisions. Taking our network model outlined in Section 3 into account, the policy server mainly decides on the weights for a outgoing packet scheduler, and on the discipline and length of the queues. Information about the capabilities of the routers is needed to decide on the configuration of the device. Information include the availability of weighted packet schedulers, configurable queues, bandwidth of the links, whether and which MPLS signalling protocol is running etc.

4.2 MPLS Policies On the network level, policies are concerned with Label Switched Paths (LSPs), including life-cycle management, LSP roles, LSP routing, and the mapping of traffic to LSPs. The Model of an LSP Since there are different kind of LSPs we model a basic LSP type, containing an LSP identification, a reference to a Forward Equivalence Class (FEC), a reference

to a traffic profile, a reference to a route specification, a role, and a resource class. The FEC specifies what type of traffic is using the LSP and the traffic profile specifies a resource profile for the LSP, e.g., bandwidth etc. The route specification may be used for explicitly set the route of an LSP or it is used to store the route chosen by the network independently of the policy server. The role is used to assign a certain property to an LSP from a management point of view. The resource class parameter specifies the class from which the LSP may draw the resources.

Specification of Traffic

LSP with Properties • ER-Hop • Traffic Profile

Traffic

Figure 4: LSP with Properties Life-cycle management Life-cycle management comprises setting up, releasing and updating an LSP along a number of routers. It should be possible to control the initiation and the execution of these processes by policies. For some signaling protocols, e.g. the Label Distribution Protocol (LDP), the signaling is initiated by a LSR. However, even in this case, the start of the signaling process may be triggered by a policy. Therefore, policy actions to initiate the setup, update, or release of an LSP are proposed in our IETF draft in the Policy Framework WG [15]. Depending on what reason the LSP is setup and what routing architecture is used in the network (distributed or centralized), different kinds of LSPs are needed. Some may have bandwidth constraints, other have routing constraints, etc. To cover the differences, we define the setup action, but allow for different models of LSPs. For this reason, the LSP type is coded into the LSP class rather than in the setup action. An LSP in our MPLS model belongs to a resource class. Resource classes are defined according to CR-LDP and are capable of indicating a resource class for an LSP. Therefore, the mapping of resource classes to scheduling classes on the core LSRs need to be specified. Signaling Control Additionally, the signalling processes, such as defined by CR-LDP, may be controlled via policies using policy actions. The typical example comprises signalling of an LSP with QoS requirements, E.g., the signaled request for a bandwidth X may be permitted or refused, depending on the policies of the network domain.

Policy Server •Modify Signaling Parameter •Issue Notification message •Issue Release message

Signalling Message (CR-LDP)

LSR

LSR

LSR

Figure 5: Signalling Control Figure 5 illustrates a situation, where signaling is controlled by policies. It shows the case of CR-LDP. The decision in the policy server may be a permit or deny. In more elaborate scenarios the decision could be to reduce the bandwidth or to use another resource class to draw the bandwidth from. Traffic Mapping The mapping of traffic to LSPs is most likely performed at the edge router of an MPLS domain (see Figure 4). However, in cases where tunnels for the purpose of traffic engineering are setup, the mapping may happen at any point in the network. In the MPLS context, the traffic mapped is often referred to as Forward Equivalence Class (FEC), which forwards a group of packets along the same path with the same per-hop behavior. We define an action to specify the mapping of traffic to an LSP. The definition of the mapping between FECs and LSPs is specified in the policy rule condition that follows the IETF’s Policy Framework WG manner. In the policy condition, any kind of filter can be specified. Refer to the QoS Policy Information Model for a deeper discussion of the specification of filters [16]. The most likely cases include mapping traffic destined for the same egress router into the same LSP. However, in the special case of MPLS with DiffServ capable Label Switched Routers, the mapping of DiffServ specific traffic into LSPs on the edge LSRs need to be specified. LSP tunneling For traffic engineering, LSPs can be used as tunnels for the aggregation of other LSPs, in order to explicitly specify the route the aggregated LSPs should take. See Figure 6 for the case of a tunnel LSP #b, which carries the traffic of LSP #a. Note that LSP #a continues after LSP #b ended. The functionality enabling this kind of tunneling is built into MPLS with the capability of stacking different MPLS headers on top each other. The definition of the

policy model for MPLS therefore needs to specify the stacking via policy rules. Since this is nothing more than another kind of mapping of traffic to an LSP, we use exactly the same policy action. The only difference is in the specification of the filter, which needs to include an LSP X to be mapped. Note however, that the location

Mapping of Traffic in LSP #a into LSP #b Traffic specified in FEC

LSP #a

LSP #b LSR A

LSP #a is not terminated at LSR A.

Figure 6: LSP tunneling is not specified, but is explicitly set by the LSP to which the traffic is mapped, and only this particular router need to be configured. The functionality to perform the mapping is built into the policy server. LSP roles In addition to LSP attributes, such as the resource class, a role can be assigned to an LSP. This helps classifying the LSPs in a domain such that for different roles different policies may apply. Typical roles of an LSP from a management point of view are “primary”, “secondary”, “backup”, “pinned”, or “tunnel”. A primary LSP is the first LSP a specified traffic aggregate is using, the secondary LSP is also used by the same traffic aggregate and load balancing between those two are performed. For reliable services, typically a backup LSP is already setup together with the primary. The traffic is switched to the backup path in case of a failure. A pinned LSP is one whose route should not be changed, and a tunnel LSP is one which specifies the route for various other LSPs. The concept of assigning roles to LSPs allows a network administrator to specify policies valid for all LSP of the same role, which simplifies the administration of a MPLS network.

4.3 Service Policies The only service the IETF DiffServ WG is promoting so far, is the virtual wire “service” (in DiffServ called the Virtual Wire Per-Domain Behavior)[17], a Constant Bit Rate service with bounded jitter using the Expedited Forwarding (EF) per-hop behavior of DiffServ. What kind of services are implemented with DiffServ in combination with MPLS is an open issue, and therefore policies concerned with the management of services are for further study. However, the notion of a service needs to be taken into account in the area of MPLS management, because many MPLS applications are closely related to services like the virtual wire service, but also value added services such as guaranteed VPN services etc.

Currently, we see a specific area where policies are beneficial, namely the handling of service level requests from users/customers. This action depends on business level policies, such as “customer X always gets the service, even if other customer get a service degradation”, or it includes also network conditions, e.g., “permit only if links are 20% under-utilized”.

5

Implementation

We developed a policy server prototype for the management of MPLS networks, in order to prove the feasibility of our architecture. The applicability to large MPLS/ DiffServ networks has been shown by using a network simulator. However, at the current stage of the implementation, we can only show a working prototype proving the concept. For more meaningful results many open issues in the area of service level specification (SLS) request arrival and duration, traffic models of source etc. need to be solved first. The prototype is based on the policy server described in [18], which was targeted to the area of IntServ and HTTP. It consists of a policy language together with a policy editor and an interface to LDAP directories. The server is implemented in Java. The policy language is a proprietary simple language, which allows an operator to specify policies in a human readable way. This means, the mapping of the policy language to the objects in the implementation is straight forward and easy to implement. As interface to policy clients, the policy server is uses upon a protocol adaptor, which abstracts from real policy protocols such as COPS, SNMP for configuration, or our proprietary one to the simulator. We extended the IETF framework by MPLS policies, according to the policy information model described in [15]. MPLS policy classes are converted into a LDAP directory schema. Furthermore, we built an interface to a network simulator, namely ns-2 [19], which offers MPLS functionality. The policy server and the simulator run on different PCs. The interface is implemented using a proprietary, COPS-like, text-based protocol between the real policy server and the network simulator using a TCP connection. The policy server is represented in the simulation by a simulated node (proxy policy server in Figure 7). All management agents send COPS-like messages to the proxy. The proxy sends the message forward to the real policy server. The messages from the network simulator to the policy server include always the network element’s address and port number of the management agent. The configuration messages from the policy server take the reverse way. Additionally, a simulation of a SLS requestor issues service requests to the policy server, and generates traffic. The service level requests are sent with the same mechanism described in the above paragraph. The source starts sending in case a SLS Permit decision is communicated back to it. Our policy sever supports two kinds of policies: policies for device configuration and policies for deciding on service requests. Device configuration policies are trig-

gered by devices, e.g. at start-up, while the other kind of policies is triggered by arriving service requests. Editor

Policy Server Service Requests Simulated Source of SLS and traffic

Protocol Adaptor Directory

Proxy Policy Server

Management Protocol Data

Simulated Network

Figure 7: Implementation of Policy Server in Simulated Network Environment

5.1 Device Configuration Policies The main task of the device configuration is the decision on what configurations apply for that specific device. In our implementation the configuration is triggered by a configuration request issued by the network element, which contains interface type information. An example policy rule, written in our proprietary policy definition language, looks as follows: IF LSR.TYPE contains WEIGHTED AND LSR.NR_QUEUES gte 2 AND LSR.Admin_state eq SETTING_UP THEN CONFIGURE SCHEDULER_WEIGHT {25%, 75%} AND CONFIGURE QUEUE_LENGTH {20, 100} The rule condition specifies that only interfaces with a packet scheduler able to perform weighted sharing of the link resource of 2 or more buffers is configured with the following configuration. The condition about the administration state tell the system, that only new LSR are configured. The action specifies that 2 queues with length 20, 100 packets and scheduler shares of 25% and 75% are configured.

5.2 Service Request Handling and LSP Setup Policies The trigger for this policies deciding on service requests are arriving service requests from any source (customer or network administrator). Our example poli-

cies shown below avoid that a lot of low bandwidth LSPs are set up. Low bandwidth requests are aggregated if they have the same source and destination. For high bandwidth requests individual LSPs are established to serve them. IF SLS.BW lt 512 kbit/s AND SLS.dest IsReachableBy LSP.egress AND SLS.src IsReachableBy LSP.Ingress THEN MapTraffic (SLS.src, SLS.dest) IF SLS.BW gte 512 kbit/s THEN SetupLSP (SLS.BW SLS.src SLS.dest) AND MapTraffic (SLS.src, SLS.dest) The conditions of these two policy rules ensure that the first one is only applied to requests for a bandwidth of less than 512 kbit/s, while the second one applies to all request above 512 kbit/s. The condition of the first rule further looks for LSPs, for which ingress and egress LSR match the requirement of the SLS. The action to be performed for service requests below 512 kbit/s is mapping the traffic to that particular LSP. In order to guarantee that there is already an LSP available, we have an initialization rule (not shown here), which sets up an LSP from each ingress to each egress LSR with a small bandwidth portion assigned. The second rule specifies that for SLS’ with a bandwidth greater than 512 kbit/s a new LSP is created and the traffic is mapped to that LSP. Note that the relation operator IsReachableBy is a complex operator implemented for this particular policy rule in the MPLS area. So far we have not found a general solution in the IETF policy framework, which is easily extendable in this direction.

6

Conclusion and Future Work

This paper proposes a network model and a policy-based management architecture for MPLS networks using DiffServ. The network model is inspired by the DiffServ model of Class of Service and by resource classes in MPLS CR-LDP. Also, the concept of a LSP was adopted from MPLS. Based on this model, a policy architecture has been introduced which logically distinguishes between service, network and device management. This architecture extends the IETF policy architecture for DiffServ by MPLS-specific features, particularly by LSP life-cycle management, service level request handling, and traffic engineering capabilities. The feasibility of our architecture and its applicability to large MPLS/DiffServ networks has been proven by a prototype implementation. During our work with the IETF Policy Framework we detected some shortcomings. (1) The policy framework is very data-centric and lacks different constructs used to build a defined execution behavior. (2) In the framework, it is impossible to have

conflict detection, because no language based approach is chosen. (3) Conditions and actions are not general, which leads to the definition of area-specific conditions and actions without a sound ground to built upon. In the future we plan to extend our prototype into the direction of service-level management in DiffServ/MPLS networks. This also includes different kind of services, the mapping of user requests to services installed in the domain, and it covers the inter-domain case, where customers need services running over different domains.

7

Acknowledgments

We would like to thank the co-authors of the IETF draft on the MPLS model for policies [15], K. Isoyama, M. Yoshida, A. Kind. We also would like to thank Darren Carlson for his help improving the English writing.

8

References

[1] T. Li, “MPLS and the Evolving Internet Architecture”, IEEE Communications Magazine, Vol. 37(12), 1999. [2] M. Masullo, S. Calo, “Policy Management: An Architecture and Approach”, Proceedings of the First IEEE Intl. Workshop on System Management, LA, USA, April 1993. [3] J. Moffett, M. Sloman, “Policy Hierarchies for Distributed Systems Management”, IEEE JSAC Special Issue on Network Management, Vol 11, December 1994. [4] R. Wies, “Policies in Network and Systems Management - Formal Definition and Architecture”, Journal of Networks and Systems Management, Vol 2(1), 1994. [5] IETF Policy Framework Working Group, http://www.ietf.org/html.charters/ policy-charter.html. [6] F. Le Faucheur et al., “MPLS Support of Differentiated Services”, IETF Draft, draft-ietf-mpls-diff-ext-07.txt, work in progress, August 2000. [7] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, “The COPS (Common Open Policy Service) Protocol”, IETF Request for Comment (RFC) 2748. [8] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, “COPS Usage for Policy Provisioning”, IETF Internet Draft, draft-ietf-rap-pr-03.txt, work in progress, July 2000. [9] IETF Configuration Management with SNMP Working Group, http:// www.ietf.org/html.charters/snmpconf-charter.html. [10] D. Grossman, “New Terminology for DiffServ”, IETF Draft, draft-ietf-diffserv-new-terms-03.txt, work in progress, August 2000. [11] D. Awduche, L, Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, IETF Draft, draft-ietf-mpls-rsvp-lsptunnel-07.txt, work in progress, August 2000. [12] B. Jamoussi, “Constraint-Based LSP Setup using LDP (CR-LDP)”, IETF Draft, draft-ietf-mpls-cr-ldp-04.txt, work in progress, July 2000. [13] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHB

Group”, IETF Request for Comments 2597, June 1999. [14] D. Grossman, “New Terminology for Diffserv”, IETF Draft, draft-ietf-diffserv-new-terms-03.txt, work in progress, August 2000. [15] K. Isoyama, M. Yoshida, M. Brunner, A. Kind, J. Quittek, “Policy Framework QoS Information Model for MPLS”, IETF Draft, draft-isoyama-policy-mplsinfo-model-00.txt, work in progress, July 2000. [16] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, “Policy Framework QoS Information Model”, IETF Draft, draft-ietf-policy-qos-info-model-01.txt, work in progress, August 2000. [17] V. Jacobson, K. Nichols, K. Poduri, “The `Virtual Wire' Per-Domain Behavior”, IETF Draft, work in progress, , July 2000. [18] C. Fan, J. Nicklisch, A. Kind, “Policy-based Value-added Services”, International Switching Symposium (WTC/ISS2000), Birmingham, May 2000. [19] “The Network Simulator - ns-2”, http://www.isi.edu/nsnam/ns/. [20] RFC 2475, “An Architecture for Differentiated Services”, S. Blake, D. Black, M.Carlson, E.Davies, Z.Wang, W.Weiss, IETF Request for Comment 2475, December 1998.