idnits 2.17.1 draft-bernet-diffedge-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 555 has weird spacing: '...dentify indiv...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 103, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DSARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSFWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MAPPING' -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'BB' -- Possible downref: Non-RFC (?) normative reference: ref. 'EF' -- Possible downref: Non-RFC (?) normative reference: ref. '802MAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'AGGREG' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Differentiated Services Y. Bernet, Microsoft 2 Internet Draft D. Durham, Intel 3 Document: draft-bernet-diffedge-01.txt F. Reichmeyer, Bay 4 November, 1998 6 Requirements of Diff-serv Boundary Routers 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 "working draft" or "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire before April 1999. Distribution of this draft 30 is unlimited. 32 Bernet 1 33 Requirements of Diff-serv Boundary Routers November 1998 35 1. Abstract........................................................3 36 2. Conventions used in this document...............................3 37 3. Introduction....................................................3 38 4. Functional Components...........................................4 39 4.1 Interfaces, Traffic Conditioning, PHBs and the Routing Core....5 40 4.2 Diff-serv Provisioning Interface...............................5 41 4.3 Monitoring.....................................................5 42 4.4 RSVP...........................................................5 43 4.5 Traffic Conditioning Agreements and PHB Capacity Tables........6 44 5. Traffic Conditioning............................................6 45 5.1 Classifiers....................................................6 46 5.2 Meters.........................................................7 47 5.3 Markers........................................................7 48 5.4 Shapers........................................................8 49 5.5 Droppers.......................................................8 50 5.6 Basic Configurations of Traffic Conditioning Components........8 51 5.7 Traffic Conditioning Configurations Supporting Value-Added 52 Services..........................................................10 53 6. Configuration Information Required at Boundary Routers.........11 54 6.1 PHB Configuration Information.................................12 55 6.2 Traffic Conditioning Configuration Information................12 56 6.2.1 Elements of Traffic Conditioning Configuration Information..13 57 6.2.2 Customer Classification Information.........................13 58 6.2.3 The Traffic Conditioning Agreement (TCA)....................14 59 6.2.3.1 The Constraint TCA........................................14 60 6.2.3.2 Fine-Grain TCA............................................16 61 6.3 Relationship Among the CCI, Constraint TCA and Fine-Grain TCA.17 62 6.4 Additional Configuration Information..........................19 63 7. Configuration Mechanisms.......................................19 64 7.1 Installing PHB Configuration Information......................19 65 7.2 Installing the Constraint TCA.................................19 66 7.3 Installing the Fine-Grain TCA.................................20 67 8. Admission Control..............................................21 68 8.1 Reflection of PHB Configuration at Ingress Interfaces.........21 69 8.2 Admitting the Constraint TCA..................................22 70 8.3 Admitting the Fine-Grain TCA..................................23 71 8.4 Summing Profiles..............................................23 72 9. Support for RSVP Admission Control.............................24 73 9.1 Overview of RSVP and Diff-serv Interoperation.................24 74 9.2 Example of Admission Control to a Diff-serv Network...........24 75 9.3 Implementing RSVP Admission Control in Boundary Routers.......25 76 9.3.1 RSVP Reservations Expressed as Fine-Grain TCA Entries.......26 77 9.3.2 Modifying Marked DSCPs......................................26 78 9.3.3 RSVP and IP Security........................................26 79 10. Intercepting or Ignoring RSVP Messages........................26 80 8. Security Considerations........................................27 81 9. References.....................................................27 82 11. Author's Addresses............................................28 83 Appendix A. COPS-DS Constraint TCA PIB Format.....................29 84 Appendix B. COPS-DS Fine-Grain TCA PIB Format.....................30 86 Bernet 2 87 Requirements of Diff-serv Boundary Routers November 1998 89 1. Abstract 91 This draft discusses requirements of routers that serve as 92 ingress/egress points to/from differentiated services (diff-serv) 93 networks. We discuss the traffic conditioning components required 94 and associated configuration mechanisms and protocols. We also 95 discuss admission control to diff-serv networks in support of 96 signaled QoS. 98 2. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 102 this document are to be interpreted as described in [RFC-2119]. 104 3. Introduction 106 Diff-serv [DSARCH, DSFWK] is a mechanism by which network service 107 providers can offer differing levels of network service to different 108 traffic, in so providing quality of service (QoS) to their 109 customers. The basic premise of diff-serv networks is that routers 110 within the networks handle packets different traffic flows by 111 applying different per-hop behaviours (PHBs). The PHB to be applied 112 is specified by a code (the diff-serv code-point or DSCP) in the IP 113 header of each packet. 115 The advantage of such a scheme is that many traffic flows can be 116 aggregated to one of a small number of PHBs, thereby simplifying the 117 processing and storage associated with packet classification. In 118 addition, there is no signaling state or related processing required 119 in the diff-serv network since QoS is invoked on a packet-by-packet 120 basis. 122 In this draft, we discuss the requirements on diff-serv boundary 123 routers. These are the routers that reside at the ingress or egress 124 points to or from diff-serv networks (from here on referred to as 125 diff-serv boundary routers). The requirements of these routers are 126 generally a superset of the requirements of routers that reside in 127 the core of the diff-serv network. This is because boundary routers 128 must enforce the SLAs that are in effect at the network boundaries 129 (in addition to providing the PHBs required in core routers). Note 130 that although the requirement set for boundary routers is broader 131 than that for core routers, the performance demands on core routers 132 may be significantly greater than those on boundary routers. 133 Specific performance requirements are not addressed in this draft. 135 The purposes of this draft are: 137 Bernet 3 138 Requirements of Diff-serv Boundary Routers November 1998 140 1. To establish baseline functionality for diff-serv boundary 141 routers. 142 2. To provide a conceptual model for the general configuration 143 information required at boundary routers. 144 3. To provide a structured model of the required traffic 145 conditioning configuration information which is conveyed via 146 COPS. 147 4. To discuss interactions of the boundary routers with various wire 148 protocols, in particular COPS and RSVP [RFC2205]. 150 4. Functional Components 152 In order to support a diff-serv network, certain functionality is 153 required from the boundary routers, which reside at the ingress and 154 egress points to and from the diff-serv network. This functionality 155 is discussed in the following sections. 157 The following diagram illustrates the major functional blocks of a 158 diff-serv boundary router: 160 ------------ 161 ---|monitoring| 162 | ------------ 163 | 164 mgmt.| ---------------- 165 COPS,| | diff-serv | 166 <------>| provisioning |------------------------ 167 SNMP,| | i/f | | 168 etc. | ---------------- | 169 | | | | 170 | | | | 171 | v | v 172 data | ----------- | --------- ------------ 173 ------->| inbound |------>|routing|------>| outbound |----> 174 | | (TC) | | --------- | (PHB) | 175 | ----------- | ------------ 176 | ^ | ^ 177 | | | | 178 | ----------- | | 179 -->| | | | 180 ------->| RSVP |----------------------------- 181 RSVP | | |--------------------- 182 cntl ----------- | | 183 msgs ^ v v 184 | ------------- ------------- 185 ---| diff-serv | | TCAs, PHB | 186 | a/c | | capacity | 187 ------------- | tables | 188 ------------- 190 Bernet 4 191 Requirements of Diff-serv Boundary Routers November 1998 193 4.1 Interfaces, Traffic Conditioning, PHBs and the Routing Core 195 An inbound interface, routing component and outbound interface are 196 illustrated at the center of the diagram. In actual router 197 implementations, there may be an arbitrary number of inbound and 198 outbound interfaces interconnected by the routing core. The 199 components of interest on these interfaces are the traffic 200 conditioning components (TC) and the PHB queuing implementations 201 [DSARCH]. These are illustrated as residing at the inbound and 202 outbound interfaces, respectively. However, this is a conceptual 203 representation only and in general, these functions may each be 204 distributed across both inbound and outbound interfaces. 206 Conceptually, it is helpful to think of TC as a 'front-end' to the 207 diff-serv network, which conditions traffic submitted by the 208 customer and directs it, through the routing core, to the 209 appropriate PHB on the egress interfaces of the boundary router and 210 in subsequent hops in the diff-serv network. The combination of 211 traffic conditioning (at ingress interfaces) and PHB treatment (at 212 egress interfaces) results in a diff-serv service. 214 4.2 Diff-serv Provisioning Interface 216 Diff-serv operating parameters are provisioned through this 217 interface. These are primarily PHB and TC configuration parameters. 218 The diff-serv admission control component can also verify these 219 parameters do not conflict with other configuration parameters and 220 the router's physical constraints, as described in subsequent 221 sections. The network administrator interacts with the diff-serv 222 provisioning interface via one of a number of management protocols 223 such as SNMP or COPS [COPS]. 225 4.3 Monitoring 227 A monitoring interface enables collection of statistics regarding 228 traffic carried at various diff-serv service levels. These 229 statistics are important for accounting purposes and for tracking 230 compliance to service level agreements (SLAs [DSARCH]) negotiated 231 with customers. 233 Specifically, counter information on how many packets/bytes were 234 transferred in-profile vs. out-of-profile would be useful on a 235 customer-by-customer basis. This same information should be provided 236 for the courser granularity DSCPs all the way down to the finer 237 granularity flow-by-flow profiling where applicable. 239 4.4 RSVP 241 The RSVP component includes standard RSVP protocol processing. It 242 enables dynamic configuration of diff-serv traffic conditioning 243 components in response to host initiated RSVP signaling and provides 244 admission control feedback to the hosts. It interacts with the diff- 246 Bernet 5 247 Requirements of Diff-serv Boundary Routers November 1998 249 serv admission control component in order to coordinate signaled 250 resource requests with provisioned resource requests, subject to the 251 constraints of the TCA and local resources. Note that diff-serv PHBs 252 rather than RSVP dictate the actual packet forwarding behaviour in a 253 diff-serv boundary router. 255 The RSVP component is optional. However, the inclusion of this 256 component provides the following benefits for traffic originating 257 from quantitative applications (E2E): 259 1. Dynamic, closed loop and topology-aware admission control to the 260 diff-serv network. 261 2. The ability to apply policy in determining which users or 262 applications can access resources in the diff-serv network. 263 3. Significant reduction in management burden. 264 4. The ability to classify IPSec encrypted traffic that would 265 otherwise be un-classifiable. 267 4.5 Traffic Conditioning Agreements and PHB Capacity Tables 269 A service level agreement (SLA) [DSARCH] represents the high-level 270 agreement between the diff-serv service provider operating the 271 boundary router and the customer(s) served by it. The TCA is a 272 subset of the SLA, which specifies detailed TC parameters to be 273 applied to the customer's traffic. In its simplest form, the TCA is 274 a static set of tables. In more sophisticated routers, the TCA may 275 be modified dynamically via signaling within the diff-serv network 276 and between the diff-serv and customer network. 278 We will see that the TCA has two sub-components, a constraint TCA 279 and a fine-grain TCA. The former is essential, and is used to 280 protect the resources of the diff-serv network. The latter may be 281 used to specify value-added functionality offered by the diff-serv 282 network. Since one TCA is installed for each customer on each 283 ingress interface, there will typically be multiple TCAs on a single 284 router. 286 The network administrator configures PHB capacity tables based on 287 the PHBs supported by the router, it's physical capacity and 288 policies that determine the allocation of resources among the 289 various PHBs. PHB capacity tables are configured for each interface. 290 These will be described in detail in a subsequent section. 292 5. Traffic Conditioning 294 TC is a fundamental component of a diff-serv boundary router. It is 295 defined in [DSARCH]]. The following paragraphs describe the TC 296 components and their functionality in greater detail. 298 5.1 Classifiers 300 Strictly speaking, classification is not a TC function [DSARCH]; 301 however, it is a necessary function for any device that treats 303 Bernet 6 304 Requirements of Diff-serv Boundary Routers November 1998 306 certain traffic differently from other traffic. The very nature of a 307 diff-serv boundary router is that it treats traffic differentially. 308 Therefore, classification is the most basic function required from a 309 differentiated service boundary router. 311 There are differing degrees of classification functionality. At 312 minimum, a boundary router must support behaviour-aggregate (BA) 313 classification. In addition, routers may support varying degrees of 314 multi-field (MF) classification. See definitions of Classifier, BA 315 Classifier and MF Classifier in [DSARCH]. 317 A boundary router that supports MF classification can offer 318 significant functionality beyond that which can be offered by a 319 boundary router which supports only BA classification. This 320 functionality will be discussed further in a subsequent section. 322 5.2 Meters 324 Boundary routers use classifiers to identify classes of traffic 325 submitted for transmission through the diff-serv network. Once 326 traffic is classified at the input to the router, traffic from each 327 class is typically passed to a meter. The meter is used to measure 328 the rate at which traffic is being submitted for each class. This 329 rate is then compared against a traffic profile, which is part of 330 the TCA. Based on the results of the comparison, the meter deems 331 particular packets to be conforming to the profile or non- 332 conforming. Appropriate policing actions are then applied to out-of- 333 profile packets. 335 5.3 Markers 337 Marking is the function of setting the DSCP in packets that are 338 submitted to the router. Boundary routers are not required to 339 provide marking functionality but may do so for the following 340 reasons: 342 1. Marking can be used as a form of policing - the TCA between the 343 provider and the customer may specify that packets submitted for 344 a certain service level (as specified by the DSCP) and which are 345 deemed to be non-conforming, may be re-marked to a lower service 346 level. In this case, the marker is used for the purpose of re- 347 marking. We refer to this as 'policer marking'. 348 2. Marking can be provided as a service to customers - customers may 349 be unable or unwilling to mark the DSCP in submitted packets. In 350 this case, a fine-grain TCA may call for the provider to mark the 351 DSCP based on certain MF classification criteria. We refer to 352 this service as 'provider marking'. 354 Provider marking is a value-added service to the customer and is not 355 required in order to provide basic differentiated service. Policer 356 marking is used by the diff-serv provider to protect its network 357 resources, but - simpler forms of policing (such as dropping) are 359 Bernet 7 360 Requirements of Diff-serv Boundary Routers November 1998 362 sufficient to achieve the protection necessary. Therefore, marking 363 is not a required function for boundary routers. 365 5.4 Shapers 367 Shapers delay packets passing through the router such that they are 368 brought into compliance with a traffic profile. Boundary routers are 369 not required to provide shaping functionality, but may do so for the 370 following reasons: 372 1. Ingress routers may use shaping as a form of policing - when 373 submitted traffic is deemed non-conforming, it must be policed to 374 protect the diff-serv network. One form of policing is to delay 375 submitted traffic in a shaper until it conforms to the profile 376 specified in the TCA. We will refer to this as 'policer shaping'. 377 2. Egress routers may shape behaviour aggregate traffic before it is 378 submitted to a subsequent provider's network. This is a 379 preventative measure that avoids policing action in the 380 subsequent network. We refer to this form of shaping as 'egress 381 shaping'. 382 3. Shaping for traffic isolation - Ingress routers may provide per- 383 flow (as opposed to per-behaviour aggregate) shaping services as 384 a value-add to customers (as specified in a fine-grain TCA). This 385 service is costly in terms of processing requirements but may be 386 valuable (to low functionality customers) in that it serves to 387 protect customer's traffic flows from each other. We refer to 388 this form of shaping as 'provider shaping'. 390 5.5 Droppers 392 Droppers are used to discard non-conforming packets. This is the 393 simplest form of policing that may be supported by ingress routers. 395 5.6 Basic Configurations of Traffic Conditioning Components 397 The following sections illustrate various configurations of TC 398 components on ingress interfaces. These components determine the 399 PHBs that will be applied to subsets of submitted traffic after they 400 are routed to the appropriate egress interfaces. PHBs and egress 401 interfaces are not illustrated. 403 DISCLAIMER: Note that these illustrations are provided for 404 clarification of concepts and are not intended to depict specific 405 implementations or implementation requirements. 407 At minimum, an ingress router must police submitted traffic to the 408 terms of the constraint TCA. Such a TCA may be represented as 409 follows: 411 DSCP Average Rate Service Level 412 ------------------------------------------ 413 000001 10 Kbps Best 414 000010 100 Kbps Better 416 Bernet 8 417 Requirements of Diff-serv Boundary Routers November 1998 419 This TCA indicates that traffic submitted with the DSCP 000001 will 420 be accepted at a rate up to 10 Kbps and will be allotted the 'best' 421 service level. Traffic submitted with DSCP 000010 will be accepted 422 at a rate up to 100 Kbps and will be allotted the 'better' service 423 level. While the TCA offers particular service levels, the 424 underlying mechanism by which the service is provided is the PHB 425 that is applied to the traffic at the egress interface to which it 426 is routed. Hence the 'best' and 'better' services described each 427 rely on an underlying PHB. 429 The following configuration of TC components can be used to enforce 430 the above TCA: 432 ------- ------- 433 | | | | 434 |->| |->| |-> Best traffic 435 ------- | | | | | 436 | | | ------- ------- 437 --->| |->| 438 | | | ------- ------- 439 ------- | | | | | 440 BA Class. |->| |->| |-> Better traffic 441 | | | | 442 ------- ------- 443 Meters Policers 444 (Re-markers, 445 Shapers or Droppers 447 The BA classifier is used to separate traffic based on the diff-serv 448 service level requested (as indicated by the DSCP in each submitted 449 packet). Meters then determine whether the traffic submitted for 450 each service level conforms to the corresponding average rate 451 specified in the TCA. The policers handle non-conforming packets 452 either by re-marking them for a lower service-level, delaying them 453 in a shaper or dropping them. 455 This configuration suffers certain limitations. Since it uses only a 456 BA classifier, it is able to separate traffic based only on the DSCP 457 in submitted packets. If traffic from multiple customers is 458 submitted on the same interface, this configuration of TC components 459 will be unable to separate traffic by customer. Since TCAs are 460 specified on a per-customer basis, TC components will be unable to 461 select the appropriate TCA to be applied. 463 Furthermore, certain services may be offered only between the 464 ingress boundary router and a specific egress point from the diff- 465 serv network [DSFWK]. For such services, the TCA would include an 466 egress point qualifier and TC components would be required to 467 classify and to police based on egress point as well as DSCP. The 468 configuration illustrated is unable to do so. 470 Bernet 9 471 Requirements of Diff-serv Boundary Routers November 1998 473 MF classifiers can be incorporated to overcome the limitations 474 identified. For example, in the following configuration, an MF 475 classifier is used to separate traffic according to customer, before 476 it is submitted for BA classification: 478 ------- ------- 479 | | | | 480 |->| |->| |-> Customer A, Best 481 ------- | | | | | 482 | | | ------- ------- 483 |->| |-| 484 | | | | ------- ------- 485 | ------- | | | | | 486 | BA Class.|->| |->| |-> Customer A, Better 487 ------- | | | | | 488 | | | ------- ------- 489 ->| |-| 490 | | | ------- ------- 491 ------- | | | | | 492 MF Class.| |->| |->| |-> Customer B, Best 493 | ------- | | | | | 494 | | | | ------- ------- 495 |->| |-| 496 | | | ------- ------- 497 ------- | | | | | 498 BA Class.|->| |->| |-> Customer B, Better 499 | | | | 500 ------- ------- 501 Meters Policers 503 Similar configurations could be used to separate traffic based on 504 egress point or other criteria dictated by the constraint TCA. MF 505 classifiers are also required to provide value-added services as 506 described in the following paragraphs. 508 5.7 Traffic Conditioning Configurations Supporting Value-Added Services 510 More complex TC configurations can enable value-added services such 511 as provider marking and provider shaping. The essence of these 512 services is that the customer relies on the provider to apply per- 513 flow processing to the customer's traffic. This requires the 514 provider to classify beyond the minimum level of granularity 515 necessary to protect the diff-serv network's resources. Such 516 additional functionality is specified in a fine-grain TCA. The 517 following configuration of TC components supports value-added 518 services: 520 ------- ------- ------- ------- 521 | | | | | | | | Best 522 |->| |->| |->| |->| |->| |-> 523 ------- | | | | | | ------- | | | | | 524 | | | ------- ------- | | | | ------- ------- 525 ->| |-| Marker Policer |->| |-| 527 Bernet 10 528 Requirements of Diff-serv Boundary Routers November 1998 530 | | | ------- ------- | | | | ------- ------- 531 ------- | | | | | | ------- | | | | | Better 532 MF Class.|->| |->| |->| BA Class.|->| |->| |-> 533 | | | | | | | | | | 534 | ------- ------- | ------- ------- 535 | Marker Policer | Meters Policers 536 | ------- ------- | (Re-markers, 537 | | | | | | Shapers or 538 |->| |->| |->| Droppers) 539 | | | | | | 540 | ------- ------- | 541 | Marker Policer | 542 | ------- ------- | 543 | | | | | | 544 |->| |->| |->| 545 | | | | | | 546 | ------- ------- | 547 | Marker Policer | 548 | . . | 549 | . . | 550 | . . | 551 V V V V 553 In this configuration, traffic is first directed to an MF classifier 554 which classifies traffic based on miscellaneous classification 555 criteria, to a granularity sufficient to identify individual 556 customer flows. Each customer flow can then be marked for a specific 557 DSCP and/or policed independently (a metering stage is implied). 558 Typically, in this configuration, multiple customer flows would be 559 marked with the same DSCP. In this example, all customer flows are 560 aggregated into one of two DSCPs - that specifying the 'best' 561 service or that specifying the 'better' service. Following the 562 marking, flows are policed individually such that they are protected 563 from each other and that the total traffic submitted for each DSCP 564 does not exceed that specified by the constraint TCA. 566 This configuration can be considered to consist of two logical 567 halves; a front-end which provides per-flow services to the customer 568 (MF classifier, per-flow markers and shapers) and a back-end which 569 enforces the terms of the constraint TCA (BA classifier, per service 570 level meters and policers). Notice that the back-end is equivalent 571 to the minimal configuration illustrated previously. 573 6. Configuration Information Required at Boundary Routers 575 This section describes the configuration information required at 576 boundary routers. This information falls into the following general 577 categories: 579 1. PHB configuration. 580 2. Traffic conditioning configuration. 581 3. Miscellaneous configuration. 583 Bernet 11 584 Requirements of Diff-serv Boundary Routers November 1998 586 DISCLAIMER: In the following sections, we use tables to represent 587 specific information that is necessary for the configuration of 588 boundary routers. These tables are intended to describe the 589 structure of required configuration information but not to dictate 590 particular protocol formats, nor to dictate specific implementation 591 mechanisms. For detailed protocol formats see appendices to this 592 draft and [COPS]. 594 6.1 PHB Configuration Information 596 Diff-serv routers implement PHBs that are used to forward traffic of 597 different service levels with differing behaviour. PHBs are 598 generally implemented via queues and schedulers that reside at the 599 router's egress interfaces. There may be multiple configuration 600 parameters required to configure PHBs. At minimum, PHB configuration 601 must: 603 1. Enable or disable specific PHBs. 604 2. Provide the quantitative parameters associated with the PHB (e.g. 605 relative weights for WFQ based PHBs). 606 3. Specify the total capacity admissible to each PHB on each egress 607 interface. Capacity should be expressed in the same terms as the 608 traffic profile [DSARCH] that applies to the PHB. This capacity 609 will generally consider both physical interface capacities as 610 well as policies. For example, PHBs which are implemented as 611 strict priority queues should include limits on the volume of 612 traffic which can be directed to the PHB in order to avoid 613 starvation of traffic directed to other PHBs on the same 614 interface. 615 4. In addition, network administrators must specify policies that 616 indicate how the admissible capacity of qualitative PHBs (see 617 [DSFWK] for a description of qualitative PHBs) on egress 618 interfaces is reflected to each ingress interface. This is 619 required for the purpose of applying admission control, and will 620 be discussed further in the subsequent section on admission 621 control. 623 The capacities in 3 and 4 are specified in the form of a PHB 624 capacity table. This table specifies capacities for quantitative 625 PHBs on each egress interface and capacity for qualitative PHBs on 626 each ingress interface. 628 Note that certain PHB configuration parameters are required that are 629 specific to each PHB. These are beyond the scope of this draft and 630 should be addressed in detail in PHB specific drafts. 631 6.2 Traffic Conditioning Configuration Information 633 As TC comprises a major function of diff-serv boundary routers, much 634 of the required configuration information will be related to these 635 components. 637 For the purpose of this discussion, we consider TC configuration 638 information to apply independently to each of the boundary router's 640 Bernet 12 641 Requirements of Diff-serv Boundary Routers November 1998 643 ingress interfaces. The majority of TC configuration information 644 required can be expressed via the TCA. The TCA is a per-customer 645 entity. In cases in which an ingress interface is dedicated to a 646 single customer, a single TCA is configured on each interface. On 647 the other hand, in cases in which multiple customers are served via 648 a single interface, multiple TCAs will be installed on the 649 interface. In these cases, it is necessary to configure criteria by 650 which the boundary router can classify submitted traffic to the 651 customer from which it is submitted and the corresponding TCA. This 652 requires configuration of 'customer classification information' 653 (CCI). 655 6.2.1 Elements of Traffic Conditioning Configuration Information 657 Before proceeding to describe the detailed configuration 658 information, we define two elements of configuration information 659 that will be referred to throughout the following paragraphs. These 660 are: 662 1. Filters - these specify the classification criteria which 663 classifiers use to classify submitted packets. BA filters are 664 quite simple, specifying only a six-bit DSCP. MF filters may be 665 arbitrarily complex, specifying multiple classification fields 666 and corresponding masks. 667 2. Profiles - [DSARCH] defines a traffic profile as "a description 668 of the temporal properties of a traffic stream such as rate and 669 burst size". Though profiles may take many forms, a typical 670 profile would consist of a set of token bucket parameters. These 671 include expected average traffic rate, peak rate and the maximum 672 burst size that can be expected at the peak rate. Individual PHB 673 specifications (in PHB specific drafts) should describe the form 674 of the profile which applies to each PHB. 676 6.2.2 Customer Classification Information 678 This information enables a boundary router to correlate submitted 679 traffic to a particular TCA for the purpose of applying TC. Customer 680 classification information can be conveyed via a table of the 681 following format: 683 CCI TCA 684 --- --- 685 Filter01 TCA01 686 Filter02 688 Filter03 TCA02 689 Filter04 690 Filter05 692 Filter06 TCA03 694 In this table, the first column lists a set of filters that should 695 be used as classification criteria to determine the customer from 697 Bernet 13 698 Requirements of Diff-serv Boundary Routers November 1998 700 which a packet originates. The second column specifies the TCA that 701 should be applied to traffic from that customer. In general, there 702 may be multiple filters required to define a single customer's 703 traffic. Typically, CCI filters will specify source subnet addresses 704 as classification criteria. 706 In the common case that an interface is dedicated to a customer, the 707 table above degenerates to the following form: 709 CCI TCA 710 --- --- 711 * TCA01 713 In this example, all traffic arriving on the interface is assumed to 714 arrive from a single customer and to be subjected to TCA01. 716 6.2.3 The Traffic Conditioning Agreement (TCA) 718 The TCA is a device specific result of the SLA negotiated (either 719 statically or dynamically) between the diff-serv provider and the 720 customer. There are two subsets of the TCA - the constraint TCA and 721 the fine-grain TCA. The constraint TCA serves to protect the 722 provider's resources at each diff-serv service level. This part of 723 the TCA is required. The fine-grain TCA defines per-flow value-added 724 functionality that the provider may offer to the customer. This part 725 of the TCA is not required for the purpose of providing basic diff- 726 serv service. Fine-grain TCAs are likely to be used only near the 727 periphery of the network where the provider offers service to a stub 728 network containing hosts. It is unlikely that fine-grain TCAs will 729 be used at boundaries between providers (where enforcement of 730 aggregate, per-service level resource usage is the primary concern). 732 6.2.3.1 The Constraint TCA 734 Recall that the purpose of the constraint TCA is to protect 735 resources in the provider's network by policing submitted traffic to 736 the terms of the agreement between the provider and the customer. In 737 its simplest form, the agreement offers to carry traffic at the 738 service level requested by the customer (via the DSCP) up to a 739 certain traffic profile. 741 When quantitative services are offered, the agreement is slightly 742 more complex. In this case, the agreement may be constrained by 743 traffic egress point. For example, the provider might agree to carry 744 traffic at a certain quantitative service level, up to a certain 745 traffic profile, but only if the traffic is destined to a specific 746 egress point. If the customer desires delivery at the same service 747 level to another egress point, then an additional profile must be 748 specified for that egress point. In this example, we effectively 749 specify multiple 'service instances' at the same service level. 751 When only qualitative services are offered, we see that it is 752 sufficient to police a customer's traffic based only on the service 754 Bernet 14 755 Requirements of Diff-serv Boundary Routers November 1998 757 level at which it will be carried. However, when quantitative 758 services are offered, it may be necessary to police the customer's 759 traffic separately for each 'service instance'. We will use the term 760 'service instance' from here on to refer to instances of service 761 which must be separately policed in order to protect the provider's 762 network. 764 The constraint TCA can be represented as a table having the 765 following format: 767 BA Filter PHB MF Filter Profile Disposition 768 --------- --- --------- ------- ----------- 769 Filter01 EF EgressFilter01 Profile01 Discard 771 Filter01 EF EgressFilter02 Profile02 Discard 773 Filter02 AFxy * Profile03 Re-mark to 001001 775 Filter03 AFpq * Profile04 Shape to profile 777 Each row in this table corresponds to a service instance provided to 778 the customer. Note that the first two rows describe two service 779 instances, at the same service level. 781 The column titled 'BA Filter' specifies a DSCP. This is the 782 classification criteria that should be used to determine the PHB 783 (and the corresponding service level) that should be allotted to a 784 submitted packet. 786 The column titled 'PHB' specifies the PHB (and the corresponding 787 service level) that should be applied to the submitted packet. As 788 such, the first two columns effectively specify a mapping of DSCP to 789 PHB. 791 The column titled 'MF Filter' is relevant when the PHB corresponds 792 to a quantitative service. In this case, it may be insufficient to 793 police traffic based on service level alone because there may be 794 multiple service instances at the same level. In this example, there 795 are two instances of service at the same level, each to a different 796 egress point. The additional classification criteria in this column 797 specify how the provider should separate traffic for the two service 798 instances. 800 The column titled 'Profile' specifies the configuration of meters 801 that are used to determine the conformance of traffic submitted for 802 each service instance. All packets that meters find to be conforming 803 to the specified profile are allotted the treatment specified by the 804 PHBs. 806 The column titled 'Disposition' specifies the disposition of packets 807 that are found to be non-conforming to the metered profile. In this 808 simple example, these packets are collectively discarded, demoted or 809 shaped (as forms of policing). In more complex examples, multiple 811 Bernet 15 812 Requirements of Diff-serv Boundary Routers November 1998 814 levels of non-conformance may be specified. In these cases, 815 different dispositions may be specified for each degree of non- 816 conformance. 818 6.2.3.2 Fine-Grain TCA 820 Recall that the fine-grain TCA is used to provide value-add to the 821 customer. Specifically, it enables the provider to process the 822 customer's traffic based on classification criteria beyond those 823 that are required to protect the provider's resources. Basically, 824 the fine-grain TCAs are applied first to police and mark a 825 customer's flows and then, based on the resulting marking, the 826 appropriate aggregate constraint TCA will be applied as described 827 above. 829 At a minimum, the fine-grain TCA might be used to invoke provider 830 marking of the customer's traffic. In order to mark customer's 831 traffic differentially (and usefully), the provider must classify 832 the traffic based on MF classification criteria such as source or 833 destination IP addresses or ports. For example, MF filters may be 834 defined to cause all traffic from IP subnet 2.3.4.0 to be marked 835 with the DSCP 001001. In this example, traffic from multiple 836 conversations, on multiple hosts, would be collectively marked with 837 the specified DSCP. 839 The fine-grain TCA could be used to specify additional 840 functionality, requiring even finer-grain classification. For 841 example, MF filters might be defined to separate traffic originating 842 from each individual conversation (microflow [DSARCH]) in the 843 customer's network. Traffic corresponding to multiple conversations 844 of the same type may still be marked identically, however, the 845 finer-grain classification would allow them to be policed or shaped 846 separately. The fine grain TCA can be represented as a table having 847 the following format: 849 MF Filter DSCP Mark Profile Disposition 850 --------- --------- ------- ----------- 851 Filter01 001001 Profile01 Remark to DSCP 001000 852 Filter02 854 Filter03 001011 Profile02 Shape to profile 856 Filter04 100100 Profile03 Discard 858 Filter05 100100 Profile04 Discard 860 In this example, the first entry specifies that two customer traffic 861 flows should be marked for DSCP 001001. These flows together should 862 be metered to Profile01. Packets from either set that do not conform 863 to Profile01 should be remarked to DSCP 001000. 865 The second entry specifies a third customer traffic flow. All 866 packets belonging to this flow should be marked for DSCP 001011. 868 Bernet 16 869 Requirements of Diff-serv Boundary Routers November 1998 871 These should be metered to Profile02. Packets belonging to this flow 872 that do not conform to Profile02 should be delayed in a shaper until 873 they do. 875 The third and fourth entries specify two customer traffic flows that 876 should be marked for DSCP 100100. Though packets belonging to both 877 flows are marked for the same DSCP, they should be metered 878 independently using Profile03 and Profile04. This protects these 879 traffic flows from each other by preventing excess traffic from one 880 flow compromising the treatment of traffic from the other flow. 882 6.3 Relationship Among the CCI, Constraint TCA and Fine-Grain TCA 884 We've presented three types of tables that collectively specify the 885 configuration of TC components. These are: 887 1. The customer classification table 888 2. The constraint TCA 889 3. The fine-grain TCA 891 These are related to each other, as illustrated in the following 892 diagram: 894 Fine-Grain Constraint 895 part part 897 ------------------ 898 |TCA0 ------- | 899 | |SI 0 | | 900 CCI | ------- | 901 Table |------------------------->| |SI 1 | | 902 | | ------- | 903 | ------------------ 904 | ---------------------------------------- 905 ------- | | ------- TCA1 | 906 |CU 0 |---| | |CF 0 | | ------- | 907 ------- | ------- |--------------->|SI 2 | | 908 --> |CU 1 |------->| |CF 1 | | ------- | 909 ------- | ------- |----->|SI 3 | | 910 |CU 2 |---| | |CF 2 | |---------| ------- | 911 ------- | | ------- |--->|SI 4 | | 912 | | |CF 3 | | | ------- | 913 | | ------- | | | 914 | | |CF 4 | | | | 916 Bernet 17 917 Requirements of Diff-serv Boundary Routers November 1998 919 | | ------- |-----------| | 920 | | |CF 5 | | | 921 | | ------- | | 922 | | |CF 6 | | | 923 | | ------- | 924 | ---------------------------------------- 925 | ------------------ 926 | |TCA2 ------- | 927 | | |SI 5 | | 928 | | ------- | 929 |------------------------->| |SI 6 | | 930 | ------- | 931 ------------------ 933 In this general example, three customers are served by the TC 934 components on a single physical interface of a boundary router. 935 Traffic received on the interface is separated according to the 936 customer from which it originates, based on customer classification 937 information (CU0, CU1 and CU2) in the CCI table. 939 Customer 0 (CU0) implements all marking and fine-grain policing in 940 the customer network. Therefore, no fine-grain TCA is necessary in 941 the provider's network. The provider is required to apply only the 942 constraint TCA. The constraint TCA for customer 0 defines two 943 different service instances (SI0, SI1). 945 Customer 1 (CU2) relies on the provider to apply certain fine-grain 946 functionality on its behalf. A fine-grain TCA defines seven distinct 947 sets of customer traffic each of which require special treatment in 948 the boundary router. Such treatment may include marking, shaping, 949 etc. 951 Following the fine-grain TCA, the constraint TCA defines the 952 aggregation of the fine-grain sets of customer traffic (CF0-CF6) 953 into a smaller number of service instances. After the fine-grain TCA 954 is applied, each packet is submitted to the constraint TCA with a 955 specific DSCP mark. This DSCP mark is compared against the BA filter 956 (and additional packet fields may be compared against the egress 957 filter) in the constraint TCA, to define which service instance 958 applies (SI2, SI3 or SI4). 960 From the diagram, the first two customer traffic flows (CF0-CF1) are 961 marked with the same DSCP, directing them to the same service 962 instance in the constraint TCA (SI2). The third customer traffic 963 flow (CF2) is marked with a DSCP that may or may not be the same as 964 the previous flows. If it is the same, then this traffic is directed 965 to a different service instance based on egress filter. 967 The fourth through seventh customer traffic flows (CF3-CF6) are 968 marked with the same DSCP. Again, this may or may not be the same 969 DSCP as previous sets. Regardless, these are collectively directed 970 to yet another service instance (SI3). 972 Bernet 18 973 Requirements of Diff-serv Boundary Routers November 1998 975 Finally, traffic from CU3 is similar to that originating from CU0 in 976 that it requires no fine-grain treatment at the boundary router. It 977 is subjected directly to the corresponding constraint TCA where it 978 is classified to a particular service instance (based on the DSCP 979 and the classification criteria in the BA filter entries of the 980 constraint TCA, and possibly based on egress filters as well). 982 6.4 Additional Configuration Information 984 A variety of additional miscellaneous configuration information is 985 required for any router. Examples include routing information, media 986 support, etc. Such information is beyond the scope of this draft. 988 7. Configuration Mechanisms 990 The following sections describe the mechanisms by which the above 991 configuration information is installed in the boundary router. It is 992 useful to consider a hierarchy of configuration information, 993 starting with basic hardware configuration, which is very static and 994 ending with the configuration of entries in the fine-grain TCA, 995 which is quite dynamic. 997 7.1 Installing PHB Configuration Information 999 PHBs are configured on each egress interface. Routers will generally 1000 provide support for limited groups of PHBs. Supported PHBs vary 1001 depending on media type, hardware support and software algorithms. 1002 Enabling a set of PHBs on each egress interface can be considered 1003 part of the router's basic hardware configuration. This aspect of 1004 PHB configuration is therefore very static and is likely to be 1005 applied as part of the router installation process. 1007 In addition to enabling PHBs, policies must be configured to 1008 determine how these PHBs make use of the interface capacity (via the 1009 PHB capacity table). Allocating interface capacity to various PHBs 1010 can be considered part of the diff-serv network provisioning. It 1011 should be possible to provision the network from a central 1012 management console. Therefore, it must be possible to configure the 1013 PHB capacity table remotely. This facility can be provided via 1014 telnet and CLI, SNMP, LDAP or COPS [COPS]. The mechanism used must 1015 be secure. In early deployments of diff-serv networks, re- 1016 provisioning is expected to occur infrequently and to require manual 1017 intervention. In the long term, this process will become more 1018 dynamic, requiring automated protocols. 1020 7.2 Installing the Constraint TCA 1022 The constraint TCA effectively specifies the resources that the 1023 provider is offering to each customer in the diff-serv network. At 1024 the boundary router, it determines the allocation of resources 1025 provisioned at PHB configuration time, among the customers served by 1026 the router's ingress interfaces. 1028 Bernet 19 1029 Requirements of Diff-serv Boundary Routers November 1998 1031 Provider and customer must agree upon this part of the TCA since it 1032 commits resources on the one hand and incurs charges on the other 1033 hand. Since this part of the TCA requires negotiation between the 1034 two parties, it tends to be relatively static (yet more dynamic than 1035 the PHB configuration associated with network provisioning). 1036 Generally, configuration of constraint TCAs on a customer by 1037 customer basis occurs after the network has been provisioned via PHB 1038 configuration. However, to some degree these processes will be 1039 iterative. This, at certain times, changes in demand will require 1040 configuration of TCAs that cannot be installed without modifications 1041 to the basic network provisioning and PHB configuration. 1043 Typically, human agents for the provider and customer would 1044 negotiate a constraint TCA as part of an SLA. Following these 1045 negotiations, an administrator of the provider's network would 1046 configure the constraint TCA in the boundary router. This process 1047 would typically occur quite infrequently (for example, monthly). 1049 In the long term, this process is likely to become more dynamic and 1050 more automated. Ultimately, bandwidth brokers [BB] representing the 1051 provider's network and the customer's network will automatically and 1052 periodically re-negotiate the constraint TCA, based on such triggers 1053 as changes in usage patterns. Bandwidth brokers will then instruct 1054 policy servers to install the updated configuration information. 1056 In the more static example, network administrators will likely 1057 install constraint TCAs into the boundary router via a management 1058 console. A user management interface at the console may use any of a 1059 number of protocols to communicate with the router, such as telnet 1060 and CLI, SNMP, LDAP, COPS, etc. 1062 As configuration of the constraint TCA becomes more automated and 1063 more dynamic, inter-machine protocols will be used. Since COPS is 1064 targeted at dynamic QoS configuration, it is ideally suited for this 1065 purpose. By providing COPS interfaces for diff-serv configuration, 1066 routers will be able to support both near-in static configuration of 1067 diff-serv parameters as well as long-term dynamic configuration. 1068 Appendix A shows specifically how the constraint TCA is conveyed 1069 using the COPS for diff-serv protocol elements defined in [COPS]. 1071 7.3 Installing the Fine-Grain TCA 1073 The provisioning mechanisms used to install the constraint TCA may 1074 also be used to install the fine-grain TCA. However, requirements 1075 surrounding configuration of the fine-grain TCA differ significantly 1076 from those surrounding configuration of the constraint TCA. These 1077 differences argue for use of a different mechanism, as described in 1078 the following paragraphs. 1080 First of all, configuration of the fine grain TCA is likely to be 1081 far more dynamic than that of the constraint TCA. Recall that the 1082 constraint TCA describes the aggregate requirements of the customer 1083 from the provider. Such aggregate requirements are relatively 1085 Bernet 20 1086 Requirements of Diff-serv Boundary Routers November 1998 1088 static. By comparison, the fine-grain TCA describes fine-grain 1089 servicing of individual customer flows, within the aggregate limits 1090 imposed by the constraint TCA. The requirements of such fine-grain 1091 service are likely to change quite frequently. 1093 For example, the customer may be using provider marking to direct 1094 traffic from certain IP addresses to different service instances, or 1095 to direct specific application traffic (identified by IP port) to 1096 different service instances. In these cases, changes in IP address 1097 assignments internal to the customer's network, or changes in ports 1098 used by applications will require frequent changes to the fine-grain 1099 TCA. 1101 Second, unlike the constraint TCA (which has financial consequences) 1102 the fine-grain TCA dictates only how the aggregate resources 1103 available to the customer are shared among the various customer 1104 flows. Thus, changes to the fine-grain TCA generally do not have 1105 financial consequences. These changes can more readily be automated. 1107 In conclusion, it is appropriate to use an automated mechanism to 1108 configure the fine-grain TCA, which supports frequent customer 1109 initiated changes with rapid response. To this end, boundary routers 1110 should support access to the fine-grain TCA via COPS. 1112 Appendix B shows specifically how the fine-grain TCA is conveyed 1113 using the COPS for diff-serv protocol elements defined in [COPS]. 1115 8. Admission Control 1117 The configuration information discussed is interrelated by admission 1118 control. Admission control is the process of approving or denying 1119 specific configuration requests subject to the constraints of 1120 previous configuration. Requests to configure PHBs and associated 1121 capacities on each egress interface are admitted or rejected based 1122 on the basic hardware resources available on the egress interface. 1123 PHB capacities at egress interfaces dictate the amount of traffic 1124 that can be directed to each PHB at ingress interfaces. Therefore, 1125 requests to configure constraint TCAs at ingress interfaces are 1126 admitted or rejected subject to PHB configuration. Requests to 1127 configure fine-grain TCAs are in turn admitted or rejected subject 1128 to the constraint TCAs that have been installed. In this section we 1129 discuss these interdependencies. 1131 8.1 Reflection of PHB Configuration at Ingress Interfaces 1133 PHBs are configured at egress interfaces. TCAs are configured at 1134 ingress interfaces. Since each service instance in a TCA consumes 1135 resources configured at egress interfaces, it is necessary to 1136 understand how these resources are reflected at the ingress 1137 interfaces. 1139 For quantitative services there is a well-defined relationship 1140 between capacities specified on PHBs at egress interfaces (in the 1142 Bernet 21 1143 Requirements of Diff-serv Boundary Routers November 1998 1145 PHB capacity table) and service instances configured at TCAs on 1146 ingress interfaces. This is because each quantitative service 1147 instance in a TCA specifies an egress filter. The router uses 1148 routing information to determine the egress interface to which 1149 traffic classified for a particular egress filter will be directed. 1150 Therefore, as quantitative service instances are configured at 1151 ingress interfaces, the appropriate amount of resources can be 1152 debited on the appropriate PHBs on egress interfaces. In the case 1153 that insufficient resources are available at an egress interface, 1154 the service instance must be rejected. 1156 For qualitative services however, there is no deterministic 1157 relationship between capacities at egress interfaces and service 1158 instances at ingress interfaces. Therefore, the network 1159 administrator must apply policy, (based on expected traffic routes 1160 within the router) to impose per service level capacity constraints 1161 (for qualitative services) at ingress interfaces. 1163 Such policy is configured as part of PHB configuration, at the time 1164 the network is provisioned. It may be modified subsequently as 1165 constraint TCAs are negotiated with customers. 1167 This policy is expressed by specifying limits on the traffic 1168 profiles admissible at each ingress interface for each qualitative 1169 PHB supported (in the PHB capacity table). Conservative policies 1170 would divide the resources available at the most constrained egress 1171 interface, among all ingress interfaces. Resources may be divided 1172 equally (if the network administrator has no knowledge of likely 1173 traffic patterns in the network), or may be divided unequally, based 1174 on expected traffic patterns. Liberal policies would over-subscribe 1175 the resources available at egress interfaces by allowing each 1176 ingress interface to admit more than its fraction of the egress 1177 capacity. In the case of liberal provisioning care must be exercised 1178 to prevent undesirable interactions among PHBs on oversubscribed 1179 egress interfaces. 1181 8.2 Admitting the Constraint TCA 1183 The constraint TCA must be admitted subject to the resources made 1184 available by PHB configuration as specified in the PHB capacity 1185 table. At the time this part of the TCA is installed, the router is 1186 expected to apply admission control as follows: 1188 1. All PHBs specified in the constraint TCA must be supported by the 1189 router and must have been previously configured. 1190 2. Quantitative service instances consume resources for specific 1191 PHBs on specific egress interfaces (as determined by egress 1192 filters and routing information). The sum of profiles for all 1193 service instances consuming resources on a particular egress 1194 interface must not exceed the configured limits for the 1195 corresponding PHB in the PHB capacity table on the appropriate 1196 egress interface. 1198 Bernet 22 1199 Requirements of Diff-serv Boundary Routers November 1998 1201 3. Profiles associated with qualitative service instances (that do 1202 not specify egress filters) are also subject to admission 1203 control. These cannot be deterministically related to resources 1204 configured at egress interfaces. Therefore, the sum of profiles 1205 for all qualitative service instances must not exceed the 1206 configured limits for the corresponding PHBs in the PHB capacity 1207 table on the corresponding ingress interface. 1209 When COPS is used to configure the router, this process becomes 1210 somewhat more automated. The policy server (PDP) can directly verify 1211 that the constraint TCAs are supported by the device. This is 1212 possible given the device accurately describes its capabilities and 1213 its available resources per interface in its initial configuration 1214 request to the PDP. 1216 8.3 Admitting the Fine-Grain TCA 1218 The fine-grain TCA may cause multiple sets of customer traffic to be 1219 marked for a specific DSCP and a specific service instance in the 1220 constraint TCA. The constraint TCA specifies a profile that limits 1221 the aggregate amount of traffic that can be serviced for each 1222 service instance. The sum of profiles in the fine-grain TCA, which 1223 are applied to traffic destined for the same service instance, 1224 should be less than the aggregate profile in the constraint TCA for 1225 that service instance. In the case of qualitative services, the 1226 following steps can easily verify this condition: 1228 1. For each DSCP that the fine-grain TCA marks, sum the profiles for 1229 all sets of customer traffic to be marked with the DSCP. 1230 2. Find the service instance in the constraint TCA that corresponds 1231 to this DSCP, as indicated by the BA filter in the constraint 1232 TCA. For qualitative services there will be only a single service 1233 instance specified for each DSCP. 1234 3. The profile from the constraint TCA should be greater or equal to 1235 the sum of profiles for the corresponding DSCP in the fine-grain 1236 TCA. 1238 In the case of quantitative services, verification is slightly more 1239 complicated as it must account for egress point as well as service 1240 level indicated by the DSCP. In this case, there may be multiple 1241 service instances in the constraint TCA, for the same DSCP. 1243 Again, when COPS is used to configure the router, this process 1244 becomes somewhat more automated. The policy server (PDP) can 1245 directly verify what fine-grain TCAs are supported by the device. 1246 This is possible given the device accurately describes its 1247 capabilities in terms of MF classification and out-of-profile 1248 disposition in its initial configuration request to the PDP. 1250 8.4 Summing Profiles 1252 The previous paragraphs on admission control mention the summing of 1253 profiles for each PHB. Different types of profiles will generally be 1255 Bernet 23 1256 Requirements of Diff-serv Boundary Routers November 1998 1258 subject to different summation rules. These should be described in 1259 the draft defining the PHB. 1261 9. Support for RSVP Admission Control 1263 9.1 Overview of RSVP and Diff-serv Interoperation 1265 As described in [E2E], diff-serv networks can be used to provide 1266 end-to-end QoS across large transit networks by supporting RSVP 1267 admission control at boundaries. This approach is of particular 1268 interest for quantitative applications [DSFWK], for which RSVP 1269 signaling is practical. 1271 To this end, Intserv service-types that are used by RSVP are mapped 1272 to specific diff-serv PHBs [MAPPING]. The concatenation of these 1273 PHBs along paths through diff-serv networks, combined with 1274 appropriate admission control at the boundaries will enable diff- 1275 serv services that can reasonably extend Intserv style QoS. Routers 1276 in diff-serv networks should support these PHBs. Boundary routers 1277 should also provide RSVP signaling for admission to diff-serv 1278 networks, as described below. 1280 9.2 Example of Admission Control to a Diff-serv Network 1282 Consider a diff-serv service that offers very low latency such as 1283 would be suitable for IP telephony. The EF PHB [EF] can provide such 1284 a service. Assume that a customer uses the diff-serv provider 1285 network to interconnect two customer networks. The customer has an 1286 SLA in place with the provider at each of the two boundaries. A 1287 service instance in each TCA offers 100 Kbps of low latency service 1288 to the peer attachment point. Now consider that the customer uses 1289 this service to carry IP telephony calls, each requiring a 16 Kbps 1290 flow. 1292 In order to obtain the low latency service, the customer (either by 1293 direct marking in the host or via provider marking) must mark IP 1294 telephony traffic for the appropriate diff-serv service level. At 1295 the same time, it is in the customer's interest to constrain the 1296 number of marked flows to six or fewer. A seventh flow will cause 1297 the customer to violate the TCA in place with the diff-serv 1298 provider. Provider policing may then arbitrarily compromise any 1299 traffic marked for the low latency service. 1301 Simple RSVP based admission control from the boundary router can 1302 prevent such over-subscription of the TCA by notifying the offending 1303 host that the seventh flow has failed admission control. In 1304 response, a properly behaving marking host will not mark traffic on 1305 the seventh flow for the low latency service level (as described in 1306 [E2E]). As a result, the six flows in place remain protected. Of 1307 course, the same mechanisms apply to applications other than IP 1308 telephony, for example - streaming video applications). 1310 Bernet 24 1311 Requirements of Diff-serv Boundary Routers November 1998 1313 Additional benefits of such admission control are described in 1314 detail in [E2E]. 1316 9.3 Implementing RSVP Admission Control in Boundary Routers 1318 Support for such admission control in boundary routers requires 1319 implementation of a subset of RSVP. In particular, RSVP signaling is 1320 required. The RSVP MF classification and scheduling mechanisms are 1321 not necessarily required. The local admission control functionality 1322 of standard RSVP routers must be modified as described in the 1323 following paragraph. 1325 When a reservation request (RESV) arrives at a standard RSVP router, 1326 the router must verify admissibility of the reservation on its 1327 sending interface by querying traffic control for the interface. If 1328 the resources specified in the Intserv flowspec of the RESV message 1329 can be accommodated at the Intserv service level specified, then the 1330 reservation request is admitted, by allowing the RESV message to 1331 pass on to the sender. If the resources cannot be accommodated, then 1332 the request is rejected by blocking the RESV and returning an error 1333 message. 1335 In a diff-serv boundary router, a similar process is used. Upon 1336 receiving a RESV from a receiver at a remote customer network, the 1337 boundary router must compare the request against the constraint TCA 1338 that is in place. The boundary router does so as follows: 1340 1. First, the boundary router must find the quantitative service 1341 instances in the constraint TCA which correspond to the diff-serv 1342 egress point from which the reservation request originated. It 1343 uses routing information to do so. 1344 2. Of the matching entries, the boundary router must find the single 1345 entry which applies to the PHB mark which maps to the Intserv 1346 service type specified in the reservation request (see 1347 [MAPPING]). 1348 3. The boundary router must then compare the resources requested in 1349 the Intserv flowspec against the profile permitted by the TCA 1350 entry. 1352 If the resources requested are less than the profile permitted by 1353 the constraint TCA entry, then the reservation can be admitted and 1354 the RESV message should be allowed to continue flowing upstream 1355 towards the sender in the customer's network. If the resources 1356 requested exceed those allowable by the profile in the constraint 1357 TCA entry, the boundary router should reject the RESV message by 1358 blocking it and by sending a rejection message towards the receiver. 1360 The boundary router must maintain an accounting of resources 1361 allocated to admitted flows at each service level (and if necessary, 1362 to each egress subnet). This admission control procedure described 1363 is based on resource availability only. Boundary routers may also 1364 apply policy based admission control just as standard RSVP routers 1365 do. 1367 Bernet 25 1368 Requirements of Diff-serv Boundary Routers November 1998 1370 9.3.1 RSVP Reservations Expressed as Fine-Grain TCA Entries 1372 Note that acceptance of a reservation request can be considered to 1373 have installed a virtual entry in the fine-grain TCA. The same 1374 admission control process applies as would apply when actual entries 1375 are configured in the fine grain TCA. 1377 The virtual entry would not necessarily call for provider marking or 1378 policing (though it may, especially in the case of hosts that 1379 support RSVP signaling but are not able to mark packets or shape 1380 traffic). The entry would specify a quantitative PHB (all PHBs which 1381 map to Intserv service types are quantitative). The MF filter for 1382 the entry would consist of a fully specified 5-tuple corresponding 1383 to the source and destination IP ports and addresses, as well as the 1384 IP protocol specified in the RSVP filterspec. The profile would 1385 correspond to that specified in the RSVP flowspec. 1387 Since COPS supports RSVP messaging as well, a PDP can be used to 1388 accurately provision and configure the necessary fine-grain TCAs. 1389 The process involves a single PDP that is handling COPS messaging 1390 for RSVP as well as COPS for DiffServ. When a COPS signaled RSVP 1391 request arrives at the PDP, the PDP can install the appropriate 1392 fine-grain TCA directly utilizing the homogenous management 1393 infrastructure. 1395 9.3.2 Modifying Marked DSCPs 1397 To this point, we have assumed a well-known mapping of Intserv 1398 service type to PHB and DSCP. However, it may be desirable to 1399 override the well-known mapping in certain scenarios. Routers may do 1400 so by including a DCLASS object [MAPPING] in the RESV message 1401 forwarded to the sender of the data stream. This mechanism is 1402 analogous to use of the TCLASS object as described in [802MAP]. 1404 9.3.3 RSVP and IP Security 1406 When IP Security (IPSec [IPSEC]) is used end-to-end between 1407 communicating hosts, RSVP may be the only mechanism which enables 1408 diff-serv networks to classify traffic to a granularity finer than 1409 IP addresses (such as per application, based on port numbers). 1410 Boundary routers can support classification of RSVP signaled IPSec 1411 encrypted flows by implementing RFC-2207 [RFC2207] and the 1412 corresponding classification logic. 1414 10. Intercepting or Ignoring RSVP Messages 1416 RSVP messages are generated with the IP router alert option. This 1417 causes the messages to be intercepted by routers, for RSVP 1418 processing. It is necessary for boundary routers at diff-serv 1419 ingress points to intercept RSVP messages for the purpose of 1420 applying admission control to the diff-serv network (as described 1421 above). Since routers internal to the diff-serv network are not 1423 Bernet 26 1424 Requirements of Diff-serv Boundary Routers November 1998 1426 required to apply RSVP processing, it is preferable, for performance 1427 reasons, that they are not alerted by the router alert option. 1429 Egress boundary routers need not apply RSVP processing for the 1430 purpose of supporting diff-serv admission control and so, are not 1431 required to respond to the router alert option on messages passing 1432 out of the diff-serv network. However, these routers should respond 1433 to the router alert option on RSVP messages passing in the opposite 1434 direction (since they are effectively ingress boundary routers for 1435 these messages). In addition, egress boundary routers may choose to 1436 implement standard RSVP processing (on their customer interfaces), 1437 in which case, they must respond to the router alert option on RSVP 1438 messages passing out of the diff-serv network. 1440 Since certain routers must intercept RSVP messages on certain 1441 interfaces and others would prefer not to, a mechanism is required 1442 to 'hide' these messages. Such a suggestion is described in [AGGREG] 1443 and is based on usage of the router alert option field. 1445 8. Security Considerations 1447 Standard router security mechanisms should be used to restrict SNMP, 1448 COPS and command line configuration. Standard RSVP security 1449 mechanisms should be used to restrict configuration via RSVP. The 1450 major security threat to consider is denial of service attacks. 1451 Refer to the 'Security Considerations' section in [DSARCH] for a 1452 further discussion of this issue. 1454 9. References 1456 [DSARCH], Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., 1457 Davies, E., "An Architecture for Differentiated Services", Internet 1458 Draft, October 1998 1460 [DSFWK], Davies, E., Keshav, S., Verma, D., Carlson, M., Ohlman, B., 1461 Blake, S., Bernet, Y., Binder, J., Wang, Z., Weiss, W., "A Framework 1462 for Differentiated Services", Internet Draft, October 1998 1464 [COPS], Reichmeyer, F., Chan, K., Durham, D., Yavatkar, R., Gai, S., 1465 McCloghrie, K., Herzog, S., "COPS Usage for Differentiated 1466 Services", Internet Draft, August 1998 1468 [MAPPING], Peter, F., Bernet, Y., "Integrated Services Over 1469 Differentiated Services", Internet Draft, March 1998 1471 [E2E], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1472 Nichols, K., Speer, M., "A Framework for the Use of RSVP With Diff- 1473 serv Networks", Internet Draft, June, 1998 1475 [IPSEC], Kent, S., Atkinson, R., "Security Architecture for the 1476 Internet Protocol", Internet Draft, July 1998 1478 Bernet 27 1479 Requirements of Diff-serv Boundary Routers November 1998 1481 [BB], Nichols, K., Blake, S., "Differentiated Services Operational 1482 Model and Definitions", Internet Draft, February 1998 1484 [EF], Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1485 Forwarding PHB", Internet Draft, August 1998 1487 [RFC2207] Berger, L., O' Malley, T., "RSVP Extensions for IPSec Data 1488 Flows", RFC 2207, September 1997 1490 [RFC2205], Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 1491 "Resource Reservation Protocl, Version 1 Functional Specification", 1492 RFC 2205, Septemeber 1997 1494 [802MAP], Seaman, M., Smith, A., Crawley, E., Wroclawski, J., 1495 "Integrated Service Mappings on IEEE 802 Networks", Internet Draft, 1496 August 1998 1498 [AGGREG], Guerin, R., Blake, S., Herzog, S., "Aggregating RSVP Based 1499 QoS Requests", Internet Draft, November 1997 1501 11. Author's Addresses 1503 Bernet, Yoram 1504 Microsoft 1505 One Microsoft Way 1506 Redmond, WA 98052 1507 Phone: (425) 936-9568 1508 E-mail: yoramb@microsoft.com 1510 Durham, David 1511 Intel Corp. 1512 2111 N.E. 25th Ave. 1513 Hillsboro, OR 97124-5961 1514 Phone: (503) 264-6232 1515 E-mail: David.Durham@intel.com 1517 Francis Reichmeyer 1518 Bay Networks, Inc. 1519 3 Federal Street 1520 Billerica, MA 01821 1521 Phone: (978) 916-3352 1522 E-mail: freichmeyer@BayNetworks.com 1524 Bernet 28 1525 Requirements of Diff-serv Boundary Routers November 1998 1527 Appendix A. COPS-DS Constraint TCA PIB Format 1529 TBD. 1531 Bernet 29 1532 Requirements of Diff-serv Boundary Routers November 1998 1534 Appendix B. COPS-DS Fine-Grain TCA PIB Format 1536 TBD. 1538 Bernet 30