Internet Draft Diana Rawlins Expiration: December 2002 Lei Yao File: draft-rawlins-admctl-ds-mgt-03.txt David E. McDysan WorldCom Edge Based Admission Control with Class Based Resource Management Last Updated June 14, 2002 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. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Abstract New value-added IP services such as VoIP requires per-flow admission control to be performed in order to ensure the admission of new traffic flows does not degrade the performance of the existing traffic flows in the network. Resource Reservation Protocol (RSVP) for Intserv [2205] is proposed to support per-flow admission control. However, RSVP requires per-flow state installation, per-flow state refreshment, per-flow traffic management and resource reservation on each node along a forwarding path, which cause significant scalability issues, especially on the boundary routers and core routers of service providesÆ networks, which need to process thousands of traffic flows as network aggregation points. Intserv over Diffserv networks proposed in [2998] requires the RSVP/Intserv processing only on boundary routers and edge routers. Nevertheless, RSVP/Intserv has still rarely been supported by boundary router Rawlins et al. Expires December 2002 [Page 1] Internet Draft ADMCTL-DS-MGT June 2002 vendors because of the scalability issue. The use of edge-based admission control with per-class resource management and policy control offers a scalable approach to manage per-flow admission control for QoS sensitive applications. Rawlins et al. Expires December 2002 [Page 2] Internet Draft ADMCTL-DS-MGT June 2002 Table of Contents 1 Introduction.....................................................4 2 Background.......................................................4 2.1 Per flow resource guarantees with Resource Reservation Protocol4 2.2 Integrated Services over Differentiated Services...............6 3 Edge-based Per-flow Admission Control............................7 3.1 RSVP Admission Control for Upstream Links......................8 3.1.1 Identifying Receiver Side RSVP Edge Router...................9 3.1.2 Upstream Link Resource Availability..........................9 4 Resource Pool and Queuing Design................................10 5 Policy Configuration Interface for Per-Flow Adm Ctl with Per-Class Resource Management...............................................12 6 Security Considerations.........................................14 7 Notice Regarding Intellectual Property Rights...................14 8 Authors' Addresses..............................................14 9 References......................................................15 Rawlins et al. Expires December 2002 [Page 3] Internet Draft ADMCTL-DS-MGT June 2002 1 Introduction The new value-added IP services such as VoIP requires per-flow admission control to be performed in order to ensure the admission of new traffic flows does not degrade the performance of the existing traffic flows in the network. Resource Reservation Protocol (RSVP) for Intserv [2205] is proposed to support per-flow admission control. However, RSVP requires per-flow state installation, per-flow state refreshment, per-flow traffic management and resource reservation on each node along a forwarding path, which cause significant scalability issues, especially on the boundary routers and core routers of service providesÆ networks, which need to process thousands of traffic flows as network aggregation points. Intserv over Diffserv networks proposed in [2998] requires the RSVP/Intserv processing only on boundary routers and edge routers. Nevertheless, RSVP/Intserv has still rarely been supported by boundary router vendors because of the scalability issue. This document describes an edge-based per-flow admission control concept that pushes all the intelligence for per-flow admission control to the very edge of a service providerÆs network, i.e. edge routers in customer sites. This asymmetric per-flow admission control moderates the scalability issue of RSVP by using the resource pool mechanism to map per-flow bandwidth requirements to class-based resource pool for resource reservation and management. Therefore, there is no need to manage resource on per-flow basis on the provider boundary routers. Furthermore, other per-flow signaling protocols, such as SIP may be used to perform admission control. This document is organized as follows: Section 2 provides a background of RSVP/Intserv and Intserv over Differentiated Services Networks; Section 3 describes the edge-based per-flow admission control approach; Section 4 discusses the resource pool and queuing design; finally, Section 5 describes the policy control for per-flow admission control with per-class resource management. 2 Background 2.1 Per flow resource guarantees with Resource Reservation Protocol RSVP requests resources for unidirectional flows. It is a QoS signaling protocol on the control plane of a network device. RSVP does not have routing functions. It is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes which decide the next hops packets get forwarded. RSVP is only concerned with the QoS of those packets that are forwarded in Rawlins et al. Expires December 2002 [Page 4] Internet Draft ADMCTL-DS-MGT June 2002 accordance with routing, i.e. RSVP consults the forwarding table (as populated by routing instances) in order to decide the downstream interface on which policy and admission control for QoS are applied. Although sender initiates a RSVP session using a PATH message, RSVP makes receivers responsible for requesting a specific QoS for the session. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request with a RESV message to all the network nodes (routers and hosts) along the reversed forwarding path to the sender. HOST ROUTER _____________________________ ____________________________ | _______ | | | | | | _______ | | _______ | | |Appli- | | | |RSVP | | | | | | cation| | RSVP <---------------------------> RSVP <----------> | | <--> | | | _______ | | | | | | |process| _____ | ||Routing| |process| _____ | | |_._____| | -->Polcy|| || <--> -->Polcy|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | |data | | |_____|| ||__.____| | | |_____|| |===|===========|==|==========| |===|==========|==|==========| | | --------| | _____ | | | --------| | _____ | | | | | ---->Admis|| | | | | ---->Admis|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | | | | | |_____|| | | | | ||_____|| | |Class-| | Packet | | | |Class-| | Packet | | | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | |______| |________| |data | |______| |________| |data | | | | |_____________________________| |____________________________| Figure 1 RSVP 2205 Figure 1 shows the RFC 2205 Intserv nodal processing model. After receiving a QoS request (carried in RESV message) from RSVP process, a node implements QoS for a particular flow by mechanisms collectively called ôtraffic conditioningö. These mechanisms include (1) a packet classifier, (2) admission control, and (3) a packet scheduler. The ôpacket classifierö identifies the packets of the flow using a multi-field filter derived from the RSVP session and determines the QoS class (and perhaps the route) for each packet. The ôPacket schedulerö provides the promised QoS forwarding behavior on each outgoing interface. During the reservation setup, an RSVP QoS request is passed to two local decision modules, ôadmission controlö and ôpolicy controlö. Admission control determines whether the node has sufficient available resources (i.e. outgoing link bandwidth) to deliver the requested QoS. Policy control determines whether the user has administrative permission to make the reservation. If both checks Rawlins et al. Expires December 2002 [Page 5] Internet Draft ADMCTL-DS-MGT June 2002 succeed, parameters are set in the packet classifier and the scheduler to obtain the desired QoS, and the RSVP process notifies the application originated the request to start transmitting data packets. If either check fails, the RSVP process returns an error notification to the application process that originated the request. 2.2 Integrated Services over Differentiated Services Figure 2 shows the generic model for Integrated Services over Differentiated Services domain as described in RFC 2998 in which edge routers connect Intserv-aware customer LANs to boundary routers of the Diffserv network. We consider a unidirectional traffic flow from the left-hand customer LAN (i.e. LAN-TX) to the right-hand customer LAN (i.e. LAN-RX). Edge router and boundary router are labeled ER-TX and BR-TX, respectively, at the transmitter side, but they are labeled ER-RX and BR-RX, respectively, at the receiver side. The control plane and data plane are shown in the upper and lower half of each router, respectively. LAN-TX ER-TX BR-TX BR-RX ER-RX LAN-RX |------| |------| |------| |------| rsvp | |rsvp | | |rsvp | | |rsvp | | rsvp <--->| IS |<--> |IS| |<--->| |IS |<--->| IS |<---> | | | | | | | | | | |------| |------| |------| |------| data |IS|DS |data |DS|DS |data |DS|DS |data |DS|IS | data ---->|IN|OUT|---->|IN|OUT|---->|IN|OUT|---->|IN|OUT|----> |------| |------| |------| | -----| ------------- TRAFFIC FLOW ------------------> Figure 2 RFC 2998 In Diffserv network, only interfaces on boundary routers facing an edge router must have Intserv control plane. The control plane manages the RSVP signal. It performs the Intserv policy and admission control functions and maintains the per flow state with path and reservation state blocks. Before sending a traffic flow, a sending host in LAN-TX initiates a RSVP PATH message. When the receiving host in LAN-RX receives the PATH message, it returns a RSVP RESV message to request the reservation of resources. After receiving the RESV message, each intermediate router having Intserv control plane must perform admission control for its downstream link, e.g., ER-RX performs admission control for the LAN-RX, BR-RX performs admission control for the link between itself and ER-RX, BR-TX performs admission control for the Diffserv path between itself and BR-RX, and ER-TX performs admission control for the link between itself and BR-TX. The RSVP admission control process verifies the resource availability on Rawlins et al. Expires December 2002 [Page 6] Internet Draft ADMCTL-DS-MGT June 2002 the link and adjusts the remaining resource level accordingly for the link after admitting the RSVP request. Although per-flow admission control is performed on the control plane, the actual delivery of QoS for a traffic flow is accomplished on the data plane. After receiving the RESV message, the sending host starts sending data packets. ER-TX performs Intserv operations on received data packets at its input interface, i.e. per-flow classification, per-flow policing as well as per-flow DSCP marking. At the output interface of ER-TX, data packets are identified and enqueued solely based on their DSCP values. BR-TX performs per-class policing for each customer at its input interface and class-based queuing at its output interface. There is no additional operation at the input interface of BR-RX. At the output interface of BR-RX, it performs class-based queuing and may also perform per-class shaping for each customer. ER-RX usually does not perform any additional operations except forwarding received packets at its input interface. At its output interface, ER-RX may perform per-flow scheduling or shaping. Note that a denial/theft of service attack can occur at BR-RX and ER-RX if per-flow policing and marking is not done at ER-TX. 3 Edge-based Per-flow Admission Control Figure 3 shows a high-level overview of the proposed approach that eliminates Intserv processing from the boundary routers. We consider a unidirectional traffic flow from the left customer LAN (i.e. LAN-TX) to the right customer LAN (i.e. LAN-RX). The routers in Figure 3 are labeled the same as those in Figure 2. The control plane and data plane are shown in the upper and lower half of each router. LAN-TX ER-TX BR-TX BR-RX ER-RX LAN-RX |------| |------| |------| |------| rsvp| |rsvp | |rsvp | |rsvp | |rsvp <--->| IS |<----------------------------->| IS |<---> | | | | | | | | | |------| |------| |------| |------| data|IS|DS |data |DS|DS |data |DS|DS |data |DS|IS |data ---->|IN|OUT|---->|IN|OUT|---->|IN|OUT|---->|IN|OUT|----> |------| |------| |------| | -----| ------------- TRAFFIC FLOW ------------------> Figure 3 Edge-based Per-Flow Admission Control All routers in Diffserv network including core routers as well as boundary routers do not have Intserv control plane. It is assumed that there is no need for admission control in the Diffserv network since it has been well traffic engineered. Only edge Rawlins et al. Expires December 2002 [Page 7] Internet Draft ADMCTL-DS-MGT June 2002 routers have Intserv control plane that processes RSVP messages. Before sending a traffic flow, a sending host in LAN-TX initiates a RSVP PATH message. When receiving the PATH message, the receiving host in LAN-RX returns a RESV message to request the reservation of resources. The RESV message is only processed at edge routers: after receiving the RESV message, ER-RX performs admission control not only for its downstream LAN-RX but also for its upstream link, i.e. the link between itself and BR-TX. The details of upstream admission control are described in Section 3.1; ER-TX performs typical downstream admission control. After receiving the RESV message, the sending host starts sending data packets. Each router along the forwarding path performs the same operations on the received data packets as those described in Section 2.2. In order to control the amount of Intserv traffic, we assume that one or more separate queues are allocated for Intserv classes at the output interface of each router. Intserv packets are marked with specific DSCP values (which could be drawn from the pool of 16 code points (Pool 2 xxxx11) reserved for experimental or local use) on ER-TX. The Intserv ûspecific DSCP values are used to identify and en-queue Intserv packets on at least the ER-TX and BR-RX routers. Intserv queue(s) may be physically separate from all other queues, or may be logically separated from other queues using one of several methods. For example, one method would be to police multiple DSCP values sharing a single queue such that the sum of the policed rates is less than the scheduler weight assigned to the shared queue. This proposed approach is a more scalable solution for Intserv over Diffserv networks than RFC 2998. Intserv to DiffSrv interworking is only required on the ER-TX. The upstream link check is only required on the ER-RX. RSVP/Intserv processing is not required on any boundary routers, i.e., BR-TX and BR-RX. 3.1 RSVP Admission Control for Upstream Links Upstream admission control is performed only on ER-RX. An ER-RX keeps separate or shared virtual pool for each Intserv class. The virtual pool keeps the upstream link resource availability for each Intserv class in the control plane of the ER-RX. Please see the detailed description of virtual pool concept in Section 4. Whenever the ER-RX receives a RESV message, it checks the available bandwidth of the requested Intserv class against the request bandwidth. If the requested bandwidth is below the reservable bandwidth of the Intserv class, the reservation request is accepted and the reservable bandwidth of the Intserv class is reduced by the amount of reserved bandwidth. Otherwise, the reservation request is rejected and ER-RX sends a RESVERR message to the receiver. After the reservation request is accepted, the ER-RX forwards the RESV message to its upstream router. Several functions must be added in order to support RSVP admission control for its upstream link on ER-RX. First the ER-RX must know that it is at the receiver-side of a traffic flow and secondly, Rawlins et al. Expires December 2002 [Page 8] Internet Draft ADMCTL-DS-MGT June 2002 the ER-RX must know the resource availability of its upstream link, i.e., the resource availability at the output interface of BR-RX. 3.1.1 Identifying Receiver Side RSVP Edge Router Figure 4 illustrates an approach that may be used to identify the receiver-side edge router. We assume all the customer LANs, edge routers and boundary routers have different IP addresses. An edge router can decide if it is at the receiver-side of a traffic flow by comparing the destination IP address (DestAddress) contained in SESSION object of the RSVP RESV message with the IP subnet of its attached customer LANs. If and only if DestAddress of the RSVP session falls into IP address range of one of its attached customer subnets, the edge router is at the receiver side of the traffic flow. For example, as shown in Figure 4, LAN-RX has subnet address a.b.p.0/24. When ER-RX receives a RESV message with session object containing DestAddress, a.b.p.d, it knows that the receiving host is in LAN-RX. Therefore, ER-RX knows that it is the receiver-side edge router and performs RSVP admission control for its upstream link. LAN-TX ER-TX BR-TX BR-RX ER-RX LAN-RX |------| |----| |----| |--------| rsvp| |rsvp | |rsvp | |rsvp | |rsvp Session= dest/addr=a.b.p.d | | |sess= a.b.p.d | | | | | | |a.b.p.d <--->|---| |<------------------------->|---| |--|<-----> |AC | | | | | | |AC | |AC| |---| | | | | | |---| |--| | | | | | | | | |------| |----| |----| |--------| data| |data | |data | |data | |data ---->| |---->| |---->| |---->| |----> |------| |----| |----| | -------| ------------- TRAFFIC FLOW ------------------> Figure 4 Upstream AdmCtl 3.1.2 Upstream Link Resource Availability There is a fundamental requirement to keep the configuration of Intserv virtual pool capacities for its upstream link on ER-RX to be consistent with the configuration of logical queue(s) and scheduler weight(s) on BR-RX. A PDP may serve as the central point for Intserv provisioning. For example, after receiving a customer service order, a network service provider sales representative or operator may use a Network Management System (NMS) to provision the PDP. The PDP pushes the configuration of Intserv virtual pool capacities onto each ER-RX that is the downstream node of a BR-RX. If the configuration is successfully installed, each ER-RX replies with an ACK. PDP then pushes the corresponding configuration of Rawlins et al. Expires December 2002 [Page 9] Internet Draft ADMCTL-DS-MGT June 2002 Intserv DSCP queue(s) and scheduler weight(s) onto BR-RX. BR-RX also returns an ACK to PDP if the configuration is successfully installed. In case that ER-RX fails to install the Intserv virtual pool(s), it should return an NACK to PDP. PDP should send a warning message to network operator with description, "Fail to configure Intserv virtual pool on ER XX!". In case that Intserv virtual pool(s) is successfully installed on ER-RX but queue(s) and scheduler weight(s) cannot be installed on BR-RX, BR-RX returns an NACK to PDP. PDP should send a message to ER-RX to release the configuration of virtual pool. PDP also needs send a warning message to network operator with description, "Fail to configure Queue and Scheduler on BR XX!" The above mechanism is sufficient for service initialization for a new customer. However, it is more complex when there is a service update order from an existing customer, i.e. the customer requests to increase or decrease its subscribed Intserv capacity. Both increasing the BR-RX capacity and decreasing the BR-RX capacity when the reserved bandwidth is below the new capacity are straightforward since the new capacity can accommodate all the ongoing customer traffic and no service interruption will be observed. Nonetheless, decreasing the BR-RX capacity when the reserved bandwidth is above the new capacity requires more coordination among PDP, BR-RX and ER-RX. 4 Resource Pool and Queuing Design The Intserv admission control process on edge router uses a free pool concept for determining the availability of local resources at a network device. The two Intserv classes either have separate resource pools or a shared resource pool in the control plane of an edge router. There is a direct association of the virtual pools used by admission control to logical queues used by Diffserv on the data plane where each member of the virtual pool is uniquely associated with one and only one member of the queues. The packet scheduler in the data plane allocates fixed bandwidth for each queue. The boundary router and edge router may use either shared or separate queues for different Intserv classes and the edge based admission control will still function correctly. One example of virtual pool and queuing design is as shown in Figure 5. There is a separate virtual resource pool and queue provided for each Intserv class (GS and CL) . As shown in the Figure, the PDP configures multiple modules in both Intserv control plane and Diffserv data plane of ER-TX through a policy control interface (PCI). The configured modules include packet scheduler, queues, virtual pools, local policy control and IS-DS internetworking configuration module (IS-DS IWF). By configuring packet scheduler, queues and virtual pools, the PDP assigns the appropriate bandwidth for each Intserv class for both admission control and packet forwarding purpose. The local policy control authorizes the eligibility of customers to request RSVP resource Rawlins et al. Expires December 2002 [Page 10] Internet Draft ADMCTL-DS-MGT June 2002 reservation. The PDP configures the mapping between Intserv classes and DSCP values on IS-DS IWF configuration module (e.g. GS-100011, CL-010011). The IS-DS IWF configuration module receives configurations also from RSVP processes and dynamically provisions the packet classifier, policer and marker for each Intserv flow. It should be noted that the packet classifier, policer and marker could be implemented as a single integrated module (e.g. a single FPGA or ASIC chip). |--------------------------------------------------| | | | ER-TX |------------------------------| | | V V | | |--------| |---------------| |---------| | | | RSVP | | Admission Ctl | | Local | | | C | Process| | |----| |----| | | Policy |< | | O |--------| | | GS | | CL | | | Control || | |---| | N v | |----| |----| | |---------|| |-| | | | T |---------| |---------------| | | | | | | R |IS-DS IWF|<------------------------------| |P| | P | | O |Config | |----------------| <-|C|--| D | | L |---------| |Virtual Pools | | |I| | P | | | | |----| |----| |<-----------| |-| | | | -----v---- | | GS | | CL | | | | | | | | | | | |----| |----| | | | |---| | | | | |----------------| |<---| | | | | | | | | | | |-----|----|---|--------------------------|--------| | V V V | | | | | |---| |-| |-| v | ||---| | | | C| | | | | |----------|-| || S| | | |P L| |P| | | | GS Queue v |<--------|| C| | | |A A| |O| |M| | |------------| ||P H| | |D |C S| |L| |A| |-| CL Queue |<------||A E| | |A |K S| |I| |R| | |------------| ||C D| | |T |E I| |C| |K| |-| EF Queue |<----||K U| | |A |T F| |E| |E| | |------------| ||E L| | | | I| |R| |R| |-| AF Queue |<--||T E| | | | E| |_| |-| | |-----------| || R| | | | R| |-| Default | ||---| | | |---| | Queue |<-| | | |-----------| | |--------------------------------------------------| Figure 5 For the upstream admission control, the ER-RX provides separate pools for GS and CL classes and BR-RX provides separate queues for GS and CL classes. The synchronized configurations of Intserv capacity between ER-RX and BR-RX is central controlled by the PDP. The local policy control on ER-RX is also configured to authorize the eligibility of customers to request RSVP resource reservation. Rawlins et al. Expires December 2002 [Page 11] Internet Draft ADMCTL-DS-MGT June 2002 5 Policy Configuration Interface for Per-Flow Adm Ctl with Per-Class Resource Management Figure 6 illustrates the policy configuration interface by which PDP provisions the edge router Intserv processing parameters and the boundary router Intserv capacity (queue(s) and scheduler weight(s)). |------------------------| | | | Policy Decision Point |<---------- | | | |-----------|------------| | | | | | ---------------------------------------- | | | | | | |----|---------|-------| | |------|--------|----| | | | | | | | | | | |--|---------|---| | |---| |---| | |---|--------|--| | | | P C I | | | | |---| | | | | | |----------------| | | | |PCI| | | P C I | | | | | | | | |---| | |---------------| | | V V | | | | | | | V | | | |-----| |----------| | | | | V | | |--------| |-----| | | |IS-DS| |Downstream| | | | |---| | |Upstream| |Pool | | | | IWF | | Adm Ctl | | | | | I | | |Adm Ctl | |Usage| | | |-----| | Virtual | | | | | S | | |Virtual | |Feed-| | | | Pool | | | | |CAP| | | Pool | |back | | | |----------| | |---| |---| | |--------| |-----| | |----------------------|BR-TX BR-RX |--------------------| ER-TX Control Plane ER-RX Control Plane Figure 6 The control planes of both ER-TX and ER-RX support RSVP processing. The ER-TX control plane processing performs Intserv to Diffserv mapping, and the downstream admission control. The ER-TX data plane processing performs the Intserv packet classification and policing, Diffserv remarking, Intserv queue(s) and scheduler weight(s) allocation. The ER-RX control plane performs upstream admission control. The upstream admission control virtual pools are associated with the BR-RX Intserv capacity. The sum total of the ER-RX virtual pools capacity cannot exceed the associated BR-RX Intsrv resource pool capacity. The PDP can also obtains feedback from the ER-RX Intserv resource pool usage and dynamically coordinate the operator initiated Intserv capacity adjustments on the virtual pools and Intserv queue(s) and scheduler weight(s) to ensure that actual utilized Intserv capacity is less than the value of the redefined capacity. Rawlins et al. Expires December 2002 [Page 12] Internet Draft ADMCTL-DS-MGT June 2002 When an edge router receives a RSVP RESV message it determines if it is the ER-RX by using End Point Identification Table as described in Section 3.1.1. If the ER-RX receives a RSVP RESV message, the RSVP processing invokes the upstream admission control. The upstream admission control process uses entries in the Admission Control Virtual Pool Table to base the maximum available capacity as described in Section 4. The sum total of capacity assigned to the admission control virtual pools cannot exceed the capacity of the associated boundary router. When the ER-TX is receiving the RSVP RESV message, the RSVP processing invokes the downstream admission control using the associated downstream entries in the Admission Control Virtual Pool table as described in Section 4. Operator initiated configuration of the BR-RX Intsrv capacity and associated ER-RX virtual pools is governed by the PDP using the ER- RX and BR-RX qosQTable weights and shapers values, related ER-RX Admission Control Virtual Pool Table entries and reported Pool Usage Feedback entries as described in Section 3.1.2. The following data structures are used by the PDP to configure the PEP. The configured attributes support the IntSrv and DiffServ interworking of an RSVP control plane and Differentiated Services data plane. Admission Control Virtual Pool Table - An entry in the AdmCtlVirtualPoolTable defines the virtual pool. It specifies the Intsrv Service Type, the maximum capacity available to the IntSrv Admission Control process, reservation acceptance status and associated boundary router logical interface. Intsrv Capacity û This Policy Rule Class is in the existing IETF Differentiated Services PIB. The qosQTable defines the capacity in terms of rates (both weight and shaper.) The qosQTable defines the rate capacity that is associated with one or more edge router virtual pools. Note that the qosQTable policy structure can be used by both the BR-RX as well as ER-RX Differentiated Services queues that are reserved for Intsrv. Intsrv to Diffserv Interworking Function Table - The Intsrv to Diffserv Interworking Function Table defines the attributes used for the interworking between the RSVP process in the control plane and the Differentiated Services in the data plane. This is used by the Packet Classification and Packet Scheduling process for classifying and marking the traffic flow with the appropriate Differentiated Services Code Point and policing the flow. Edge Point Identification Table - The Edge Point Identification Table is used to identify the receiver domain. One or more entries of this table defines a range or ranges of addresses that are receivers with respect to the router. Admission control performs the Rawlins et al. Expires December 2002 [Page 13] Internet Draft ADMCTL-DS-MGT June 2002 upstream resource check when the RSVP Session Object matches one of these address ranges. Pool Usage Feedback Table û An entry of this table type provides current resource consumed by the Intsrv flows information. This is used by the PDP to determine when to complete provisioning an operator initiated capacity update. Boundary Resource Pool Table û This table defines the total rate capacity that may be assigned to the various Admission control virtual pools associated with a given egress boundary router (BR- RX) 6 Security Considerations The feedback information is sensitive and requires that authorized messaging occur between the PEP and the PDP. This protection can be accomplished with IPSEC between the PEP and the PDP or using the security mechanisms described in the base COPS protocol. 7 Notice Regarding Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 8 Authors' Addresses Diana Rawlins WorldCom 901 International Parkway Rawlins et al. Expires December 2002 [Page 14] Internet Draft ADMCTL-DS-MGT June 2002 Richardson, Texas 75081 Phone: 972-729-1044 Email: Diana.Rawlins@wcom.com Lei Yao 22001 Loudoun County Parkway Ashburn, VA 20147 Email: lei.yao@wcom.com Dave McDysan 22001 Loudoun County Parkway Ashburn, VA 20147 Email: dave.mcdysan@wcom.com 9 References [2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP)" RFC2205, September 1997. [2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC2210, September 1997. [2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC2211, September 1997. [2212] Shenker, S., Partridge, C., Guerin, R., "Specification of Guaranteed Quality of Service", RFC2212, September 1997. [2474]K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [2475]M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, "An Architecture for Differentiated Services", RFC 2475, December 1998 [2998] Bernet, Y., et al, ôIntegrated Services over Diffserv Networksö, RFC 2998, November 2000. [2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748, January 2000. [3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Policy Provisioning," RFC 3084, March 2001. Rawlins et al. Expires December 2002 [Page 15] Internet Draft ADMCTL-DS-MGT June 2002 [RSVPPCC] D. Rawlins, L. Yao, R. McClain, A. Kulkarni, ôRSVP Policy Control Criteria PIBö, draft-ietf-rap-rsvppcc-pib-01.txt, February 2002. Rawlins et al. Expires December 2002 [Page 16]