idnits 2.17.1 draft-brunner-nsis-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 1 longer page, the longest (page 1) being 1602 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (November 2001) is 8197 days in the past. Is this intentional? 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: 'QoS' on line 259 -- Looks like a reference, but probably isn't: 'Extension' on line 961 == Unused Reference: '6' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1348, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3132 (ref. '1') == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-qos-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mobileip-qos-requirements (ref. '2') == Outdated reference: A later version (-04) exists of draft-manner-seamoby-terms-02 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-westberg-rmd-cellular-issues-00 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Andreas Schrader 3 Internet Draft Hannes Hartenstein 4 Document: draft-brunner-nsis-req-00.txt Ralf Schmitz 5 Expires: May 2002 Juergen Quittek 6 Morihisa Momona 7 Marcus Brunner 8 NEC 10 Robert Hancock 11 Eleanor Hepworth 12 Roke Manor Research 14 Mathias Rautenberg 15 Hannes Tschofenig 16 Cornelia Kappler 17 Hans-Peter Schwefel 18 Christoph Niedermeier 19 Siemens AG 21 Holger Karl 22 Xiaoming Fu 23 TU Berlin 25 Andreas Kassler 26 University Ulm 28 November 2001 30 Requirements for QoS Signaling Protocols 31 33 Status of this Memo 35 This document is an Internet-Draft and is in full conformance 36 with all provisions of Section 10 of RFC2026. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other documents 45 at any time. It is inappropriate to use Internet-Drafts as 46 reference material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Informational - Expires May 2002 1 55 Requirements for QoS Signaling Protocols November 2001 57 Abstract 59 This draft proposes a set of requirements for signaling QoS across 60 different network environments. To achieve wide applicability of the 61 requirements, the starting point is a diverse set of user scenarios 62 concerning both access and core networks, application interactions, 63 and use within cellular networks. We also provide an outline 64 structure for the problem, including QoS related terminology. Taken 65 with the user scenarios, this allows us to focus more precisely on 66 which parts of the overall QoS problem needs to be solved. We 67 present the assumptions and the aspects not considered within scope 68 before listing the requirements grouped according to areas such as 69 architecture and design goals, signaling flows, layering, 70 performance, flexibility, security, and mobility. The motivation for 71 each requirement is included as well as a distinction between 72 requirements that should be met by the core part of the solution and 73 those that could be implemented as extensions. 75 1. Introduction 77 In order to derive requirements for QoS signaling it is necessary to 78 first have a clear idea of the scope within which they are 79 applicable. After defining terminology in Section 2, we therefore 80 start in Section 3 with a set of QoS signaling scenarios. These 81 scenarios derive from a variety of backgrounds, and help obtain a 82 clearer picture of what is in or out of scope of the NSIS work. They 83 illustrate the problem of QoS signaling from various perspectives 84 (end-system, access network, core network) and for various areas 85 (fixed line, mobile, wireless environments). As the NSIS work 86 becomes more clearly defined, scenarios will be added or dropped, or 87 defined in more detail. 89 Based on these scenarios, we are able to define the QoS signaling 90 problem on a more abstract level. In Section 4, we thus present a 91 simple conceptual model of the QoS signaling problem, describe the 92 entities involved in QoS signaling, and typical signaling paths. 93 Additionally we list our assumptions and exclusions. 95 The model of Section 4 allows deriving requirements from the 96 scenarios presented in Section 2 in a coherent and consistent 97 manner. Requirements are grouped according to areas such as 98 Architecture and design goals, Signaling Flows, Layering, 99 Performance, Flexibility, Security and Mobility. 101 QoS is a pretty large field with a lot of interaction with other 102 protocols, mechanisms, applications etc. In the following, some 103 thoughts from an end-system point of view and from an network point 104 of view. 106 End-system perspective: In future mobile terminals, the support of 107 adaptive applications is more and more important. Adaptively can be 108 seen as an important technique to react to QoS violations that may 109 occur frequently, e.g., in wireless environments due to changed 110 environmental and network conditions. This may result in degraded 112 Brunner et al. Informational - Expires May 2002 2 114 Requirements for QoS Signaling Protocols November 2001 116 end-to-end performance. It is then up to adaptive applications to 117 react to the new resource availability. Therefore, it is essential 118 to define interoperability between media-, mobility- and QoS 119 management. While most likely mobile terminals cannot assume, that 120 explicit QoS reservation schemes are available, some access networks 121 nevertheless may offer such capabilities. Applications subscribed to 122 an end-system QoS management system should be supported with a 123 dedicated QoS API to set-up, control and adapt media sessions. 125 Network perspective: QoS enabled IP networks are expected to handle 126 two different kinds of QoS granularities: per-flow QoS and per- 127 trunk/per-class QoS. Per-flow QoS might be needed in access networks 128 and may there be subject of QoS signaling. However, in the core 129 network only per-trunk or per-class QoS can be considered for 130 scalability reasons. Therefore there might be different requirements 131 on QoS signaling applying to different parts of the network. In the 132 access network QoS signaling is an interaction between end systems 133 and access routers or access network QoS managers (in the following 134 we call them QoS initiator and QoS controller). In the core network 135 QoS signaling refers to trunks or classes of traffic between core 136 and edge systems or between peering core systems. Please note that 137 this does not exclude the transport of per-flow signaling through 138 core networks. 140 It is clear from these descriptions that the subject of QoS is 141 uniquely complex and any investigation could potentially have a very 142 broad scope - so broad that it is a challenge to focus work on an 143 area which could lead to a concrete and useful result. This is our 144 motivation for considering a set of use cases which map out the 145 domain of application that we want to address; these use cases are 146 given in section 3. It is also the motivation for defining a problem 147 structure, which allows us to state the boundaries of what types of 148 functionality to consider, and to list background assumptions. This 149 structure is given in section 4. The requirements themselves follow 150 in section 5. There are several areas of the requirements related to 151 networking aspects which are incomplete, for example, interaction 152 with host and site multi-homing, use of anycast services, and so on. 153 These issues should be considered in any future requirement analysis 154 work. 156 2. Terminology 158 Aggregate: a group of flows, usually with similar QoS requirements, 159 which can be treated together as a whole with a single overall QoS 160 requirement for signaling and provisioning. Aggregates and flows can 161 be further aggregated together. 163 [QoS] Domain: a collection of networks under the same administrative 164 control and grouped together for administrative purposes. 166 Egress point: the router via which a path exits a domain/subdomain. 168 End Host: the end system or host, for whose flows QoS is being 169 requested and provisioned. 171 Brunner et al. Informational - Expires May 2002 3 173 Requirements for QoS Signaling Protocols November 2001 175 End-to-End QoS: the QoS delivered by the network between two 176 communicating end hosts. End-to-end QoS co-ordinates and enforces 177 predefined traffic management policies across multiple network 178 entities and administrative domains. 180 Edge-to-edge QoS: QoS within an administrative domain that connects 181 to other networks rather than hosts or end systems. 183 Flow: a traffic stream (sequence of IP packets between two end 184 systems) for which a specific level of QoS is to be provided. The 185 flow can be unicast (uni- or bi-directional) or multicast. 187 Flow Administration: represents the policy associated with how flows 188 should be treated in the network, for example whether and how the 189 flows should be aggregated. It may consist of both user and local 190 network management information. 192 Higher Layers: the higher layer (transport protocol and application) 193 functions that request QoS from the network layer. The request might 194 be a trigger generated within the end system, or the trigger might 195 be provided by some entity within the network (e.g. application 196 proxy or policy server). 198 Indication: feedback from QoS provisioning to indicate the current 199 QoS being provided to a flow or aggregate, and whether any 200 violations have been detected by the QoS technology being used 201 within the local domain/subdomain. 203 Ingress point: the router via which a path enters a 204 domain/subdomain. 206 Mapping: the act of transforming parameters from QSCs to values that 207 are meaningful to the actual QoS technology in use in the 208 domain/subdomain. 210 Path: the route across the networks taken by a flow or aggregate, 211 i.e. which domains/subdomains it passes through and the 212 egress/ingress points for each. 214 Path segment: the segment of a path within a single 215 domain/subdomain. 217 QoS Administration Function: a generic term for all functions 218 associated with admission control, policy control, traffic 219 engineering etc. 221 QoS Control Information: the information the governs the QoS 222 treatment to be applied to a flow or aggregate, including the QSC, 223 flow administration, and any associated security or accounting 224 information. 226 QoS Controller: this is responsible for interpreting the signaling 227 carrying the user QoS parameters, optionally inserting/modifying the 229 Brunner et al. Informational - Expires May 2002 4 231 Requirements for QoS Signaling Protocols November 2001 233 parameters according to local network QoS management policy, and 234 invoking local QoS provisioning mechanisms. 236 QoS Initiator: this is responsible for generating the QSCs for 237 traffic flow(s) based on user or application requirements and 238 signaling them to the network as well as invoking local QoS 239 provisioning mechanisms. This can be located in the end system, but 240 may reside elsewhere in network. 242 QoS Provisioning: the act of actually allocating resources to a flow 243 or aggregate of flows, may include mechanisms such as LSP initiation 244 for MPLS, packet scheduler configuration within a router, and so on. 245 The mechanisms depend on the overall QoS technology being used 246 within the [sub]domain. 248 QoS Service Classes (QSC): specify the QoS requirements of a traffic 249 flow or aggregate. Can be further sub-divided into user specific 250 and network related parameters 252 QoS Signalling: a way to communicate QSCs and QoS management 253 information between hosts, end systems and network devices etc. May 254 include request and response messages to facilitate negotiation/re- 255 negotiation, asynchronous feedback messages (not delivered upon 256 request) to inform End Hosts, QoS initiators and QoS controllers 257 about current QoS levels, and QoS querying facilities. 259 [QoS] Subdomain: a network within an administrative domain using a 260 uniform technology/QoS provisioning function to provision resources. 262 QoS Technology: a generic term for a set of protocols, standards and 263 mechanisms that can be used within a QoS domain/subdomain to manage 264 the QoS provided to flows or aggregates that traverse the domain. 265 Examples might include MPLS, DiffServ, and so on. A QoS technology 266 is associated with certain QoS provisioning techniques. 268 QoS Violation: occurs when the QoS applied to a flow or aggregate 269 does not meet the requested and negotiated QoS agreed for it. 271 Resource: something of value in a network infrastructure to which 272 rules or policy criteria are first applied before access is granted. 273 Examples of resources include the buffers in a router and bandwidth 274 on an interface. 276 Resource Allocation: part of a resource that has been dedicated for 277 the use of a particular traffic type for a period of time through 278 the application of policies 280 For terminology in IP paging etc. see RFC 3132 [1] and in mobility 281 see [3]. 283 3. Scenarios 285 Brunner et al. Informational - Expires May 2002 5 287 Requirements for QoS Signaling Protocols November 2001 289 In the following we describe some scenarios, which are important to 290 cover, and which allow us to discuss various requirements. Note that 291 the NSIS working group might choose to explicitly not cover some of 292 them. 294 3.1. Scenario 1: Terminal Mobility 296 The scenario we are looking at is the case where a mobile terminal 297 (MT) changes from one access point to another access point. The 298 access points are located in separate QoS domains. We assume Mobile 299 IP to handle mobility on the network layer in this scenario and 300 consider the various extensions (i.e., IETF proposals) to Mobile IP, 301 in order to provide 'fast handover' for roaming Mobile Terminals. 302 The goal to be achieved lies in providing, keeping, and adapting the 303 requested QoS for the ongoing IP sessions in case of handover. 304 Furthermore, the negotiation of QoS parameters with the new domain 305 via the old connection might be needed, in order to support the 306 different 'fast handover' proposals within the IETF. 308 The entities involved in this scenario include a mobile terminal, 309 access points, a access network manager, communication partners of 310 the MT (the other end(s) of the communication association). 311 From a technical point of view, terminal mobility means changing the 312 access point of a mobile terminal (MT). However, technologies might 313 change in various directions (access technology, QoS technology, 314 administrative domain). If the access points are within one specific 315 QoS technology (independent of access technology) we call this 316 intra-QoS technology handoff. In the case of an inter-QoS technology 317 handoff, one changes from e.g. a DiffServ to an IntServ domain, 318 however still using the same access technology. Finally, if the 319 access points are using different access technologies we call it 320 inter-technology hand-off. 322 The following issues are of special importance in this scenario: 324 1) Handoff decision 326 - The QoS management requests handoff. The QoS management can decide 327 to change the access point, since the traffic conditions of the new 328 access point are better supporting the QoS requirements. The metric 329 may be different (optimized towards a single or a group/class of 330 users). Note that the MT or the network (see below) might trigger 331 the handoff. 333 - The mobility management forces handoff. This can have several 334 reasons. The operator optimizes his network, admission is no longer 335 granted (e.g. emptied prepaid condition). Or another example is when 336 the MT is reaching the focus of another base station. However, this 337 might be detected via measurements of QoS on the physical layer and 338 is therefore out of scope of QoS signaling in IP. Note again that 339 the MT or the network (see below) might trigger the handoff. 341 - This scenario shows that local decisions might not be enough. The 342 rest of the path to the other end of the communication needs to be 344 Brunner et al. Informational - Expires May 2002 6 346 Requirements for QoS Signaling Protocols November 2001 348 considered as well. Hand-off decisions in a QoS domain, does not 349 only depend on the local resource availability, e.g., the wireless 350 part, but involves the rest of the path as well. Additionally, 351 decomposition of an end-to-end reservation might be needed, in order 352 to change only parts of it. 354 2) Trigger sources 356 - Mobile terminal: If the end-system QoS management identifies 357 another (better suited) access point, it will request the handoff 358 from the terminal itself. This will be especially likely in the case 359 that two different provider networks are involved. Another important 360 example is when the current access point bearer disappears (e.g. 361 removing the Ethernet cable). In this case, the QoS initiator is 362 basically located on the mobile terminal. 364 - Network (access network manager): Sometimes, the handoff trigger 365 will be issued from the network management to optimize the overall 366 load situation. Most likely this will result in changing the base- 367 station of a single providers network. Most likely the QoS initator 368 is located on a system within the network. 370 3) Integration with other protocols 372 - Interworking with other protocol must be considered in one or the 373 other form. E.g., it might be worth combining QoS signaling between 374 different QoS domains with mobility signaling at hand-over. 376 3.2. Scenario 2: Cellular Networks 378 In this scenario, the user is using the packet service of a 3rd 379 generation cellular system, e.g. using UMTS. The region between the 380 End Host and the edge node connecting the cellular network to 381 another QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is 382 considered to be a single QoS domain [4][5]. 384 Cellular systems provide their own QoS technology with specialized 385 parameters to co-ordinate the QoS provided by both the radio access 386 and access network. For example, in a UMTS network, one aspect of 387 GPRS is that it can be considered as a QoS technology; provisioning 388 of QoS within GPRS is described mainly in terms of things called 389 UMTS bearer classes. This QoS technology needs to be invoked with 390 suitable parameters when a request for QoS is triggered by higher 391 layers, and this therefore involves mapping the requested IP QoS 392 onto these UMTS bearer classes. This request for resources triggers 393 IP signaling messages that pass across the cellular system, and 394 possibly other QoS domains, to negotiate for network resources. 395 Typically, cellular system specific messages invoke the underlying 396 cellular system QoS technology in parallel with the IP QoS 397 negotiation, to allocate the resources within the cellular system. 399 The QoS initiator could be located at the End Host (triggered by 400 applications), the GGSN/PDSN, or at a node not directly on the data 401 path, such as a bandwidth broker. In the second case, the GGSN/PDSN 403 Brunner et al. Informational - Expires May 2002 7 405 Requirements for QoS Signaling Protocols November 2001 407 could either be acting as a proxy on behalf of an End Host with 408 little capabilities, and/or managing aggregate resources within its 409 QoS domain (the UMTS core network). The IP signaling messages are 410 interpreted by the QoS controllers, which may be located at the 411 GGSN/PDSN, and in any QoS sub-domains within the cellular system. 412 IP-level QoS re-negotiation may be initiated by either the End Host, 413 or by the network, based on current network loads. 415 Note that in comparison to the former scenario, the emphasis is much 416 less on the mobility aspects, because mobility is mainly handled on 417 the lower layer. 419 3.3. Scenario 3: Session mobility 421 In this scenario, a session is moved from one end-system to another. 422 Ongoing sessions are kept and QoS parameters need to be adapted, 423 since it is very likely that the new device provides different 424 capabilities. Note that it is open which entity initiates the move, 425 which implies that the QoS initiator might be triggered by different 426 entities. 428 User mobility (i.e., a user changing the device and therefore moving 429 the sessions to the new device) is considered to be a special case 430 within the session mobility scenario. 432 Note that this scenario is different from terminal mobility. Not the 433 terminal (end-system) has moved to a different access point. Both 434 terminals are still connected to an IP network at their original 435 points. Keeping the QoS guarantees negotiated implies that the end- 436 point(s) of communication are changed without changing the 437 reservations. 439 3.4. Scenario 4: QoS reservations/negotiation from access to core 440 network 442 The scenario includes the signaling between access networks and core 443 networks in order to setup and change reservations together with 444 potential negotiation. 446 The issues to be solved in this scenario are different from previous 447 ones. The entity of reservation is most likely an aggregate, and the 448 time scales of reservations might be different (long living 449 reservations of aggregates, rarer re-negotiation). However, the 450 specification of the traffic, a particular QoS is guaranteed for, 451 needs to be changed. E.g., in case additional flows are added to the 452 aggregate, the traffic specification of the flow needs to be added 453 if it is not already included in the aggregates specification. 455 3.5. Scenarios 5: QoS reservation/negotiation over administrative 456 boundaries 458 Signaling between two or more core networks to provide QoS is 459 handled in this scenario. The might also include access to core 460 signaling over administrative boundaries. Compare to the previous 462 Brunner et al. Informational - Expires May 2002 8 464 Requirements for QoS Signaling Protocols November 2001 466 one it adds the case, the two networks are not in the same 467 administrative domain. Basically, it is the inter-domain/inter 468 provider signaling which is handled in here. 470 The domain boundary is the critical issue to be resolved. Normally, 471 only basic information should be exchanged, if the signaling is 472 between competing administrations. Specifically information about 473 core network internals (e.g., topology, technology, etc.) should not 474 be exchanged. Some information exchange about the "access points" of 475 the core networks (which is topology information as well) may need 476 to be exchanged. 478 Additionally, as in scenario 4, signaling most likely is based on 479 aggregates. 481 4. Problem Statement and Scope 483 We provide in the following a preliminary architectural picture as a 484 basis for discussion. We will refer to it in the following 485 requirement section. 487 The overall problems to be solved have been given at a top level by 488 the use cases/scenarios of section 3. However, the problem of QoS 489 has an extremely wide scope and there is a great deal of work 490 already done to provide different components of the solution, such 491 as QoS technologies for example. A basic goal should be to re-use 492 these wherever possible, and to focus requirements work at an early 493 stage on those areas where a new solution is needed (e.g. an 494 especially simple one). We also try to avoid defining requirements 495 related to internal implementation aspects. 497 In this section, we present a simple conceptual model of the overall 498 QoS problem in order to identify the applicability to NSIS of 499 requirements derived from the use cases, and to clarify the scope of 500 the work, including any open issues. This model also identifies 501 further sources of requirements from external interactions with 502 other parts of an overall QoS solution, clarifies the terminology 503 used, and allows the statement of design goals about the nature of 504 the solution (see section 5). 506 Note that this model is intended not to constrain the technical 507 approach taken subsequently, simply to allow concrete phrasing of 508 requirements (e.g. requirements about placement of the QoS 509 initiator, or ability to 'drive' particular QoS technologies.) 511 4.1. Problem Discussion Model 513 A simple layer model covering a single path segment is shown in 514 figure 1, using the terminology from Section 2. 516 Roughly, the scope of NSIS within the context of this diagram is 517 assumed to be the interaction between the initiator and 518 controller(s), including selection of signaling protocols to carry 520 Brunner et al. Informational - Expires May 2002 9 522 Requirements for QoS Signaling Protocols November 2001 524 the QoS information, and the syntax/semantics of the information 525 that is exchanged. Further statements on assumptions/exclusions are 526 given below. The main elements shown are: 528 1. Something that starts the request for QoS, the QoS Initiator. 529 This might be in the end system or within some part of the network. 530 The distinguishing feature of the QoS initiator is that it acts on 531 triggers coming (directly or indirectly) from the higher layers in 532 the end systems, mapping the QoS requested by them, and also 533 provides feedback information to the higher layers which might be 534 used by transport layer rate management or adaptive applications. 536 2. Something that assists in managing QoS further along the path, 537 the QoS controller. The QoS controller does not interact with higher 538 layers, but interacts with the QoS initiator and possibly more QoS 539 controllers on the path, edge to edge or possibly end to end. 541 3. The QoS initiator and controller(s) interact with each other, 542 path segment by path segment. This interaction involves the exchange 543 of data (QoS control information) over some signaling protocol. 545 4. The path segment traverses an underlying network (QoS domain or 546 subdomain) covering one or more IP hops. The underlying network uses 547 some local QoS technology. This QoS technology has to be provisioned 548 appropriately for the flow, and this is done by the QoS initiator 549 and controller(s), mapping their QoS control information to 550 technology-related QoS parameters and receiving indications about 551 success or failure in response. 553 Brunner et al. Informational - Expires May 554 2002 10 556 Requirements for QoS Signaling Protocols November 2001 558 .............. ................ 559 . request/ . . response/ . 560 .trigger from. . feedback to . 561 .higher layer. .higher layers . 562 .............. ................ 563 | ^ 564 | | 565 | | ............... 566 | | . QoS Control . 567 V | . Information . 568 +----------------+ ............... +----------------+ 569 --->| |------------------------->| |-> 570 | | QoS signalling | | 571 | QoS Initiator | (request/query, | QoS Controller | 572 | | response/error etc.) | | 573 <---| |<-------------------------| |<- 574 +----------------+ +----------------+ 575 ^ | ^ | 576 | | | | 577 | ............ | | ............ | 578 | QoS | | QoS | 579 | provisioning | | provisioning | 580 | commands & | | commands & | 581 | responses | | responses | 582 | ............ | | ............ | 583 | | | | 584 | | | | 585 | V | V 586 +--------------------------------------------------------------+ 587 | QoS (sub)domain using any | 588 | Qos technology | 589 | | 590 | +------+ +------+ +------+ | 591 | |Router| |Router| |Router| | 592 =========| |=======| |=====================| |======= 593 | | | | | flow path | | | 594 | +------+ +------+ +------+ | 595 +--------------------------------------------------------------+ 597 Figure 1: Generic scope of signaling 599 A second diagram, figure 2, concentrates more on the overall end to 600 end (multiple QoS domains) aspects, in particular: 602 1. The QoS initiator need not be located at the end system, and the 603 QoS controllers are not assumed to be located on the flow path. 604 However, they must be able to identify the ingress and egress points 605 for the flow path as it traverses the domain/subdomain. Any 606 signalling protocol must be able to find the appropriate QoS 607 controller and carry this ingress/egress point information. 609 2. We see the network at the level of domains/subdomains rather than 610 individual routers (except in the special case that the domain 612 Brunner et al. Informational - Expires May 2002 11 614 Requirements for QoS Signaling Protocols November 2001 616 contains one link). Domains are assumed to be administrative 617 entities, so security requirements apply to the signaling between 618 them. Subdomains are introduced to allow the fact a given QoS 619 provisioning mechanism may only be used within a part of a domain, 620 typically for a particular subnetwork technology boundary. 621 Aggregation can also take place at subdomain boundaries. 623 3. Only a unicast flow is shown, with the QoS initiator at or near 624 one end. However, we do not exclude bi-directional flows with the 625 QoS requested by either end. Further QoS initiators may exist on the 626 path. Multicast or anycast flows or flows with variable paths within 627 a subdomain (e.g. to a mobile end system) are also logically 628 possible. 630 4. Any domain may contain QoS administration functions (e.g. to do 631 with traffic engineering, admission control, policy and so on). 632 These are assumed to interact with the QoS initiator and controllers 633 (and end systems) using standard mechanisms. 635 Brunner et al. Informational - 636 Expires May 2002 12 638 Requirements for QoS Signaling Protocols November 2001 640 +--------------------------+ 641 | QoS Domain | 642 +----+ flow path +-+ +-+ 643 |Host|==================|R|========================|R|==========++ 644 +----+ +-+ +-+ || 645 | \ / | || 646 | \+----+ +----+/ | || 647 | |QoS | |QoS | | || 648 | |cont| |init| | || 649 | +----+ +----+ | || 650 | ^ ^ | || 651 | | | | || 652 | V V | || 653 | +------------------+ | || 654 | |QoS administration| | || 655 | | functions | | || 656 | +------------------+ | || 657 +--------------------------+ || 658 || 659 +-----------------------------------------+ || 660 | +--------------------+ | || 661 | +-----| QoS controller |--+ | || 662 | / +--------------------+ \ | || 663 | / \ | || 664 | / +--------------------------+ \ | || 665 | / | QoS Subdomain | \ | || 666 +----+ +-+ +-+ +-+ +-+ || 667 |Host|========|R|======|R|************************|R|===|R|====++ 668 +----+ +-+ +-+ aggregate path +-+ +-+ 669 | | \ / | | 670 | | \+----+ +----+/ | | 671 | | |QoS | |QoS | | | 672 | | |init| |cont| | | 673 |QoS | +----+ +----+ | | 674 |Domain +--------------------------+ | 675 +-----------------------------------------+ 677 Figure 2: Signaling in a multiple (QoS)domains 679 4.2. Assumptions and Non-Assumptions 681 1. The NSIS signaling could run end to end, end to edge, or edge to 682 edge, or network-to-network ((between providers), depending on what 683 point in the network acts as the initiator, and how far towards the 684 other end of the network the signaling propagates. One extreme would 685 be to have the initiator at the end system and the scope of 686 signaling only as far as the first hop router; another would be to 687 have signaling edge to edge across an interior QoS domain, triggered 688 e.g. by a application layer proxy. 690 2. It does not make much sense to consider 'pure' end-to-end QoS 691 signaling that is not interpreted anywhere within the network. 693 Brunner et al. Informational - Expires May 2002 13 695 Requirements for QoS Signaling Protocols November 2001 697 Mainly in the area of mobility it is essential to decompose the path 698 into path segments (see scenario 1,2,3). This is part of the 699 transport or application layers. 701 3. Where the signaling does cover several QoS domains or subdomains, 702 we do not exclude that different signaling protocols are used in 703 each path segment. We only place requirements on the universality of 704 the QoS control information that is being transported. (The goal 705 here would be to allow the use of signaling protocols which are 706 matched to the characteristics of the portion of the network being 707 traversed.) Note that the outcome of NSIS work might result in 708 various protocols or various flavors of the same protocol. This 709 implies the need for the translation of information into QoS domain 710 specific format as well. 712 4.3. Exclusions 714 1. Development of specific mechanisms and algorithms for application 715 and transport layer adaptation are not considered, nor are the 716 protocols that would support it. 718 2. Specific mechanisms (APIs and so on) for interaction between 719 transport/applications and the network layer are not considered, 720 except to clarify the requirements on the negotiation capabilities 721 and information semantics that would be needed of the signaling 722 protocol. The same applies to application adaptation mechanisms. 724 3. Specific mechanisms for QoS provisioning within a 725 domain/subdomain are not considered. It should be possible to 726 exploit these mechanisms optimally within the end to end context. 727 Consideration of how to do this might generate new requirements for 728 NSIS however. For example, the information needed by an QoS 729 controller to manage a radio subnetwork needs to be provided by the 730 NSIS solution. 732 4. Specific mechanisms (APIs and so on) for interaction between the 733 network layer and underlying QoS provisioning mechanisms are not 734 considered. 736 5. Interaction with QoS administration capabilities is not 737 considered. Standard protocols should be used for this (e.g. COPS). 738 This may imply requirements for the sort of information that should 739 be exchanged between the NSIS network QoS entities. 741 6. Security issues related to multicasting are outside the scope of 742 the QoS signaling protocol. 744 Since multicasting is currently not an issue for the QoS protocol, 745 security issues related to multicast are outside the scope. 746 Multicast security may additionally be an application issue which is 747 also outside the scope of the QoS protocol. 749 7. Protection of non-QoS signaling messages are outside the scope of 750 the QoS protocol 752 Brunner et al. Informational - Expires May 2002 14 754 Requirements for QoS Signaling Protocols November 2001 756 Security protection of data messages transmitted along the establish 757 QoS path are outside the scope of the QoS protocol. These security 758 properties are likely to be application specific and may be provided 759 by the corresponding application layer protocol. 761 5. Requirements 763 This section defines more detailed requirements for a QoS signaling 764 solution, derived from consideration of the use cases/scenarios, and 765 respecting the framework, scoping assumptions, and terminology 766 considered earlier. The requirements are in subsections, grouped 767 roughly according to general technical aspects: architecture and 768 design goals, topology issues, QoS parameters, performance, 769 security, information, and flexibility. 771 Two general (and potentially contradictory) goals for the solution 772 are that it should be applicable in a very wide range of scenarios, 773 and at the same time lightweight in implementation complexity and 774 resource requirements in nodes. One approach to this is that the 775 solution could deal with certain requirements via modular components 776 or capabilities, which are optional to implement in individual 777 nodes. Requirements which could be handled this way are labeled 778 [Extension] in what follows. 780 There may be a better label than [Extension], but we think it has 781 the right implications: it doesn't imply 'optional to solve in the 782 work of the group' (like 'option' would) but it does not need to be 783 part of a 'core' solution. 785 Some of the requirements are technically contradictory. Depending on 786 the scenarios a solution apply to one or the other requirement is 787 applicable. We believe that the working group needs to decide first 788 on the scenarios to be covered, and which one to exclude. 790 5.1. Architecture and Design Goals 792 This section contains requirements related to desirable overall 793 characteristics of a solution, e.g. enabling flexibility, or 794 independence of parts of the framework. 796 1) Signaling must be applicable for different QoS technologies. 797 This includes sufficient QoS information. The information exchanged 798 over the signaling protocol must be in such detail and quantity that 799 it is useful for various QoS technologies. 801 2) Resource availability information on request [Extension] 802 In some scenarios, e.g., the mobile terminal scenario, it is 803 required to query, whether resources are available, without 804 performing a reservation on the resource. Feedback 806 3) Modularity 808 Brunner et al. Informational - Expires May 2002 15 810 Requirements for QoS Signaling Protocols November 2001 812 A modular design should allow for more lightweight implementations, 813 if fewer features are needed. Mutually exclusive solutions are 814 supported. Examples for modularity: 815 - Work over any kind of network (narrowband / broadband, error-prone 816 / reliable...) - This implies low bandwidth signaling and redundant 817 information must be supported if necessary. 819 - In case QoS requirements are soft (e.g. banking transactions, 820 gaming), fast and lightweight signaling (e.g., not more than one 821 round-trip time) 822 - Uni- and bi-directional reservations are possible 824 4) Decoupling of protocol and information it is carrying 825 The signaling protocol(s) used should be clearly separated from the 826 QoS control information being transported. This provides for the 827 independent development of these two aspects of the solution, and 828 allows for this control information to be carried within other 829 protocols, including application layer ones, to be developed in the 830 future. The gained flexibility in the information transported allows 831 for the applicability of the same protocol in various scenarios. 832 However, note that the information carried needs to be the same. 833 Otherwise interoperability is difficult to achieve. 835 5) Reuse of existing QoS provisioning 836 Reuse existing QoS functions and protocols for QoS provisioning 837 within a domain/subdomain unchanged. (Motivation: 'Don't re-invent 838 the wheel'.) 840 6) Avoid duplication of [sub]domain signaling functions 841 The specification of the NSIS signaling protocol should be optimised 842 to avoid duplication of existing [sub]domain QoS signaling and to 843 minimise the overall complexity. (Motivation: we don't want to 844 introduce duplicate feedback or negotiation mechanisms, or 845 complicate the work by including all possible existing QoS signaling 846 in some form. The function will be placed in the new part if it has 847 to be end-to-end, universal to all network types 848 ('simple/lightweight'), or if it has to be protected by upper layer 849 security mechanisms.) 851 The point here is that the QoS technology (lower layer stuff) gets 852 re-used unchanged, and we have new signaling above it. But, in many 853 cases the local QoS technology will contain equivalent functions to 854 the NSIS-required ones, just in a technology specific form. Examples 855 of these functions would be error/QoS violation notifications, 856 ability to query for resources and so on. So, there is a danger that 857 our 'lightweight' signaling ends up trying to carry all this 858 information all over again, and (even worse) that the 859 initiator/controller functions have to weigh up nearly equivalent 860 information coming from two directions. However, the basic problem 861 here is that the boundary between new and re-used stuff is pretty 862 shaky. The requirement is trying to scope our problem (a) to 863 eliminate the potential overlap, and (b) to keep the new NSIS stuff 864 simple. 866 Brunner et al. Informational - Expires May 2002 16 868 Requirements for QoS Signaling Protocols November 2001 870 7) Avoid modularity with large overhead (in various dimensions) 871 The protocols used for transporting signaling information over 872 various path segments do not need to be the same. Only the QoS 873 control information needs to be interworked between each segment. 874 (Motivation: the protocol can be chosen optimally for the 875 characteristics of the QoS domain being traversed. Also, we allow a 876 choice of protocols in end systems and networks without forcing 877 everyone to implement all choices; the network implementer's choice 878 of protocol can be local.) 880 8) Possibility to use the signaling protocol for existing local 881 technologies 882 It needs to be possible to use the new signaling as another local 883 QoS technology in its own right. For example, the treatment of 884 aggregates but possibly for other reasons also. Note that figure 2 885 shows precisely this case, it is being used there to support 886 signaling QoS for the aggregates. 888 5.2. Signaling Flows 890 This section contains requirements related to the possible signaling 891 flows that should be supported, e.g. over what parts of the flow 892 path, between what entities (end-systems, routers, middleboxes, 893 management systems), in which direction. 895 1) The protocol(s) must work in various scenarios end-to-end, edge- 896 to-edge, (e.g., just within one providers domain), user-to-network 897 (from end system into the network, ending, e.g., at the entry to the 898 network and vice versa), network-to-network (e.g., between 899 providers). In the figures of section 4, this means the location of 900 QoS Initiator and QoS Controllers can be chosen freely. 902 2) QoS signaling and QoS Controllers must not be constrained to be 903 in the data path. 905 3) Concealment of topology 906 In various scenarios, topology information should be hidden for 907 various reasons. From a business point of view, some administrations 908 don't want to reveal the topology and technology used. 910 4) Optional transparency of QoS signaling to network 911 It should be possible for the QoS signaling for some flows to 912 traverse path segments transparently, i.e. without interpretation at 913 QoS controllers within the network. An example would be a subdomain 914 within a core network, which only interpreted signaling for 915 aggregates established at the domain edge, with the flow-related 916 signaling passing transparently through it. 918 5.3. Additional information beyond signaling of QoS information 920 This section contains the desired signaling (messages) for other 921 purpose other than that for conveying QoS parameters. 923 Brunner et al. Informational - Expires May 2002 17 925 Requirements for QoS Signaling Protocols November 2001 927 1) Explicit release of resources 928 When a QoS reservation is no longer necessary, e.g. because the 929 application terminates, or because a mobile host experienced a hand- 930 off, it must be possible to explicitly release resources. 932 2) Ability to signal life-time of a reservation 933 Information about the life-time of a reservation allows to reduce 934 the reservation update frequency in case of soft state based 935 signaling. Note however, that we do not require in advance 936 reservation, only the expected duration of the reservation should be 937 included. 939 3) Possibility for automatic release of resources after failure 940 When the QoS Initiator goes down, the resources it requested should 941 be released, since they will no longer be necessary. 943 4) Possibility for automatic re-setup of resources after recovery 944 [Extension] 945 In case of a failure, the reservation can get setup again 946 automatically. It enables sort of a persistent reservation, if the 947 QoS Initiator requests it. In scenarios where the reservations are 948 on a longer time scale, this could make sense to reduce the 949 signaling load in case of failure and recovery. 951 5) Prompt notification of QoS violation in case of error / failure 952 to QoS Initiator and QoS Controllers 954 6) Feedback about the actually received level of QoS guarantees 955 The feedback must be independent of streaming technology used. 956 In some scenarios it might be requested to receive statistics about 957 the QoS received. E.g., feedback information might be used as input 958 to adaptation mechanisms. 960 7) Automatic notification on available resources not been granted 961 before [Extension] 962 In many cases, a QoS initiator does want to get a notification if 963 the resource he requested for some time ago, gets free. In order to 964 keep it simple, information on how long a request is kept and 965 notified. It implies keeping state about requests, which have been 966 rejected. 968 5.4. Layering 970 This section contains requirements related to the way the signaling 971 being considered interacts with upper layer functions (users, 972 applications, and QoS administration), and lower layer QoS 973 technologies. 975 1) The signaling protocol and QoS control information should be 976 application independent. However, opaque application information 977 should get transported in the signaling message, without being 978 handled in the network. Development and deployment of new 979 applications should be possible without impacting the network 981 Brunner et al. Informational - Expires May 2002 18 983 Requirements for QoS Signaling Protocols November 2001 985 infrastructure. Additionally, QoS protocols are expected to conform 986 to the Internet principles. 988 5.5. QoS Control Information 990 This section contains requirements related to the QoS control 991 information that needs to be exchanged. 993 1) Mutability information on parameters 994 It should be possible for the initiator to control the mutability of 995 the QSC information. This prevents from being changed in a non- 996 recoverable way. The initiator should be able to control what is 997 requested end to end, without the request being gradually mutated as 998 it passes through a sequence of domains. This implies that in case 999 of changes made on the parameters, the original requested ones must 1000 still be available. 1002 2) Possibility to add and remove local domain information 1003 It should be possible for the QoS control functions to add and 1004 remove local scope elements. E.g., at the entrance to a QoS domain 1005 domain-specific information is added, which is used in this domain 1006 only, and the information is removed again when a signaling message 1007 leaves the domain. The motivation is in the economy of re-use the 1008 protocol for domain internal signaling of various information. Where 1009 additional information is needed for QoS control within a particular 1010 domain, it should be possible to carry this at the same time as the 1011 'end to end' information.) 1013 3) The QoS service classes should be defined taking into account how 1014 they will be mapped to QoS provisioning or upper layer parameters. 1015 (Motivation: the simpler and more direct this mapping, the more 1016 faithful the overall QoS provided to the application.) 1018 4) Aggregation method specification 1019 The initiator should be able to specify the aggregation method that 1020 will be applied to the flow. Since the aggregation method implicitly 1021 affects the QoS that applies to the flows, the initiator must be 1022 able to influence this. 1024 The point in this requirement is that a reservation for a flow may 1025 make sense in isolation, but for scalability we need to aggregate 1026 flows together (as we all know). The treatment of the flow within 1027 the aggregate won't match the original reservation exactly - there 1028 has to most likely be an information loss - but the user (QoS 1029 initiator) should be able to at least indicate how the aggregation 1030 takes place. 1032 As an example, we use a controlled load service request for NRT 1033 traffic as an example. the initiator is happy to have just some sort 1034 of fair sharing with other flows within the aggregate rather than 1035 precise matching of the leaky bucket parameters at every hop along 1036 the aggregate path. a second more direct aspect is that a user might 1037 want to make a set of reservations but indicate the way they get 1039 Brunner et al. Informational - Expires May 2002 19 1041 Requirements for QoS Signaling Protocols November 2001 1043 aggregated together (e.g. set of reservations which are all intended 1044 to share a common resource). 1046 As another example, say a user has multiple web sessions running and 1047 wants anything sent to him on port 80 to be aggregated onto a single 1048 reservation where possible (so that he doesn't have to pay for 1049 individual reservations for each session). The requirement is to 1050 allow the user to specify a minimum aggregation that he would like 1051 for his flows, but without preventing each individual domain from 1052 further aggregating flows according to their own QoS technology. 1054 5) Multiple levels of detail 1055 The QSC should allow for multiple levels of detail in description. 1056 (Motivation: someone interpreting the request can tune its own level 1057 of complexity by going down to more or less levels of detail. A 1058 lightweight implementation within the core could consider only the 1059 coarsest level.) 1061 6) Ranges in specification 1062 The QSC should allow for specification of minimum required QoS 1063 and/or desirable QoS. (Motivation: The QoS Service Classes should 1064 allow optionally for ranges to be indicated, to minimize negotiation 1065 latency and suppress error notifications during handover events.) 1067 7) Independence of reservation identifier 1068 A reservation identifier must be used, which is independent of the 1069 flow identifier, the IP address of the QoS Initiator, and the flow 1070 end-points. Various scenarios in the mobility area require this 1071 independence because flows resulting from handoff might have changed 1072 end-points etc. but still have the same QoS requirement. 1074 8) Seamless modification of already reserved QoS 1075 In many case, the reservation needs to be updated (up or downgrade). 1076 This must happen seamlessly without service interruption. At least 1077 the signaling protocol must allow for it, even if some data path 1078 elements might not be capable of doing so. 1080 9) Signaling must support quantitative, qualitative, and relative 1081 QoS specifications 1083 10) QoS conformance specification 1084 The initiator should be able to indicate how faithfully the QoS 1085 provided by the network should conform to that requested. 1086 (Motivation: this allows for some flexibility in the level of QoS 1087 fulfilled by the network compared to that requested by the initiator 1088 deep inside the network.) 1090 5.6. Performance 1092 This section discusses performance requirements and evaluation 1093 criteria and the way in which these could and should be traded off 1094 against each other in various parts of the solution. 1096 1) Scalability 1098 Brunner et al. Informational - Expires May 2002 20 1100 Requirements for QoS Signaling Protocols November 2001 1102 Scalability is a must anyway. However, depending on the scenario the 1103 question to which extend the protocol must be scalable. The protocol 1104 must be scalable: 1105 - in the number of messages received by a signaling communication 1106 partner (QoS initiator and controller) 1107 - in number of hand-offs 1108 - in the number of interactions for setting up a reservation 1109 - in the number of state per entity (QoS initiators and QoS 1110 controllers) 1112 2) Low latency 1113 Low latency is only needed in scenarios, where reservations are in a 1114 short time scale (e.g. mobile environments), or where human 1115 interaction is immediately concerned (e.g., voice communication 1116 setup delay) 1118 3) Low bandwidth consumption 1119 Again only small sets of scenarios call for low bandwidth, mainly 1120 those where wireless links are involved. 1122 Note that many of the performance issues are heavily dependent on 1123 the scenario assumed and are normally a trade-off between speed, 1124 reliability, complexity, and scalability. The trade-off varies in 1125 different parts of the network. For example, in radio access 1126 networks low bandwidth consumption will overweight the low latency 1127 requirement, while in core networks it may be reverse. 1129 5.7. Flexibility 1131 This section lists the various ways the protocol can flexibly be 1132 employed. 1134 1) Aggregation capability, including the capability to select and 1135 change the level of aggregation. 1137 2) Flexibility in the placement of the QoS initiator 1138 It might be the sender or the receiver of content. But also network 1139 initiated reservations are required in various scenarios. 1141 3) Flexibility in the initiation of re-negotiation (QoS change 1142 requests) 1143 Again the sender or the receiver of content might initiate a re- 1144 negotiation due to various reasons, such as local resource shortage 1145 (CPU, memory on end-system) or a user changed application 1146 preference/profiles. But also network-initiated re-negotiation is 1147 required in cases, where the network is not able to further 1148 guarantee resources etc. 1150 4) Uni / bi-directional reservation 1151 Both uni-directonal as well as bi-direction reservations must be 1152 possible. 1154 Brunner et al. Informational - Expires May 2002 21 1156 Requirements for QoS Signaling Protocols November 2001 1158 5.8. Security 1160 This section includes security-related requirements. 1162 1) The QoS protocol must provide strong authentication 1164 A QoS protocol must make provision for enabling various entities to 1165 be authenticated against each other using data origin and/or entity 1166 authentication. The QoS protocol must enable mutual authentication 1167 between the two communicating entities. The term strong 1168 authentication points to the fact that weak plaintext password 1169 mechanisms must not be used for authentication. 1171 2) The QoS protocol must provide means to authorize resource 1172 requests 1174 This requirement demands a hook to interact with a policy entity to 1175 request authorization data. This allows an authenticated entity to 1176 be associated with authorization data and to verify the resource 1177 request. Authorization prevents reservations by unauthorized 1178 entities, reservations violating policies, theft of service and 1179 additionally limit denial of service attacks against parts of the 1180 network or the entire network. 1182 3) The QoS signaling messages must provide integrity protection. 1184 The integrity protection of the transmitted signaling messages 1185 prevent an adversary from mounting denial of service attacks against 1186 network elements participating in the QoS protocol, from hijacking a 1187 connection and from forging reservation requests and the 1188 corresponding replies. 1190 4) The QoS signaling messages must provide protection against replay 1191 attack. 1193 To prevent replay of previous signaling messages the QoS protocol 1194 must provide means to detect old messages. A solution must cover 1195 issues of synchronization problems in the case of a restart or a 1196 crash of a participating network element. 1198 5) The QoS signaling protocol must allow for hop-by-hop security. 1200 Hop-by-Hop security is a well-known and proven concept in QoS 1201 protocols that allows intermediate nodes that actively participate 1202 in the QoS protocol to modify the messages as required by the QoS 1203 processing. Note that this requirement does not exclude end-to-end 1204 security of a QoS reservation request. End-to-End security between 1205 the initiator and the responder may be used to provide protection of 1206 non-mutable data fields. Since the QoS protocol makes no provision 1207 to establish an end-to-end security association such an end-to-end 1208 protection cannot be a must-requirement. 1210 6) The QoS protocol should allow identity confidentiality and 1211 location privacy. 1213 Brunner et al. Informational - Expires May 2002 22 1215 Requirements for QoS Signaling Protocols November 2001 1217 Identity confidentiality enables privacy and avoids profiling of 1218 entities by an adversary eavesdropping the signaling traffic along 1219 the path. The identity used in the process of authentication may 1220 also be hidden to a limited extent from a network to which the 1221 initiator is attached. It is however required that the identity 1222 provides enough information for the access network to collect 1223 accounting data. Location privacy is an issue for the initiator who 1224 triggers the QoS protocol. In some scenarios the initiator may not 1225 be willing to reveal location information to the responder. 1227 7) The QoS protocol should provide hooks for AAA protocols 1229 The security mechanism should be developed with respect to be able 1230 to collect usage records from one or more network elements. 1232 8) The QoS protocol should prevent denial-of-service attacks against 1233 signaling entities. 1235 To effectively prevent denial-of-service attacks the QoS protocol 1236 and the used security mechanisms should not force to do heavy 1237 computation to verify a resource request. The QoS protocol and the 1238 used security mechanisms should not require large resource 1239 consumption for example main memory to take place. 1241 9) The QoS protocol should not disclose the network topology 1243 The QoS protocol should allow hiding the internal structure of a QoS 1244 domain from end-nodes and from other networks. Hence an adversary 1245 should not be able to learn the internal structure of a network with 1246 the help of the QoS protocol. 1248 10) The QoS protocol may support confidentiality of signaling 1249 messages. 1251 Based on the signaling information exchanged between nodes 1252 participating in the QoS protocol an adversary may learn both the 1253 identities and the content of the QoS messages. To prevent this from 1254 happening, confidentiality of the QoS requests in a hop-by-hop 1255 manner may be provided. Note that hop-by-hop is always required 1256 whenever entities actively participating in the protocol must be 1257 able to read and eventually modify the content of the QoS messages. 1258 This does not exclude the case where one or more network elements 1259 are not required to read the information of the transmitted QoS 1260 messages. 1262 11) The QoS protocol should provide hooks to interact with 1263 authentication and key management negotiation protocols 1265 The negotiation of an authentication and key management protocols 1266 within the QoS protocol is outside the scope of the QoS protocol. 1267 The goal of such a negotiation step is to determine which 1268 authentication and key management protocol to use is executed prior 1269 to the execution of the chosen key management protocol. A QoS 1271 Brunner et al. Informational - Expires May 2002 23 1273 Requirements for QoS Signaling Protocols November 2001 1275 protocol should however provide a way to interact with these 1276 negotiation protocols. 1278 12) The QoS protocol should provide means to interact with key 1279 management protocols 1281 Key management protocols typically require a larger number of 1282 messages to be transmitted to allow a session key and the 1283 corresponding security association to be derived. To avoid the 1284 complex issue of mapping individual authentication and key 1285 management protocols to a QoS protocol such a protocol is outside 1286 the scope of the QoS protocol. Although the key management protocol 1287 may be independent there must be a way for the QoS protocol to 1288 exploit existing security associations to avoid executing a separate 1289 key management protocol (or instance of the same protocol) for 1290 protocols that closely operate together. If no such security 1291 association exists then there should be means for the QoS protocol 1292 to trigger a key management protocol to dynamically create the 1293 required security associations. 1295 5.9. Mobility 1297 Mobility related requirements are already covered in [2], and are 1298 not repeated here. 1300 5.10. 1301 Interworking with other protocols and techniques 1303 Hooks must be provided to enable efficient interworking between 1304 various protocols and techniques including: 1306 1) Policies, traffic engineering, network management, accounting, 1307 Session signaling (particularly SIP proxy), Context transfer 1309 2) The solution should not constrain either to IPv4 or IPv6 1311 3) Combination with Mobility management 1312 Combining mobility and QoS signaling should be supported for 1313 economic signaling behavior (e.g., negotiation with the new access 1314 network: Mobile IP message to acquire new care-of address and query 1315 for QoS information could be combined, in order to preserve 1316 bandwidth and reduce latency). 1318 4) Independence from charging model 1319 Signaling must not be constrained by charging models or the charging 1320 infrastructure used. However, the end-system should be able to query 1321 current pay statistics and to specify user cost functions. 1323 6. References 1325 [1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem 1326 Statement", RFC 3132, June 2001. 1328 Brunner et al. Informational - Expires May 2002 24 1330 Requirements for QoS Signaling Protocols November 2001 1332 [2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP", 1333 draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress, 1334 August 2001 1336 [3] Manner. J., et al, "Mobility Related Terminology", draft-manner- 1337 seamoby-terms-02.txt, Work In Progress, July 2001. 1339 [4] 3GPP, "General Packet Radio Service (GPRS); Service Description 1340 Stage 2 v 7.7.0", TS 03.60, June 2001 1342 [5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum 1343 System, revision B", S.R0005-B, May 2001 1345 [6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling 1346 BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001 1348 [7] Partain, D., et al, "Resource Reservation Issues in Cellular 1349 Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt, 1350 Work in Progress, June 2001 1352 7. Acknowledgments 1354 Quite a number of people have been involved in the discussion of the 1355 draft, adding some ideas, requirements, etc. We list them without a 1356 guarantee on completeness: Changpeng Fan, Krishna Paul, Maurizio 1357 Molina, Mirko Schramm. 1359 8. Author's Addresses 1361 Andreas Schrader, Hannes Hartenstein, Ralf Schmitz, Juergen Quittek, 1362 Marcus Brunner 1363 NEC Europe Ltd. 1364 Network Laboratories 1365 Adenauerplatz 6 1366 D-69115 Heidelberg 1367 Germany 1368 E-Mail: brunner@ccrle.nec.de (contact) 1370 Morihisa Momona 1371 NEC Corporation 1372 Japan 1373 E-Mail: momona@ccm.cl.nec.co.jp 1375 Robert Hancock, Eleanor Hepworth 1376 Roke Manor Research Ltd 1377 Romsey, Hants, SO51 0ZN 1378 United Kingdom 1379 E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk 1381 Cornelia Kappler 1382 Siemens AG 1383 Berlin 13623 1385 Brunner et al. Informational - Expires May 2002 25 1387 Requirements for QoS Signaling Protocols November 2001 1389 Germany 1390 Phone: +49-30-386-32894 1391 E-Mail: cornelia.kappler@icn.siemens.de 1393 Holger Karl, Xiaoming Fu 1394 Technical University Berlin 1395 Sekr. 5-2, Einsteinufer 25 1396 Berlin 10587 1397 Germany 1398 Phone: +49-30-314-23826 1399 E-Mail: [karl|fu]@ee.tu-berlin.de 1401 Hans-Peter Schwefel 1402 Siemens AG 1403 Munich 1404 Germany 1405 Phone +49-89-722-59890 1406 E-Mail: hans.schwefel@icn.siemens.de 1408 Mathias Rautenberg 1409 Siemens AG 1410 Hofmannstr. 51 1411 81359 Munchen 1412 Germany 1413 E-Mail: Mathias.Rautenberg@icn.siemens.de 1415 Hannes Tschofenig 1416 Siemens AG 1417 Otto-Hahn-Ring 6 1418 81739 Munchen 1419 Germany 1420 Email: Hannes.Tschofenig@mchp.siemens.de 1422 Dr. Christoph Niedermeier 1423 CT SE 2 1424 Siemens AG 1425 D-81730 Muenchen, 1426 Germany 1427 phone: ++49-89/636-45783 1428 fax: ++49-89/636-40898 1429 email: Christoph.Niedermeier@mchp.siemens.de 1431 Andreas Kassler 1432 Dept. Distributed Systems 1433 University of Ulm 1434 Oberer Eselsberg 1435 89069 Ulm 1436 Germany 1437 Tel.: ++49 731 502 4139 1438 Fax.: ++49 731 502 4142 1439 eMail: kassler@informatik.uni-ulm.de 1441 Brunner et al. Informational - Expires May 2002 26 1443 Requirements for QoS Signaling Protocols November 2001 1445 Brunner et al. 1446 Informational - Expires May 2002 27