idnits 2.17.1 draft-bernet-diffedge-00.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-04-27) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 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: ---------------------------------------------------------------------------- == 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) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 45 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Differentiated Services Y. Bernet, Microsoft 3 Internet Draft July, 1998 4 Document: draft-bernet-diffedge-00.txt 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 ds.internic.net, 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 January 1999. Distribution of this draft 30 is unlimited. 32 1. Abstract 34 This draft discusses requirements of routers that serve as ingress 35 points to diff-serv provider networks. We discuss the traffic 36 conditioning components required and associated configuration 37 mechanisms and protocols. We also discuss admission control to diff- 38 serv networks in support of signaled QoS. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in [RFC-2119]. 46 3. Introduction 48 Diff-serv is a mechanism by which network service providers can 49 offer differing levels of network service to different traffic, in 50 so providing quality of service (QoS) to their customers. The basic 52 Bernet 1 53 premise of diff-serv networks is that routers within the networks 54 handle packets on different traffic flows by applying different per- 55 hop behaviours (PHBs). The PHB to be applied is specified by a code 56 in the IP header of each packet. 58 The advantage of such a scheme is that many traffic flows can be 59 aggregated to one of a small number of PHBs, thereby simplifying the 60 processing and storage associated with packet classification. In 61 addition, there is no signaling state or related processing required 62 in the diff-serv network since QoS is invoked on a packet-by-packet 63 basis. 65 4. Functional Components 67 In order to support a diff-serv network, certain functionality is 68 required from the boundary routers, which guard the ingress points 69 to the diff-serv network. This functionality is discussed in the 70 following sections. 72 The following diagram illustrates the major functional blocks of a 73 diff-serv boundary router: 75 mgmt. ---------------- 76 COPS, | diff-serv | 77 <------>| provisioning |------------------------ 78 SNMP,| | i/f | | 79 etc. | ---------------- | 80 | | | | 81 | | | | 82 | | | | 83 data | ----------- | --------- ------------ 84 ------->| inbound |------>|routing|------>| outbound |----> 85 | | t/c | | --------- | t/c & phb| 86 | ----------- | ------------ 87 | ^ | ^ 88 | | | | 89 | ----------- | | 90 -->| | | | 91 ------->| RSVP |----------------------------- 92 RSVP | | | 93 cntl ----------- | 94 msgs ^ | 95 | ------------- ------- 96 ---| diff-serv |<----->| TCA | 97 | a/c | | | 98 ------------- ------- 100 4.1 Interfaces, Traffic Conditioning and Routing Core 102 Bernet 2 103 An inbound interface, routing component and outbound interface are 104 illustrated at the center of the diagram. In real routers, there may 105 be an arbitrary number of inbound and outbound interfaces 106 interconnected by the routing core. The components of interest on 107 the interfaces are the traffic conditioning [1] components. These 108 are primarily at the inbound interface but may include a shaper at 109 the outbound interface. Certain queuing functionality, which 110 determines the per-hop behaviour [1](PHB) of the router is generally 111 implemented at the outbound interface. 113 4.2 Diff-serv Provisioning Interface 115 Diff-serv operating parameters are provisioned through this 116 interface. These are primarily traffic conditioning parameters. The 117 diff-serv admission control component checks these parameters for 118 admissibility subject to a traffic conditioning agreement (TCA) and 119 the level of resources currently committed. The network 120 administrator interacts with the diff-serv provisioning interface 121 via one of a number of management protocols such as SNMP or COPS 122 [2]. 124 4.3 RSVP 126 The RSVP component includes standard RSVP protocol processing. It 127 enables dynamic configuration of diff-serv traffic conditioning 128 components in response to host initiated RSVP signaling and provides 129 admission control feedback to the hosts. It interacts with the diff- 130 serv admission control component in order to coordinate signaled 131 resource requests with provisioned resource requests, subject to the 132 constraints of the TCA and local resources. Note that diff-serv PHBs 133 rather than RSVP dictate the actual packet forwarding behaviour in a 134 diff-serv boundary router. 136 4.4 Traffic Conditioning Agreement (TCA) 138 A service level agreement (SLA) represents the high-level agreement 139 between the diff-serv service provider operating the boundary router 140 and the customer(s) served by it. The TCA [1] is a subset of the 141 SLA, which specifies detailed traffic conditioning parameters to be 142 applied to the customer's traffic. In its simplest form, the TCA is 143 a static set of tables. In more sophisticated routers, the TCA may 144 be modified dynamically via signaling within the diff-serv network 145 and between the diff-serv and customer network. 147 5. Traffic Conditioning Components 149 Traffic conditioning is a fundamental component of a diff-serv 150 router. It is defined in [1]. The diagram in the previous section 151 illustrates the traffic conditioning components as an aggregate 152 functionality distributed between the inbound and outbound 153 interfaces of a diff-serv boundary router. The following paragraphs 154 describe the traffic conditioning components in greater detail. Note 155 that, with the exception of the shaper, all traffic conditioning 157 Bernet 3 158 components can be considered to reside at the inbound interfaces to 159 the router. 161 5.1 Classification 163 In order for the boundary router to treat traffic differentially it 164 must be able to differentiate certain traffic from other traffic. 165 This requirement dictates the minimal requirement of a boundary 166 router; classification. 168 There are differing degrees of classification functionality. At 169 minimum, a boundary router must support behaviour-aggregate (BA) 170 classification. In addition, routers may support varying degrees of 171 multi-field (MF) classification. See definitions of Classifier, BA 172 Classifier and MF Classifier in [1]. 174 A boundary router that supports MF classification can offer 175 significant functionality beyond that which can be offered by a 176 boundary router which supports only BA classification. This 177 functionality will be discussed further in a subsequent section. 179 5.2 Metering and Policing 181 Boundary routers use classifiers to identify classes of traffic 182 submitted for transmission through the diff-serv network. Once 183 traffic is classified at the input to the router, traffic from each 184 class is typically passed to a meter. The meter is used to measure 185 the rate at which traffic of each class is being submitted. This 186 rate can then be compared against a traffic profile that has been 187 negotiated between the diff-serv provider and the diff-serv 188 customer. Based on the results of the comparison, the meter deems 189 particular packets to be conforming to the negotiated profile (in- 190 profile) or non-conforming (out-of-profile). Appropriate policing 191 actions are then applied to out-of-profile packets. See [1] for a 192 definition of Meter and Policing. See [3] for a discussion of the 193 metering model applicable to several diff-serv service types. 195 Boundary routers should use meters and policers to protect the 196 resources within the diff-serv network. These traffic-conditioning 197 elements assure that customers cannot seize more than their fair 198 share of resources within the diff-serv network. Forms of policing 199 that may be used are: 201 1. Discarding out-of-profile packets. 202 2. Delaying out-of-profile packets until they become conforming 203 (Shaping). 204 3. Demoting the traffic class of out-of-profile packets by marking 205 appropriately (policer marking). 206 4. Charging for excess usage. 208 5.3 Marking 210 Bernet 4 211 Marking refers to setting the code in a packet's DS-field based on a 212 set of rules. We recognize three types of marking: 214 1. Boundary Marking 215 2. Customer Marking 216 3. Policer Marking 218 Routers are configured for one of two marking modes; customer 219 marking or boundary marking. In addition, routers should always 220 apply policer marking, regardless of the marking mode for which they 221 are configured. 223 5.3.1 Boundary Marking 225 In the case of boundary marking, the boundary router marks packets 226 for a specific service level, as a service to the customer. This 227 mode is generally employed when the customer is unable to mark 228 packets submitted to the diff-serv network. A table is used to 229 determine the DS-field code to be marked based on classification 230 results. 232 5.3.2 Customer Marking 234 In the case of customer marking, the customer is assumed to mark 235 packets directly, before submission to the diff-serv network. 237 5.3.3 Policer Marking 239 Regardless of the marking mode for which the boundary router is 240 configured, it may have to re-mark packets that would otherwise 241 receive a higher service level than that to which they are entitled. 242 For example, assume that the agreement between customer and provider 243 allows for 100 packets per second to be allotted the service level 244 invoked by the DS-field code 100100. In the case of customer 245 marking, the customer may submit 101 packets with this code in a 246 single second. In order to protect its resources, the boundary 247 router must select one packet to be discarded, or to delay the 248 transmission of the 101st packet or to re-mark it for a lower 249 service level. This re-marking is a form of policing (employed to 250 protect the diff-serv network's resources) that may be negotiated as 251 part of the service agreement between customer and provider and is 252 known as policer marking. 254 Even if boundary marking is employed, the marking table may cause 255 the boundary router to mark 101 packets for code 100100 in a single 256 second. In this case, the boundary router would either not mark the 257 101st packet for the code 100100, or would mark it for the code 258 100100 and would later re-mark it for a lower service level. The 259 result is logically equivalent. 261 Note that re-marking is always within the same PHB group (see [1]). 263 5.3.4 Classification Requirements Dictated by Marking Mode 265 Bernet 5 266 When boundary marking is employed, the boundary router is required 267 to recognize certain packets based on multiple fields in the packet 268 header (such as IP addresses and ports), and to set an appropriate 269 value in the DS-field of the packet. This requires MF classification 270 in the boundary router. A marking table is used to specify the 271 appropriate mark based on the classification results. 273 When customer marking is employed, only BA classification is 274 required at the boundary router. In this case, the boundary router 275 need only to track submitted packets for each DS-field value and to 276 re-mark in the case that a packet marked for a specific DS-field 277 value does not conform to the profile negotiated for the 278 corresponding service level. 280 MF classification is more costly (in terms of processing and state) 281 than BA classification. Therefore, there is an advantage to customer 282 marking, which avoids the need for MF classification in the router. 283 In addition, customer marking allows the transmitting host to pre- 284 mark non-conforming packets selectively. This is preferable to the 285 boundary marking alternative in which the boundary router will 286 select arbitrary packets for demotion as non-conforming. 288 5.3.5 The Marking Table 290 As described above, when the boundary router is configured for 291 boundary marking, a marking table is used to select the appropriate 292 mark based on results of MF classification. This table takes the 293 form of a mapping of classification fields to DS-field values. This 294 is illustrated in the following example: 296 IP Src Addr IP Dest Addr IP Src Port IP Dest Port DS-field 297 ----------- ------------ ----------- ------------ -------- 298 1.2.X.X X.X.X.X X X 100110 299 1.3.X.X X.X.X.X X X 100111 300 X.X.X.X X.X.X.X 5000 5001 110000 302 Notes: 303 1. The above table presents conflicts. For example; Which DS-field 304 should be marked for a packet with source IP address 1.2.3.4, 305 source IP port 5000 and destination IP port 5001? The agreement 306 between customer and provider must include rules for resolving 307 such conflicts. 308 2. The example above is based solely on common IP header fields. 309 Complex marking tables might define additional classification 310 fields to be used in submitted packets. 312 5.4 Configurations of Logical Traffic Conditioning Components 314 The following examples illustrate certain combinations of the 315 traffic conditioning components described. Note that these 316 illustrations are intended to represent logical combinations. The 318 Bernet 6 319 physical realizations of these combinations will vary from 320 implementation to implementation. 322 5.4.1 Customer Marking Configuration 324 The following diagram illustrates the traffic conditioning 325 components of a boundary router configured for customer marking: 327 --------- --------- --------- 328 | | | | | | 329 --->| |-->| |-->| |--> 330 | | | | | | 331 --------- --------- --------- 333 BA Class. Meter Policer 334 (opt. Re-marking) 336 The BA classifier is used to determine the diff-serv service level 337 requested, as indicated by the marking in the DS-field of each 338 packet. The meter determines whether the packet is conforming per 339 the profile negotiated for the requested service level. The policer 340 handles non-conforming packets either by discarding, delaying or re- 341 marking the packet for a lower service-level. 343 This traffic conditioning configuration is suitable only in the case 344 that it is dedicated to a single customer. This is because it 345 classifies traffic using a BA classifier and therefore is able to 346 discriminate traffic based on diff-serv service level only. In order 347 to support multiple customers, it is necessary to discriminate 348 traffic based on customer as well as service level. This requires an 349 MF-classifier as shown in the following diagram: 351 --------- --------- --------- 352 | | | | | | 353 |--->| |-->| |-->| |--> 354 | | | | | | | 355 | --------- --------- --------- 356 --------- | 357 | |-| BA Class. Meter Policer 358 ----->| | (opt. Re-marking) 359 | |-| 360 --------- | --------- --------- --------- 361 | | | | | | | 362 |--->| |-->| |-->| |--> 363 MF Class. | | | | | | 364 --------- --------- --------- 366 BA Class. Meter Policer 367 (opt. Re-marking) 369 Typically, an interface and its traffic conditioning components 370 would be dedicated to a single customer, obviating the need for the 372 Bernet 7 373 MF classifier illustrated. Such a configuration is preferable since 374 MF classification is more costly than BA classification. In the case 375 that a single interface must be dedicated to multiple customers, an 376 optimization to the illustrated configuration can be realized by 377 inserting a BA classifier in advance of the MF classifier. This 378 would identify all traffic marked for the default DS-field and allow 379 it to bypass the costly MF classifier since it is not requesting 380 preferential treatment. In many cases, the majority of traffic will 381 be marked for the default DS-field. 383 5.4.2 Boundary Marking Configuration 385 The following diagram illustrates the traffic conditioning 386 components of a boundary router configured for boundary marking. 388 --------- --------- --------- --------- --------- 389 | | | | | | | | | | 390 --->| |-->| |-->| |-->| |-->| |--> 391 | | | | | | | | | | 392 --------- --------- --------- --------- --------- 394 MF Class. Marker BA Class. Meter Policer 395 (opt. Re-marking) 397 In this example, an MF classifier is used to determine which diff- 398 serv service level a packet should be served at. The marker then 399 marks the DS-field of the packet with the appropriate code for the 400 service level. The operation of the classifier and marker is 401 directed by the marking table described in section 5.3.5. 403 Once the DS-field is marked based on the results of the MF 404 classification, the packet is submitted for BA classification. From 405 this point on, the packet is tracked based on the diff-serv service 406 level for which it is targeted, as if the boundary router had been 407 configured for customer marking. 409 Per the illustration, a boundary router configured for boundary 410 marking can logically be considered to concatenate the traffic 411 conditioning components required for customer classification behind 412 the MF classifier and marker required for boundary marking. In 413 practical implementations, the initial marking based on MF 414 classification will likely be combined with the remarking function 415 of the policer. Similarly, the MF and BA classifiers will likely be 416 combined. 418 5.4.3 Simultaneous Support for Customer and Boundary Marking 420 We previously considered boundary routers to be configured either 421 for boundary marking or customer marking. In practice, it may be 422 useful to support both schemes simultaneously. For example, the 423 diff-serv network provider may choose to support customers that have 424 hosts that are capable and trusted to mark directly, as well as 425 hosts that are not. The diff-serv provider can offer such mixed 427 Bernet 8 428 services either by requiring the customer to isolate hosts of each 429 type behind a dedicated interface to the diff-serv network or by 430 using the traffic conditioning configuration illustrated below. 432 In this example, a full MF classifier is employed to determine which 433 packets should be marked by the boundary router, and which should be 434 left unmodified. This is logically illustrated by the following 435 modification to the boundary marking traffic conditioner 436 configuration: 438 --------- --------- --------- --------- --------- 439 | | | | | | | | | | 440 --->| |-->| |-->| |-->| |-->| |--> 441 | |-| | | ->| | | | | | 442 --------- | --------- | --------- --------- --------- 443 | | 444 ------------- 445 MF Class. Marker BA Class. Meter Policer 446 (opt. Re-marking) 448 Note the arrow connecting the output of the MF classifier to the 449 input of the BA classifier (bypassing the marker). This represents 450 processing of packets that are determined by the MF classifier to be 451 pre-marked and trusted. 453 5.6 Boundary Shaping vs. Customer Shaping 455 The TCA for certain diff-serv service levels specifies a 456 quantitative profile to which traffic submitted for the service 457 level must conform. In order to assure conformance, it is necessary 458 for the traffic to be shaped to the profile. Ideally, shaping is 459 applied on a per-flow basis, at each host (where it scales best). If 460 the customer's hosts cannot be relied upon to shape, the customer 461 may negotiate a TCA that calls for the provider to shape on behalf 462 of the customer. This is a form of policing, referred to as boundary 463 shaping. 465 The TCA may call for aggregate boundary shaping or for per-flow 466 boundary shaping. Aggregate boundary shaping is a specific method of 467 implementing the aggregate policing which is necessary at boundary 468 routers. It requires only BA classifiers. It does not provide any 469 traffic separation for the customer. Per-flow boundary shaping may 470 be offered as an additional service to the customer. It has the 471 advantage of providing traffic separation for the customer, but 472 requires an MF classifier and multiple shaping queues and will 473 therefore be costly at the boundary router. 475 As illustrated in the context of customer marking vs. boundary 476 marking numerous configurations of traffic conditioning components 477 can be used to support customer shaping vs. boundary shaping. 479 6. Configuration of Boundary Routers 481 Bernet 9 482 In the previous section we examined the traffic conditioning 483 components which comprise the core diff-serv functionality of the 484 boundary router. This section discusses configuration of the traffic 485 conditioning components via the diff-serv provisioning interface and 486 RSVP (see block diagram in section 4). 488 6.1 Configuration Information 490 The following configuration information is required. 492 6.1.1 The Traffic Conditioning Agreement (TCA) 494 The TCA is negotiated (either statically or dynamically) between the 495 diff-serv provider and the customer. At minimum, the TCA defines 496 traffic conditioning parameters on a per diff-serv service level 497 granularity. This granularity reflects the fundamental nature of 498 diff-serv service; the provision of resources at a limited number of 499 service levels. 501 Diff-serv providers may offer additional functionality in boundary 502 routers to assist the customer in providing some degree of finer 503 grain traffic isolation. This is also reflected in the TCA. Boundary 504 marking is an example of such an additional service. 506 As such, it is helpful to consider two subsets of the TCA. One is 507 the subset of the TCA that defines the aggregate per service-level 508 resources that are negotiated between provider and customer. We will 509 refer to this subset informally as the constraint TCA. The other 510 subset of the TCA defines finer grain traffic conditioning which may 511 be provided to the customer as a value-add. We will refer to this 512 subset as the fine-grain TCA. Information in the fine-grain TCA is 513 subject to the constraints of the constraint TCA. 515 The TCA includes at least a policing table and may optionally 516 include a marking table, as described in the following sections. 518 6.1.2 Policing Table 520 Policing is the mechanism by which diff-serv providers protect their 521 network resources. By policing, the provider is effectively 522 approving or denying instantaneous requests for resources at a 523 particular service-level (as conveyed by the marking in each 524 packet's DS-field). As such, a per-service policing table is a 525 required part of the constraint TCA. 527 Policing configuration information can be expressed as a table of 528 entries having the following format: 530 DS-field : Metering Profile : Disposition of non-conforming traffic 532 The first column specifies the DS-field (in packet headers) to which 533 the entry applies. The second column specifies the traffic profile 535 Bernet 10 536 against which packets with the corresponding DS-field should be 537 measured. (In the case of a token bucket profile, the metering 538 profile would specify, token rate, peak rate and bucket size). The 539 third column specifies the action to be taken for packets that are 540 deemed non-conforming to the profile. Actions typically include: 541 shape to profile, discard, charge for excess usage, or demote to a 542 lower, specified service class by re-marking the PHB. 544 For PHBs that offer tight QoS assurances [4], it is generally 545 necessary to limit these assurances to flows between the ingress 546 boundary router and specific egress points from the diff-serv 547 network. Therefore, a fourth column may be required for certain 548 entries. This column would specify an egress subnet. Such an entry 549 should be understood to assure the service level specified by the 550 DS_field for traffic conforming to the profile and sent from the 551 boundary router ingress point to the specified egress point. 553 A diff-serv provider may offer fine-grain policing (especially in 554 the form of shaping) services to a customer. In this case, a 555 policing table similar to the one above would be incorporated as 556 part of the fine-grain TCA and would be subject to the constraints 557 of the constraint TCA. The first column of this policing table would 558 specify MF-classification criteria rather than DS-field value. 560 6.1.1.1 Marking Table 562 If boundary marking is to be provided, a marking table as described 563 in section 5.3.5, is required. The marking table is used to 564 configure MF classifiers and Markers. 566 Since the marking table is generally used to effectively map fine- 567 grain traffic flows into a small number of diff-serv service levels, 568 it can be considered part of the fine-grain TCA. Note that marking 569 amounts to generating requests for particular service levels. These 570 requests are then approved or denied by a policer. As such, marking 571 per-se is not subjected to the constraints of the constraint TCA. 573 6.1.3 PHB Configuration Information 575 Diff-serv routers implement PHBs that are used to forward traffic of 576 different service levels with differing behaviour. PHBs are 577 generally implemented via queues and schedulers that reside at the 578 router's outbound interfaces. There may be multiple configuration 579 parameters required to configure PHBs. These are beyond the scope of 580 this draft. Such parameters should be addressed as part of each PHB 581 specification. 583 6.1.4 Additional Configuration Information 585 A variety of miscellaneous configuration information is required for 586 any router. Examples include routing information, media support, 587 etc. Such information is beyond the scope of this draft. 589 Bernet 11 590 6.2 Configuration Mechanisms 592 The following sections describe the mechanisms by which the above 593 configuration information is installed in the boundary router. We 594 are concerned primarily with the configuration of the marking table 595 and policing information. A significant distinction is made between 596 signaled configuration (RSVP) and provisioned configuration (all 597 other mechanisms). 599 6.2.1 Installing the Constraint TCA 601 The constraint TCA effectively specifies the resources that the 602 provider is offering to the customer in the diff-serv network. The 603 two parties must agree upon this part of the TCA since it commits 604 resources on the one hand and incurs charges on the other hand. 605 Since this part of the TCA requires negotiation between the two 606 parties, it tends to be relatively static. 608 Note that protocols between the provider and customer may be used to 609 renegotiate the constraint TCA. This would allow the constraint TCA 610 to be somewhat more dynamic. 612 Static constraint TCAs may be installed into the boundary router via 613 a user management interface or protocol. For example, the constraint 614 TCA could be installed using SNMP or via vendor specific command 615 line interfaces. 617 Alternatively, COPS may be used to install the constraint TCA. 618 Because it is targeted primarily at QoS management, COPS is better 619 suited to support dynamic modifications to the constraint TCA. 621 In either case, the constraint TCA is considered to convey 622 provisioned configuration (as opposed to signaled configuration). 624 6.2.2 Configuring the Fine-Grain TCA 626 The fine-grain TCA specifies how the customer allocates the 627 resources it is paying for among its various traffic flows. The 628 provisioning mechanisms used to install the constraint TCA (SNMP, 629 COPS and command line interfaces) may also be used to install the 630 fine-grain TCA. However, there are advantages to using a signaling 631 mechanism to configure the fine-grain TCA. These are discussed 632 below. 634 The customer may wish to modify the fine grain TCA quite frequently. 635 In addition, the customer can for the most part, be allowed to 636 modify the fine-grain TCA without requiring the provider's approval. 637 For example, the customer may wish to stop marking packets from 638 subnet 1.X.X.X for a certain diff-serv service level and to start 639 marking packets from subnet 2.X.X.X for that service level. The 640 customer may wish to do so instantly and should not be required to 641 obtain approval from the diff-serv provider to do so. To this end, 643 Bernet 12 644 the customer may use RSVP to modify the marking table that is part 645 of the fine-grain TCA. 647 Similarly, the customer may use RSVP to configure fine-grain 648 policing information. For example, the customer may invoke per-flow 649 packet shaping services from the boundary router (within a diff-serv 650 service level) via RSVP signaling. 651 Using RSVP to configure such information in the fine-grain TCA has 652 the advantages of providing instant response to the customer, with 653 reduced management burden to the provider. In addition, RSVP can be 654 used to configure boundary routers to recognize IPSec [5] (or other) 655 encrypted flows. Without RSVP, MF classifiers will not be able to 656 recognize encrypted flows. 658 Finally, RSVP offers a significant advantage by virtue of supporting 659 admission control. Admission control support in boundary routers is 660 discussed in the next section. 662 7. Support for RSVP Admission Control 664 7.1 Overview of RSVP and Diff-serv Interoperation 666 As described in [4], diff-serv networks can be used to provide end- 667 to-end QoS across large transit networks by supporting RSVP. This 668 approach is of particular interest for a certain class of 669 applications for which RSVP signaling is practical, including 670 primarily multi-media applications. These applications generally: 672 1. Are able to quantify their QoS requirements 673 2. Require tighter QoS assurances than other applications 674 3. Operate between specific end-points 676 The Intserv service-types that are used by RSVP are mapped to 677 specific diff-serv PHBs [3,4]. Routers in diff-serv networks should 678 support these PHBs. The concatenation of these PHBs along paths 679 through diff-serv networks, combined with appropriate admission 680 control at the boundaries will enable diff-serv services that can 681 reasonably extend Intserv style QoS. 683 7.2 How Admission Control is Used 685 Consider a diff-serv service that offers very low latency such as 686 would be suitable for IP telephony. The EF PHB [6] is expected to 687 provide such a service. Assume that a customer uses the diff-serv 688 provider network to interconnect two customer networks. The customer 689 has an SLA in place with the provider at each of the two boundaries. 690 The TCAs offer 100 Kbps of EF service between the two attachment 691 points. Now consider that the customer uses this service to carry 692 voice over IP calls, each requiring a 16 Kbps flow. 694 In order to obtain the low latency service, the customer (either by 695 direct marking or by boundary marking) must mark voice over IP 696 traffic for the appropriate diff-serv service level. At the same 698 Bernet 13 699 time, the customer must constrain the number of marked flows to six 700 or fewer. A seventh flow will cause the customer to violate the TCA 701 in place with the diff-serv provider. Provider policing may then 702 arbitrarily compromise any traffic marked for the low latency 703 service. Simple RSVP based admission control from the boundary 704 router can prevent such over-subscription of the TCA by notifying 705 the offending host that the seventh flow has failed admission 706 control. In response, a properly behaving marking host will mark 707 traffic on the seventh flow for a lower service level (as described 708 in [4]). As a result, the six flows in place remain protected. Of 709 course, the same mechanisms apply to applications other than voice 710 over IP, for example - streaming video applications). 712 Additional benefits of such admission control include: 714 1. The ability to admit traffic to the diff-serv network based on 715 the approval of policy information carried in RSVP signaling 716 networks. 717 2. The ability to coordinate reservation of resources in RSVP 718 enabled regions of a network with acquisition of resources in 719 diff-serv regions of a network. For example, consider an end-to- 720 end path which originates and terminates at RSVP enabled campus 721 networks interconnected by a diff-serv enabled transit network. 722 It makes little sense to install reservations in the campus 723 networks if the diff-serv network cannot support the necessary 724 quality. Diff-serv admission control would avert this eventuality 725 by rejecting the reservation request at the diff-serv boundary 726 router. 727 3. Feedback to applications regarding the end-to-end admissibility 728 of their resource request can be used to cause the applications 729 to retry at a lower bandwidth or to invoke alternate adaptation 730 mechanisms. 732 7.3 Implementing Diff-serv Admission Control in Boundary Routers 734 Diff-serv admission control in boundary routers requires 735 implementation of a subset of RSVP. In particular, the RSVP protocol 736 state machine is required. The RSVP MF classification and scheduling 737 mechanisms are not necessarily required. The local admission control 738 functionality of standard RSVP routers [7] must be modified as 739 described in the following paragraph. 741 When a reservation request (RESV) arrives at a standard RSVP router, 742 the router must verify admissibility of the reservation on its 743 sending interface by querying traffic control for the interface. If 744 the resources specified in the Intserv flowspec of the RESV message 745 can be accommodated at the Intserv service level specified, then the 746 reservation request is admitted, by allowing the RESV message to 747 pass on to the sender. If the resources cannot be accommodated, then 748 the request is rejected by blocking the RESV and returning an error 749 message. 751 Bernet 14 752 In a diff-serv boundary router, a similar process is used. Upon 753 receiving a reservation request from a receiver at a remote customer 754 network, the boundary router must compare the request against the 755 constraint TCA that is in place. The boundary router does so as 756 follows: 758 1. First, the boundary router must find the TCA entries 759 corresponding to the diff-serv egress point from which the 760 reservation request originated. It uses routing information to do 761 so. 762 2. Of the matching entries, the boundary router must find the single 763 entry which applies to the DS-field mark which maps to the 764 Intserv service type specified in the reservation request (see 765 [3]). 766 3. The boundary router must then compare the resources requested in 767 the Intserv flowspec against the profile permitted by the TCA 768 entry. 770 If the resources requested are less than the profile permitted by 771 the constraint TCA entry, then the reservation can be admitted and 772 the RESV message should be allowed to continue flowing upstream 773 towards the sender in the customer's network. If the resources 774 requested exceed those allowable by the profile in the constraint 775 TCA entry, the boundary router should reject the RESV message by 776 blocking it and by sending a rejection message towards the receiver 777 [8]. 779 The boundary router must maintain an accounting of resources 780 allocated to admitted flows at each service level (and if necessary, 781 to each egress subnet). This admission control procedure described 782 is based on resource availability only. Boundary routers may also 783 apply policy based admission control just as standard RSVP routers 784 do. 786 7.4 Dynamic Constraint TCAs 788 The admission control procedure described above assumes static 789 constraint TCAs. In certain cases, protocols (such as the bandwidth 790 broker protocol [9]) employed within the diff-serv network (and 791 possibly between the diff-serv network and the customer network) may 792 be used to renegotiate constraint TCAs. Such protocols can be used 793 to dynamically adjust the constraint TCA. 795 For example, a boundary router may maintain a high-water mark 796 against which resources at a particular service level (and to a 797 particular egress subnet) are tracked. The high-water mark would 798 specify a resource level slightly lower than the limit specified by 799 the profile in the constraint TCA. If the level of resources 800 committed to a customer by diff-serv admission control reaches the 801 high-water mark, the boundary router would use a protocol to 802 negotiate a new profile for the appropriate constraint TCA entry. 803 Similarly, a low-water mark would be defined and when the level of 804 resources committed fell below the low-water mark, the profile would 806 Bernet 15 807 again be re-negotiated. Such a mechanism assumes that the SLA 808 between the customer and the provider allows for re-negotiation of 809 TCA entries as needed. 811 8. Intercepting or Ignoring RSVP Messages 813 RSVP messages are generated with the IP router alert option. This 814 causes the messages to be intercepted by routers, for RSVP 815 processing. It is necessary for boundary routers at diff-serv 816 ingress points to intercept RSVP messages for the purpose of 817 applying admission control to the diff-serv network (as described 818 above). Since routers internal to the diff-serv network are not 819 required to apply RSVP processing, it is preferable, for performance 820 reasons, that they are not alerted by the router alert option. 822 Egress boundary routers need not apply RSVP processing for the 823 purpose of supporting diff-serv admission control and so, are not 824 required to respond to the router alert option on messages passing 825 out of the diff-serv network. However, these routers should respond 826 to the router alert option on RSVP messages passing in the opposite 827 direction (since they are effectively ingress boundary routers for 828 these messages). In addition, egress boundary routers may choose to 829 implement standard RSVP processing (on their customer interfaces), 830 in which case, they must respond to the router alert option on RSVP 831 messages passing out of the diff-serv network. 833 Since certain routers must intercept RSVP messages on certain 834 interfaces and others would prefer not to, a mechanism is required 835 to 'hide' these messages. Such a suggestion is described in [10] and 836 is based on usage of the router alert option field. 838 8. Security Considerations 840 Standard router security mechanisms should be used to restrict SNMP, 841 COPS and command line configuration. Standard RSVP security 842 mechanisms should be used to restrict configuration via RSVP. 844 9. References 846 [1], Carson, M., Weiss, W., Blake, S., Wang, Z., Black, D., Davies, 847 E., "An Architecture for Differentiated Services", Internet Draft, 848 May 1998 850 [2], Herzog, S., Sastry, A., Rajan, R., Cohen, J., Boyle, J., 851 Durham, D., "The COPS (Common Open Policy Service) Protocol", 853 [3], Peter, F., Bernet, Y., "Integrated Services Over Differentiated 854 Services", Internet Draft, March 1998 856 [4], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 857 Nichols, K., Speer, M., "A Framework for the Use of RSVP With Diff- 858 serv Networks", Internet Draft, June, 1998 860 Bernet 16 862 [5], Kent, S., Atkinson, R., "Security Architecture for the Internet 863 Protocol", Internet Draft, July 1998 865 [6], Nichols, K., Blake, S., "Differentiated Services Operational 866 Model and Definitions", Internet Draft, February 1998 868 [7], Wroclawski, J., "The Use of RSVP With IETF Integrated 869 Services", RFC 2210, September, 1997 871 [8], Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 872 "Resource Reservation Protocl, Version 1 Functional Specification", 873 RFC 2205, Septemeber 1997 875 [9], Nichols, K., Jacobson, V., Zhang, L., "A Two-Bit Differentiated 876 Services Architecture for the Internet", Internet Draft, November 877 1997 879 [10], Guerin, R., Blake, S., Herzog, S., "Aggregating RSVP Based QoS 880 Requests", Internet Draft, November 1997 882 11. Author's Addresses 884 Bernet, Yoram 885 Microsoft 886 One Microsoft Way 887 Redmond, WA 98052 889 Phone: (425) 936-9568 890 E-mail: yoramb@microsoft.com 892 Bernet 17