Internet Draft

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  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  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