Network Working Group S.Wright Internet Draft BellSouth Document: draft-wright-policy-mpls-00.txt Category: Informational S.Herzog F.Reichmeyer IP Highway R. Jaeger LTS, University of Maryland March 2000 Requirements for Policy Enabled MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo provides a brief overview of MPLS networks and policy- based network architectures. It proposes that MPLS networks be Policy-Enabled in order to facilitate easier administration. To facilitate further discussion, an Intra-net example of a policy- based MPLS network architecture is described. Example policies applicable to the MPLS network are discussed. A scenario of operation example is provided to illustrate some of the dynamics associated with Policy-Enabled MPLS networks. Wright Informational Expires September 2000 1 Requirements for Policy Enabled MPLS March, 2000 1 Introduction In this draft we seek to define the requirements for Policy-Enabled MPLS networks. Policy controls enable improved administrative control of network capabilities to meet service objectives. MPLS provides efficient explicit routing capabilities for IP networks, a key element in the traffic engineering of those networks. Combining the two approaches should enable improved network service. In general, policy management for MPLS involves Life Cycle management (i.e., creating, deleting and monitoring) Label Switched Paths (LSPs) paths through the network along with the controlling access (LSP Admission Control) to those managed resources by the traffic on the network. MPLS supports explicit traffic engineering via a number of specifications (CR-LDP, RSVP) that allow LSPs to be managed based on QoS and other constraints. MPLS can also be used with implicit traffic engineering of LSP Quality of Service. The policy management architecture used to control traffic engineering functionality should be independent of the MPLS mechanisms used; however, it is these mechanisms that we target with policy management. That is, the focus here is on managing MPLS mechanisms to provide consistent, predictable network services. A major application (see e.g., [3], [13]) of MPLS is in providing traffic engineering capabilities to IP networks. In some cases, this may involve the use of specific QoS mechanisms (e.g., Diffserv, Int- Serv). This effort is intended to be complementary to those ongoing studies by leading efficient administration of those capabilities. The following are non-goals of this internet draft: (a) Not an exhaustive list of requirements or policies at this stage (b) Not seeking major new protocol work - reuse existing capabilities (c) Not attempting to define new traffic engineering mechanisms or paradigms, (but may enable some applications) The examples used in this draft to illustrate MPLS policy control are based primarily on the assumption of COPS to implement policy management. Any extensions to the cops-provisioning protocol, specification of new cops-mpls client type, or definition of MPLS PIBs necessary to implement MPLS policy with COPS, is beyond the scope of this draft. In this internet draft we focus on Intra-domain policy enablement of MPLS networks. The policy environment for the case of Inter-domain MPLS networks is a subject for further study. At this stage we seek further discussion and wider participation regarding Policy-Enabled MPLS networks. If considered appropriate, we would like to make this a WG draft and further refine any requirements related to Policy-Enabled MPLS networks. Wright Informational Expires September 2000 2 Requirements for Policy Enabled MPLS March, 2000 2 Policy-based Networks Policy-based Networking [4] provides an infrastructure for the management of networks with a rich set of management capabilities. As described in [5], the basic components of the policy-based management system consist of a Policy Decision Point (PDP) and Policy Enforcement Points (PEP). The PDP is a logical component residing within a Policy Server and the PEP is a logical component, usually residing in the network device. Other components of a policy management system include a policy management console (PMC) that provides a human interface to the policy system and a policy repository (PR) to store the policy. The PMC can be used to generate policies for storage in the repository and to administer the distribution of policies across various PDP. Policies may also be imported into the system via other mechanisms, e.g. retrieved from an LDAP directory and stored directly into the repository. From the PDP, policy rules are installed in the network and are implemented at the PEPs. The general architecture of a policy-based network management system is shown in Figure 1. Decisions regarding what policy rules are to be installed in the network devices can be the result of several different events. There are primarily two models of policy management that determine how and when policy decisions get made, provisioning and outsourcing. In policy provisioning, events occur at the PDP that cause the PDP to install policy rules in the PEPs. Examples of such events include human intervention (via the management console), signaling from an external application server, or feedback about dynamic state changes in the devices that the PDP is managing. In policy outsourcing, events occur, at the PEPs themselves, which require a policy-based decision and the PEP requests the decision from the PDP. An example of this type of event is the receipt of an RSVP message, or some other network signaling protocol, containing policy information and a request for resource reservation. The PEP sends a message to the PDP requesting a decision, based on the policy information provided, on whether to accept or deny the resource reservation request. Policy is applicable to admission control decisions as described in [5]. This Admission control Framework also considers other possible implementations where the network element incorporates additional functional elements from the policy architecture. If it is available, the PEP will first use a Local Policy Decision Point LPDP to reach a local decision. This partial decision and the original policy request are next sent to the PDP that renders a final decision (possibly, overriding the LPDP). Wright Informational Expires September 2000 3 Requirements for Policy Enabled MPLS March, 2000 ++++++++++++++ + Policy + + Management + + Tool + ++++++++++++++ |\ |\ | | | | (e.g. LDAP) | ++++++++++++++ | + Policy + | + Repository + | + + | ++++++++++++++ | |\ | | | | (e.g. LDAP) ++++++++++++++ + Policy + + Decision + + Point + ++++++++++++++ |\ | | (e.g. COPS, SNMP) ++++++++++++++ + Policy + --- + Enforcement+--- + Point + (e.g. RSVP,LDP,BGP) ++++++++++++++ Figure 1 Policy Architecture ________________ ____________________ | | | | | Network Node | Policy Server | Network Node | | _____ | _____ | _____ _____ | | | | | | | | | | | | | | | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | | | |_____| | |_____| | |_____| |_____| | | ^ | | | | | _____ | |____________________| | \-->| | | | | LPDP| | | |_____| | | | |________________| Figure 2 Other Possible Configurations of Policy Control Architecture Wright Informational Expires September 2000 4 Requirements for Policy Enabled MPLS March, 2000 One important aspect of the policy management system is feedback from the PEPs to the PDP. This feedback includes such information as changes in dynamic state of network resources, link failures and congestion, statistics related to installed policy, etc. The information supplied by the PEPs is used by the PDP to make future policy-based decisions, or make changes to current decisions, regardless of the policy management model used. Policy protocols have been developed, such as COPS [9], which provide this robust feedback mechanism for policy management applications. By specifying the proper information in the Policy Information Base [10], the PDP can receive feedback on a variety of parameters such as flow characteristics and performance. 3 MPLS Networks A general discussion of issues related to MPLS is presented in the framework [11] and architecture [12] documents. A brief summary of salient features is provided below as context for the later sections. ER---LSR-------LSR -----ER / ER---LSR----/ Figure 3 MPt-Pt LSP Traversing an MPLS Network As shown in Figure 3, a Label Switch Path in MPLS is in general a sink-based tree structure traversing a series of Label Switch Routers (LSRs) between the ingress and egress Edge Routers (ERs). This assumes the existence of a merging function at the LSRs, which is an optional LSR feature that may not be supported by certain classes of equipment (e.g., legacy ATM switches). Point-to-Point LSPs are a degenerate case of MPt-Pt LSPs where no merging is performed. In MPLS networks, choosing the next hop can be thought of as the composition of two functions. The first function classifies all possible packets into a set of "Forwarding Equivalence Classes (FECs)". The second function maps each FEC to a next hop. In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn re-examines the packet and assigns it to a FEC. In MPLS, the assignment of a particular packet to a particular FEC is done just once. At subsequent hops along the Label Switched path (LSP), there is no further analysis of the packet's network layer header. This has a number of advantages over conventional network layer forwarding. a) MPLS forwarding can be done by switches that are capable of doing label lookup and replacement, (e.g., ATM Switches) Wright Informational Expires September 2000 5 Requirements for Policy Enabled MPLS March, 2000 b) The considerations that determine how a packet is assigned to a FEC can become ever more and more complicated, without any impact at all on the routers that merely forward labeled packets. Since a packet is classified into an FEC when it enters the network, the ingress edge router may use any information it has about the packet, even if that information cannot be gleaned from the network layer header. For example, packets arriving on different ports or at different routers may be assigned to different FECs. c) Sometimes it is desirable to force a packet to follow an explicit route, rather than being chosen by the normal dynamic routing algorithm as the packet travels through the network. This may be done as a matter of policy, or to support traffic-engineering objectives such as load balancing. d) MPLS allows (but does not require) the class of service to be inferred from the label. In this case, the label represents the combination of a FEC and Quality of Service. See [7] for a more detailed description of the interaction between MPLS and Diffserv. MPLS also permits the use of labels in a hierarchical form û a process known as label stacking. Figure 4 illustrates how MPLS may operate in a hierarchy using as an example three transit routing domains. Domain Boundary Routers are shown in each domain and we suppose that these domain boundary routers are operating BGP. Internal routers are not illustrated in domain #1 and #3. However, internal routers are illustrated within domain #2. In particular, the path between routers R3 and R8 follows the internal routers R4, R5, R6, and R7 within domain #2. ................. ........................ ................ . . . . . . . . . . . . .R1 R2------R3 R8------R9 R10. . . . \ / . . . . . . R4---R5---R6---R7 . . . . . . . . . . Domain#1 . . Domain#2 . . Domain#3 . ................. ........................ ................ Figure 4 Example of the Use of MPLS in a Hierarchy In this example there are two levels of routing taking place. For example, OSPF may be used for routing within Domain #2. The domain boundary routers operate BGP in order to determine paths between routing domains. MPLS allows label forwarding to be done independently at multiple levels. Thus when the IP packet traverses Domain #2, it will contain two labels, encoded as a "label stack". The higher level label would be used between routers R3 and R8. This would be encapsulated inside a header specifying a lower level label used within domain #2. Wright Informational Expires September 2000 6 Requirements for Policy Enabled MPLS March, 2000 4 Policy-Enabled MPLS Networks We propose the following base requirement: [R0] It shall be possible to policy enable an MPLS network This implies the existence of PIB elements that identify LSPs, and policy actions that affect LSPs e.g. admission of flows to LSPs and LSP life cycle operations such as creation/ deletion of LSPs. 4.1 Rationale Policy controls for MPLS provide a rich environment for the creation of network services in an efficient manner. The following operational advantages are seen in a policy based approach to the management and control of MPLS networks: (a) MPLS Abstraction - While MPLS could be controlled directly through the relevant MIBs (see e.g., [8], [2]), the use of a higher abstraction level PIB provides a mechanism to abstract away some of the implementation options within MPLS, to focus on operational advantages e.g. those provided by the explicit routing capabilities. (b) Controllability of LSP Life Cycle - While MPLS may be operated in an autonomous fashion, e.g., with topology-driven LSP establishment, this does not necessarily provide the explicit routes and QoS required for traffic engineering. While manual establishment of explicit route LSPs with associated QoS parameters may be feasible, this is expected to have some issues of scale, and consistency when applied in large networks. (c) Consistency with other techniques -The need for MPLS and Diffserv to interact appropriately has already been foreseen in [6], and [7]. Work on the policy controls for Diffserv networks is already underway in [10] and [9]. This internet draft seeks to address the application of policy for MPLS networks that may, but do not necessarily, implement Diffserv. It is expected that this operational environment may facilitate the deployment of some of the traffic engineering objectives currently [3] as well as those under consideration elsewhere (refer: traffic engineering working group - tewg). (d) Flexibility in LSP Admission Control - The set of flows admitted to an LSP my change over time. Policy provides a mechanism to simplify the administration of dynamic LSP admission criteria in order to optimize network performance. For example, LSP admission control policies may be established to vary the set of admitted flows to match projected time-of-day sensitive traffic demands. (e) Integration with Network Service Objectives. The policy based networking architecture provides a mechanism to link the service level objectives of the network to specific protocol actions within MPLS. 4.2 Example Intra-Network Architecture Applying the policy-based network architecture to the MPLS network, the Edge Label Switch Router (ELSR) becomes the PEP as it is involved in the admission control of flows to the LSP. Intervening Wright Informational Expires September 2000 7 Requirements for Policy Enabled MPLS March, 2000 LSRs may also be PEPs e.g. in the case of MPt-Pt LSPs. Actual implementations may use a generic computing platform and leave the LSR as a PIN, but for now it is conceptually simpler to consider them the same piece of equipment. ++++++++++++++ + Policy + + Management + + Tool + ++++++++++++++ |\ |\ | | (e.g., LDAP) | ++++++++++++++ | + Policy + | + Repository + | + + | ++++++++++++++ | |\ | | (e.g. LDAP) ++++++++++++++ + Policy + + Decision + + Point + ++++++++++++++ / | \ / | +-------+ / | \ (e.g. COPS, SNMP) +++++++++++++++ ++++++++++++++ +++++++++++++++ + ELSR is PEP +---+ LSR is PEP +---+ ELSR is PEP + +++++++++++++++ ++++++++++++++ +++++++++++++++ Figure 5 LSR as PEP 5 Example Policies In this draft we consider two main categories of Policies for MPLS : 1. LSP Admission Policies that map traffic flows onto LSPs (see section 5.1) 2. LSP Life Cycle Policies affecting LSP creation, deletion, configuration and monitoring (see section 5.2) Mapping traffic flows onto LSPs involves the policy system setting up classifiers in the ingress LSR(s) of an LSP to identify which packets get admitted onto the LSP and process the packets accordingly. In MPLS, label switched paths are associated with a Forwarding Equivalence Class (FEC) that specifies which packets are to be sent onto the LSP. Classifiers from the policy server define the characteristics of the FEC and packets/flows that match these characteristics are sent over the LSP. In this way, the FEC that gets mapped onto an LSP can be defined according to a number of flow characteristics such as application, source/destination/subnet address, user, diffserv code point on incoming packet, etc. Wright Informational Expires September 2000 8 Requirements for Policy Enabled MPLS March, 2000 Configuring LSPs involves the creation and deletion of LSPs in the network according to some QoS or other criteria. This can be achieved in a number of ways, such as manual creation or invoking one of the label distribution mechanisms that support this (CR-LDP, RSVP). After a label switched path is created, it must be monitored for performance to ensure that the service it provides continues to behave as expected. For example, the LSP MIB counters such as a count of packets dropped in a particular LSP can be used to gauge performance. If the configured resources along the LSP become insufficient for the traffic requests for them, or if the requirements change, a new path may be necessary, or an existing one changed, according to a new set of constraints. As part of the policy-based management of MPLS, the LSRs must provide feedback to the policy system to perform this monitoring. For example, in [2], an LSP performance table tracks incoming and outgoing statistics related to octets, packets, drops, and discards on MPLS trunks. Using this information, the LSR can notify the server when performance levels fall below some threshold based on the available statistics. The server would then have the ability to enhance the current LSP or create alternatives. 5.1 LSP Admission Policies While an LSP can be configured for use with best effort traffic services, there are often operational reasons and service class reasons for restricting the traffic that may enter a specific LSP. This problem is conceptually similar to the flow classification problem within the differentiated service architecture where flows are classified in order to have a specific marking applied. Here the classification results in admission to the FEC associated with a specific LSP. The problem is larger than that in the Diffserv architecture because the admission criteria may include (for example): (a) the DS marking as one of the potential classification mechanisms, (b) some form of authentication e.g. for access to an LSP-based VPN, or (c) traffic engineering policies related to other architectures than Diffserv (e.g. Int-Serv) The MPLS Framework [11] considers this classification aspect in terms of establishing a flow with a specific granularity. These granularities can be considered as a base set of criteria for classification policies. It identifies the following examples of Unicast traffic granularities: - PQ (Port Quadruples) same IP source address prefix, destination address prefix, TTL, IP protocol and TCP/UDP source/destination ports - PQT (Port Quadruples with TOS) same IP source address prefix, destination address prefix, TTL, IP protocol and TCP/UDP Wright Informational Expires September 2000 9 Requirements for Policy Enabled MPLS March, 2000 source/destination ports and same IP header TOS field (including Precedence and TOS bits). - HP (Host Pairs) Same specific IP source and destination address (32 bit) - NP (Network Pairs) Same IP source and destination address prefixes (variable length) - DN (Destination Network) Same IP destination network address prefix (variable length) - ER (Egress Router) Same egress router ID (e.g. OSPF) - NAS (Next-hop AS) Same next-hop AS number (BGP) - DAS (Destination AS) Same destination AS number (BGP) The Framework document also identifies following Multicast traffic granularities: - SST (Source Specific Tree) Same source address and multicast group - SMT (Shared Multicast Tree) Same multicast group address For LSP admission decisions based on QoS criteria, the calculations may involve other traffic characteristics relating to buffer occupancy and scheduling resource decisions. These may include parameters such as : - burstiness measures ( e.g. Path MTU size or Packet size) - Inferred or signaled bandwidth requirements 5.2 LSP Life Cycle Policies MPLS permits a range of LSP creation / deletion modes from relatively static, manually provisioned LSPs, dynamic LSPs initiated in response to routing topology information and data driven LSP generation. Policy impacts can vary depending on the LSP creation / deletion modes. The RFCs encompassing MPLS support a variety of mechanisms for the creation / deletion of LSPs e.g. manual provisioning, LDP, CR-LDP, RSVP, BGP etc. Ideally the policy should be independent of the underlying mechanism. For example, with manually provisioned LSPs, the role of policy may be to restrict the range of authorized users that can create or delete LSPs, or the range of addresses that can be connected by LSPs (e.g. Intra-Domain, intra-VPN). With topology driven LSP setup, there may be policy constraints on speed of re-establishment of LSPs or the number of LSPs. With data driven LSP establishment, there may be policies related to the data characteristics that trigger the creation or deletion of an LSP. When created, LSPs may have certain attributes. For example, traffic-engineering policies may be applied to reserve network resources such as bandwidth on specific links for an LSP. LSPs in general are sink based tree structures. The merge points of the LSP may have policies, for example, policies associated with the buffer management at the merge point. The characteristics or attributes of an LSP may be impacted by different policy considerations. While this may be affected at the Wright Informational Expires September 2000 10 Requirements for Policy Enabled MPLS March, 2000 time of LSP creation, it may also be desirable to alter the attributes of an existing LSP. 6 Scenario Example of a Policy-Enabled MPLS network This scenario only addresses a subset of the LSP Creation/Deletion Policies that are mentioned in Section 5 above; this is just meant to be a starting point, not a specification. We include this level of detail in this draft, in order to help fit some of the pieces together in describing the base requirements and to provide examples of the mechanisms that may be used to implement MPS policy. Our sample policy-enabled MPLS scenario, makes the following (limiting) assumptions: (a) A label distribution protocol that supports the specification of QoS constraints is used (b) LSPs are established as administratively specified explicit paths where the route is specified either entirely or partially at the time the path is established (c) COPS + PIBs used for policy protocol between policy server (PDP) and LSRs (PEPs); this lets us reference specific examples of policy protocol messages. This is NOT meant to represent a specification of a cops-mpls policy client. 6.1 LSP Setup The PDP determines an LSP is to be established. Possible choices for how the PDP gets signaled to make this determination include: human input at the network management console (manually provisioned LSP), and receipt of a <trigger> from an ingress LSR as a result of receiving a particular type of data packet or observing a particular performance level deficiency (data-driven LSP provisioning). Note that in the case of data-driven LSP establishment, an initial policy must get implemented in the LSR specifying what types of data packets to look for that can trigger an LSP. This is very much like RSVP QoS policy where the decision to permit the resource reservation is outsourced to the PDP. In the MPLS case, however, the outsourced decision is not just to accept or deny the request, but involves a separate step of initiating the LSP session, as described below. For example, an LSP may be required to support a specific service or set of services in the network. This may imply traffic characteristics for the LSP, for example peak data rate, committed data rate, burst size, etc. If explicit routes are used, the PDP determines the specific LSRs that are to be part of the path. The LSP may be partially explicit, specifying some specific LSRs that must be included, and the remainder of the LSP left to the routing protocols. An intelligent PDP may use feedback information from the LSRs to determine if they currently have sufficient resources free to support the resource requirements of the LSP. Alternatively, the LSP creation could use a Wright Informational Expires September 2000 11 Requirements for Policy Enabled MPLS March, 2000 topology-driven method where the path is determined by the routing protocol (and the underlying label distribution protocol processing). In this case, the LSP creation is initiated with specification of the traffic requirements. Any way the LSP is routed, any traffic constraint requirements must be met by all LSRs that get included in the LSP. The PDP issues a policy message to the ingress LSR of the LSP, including the explicit route information (if applicable), strict or loose route preferences, traffic parameters (constraint requirements), etc. In the COPS + PIB example, this is done via a COPS Decision (cops-pr, probably using a <cops-mpls> client type in the PEP) that includes MPLS PIBs describing the CR-LDP constraints. The MPLS policy client in the LSR takes the message and initiates a LSP session. If CR-LDP is used, for example, this is done by sending a Label Request message containing the necessary CR-LDP TLVs (ER- TLV, Traffic TLV, CD-LSP FEC, etc.). If RSVP is used, a Path message containing the constraint information is sent from the ingress LSR to the egress LSR. The LSR establishment is similar, from a policy point of view, regardless of label distribution protocol used. We will assume CR-LDP in the rest of the example. The Label Request is propagated downstream and gets processed as usual according to CR- LDP procedures (downstream on demand label advertisement). When the egress LSR processes the Label Request, it issues a Label Mapping message that propagates back upstream establishing label mappings between MPLS peers for the LDP. Eventually the ingress LSR receives back a Label Mapping message from the next-hop LSR and it notifies the PDP of the label it received, to be used when forwarding packets to the next-hop on this LDP, and the LSPID. If the path could not be established, due to errors or insufficient resources or whatever, the error notification gets sent to the PDP. If COPS is used as the policy protocol, this is done with a COPS Report message, containing the MPLS label and referencing the Decision message that initiated the CR-LDP session. 6.2 LSP Admission Control With the LSP established and the label to be used for sending packets to the next-hop on the LSP known, the PDP can issue policies to specify which packets/flows get mapped onto the LSP, i.e. which packets belong to the FEC for the LSP. Using the COPS + PIB example, this is done in a similar manner to the way packets get mapped to Diffserv PHBs in ingress routers of a Diffserv network. A COPS Decision message is issued containing PIB table entries for: the classifier that specifies the FEC, a profile for policing and admission control to the LSP, the label to put on the packets that match the classifier, and what to do with packets that match but are out of profile. As packets come into the ingress LSR the MPLS policy is enforced and packets are matched against the FEC classification and profile. The metering capability allows the PDP to specify a profile for policing so that admission control can be performed on the packets utilizing Wright Informational Expires September 2000 12 Requirements for Policy Enabled MPLS March, 2000 the LSP resources. Also, the policy installed by the PDP for the FEC can specify a (PIB) MPLS Action table entry, for certain data packet types that might be admitted onto the LSP, to authenticate the policy information about the packet with the PDP. This action is quite similar to the way COPS-RSVP works, where the PDP returns an accept/deny decision to indicate whether the packet is allowed access to the LSP or not. Packets that match the FEC classification and are in-profile, and have valid policy information (if applicable) get the label associated with the LSP for that FEC. This might involve pushing the label onto the top of a label stack if the packet already has a label for another LSP. This is handled according to MPLS label processing rules. 6.3 LSP Monitoring The PDP must monitor the performance of the LSP to ensure the packets that are being mapped to the LSP receive the intended service. Information such as that specified in the MPLS LSR MIB [2] In-segment Performance table, Out-segment Performance table, etc. may be used for this purpose (other data/stats may also be better or be better suited for this purpose). As the PDP gathers this feedback information, it makes decisions regarding the creation/deletion/changing of LSPs and the packets that get mapped onto them. Actions taken by the PDP as a result of performance feedback analysis may include re-directing existing LSPs to route traffic around high congestion areas of the network, changing traffic parameters associated with an LSP to reserve more resources for the FEC, adding a new LSP to handle overflow traffic from an existing path, tearing down an LSP no longer in use, etc. 7 Security Considerations The policy system and the MPLS system both have their inherent security issues. The policy system can help to secure the MPLS system by providing appropriate controls on the LSP life cycle. Conversely, if the security of the Policy system is compromised, then this may impact any MPLS systems controlled by that policy system. The MPLS network is not expected to impact the security of the Policy system. Further security considerations of Policy-Enabled MPLS networks is for further study. 8 References [1] C.Srinivasan, A.Viswanathan, "MPLS Traffic Engineering Management Information base using SMIv2", work in progress, draft- ietf-mpls-te-mib-01.txt, June1999 Wright Informational Expires September 2000 13 Requirements for Policy Enabled MPLS March, 2000 [2] C.Srinivasan, A.Viswanathan, "MPLS Label Switch router Management Information base using SMIv2", work in progress, draft- itef-mpls-lsr-mib-00.txt, June1999 [3] D.Awduche, J.Malcolm, J.Agogbua, M.OÆDell, J.McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999. [4] H.Mahon, Y.Bernet, S.Herzog, "Requirements for a Policy Management System", work in progress, draft-ietf-policyûreq-01.txt, October 1999. [5] R.Yavatkar, D.Pendarakis, R.Guerin, "A Framework for Policy- based Admission Control", RFC2753, January 2000. [6] T.Li, Y.Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering(PASTE)", RFC 2430, October 1998 [7] F.LeFaucher, L.Wu, B.Davie, S.Davari, P.Vaananen, R.Krishnan, P.Cheval, "MPLS Support of Differentiated Services", work in progress, draft-ietf-mpls-diff-ext-02.txt, October 1999 [8] J. Cucchiara, H. Sjostrand, J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", draft-ietf-mpls-ldp-mib-04.txt, January 2000. [9] F.Reichmeyer, S. Herzog, K. Chan, J. Seligson, D.Durham. R. Yavatkar, S. Gai, K. McCloghrie, A. Smith, "COPS Usage for Policy Provisioning", work in progress, draft-ietf-rap-pr-01.txt, October 1999. [10] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, "Quality of Service Policy Information Base", work in progress, draft-mfine-cops-pib-02.txt, October, 1999. [11] R.Callon, P.Doolan, N.Feldman, A.Freddette, G.Swallow, A.Viswanathan, "A Framework for MPLS", work in progress, draft-ietf- mpls-framework-05.txt, September 1999. [12] E.Rosen, A.Viswanathan, R.Callon, "Multiprotocol Label Switching Architecture", work in progress, draft-ietf-mpls-arch- 06.txt, August 1999. [13] G.Armitage, "MPLS: The Magic Behind the Myths", IEEE Communications Magazine, January 2000, pp 124-131 [14] J.Strassner, E.Ellesson, "Terminology for describing Network Policy and Services", work in progress, draft-ietf-policy-terms- 00.txt, June 1999 Wright Informational Expires September 2000 14 Requirements for Policy Enabled MPLS March, 2000 9 Authors Addresses Steven Wright Science & Technology BellSouth Telecommunications 41G70 BSC 675 West Peachtree St. NE. Atlanta, GA 30375 Phone +1 (404) 332-2194 Email: steven.wright@snt.bellsouth.com Shai Herzog & Francis Reichmeyer IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone +1 (201) 655-8714 Email: franr@iphighway.com Robert Jaeger Laboratory for Telecommunications Science, 2800 Powder Mill Road, Bldg 601, Room 131 Adelphi, MD 20783 Phone +1 (301) 688-1420 Email: rob@lts.ncsc.mil Wright Informational Expires September 2000 15 Requirements for Policy Enabled MPLS March, 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Wright Informational Expires September 2000 16