49th IETF TUESDAY, December 12, 2000 1300-1400 Afternoon Sessions I Resource Allocation Protocol WG Meeting Minutes (Grande Blrm B) The chair (Mark Stevens) gave an overview of the agenda: -Status of COPS-PR -Dave Durham -Status of Framework PIB - Scott Hahn -Using RSVP to maintain control of network resources - Yoram Bernet -Framework Accounting PIB - Diana Rawlins -Std Application ids for use in RSVP identity policy element - Ralph Santitoro -A Filtering PIB for Edge Router Services and Provisioning via COPS-PR - Joerg Ottensmeyer -RSVP Policy Control Criteria PIB - Diana Rawlins -Data Model for Network Access - David Spence -COPS usage for SIP- Gerhard Gross ***Status of COPS-PR -Dave Durham The COPS-PR draft has completed last call. Some clarifications were added to the text; Forward SPPI references were added to the draft; Size Restriction for Reports was removed and the document is in IETF last call. The AD pointed out that the document could go through last call pending the SPPI is approved. Dave pointed out that the related documents i.e., SPPI and the framework PIB also completed last call. The COPS over TLS draft needs a port number from IANA. Comments/Questions: None ***Status of Framework PIB - Scott Hahn WG last call completed. Scott presented the following updates: text was cleaned up in the draft; The Role and RoleCombination TCs were added to the framework PIB document; Filters were simplified by removing the FilterGroup PRC, adding a negation flag to the base filter and using EXTENDS to extend the base filter to define the IP and 802 filters. The authors intend to ask for IETF last call for the framework PIB and the SPPI after this IETF. Comments/Questions: The AD confirmed that all 3 drafts (COPS-PR, SPPI and the frameworkPIB) will be submitted to the IESG for the Standards Track together. ***New RSVP ErrorValues Used to Modify Sender Behavior - Yoram Bernet Yoram pointed out that IT managers tend to not put traffic on the network if there is no way to control it. He presented two sample networks - one with a leased line and another with a diffserv n/w with a static SLA. The Sender behavior was to be controlled. This can be done by causing admitted traffic to be marked for prioritized traffic while, rejected traffic be marked for LBE (Less-than Best Effort) or be reduced. When there is no more capacity on the link, flow is rejected, hence no RESV is returned, hence no DCLASS is set. The objective is to have a mechanism to stop multimedia traffic from trashing the link as it interferes with BE traffic. The solution is to use PATH_ERR. -To signal explicit notification that flow cannot be handled. - Include policy error object NO_QOS_PROVIDED (optionally include DCLASS to force LBE) - explicit and immediate direction NOT to send (via PATH_ERR object DO_NOT_SEND). The sender responses for each of the above error codes was described. For NO_QOS_PROVIDED the sender can - scale back (reduce TSpec), - settle for LBE, - give busy signal to user (abstraction) - or use alternate I/f. For error code DO_NOT_SEND - the app has no choice. It either, does not send, or scales back and tries again or - use alternate I/f. Yoram presented a sample policy: if Requests (Total) < TB1 - admit and return DCLASS, if TB1 < Requests (Total) < TB2 admit BE DCLASS (or no DCLASS) OR reject if Requests (Total)>TB2 return DO_NOT_SEND Comments/Questions: Q: Is there some way of signaling - premium or nothing (go ahead and drop it)? A: On the host side we haven't thought of distinguishing that but that would be useful. Note that what one PDP uses as a DSCP for LBE may not be the same on another host. Q: 1. I noticed that a difference exists between what happens to RESV in the last two cases when the flow is rejected.2. Isn't the path pinned? A: There is no reserved path between the 2 endpoints- this should be mapped to something in the diffserv domain. Q: Should we explore the trust relationship here-should the n/w rely on actions taken by the host? A: The initial n/w we looked at is a leased line, and the diffserv cloud is a static SLA so the trust relationship is between the PDP and the clients around the diffserv cloud. Q: is there an issue here about traffic being injected into the n/w? A: The diffserv providers will have policies at the edge routers, and if somebody is hacking the PDP then there is recourse. In this case its not an issue - Now if the agent is adjusting the enterprise resources based on this traffic then it can be an issue. Q: The Busy signal - is this a metaphor you want to define? A: It's not the "beep beep". Its feedback of the form "go use a different network" or "Quality will be mediocre" or "use 56k instead of T1" - it's an abstract. The network should indicate the resources are not available. Q: Is Standards Track intended? -Yes, the error objects defined for the PATH_ERR message are optional, ignore them if you don't know what they mean. ***Framework Accounting PIB - Diana Rawlins Diana pointed out that this draft was being presented for the second time with significant changes from the 48th IETF. The draft addresses a need for a deterministic and flexible Reporting mechanism. The Approach was to define Reusable + extensible PRCs to specify selection, linkage and usage. PDP controls the RPT interval (ref RFC2748 AcctTimeObject) by specifying the Max interval and the resume attribute. PEP specifies reporting capabilities. Reporting TC CountType defined as an Unsigned64 that sticks. SPPI defines a "report" PIB-ACCESS type for report PRCs. The PRC structure is as follows: the selection-PRCs define "who"; the usage classes define "what" is counted/recorded and the linkage classes are the association classes. Issues to be addressed are: What if acct rpt spans many COPS RPT messages? - This was not anticipated but suggested resolution was a continuation flag to indicate more messages. Next steps were listed - to develop diffserv QoS Acct PIB and - Classification of multiple usage instances per report message. Comments/Questions: Q is this also useful for RSVP? - Yes, it's needed; needs to be done. ***Standardized Application Identifiers for RSVP Identity Policy- Ralph Santitoro Background - RFC 2752 and 2782. Needed as QoS-enabled Apps are being rolled out, networks are administered by X, and deployed by Y, the Std app-ids will facilitate vendor interoperability-policies can be in a common set. PDP can make informed decisions; the app-ids use a textual format to describe what the application is. Draft focuses on real time apps. AppId = Name, sup-app-id, sub-app-id - for example Voice, Video, Audio A Policy examples for campus LAN was explained, (use G.711 codec for traffic with DA x.y.z.*, Use no voice activity detection); Also a service provider policy was explained. Comments/Questions: Q: From author for audience, WG: is this work something they want to work on? C: We are mixing RSVP with SIP - signaling protocol model is broken A: Call admission is done by the PDP. C: RSVP should not have to know about an audio decoder C: Once you are talking about n/w resources, in some parts of the n/w, some apps may not have access to n/w resources, in the enterprise the policy may be "no n/w m media on my n/w" A SIP for QoS addresses these issues. Q: Why do you want to standardize SApp-IDs in this group. Why not Voice-over-IP? A: As you have different policies, when the telephony device signals the n/w and because app providers put these into the devices, the PDP does use this information. Q: Current model has "voice activity" - is that required? A: When VA is enables - bandwidth can be saved C: But - Originator and destination negotiate a codec in SIP A: This is done during call setup - what we're talking about is Media path reservation. C: in general, I can see a value in sub class ids, but the voice space is very muddy and with b/w mgmt systems not well defined, also call setup is a concern when you're doing end-to-end resv. This activity is premature - voice activity should be flushed out. Q: do we want RAP to finish before we add to the charter? AD: I would like RAP to be finished, before we want to take more work. Yoram: we need to give more control to the n/w admins AD: we need to finish this working group. Is this work a part of the "Using RSVP to maintain control of network resources" presentation? Yoram: No, these are two separate drafts, I don't understand why the question - should we work on this, was answered by - should we finish? Ralph Santitoro gave an explanation of what the two drafts are proposing. C: We need to close off the work that's done, this work belongs in this group but I'd like to see the work that's done - completed. The chair moved this discussion to the RAP wg mailing list. ***A Filtering PIB for Edge Router Services and Provisioning via COPS-PR - Joerg Ottensmeyer A filtering service is a useful thing to have to control access to n/w and/or services, to enforce certain handling of packets. - Filtering rules need to be updated frequently example: when a new user session is starting, when a session must be terminated. Joerg gave an example of filtering for a Portal service. A PIB overview was presented. The PIB consists of interface objects (params of I/Fs), filter rules, classifier objects and session objects. Session Objects are meaningless to PEP, have meaning for PDP. They are used to recover from switch over and allow PDP to seamlessly restore control of PEP without interrupting existing sessions. Session objects are retrieved by PDP at (re)synchronization Joerg requested some COPS-PR enhancements for accounting and listing PIB table instances: Accounting - Need: PDP wants to query PEP for account information. Solution (Essential functionality): PDP sends DEC command with command code set to "accounting" and prids of accounting objects to retrieve. List - Need (Obsolete): PDP wants to retrieve all objects of a certain class. Comments/Questions: C: Dave commented that the same behavior can be achieved by modeling the PIB, not changing the protocol. C: Scott commented that, Filter classes can be extended to form specialized classes. ***RSVP Policy Control Criteria PIB - Diana Rawlins Outsourcing RSVP is not feasible all the time and manual configuration is not an option. 3 operational modes were presented: Local decision and outsource for confirmation, Local decision and outsource only if there is no PDP, Policy decisions only. The Policy definition is represented by an association instance linking a filter instance and an authorization instance. The filtering requirement is fulfilled by frwkIPFilter from the framework PIB. The authorization PRC contains traffic specification (SENDER_T_SPEC: Controlled load or guaranteed services, RSPEC: Guaranteed services), Auth specification, priority preemption priority element. Diana presented the following next steps: Solicit feedback from policy wg, RAP wg. -Should this be a RAP wg item? Comments/Questions: Q: How do you deal with aggregation issues? How do you deal with security factors? There is a notion that we authorize something to go through, but send it to confirm the decision and it may come back and cut it off. ***Data Model for Network Access - David Spence This effort grew out of the AAA wg. Need for a Ng protocol to succeed Radius. SPPI is a very nice way of structuring data. Radius carries its data in type, attribute pairs, and you pick and choose what you want and that is your protocol. We wanted to structure the information on n/w access data. AUML model of a NAS providing n/w access service was constructed. We started with Radius attributes. Grouped by service into classes. Created a PIB. David gave an overview of the UML model for NAS. Radius PIB: If implemented: Mgmt programs doing real time monitoring versus AAA server log. Diameter for Acct/Auth, SNMP for accounting. David presented some issues and pointed out that temporal aspects are not modeled right now. These can be modeled in UML, as we need more than static data model. David expressed the need for future work in the direction of a proper model for NAS, not necessarily Radius based. Comments/Questions: None ***COPS usage for SIP- Gerhard Gross Gery presented COPS usage for SIP Inter-domain QoS. This is a COPS extension for SIP. Comments/Questions: Q: Yoram: What is the protocol used for QOS? A: RSVP C: Diana: This is a new COPS client type (tbd) for SIP usage using COPS. ***Wrap-up Status for all the drafts given by the chair. -RAP signaled priority draft (in IESG queue, pending "new-identity" draft issue) -New Identity draft - has a security issue - May actually apply to the RFC - The orig. draft could be changed or we could get an IESG note attached. -Pol Aux MIB draft - Scott mentioned changes required. -jwalker-cops-tls moved to last call -jwalker-cops-cms moved to last call