idnits 2.17.1 draft-ietf-nsis-req-01.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 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1690: '... colums with the MUST, SHOULDs, and MA...' RFC 2119 keyword, line 1692: '...) MUSTs, SHOULDs, MAY needs discussion...' RFC 2119 keyword, line 1809: '...ack of a request MUST include yes and ...' RFC 2119 keyword, line 1810: '...in case of no it MAY include an opaque...' RFC 2119 keyword, line 1948: '...NSIS QoS signalling protocol MAY carry...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1894 has weird spacing: '...neering and r...' -- 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 (April 2002) is 8046 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 186 == Unused Reference: '1' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1085, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- No information found for draft-westberg-rmd-framework-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-03) exists of draft-kempf-cdma-appl-02 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group 2 Internet Draft M. Brunner (Editor) 3 Document: draft-ietf-nsis-req-01.txt NEC 4 Expires: October 2002 April 2002 5 Requirements for QoS Signaling Protocols 6 7 Status of this Memo 8 This document is an Internet-Draft and is in full conformance 9 with all provisions of Section 10 of RFC2026. 10 Internet-Drafts are working documents of the Internet Engineering 11 Task Force (IETF), its areas, and its working groups. Note that 12 other groups may also distribute working documents as Internet- 13 Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet-Drafts as 17 reference material or to cite them other than as "work in progress." 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt 20 The list of Internet-Draft Shadow Directories can be accessed at 21 http://www.ietf.org/shadow.html. 23 Abstract 24 This document defines requirements for signaling QoS across 25 different network environments. To achieve wide applicability of the 26 requirements, the starting point is a diverse set of scenarios/use 27 cases concerning various types of networks and application 28 interactions. We also provide an outline structure for the problem, 29 including QoS related terminology. Taken with the scenarios, this 30 allows us to focus more precisely on which parts of the overall QoS 31 problem needs to be solved. We present the assumptions and the 32 aspects not considered within scope before listing the requirements 33 grouped according to areas such as architecture and design goals, 34 signaling flows, layering, performance, flexibility, security, and 35 mobility. 36 1 Introduction 37 This document defines requirements for signaling QoS across 38 different network environments. It does not list any problems of 39 existing QoS signaling protocols such as RSVP. 40 In order to derive requirements for QoS signaling it is necessary to 41 first have a clear idea of the scope within which they are 42 applicable. 43 We describe a set of QoS signaling scenarios and use cases in the 44 Appendix of that document. These scenarios derive from a variety of 45 backgrounds, and help obtain a clearer picture of what is in or out 46 of scope of the NSIS work. They illustrate the problem of QoS 47 signaling from various perspectives (end-system, access network, 48 core network) and for various areas (fixed line, mobile, wireless 49 environments). As the NSIS work becomes more clearly defined, 50 scenarios will be added or dropped, or defined in more detail. 51 Based on these scenarios, we are able to define the QoS signaling 52 problem on a more abstract level. In Section 3, we thus present a 53 simple conceptual model of the QoS signaling problem, describe the 54 entities involved in QoS signaling, and typical signaling paths. In 55 Section 4 we list assumptions and exclusions. 56 The model of Section 3 allows deriving requirements from the 57 scenarios presented in the appendix in a coherent and consistent 58 manner. Requirements are grouped according to areas such as 59 Architecture and design goals, Signaling Flows, Layering, 60 Performance, Flexibility, Security and Mobility. 61 QoS is a pretty large field with a lot of interaction with other 62 protocols, mechanisms, applications etc. In the following, some 63 thoughts from an end-system point of view and from a network point 64 of view. 65 End-system perspective: In future mobile terminals, the support of 66 adaptive applications is more and more important. Adaptively can be 67 seen as an important technique to react to QoS violations that may 68 occur frequently, e.g., in wireless environments due to changed 69 environmental and network conditions. This may result in degraded 70 end-to-end performance. It is then up to adaptive applications to 71 react to the new resource availability. Therefore, it is essential 72 to define interoperability between media-, mobility- and QoS 73 management. While most likely mobile terminals cannot assume, that 74 explicit QoS reservation schemes are available, some access networks 75 nevertheless may offer such capabilities. Applications subscribed to 76 an end-system QoS management system should be supported with a 77 dedicated QoS API to set-up, control and adapt media sessions. 78 Network perspective: QoS enabled IP networks are expected to handle 79 two different kinds of QoS granularities: per-flow QoS and per- 80 trunk/per-class QoS. Per-flow QoS might be needed in access networks 81 and may there be subject of QoS signaling. However, in the core 82 network only per-trunk or per-class QoS can be considered for 83 scalability reasons. Therefore there might be different requirements 84 on QoS signaling applying to different parts of the network. In the 85 access network QoS signaling is an interaction between end systems 86 and access routers or access network QoS managers (in the following 87 we call them QoS initiator and QoS controller). In the core network 88 QoS signaling refers to trunks or classes of traffic between core 89 and edge systems or between peering core systems. Please note that 90 this does not exclude the transport of per-flow signaling through 91 core networks. 92 It is clear from these descriptions that the subject of QoS is 93 uniquely complex and any investigation could potentially have a very 94 broad scope - so broad that it is a challenge to focus work on an 95 area which could lead to a concrete and useful result. This is our 96 motivation for considering a set of use cases, which map out the 97 domain of application that we want to address. It is also the 98 motivation for defining a problem structure, which allows us to 99 state the boundaries of what types of functionality to consider, and 100 to list background assumptions. 101 There are several areas of the requirements related to networking 102 aspects which are incomplete, for example, interaction with host and 103 site multi-homing, use of anycast services, and so on. These issues 104 should be considered in any future requirement analysis work. 105 2 Terminology 106 In the area of Qualiaty of Service (QoS) it is quite difficult and 107 an exercise for its own to define terminology. Nevertheless, we 108 tried to list the most often used terms in the draft and tried to 109 explain them. However, don't be to religious about it, they are not 110 meant to prescribe any thing in the draft. 111 Aggregate: a group of flows, usually with similar QoS requirements, 112 which can be treated together as a whole with a single overall QoS 113 requirement for signaling and provisioning. Aggregates and flows can 114 be further aggregated together. 116 [QoS] Domain: a collection of networks under the same administrative 117 control and grouped together for administrative purposes. 118 Egress point: the router via which a path exits a domain/subdomain. 119 End Host: the end system or host, for whose flows QoS is being 120 requested and provisioned. 121 End-to-End QoS: the QoS delivered by the network between two 122 communicating end hosts. End-to-end QoS co-ordinates and enforces 123 predefined traffic management policies across multiple network 124 entities and administrative domains. 125 Edge-to-edge QoS: QoS within an administrative domain that connects 126 to other networks rather than hosts or end systems. 127 Flow: a traffic stream (sequence of IP packets between two end 128 systems) for which a specific level of QoS is to be provided. The 129 flow can be unicast (uni- or bi-directional) or multicast. 130 Flow Administration: represents the policy associated with how flows 131 should be treated in the network, for example whether and how the 132 flows should be aggregated. It may consist of both user and local 133 network management information. 134 Higher Layers: the higher layer (transport protocol and application) 135 functions that request QoS from the network layer. The request might 136 be a trigger generated within the end system, or the trigger might 137 be provided by some entity within the network (e.g. application 138 proxy or policy server). 139 Indication: feedback from QoS provisioning to indicate the current 140 QoS being provided to a flow or aggregate, and whether any 141 violations have been detected by the QoS technology being used 142 within the local domain/subdomain. 143 Ingress point: the router via which a path enters a 144 domain/subdomain. 145 Mapping: the act of transforming parameters from QSCs to values that 146 are meaningful to the actual QoS technology in use in the 147 domain/subdomain. 148 Path: the route across the networks taken by a flow or aggregate, 149 i.e. which domains/subdomains it passes through and the 150 egress/ingress points for each. 151 Path segment: the segment of a path within a single 152 domain/subdomain. 153 QoS Administration Function: a generic term for all functions 154 associated with admission control, policy control, traffic 155 engineering etc. 157 QoS Control Information: the information the governs the QoS 158 treatment to be applied to a flow or aggregate, including the QSC, 159 flow administration, and any associated security or accounting 160 information. 161 QoS Controller: this is responsible for interpreting the signaling 162 carrying the user QoS parameters, optionally inserting/modifying the 163 parameters according to local network QoS management policy, and 164 invoking local QoS provisioning mechanisms. Note that q QoS 165 controller might have very different functionality depending on 166 where in the network and in what environment they are implemented. 167 QoS Initiator: this is responsible for generating the QSCs for 168 traffic flow(s) based on user or application requirements and 169 signaling them to the network as well as invoking local QoS 170 provisioning mechanisms. This can be located in the end system, but 171 may reside elsewhere in network. 172 QoS Provisioning: the act of actually allocating resources to a flow 173 or aggregate of flows, may include mechanisms such as LSP initiation 174 for MPLS, packet scheduler configuration within a router, and so on. 175 The mechanisms depend on the overall QoS technology being used 176 within the [sub]domain. 177 QoS Service Classes (QSC): specify the QoS requirements of a traffic 178 flow or aggregate. Can be further sub-divided into user specific 179 and network related parameters 180 QoS Signaling: a way to communicate QSCs and QoS management 181 information between hosts, end systems and network devices etc. May 182 include request and response messages to facilitate negotiation/re- 183 negotiation, asynchronous feedback messages (not delivered upon 184 request) to inform End Hosts, QoS initiators and QoS controllers 185 about current QoS levels, and QoS querying facilities. 186 [QoS] Subdomain: a network within an administrative domain using a 187 uniform technology/QoS provisioning function to provision resources. 188 QoS Technology: a generic term for a set of protocols, standards and 189 mechanisms that can be used within a QoS domain/subdomain to manage 190 the QoS provided to flows or aggregates that traverse the domain. 191 Examples might include MPLS, DiffServ, and so on. A QoS technology 192 is associated with certain QoS provisioning techniques. 193 QoS Violation: occurs when the QoS applied to a flow or aggregate 194 does not meet the requested and negotiated QoS agreed for it. 195 Resource: something of value in a network infrastructure to which 196 rules or policy criteria are first applied before access is granted. 197 Examples of resources include the buffers in a router and bandwidth 198 on an interface. 200 Resource Allocation: part of a resource that has been dedicated for 201 the use of a particular traffic type for a period of time through 202 the application of policies. 203 Sender-initiated QoS signaling protocol: A sender-initiated QoS 204 signaling protocol is a protocol (see e.g., YESSIR [8], RMD [10]) 205 where the QI initiates the signaling on behalf of the sender of the 206 data. What this means is that admission control and resource 207 allocation functions are processed from the data sender towards the 208 data receiver. However, the triggering instance is not specified. 209 Receiver-initiated QoS signalling protocol: A receiver-initiated 210 protocol, (see e.g., RSVP [9]) is a protocol where the QoS 211 reservations are initiated by the QoS Reiceiver on behalf of the 212 receiver of the user data. What this means is that admission control 213 and resource allocation functions are processed from the data 214 receiver back towards the data sender. However, the triggering 215 instance is not specified. 216 3 Problem Statement and Scope 217 We provide in the following a preliminary architectural picture as a 218 basis for discussion. We will refer to it in the following 219 requirement section. 220 A set of issues and problems to be solved has been given at a top 221 level by the use cases/scenarios of the appendix. However, the 222 problem of QoS has an extremely wide scope and there is a great deal 223 of work already done to provide different components of the 224 solution, such as QoS technologies for example. A basic goal should 225 be to re-use these wherever possible, and to focus requirements work 226 at an early stage on those areas where a new solution is needed 227 (e.g. an especially simple one). We also try to avoid defining 228 requirements related to internal implementation aspects. 229 In this section, we present a simple conceptual model of the overall 230 QoS problem in order to identify the applicability to NSIS of 231 requirements derived from the use cases, and to clarify the scope of 232 the work, including any open issues. This model also identifies 233 further sources of requirements from external interactions with 234 other parts of an overall QoS solution, clarifies the terminology 235 used, and allows the statement of design goals about the nature of 236 the solution (see section 5). 237 Note that this model is intended not to constrain the technical 238 approach taken subsequently, simply to allow concrete phrasing of 239 requirements (e.g. requirements about placement of the QoS 240 initiator, or ability to 'drive' particular QoS technologies.) 241 Roughly, the scope of NSIS is assumed to be the interaction between 242 the QoS initiator and QoS controller(s), including selection of 243 signaling protocols to carry the QoS information, and the 244 syntax/semantics of the information that is exchanged. Further 245 statements on assumptions/exclusions are given in the next Section. 246 The main elements are: 247 1. Something that starts the request for QoS, the QoS Initiator. 248 This might be in the end system or within some other part of the 249 network. The distinguishing feature of the QoS initiator is that it 250 acts on triggers coming (directly or indirectly) from the higher 251 layers in the end systems. It needs to map the QoS requested by 252 them, and also provides feedback information to the higher layers 253 which might be used by transport layer rate management or adaptive 254 applications. 255 2. Something that assists in managing QoS further along the path, 256 the QoS controller. 257 The QoS controller does not interact with higher layers, but 258 interacts with the QoS initiator and possibly more QoS controllers 259 on the path, edge to edge or possibly end to end. 260 3. The QoS initiator and controller(s) interact with each other, 261 path segment by path segment. This interaction involves the exchange 262 of data (QoS control information) over some signaling protocol. 263 4. The path segment traverses an underlying network (QoS domain or 264 subdomain) covering one or more IP hops. The underlying network uses 265 some local QoS technology. This QoS technology has to be provisioned 266 appropriately for the flow, and this is done by the QoS initiator 267 and controller(s), mapping their QoS control information to 268 technology-related QoS parameters and receiving indications about 269 success or failure in response. 270 Now concentrating more on the overall end to end (multiple QoS 271 domains) aspects, in particular: 272 1. The QoS initiator need not be located at an end system, and the 273 QoS controllers are not assumed to be located on the flow's data 274 path. However, they must be able to identify the ingress and egress 275 points for the flow path as it traverses the domain/subdomain. Any 276 signaling protocol must be able to find the appropriate QoS 277 controller and carry this ingress/egress point information. 278 2. We see the network at the level of domains/subdomains rather than 279 individual routers (except in the special case that the domain 280 contains one link). Domains are assumed to be administrative 281 entities, so security requirements apply to the signaling between 282 them. Subdomains are introduced to allow the fact a given QoS 283 provisioning mechanism may only be used within a part of a domain, 284 typically for a particular subnetwork technology boundary. 285 Aggregation can also take place at subdomain boundaries. 286 3. Any domain may contain QoS administration functions (e.g. to do 287 with traffic engineering, admission control, policy and so on). 289 These are assumed to interact with the QoS initiator and controllers 290 (and end systems) using standard mechanisms. 291 4. The placement of the QoS initiators and QoS controllers is not 292 fixed. Actually, there are two extreme cases: 293 - Each router on the data path implements a QoS controller and QoS 294 initiator. 295 - Only the end systems incorporate a QoS controller and QoS 296 initiator, which means the end systems need to have QoS provisioning 297 capabilities. However this case does not seam to be realistic but 298 shows the flexible allocation of the controller and initiator 299 function. 300 4 Assumptions and Exclusions 301 4.1 Assumptions and Non-Assumptions 302 1. The NSIS signaling could run end to end, end to edge, or edge to 303 edge, or network-to-network ((between providers), depending on what 304 point in the network acts as the initiator, and how far towards the 305 other end of the network the signaling propagates. Although the 306 figures show QoS controllers at a very limited number of locations 307 in the network (e.g. at domain or subdomain borders, or even 308 controlling a complete domain), this is only one possible case. In 309 general, we could expect QoS controllers to become more 'dense' 310 towards the edges of the network, but this is not a requirement. An 311 overprovisioned domain might contain no QoS controllers at all (and 312 be NSIS transparent); at the other extreme, QoS controllers might be 313 placed at every router. In the latter case, QoS provisioning can be 314 carried out in a local implementation-dependent way without further 315 signalling, whereas in the case of remote QoS controllers, a 316 provisioning protocol might be needed to control the routers along 317 the path. This provisioning protocol is then independent of the end 318 to end NSIS signalling. 319 2. We do not consider 'pure' end-to-end QoS signaling that is not 320 interpreted anywhere within the network. Such signaling is an 321 application-layer issue and IETF protocols such as SIP etc. can be 322 used. 323 3. Where the signaling does cover several QoS domains or subdomains, 324 we do not exclude that different signaling protocols are used in 325 each path segment. We only place requirements on the universality of 326 the QoS control information that is being transported. (The goals 327 here would be to allow the use of signaling protocols which are 328 matched to the characteristics of the portion of the network being 329 traversed.) Note that the outcome of NSIS work might result in 330 various protocols or various flavors of the same protocol. This 331 implies the need for the translation of information into QoS domain 332 specific format as well. 334 4. We assume that the service definitions a QoS initiator can ask 335 for are known in advance of the signaling protocol running. Service 336 definition includes QoS parameters, life-time of QoS guarantee etc. 337 There are many ways a service requester get to know about it. There 338 might be standardized services, the definition can be negotiated 339 together with a contract, the service definition is published at a 340 Web-page, etc. 341 5. We assume that there are means for the discovery of NSIS entities 342 in order to know the signaling peers (solutions include static 343 configuration, automatically discovered, or implicitly runs over the 344 right nodes, etc.) 345 4.2 Exclusions 346 1. Development of specific mechanisms and algorithms for application 347 and transport layer adaptation are not considered, nor are the 348 protocols that would support it. 349 2. Specific mechanisms (APIs and so on) for interaction between 350 transport/applications and the network layer are not considered, 351 except to clarify the requirements on the negotiation capabilities 352 and information semantics that would be needed of the signaling 353 protocol. The same applies to application adaptation mechanisms. 354 3. Specific mechanisms for QoS provisioning within a 355 domain/subdomain are not considered. It should be possible to 356 exploit these mechanisms optimally within the end to end context. 357 Consideration of how to do this might generate new requirements for 358 NSIS however. For example, the information needed by an QoS 359 controller to manage a radio subnetwork needs to be provided by the 360 NSIS solution. 361 4. Specific mechanisms (APIs and so on) for interaction between the 362 network layer and underlying QoS provisioning mechanisms are not 363 considered. 364 5. Interaction with QoS administration capabilities is not 365 considered. Standard protocols should be used for this (e.g. COPS). 366 This may imply requirements for the sort of information that should 367 be exchanged between the NSIS network QoS entities. 368 6. Security issues related to multicasting are outside the scope of 369 the QoS signaling protocol. 370 Since multicasting is currently not an issue for the QoS protocol, 371 security issues related to multicast are outside the scope. 372 Multicast security may additionally be an application issue that is 373 also outside the scope of the QoS protocol. 374 7. Protection of non-QoS signaling messages is outside the scope of 375 the QoS protocol 376 Security protection of data messages transmitted along the 377 established QoS path is outside the scope of the QoS protocol. These 378 security properties are likely to be application specific and may be 379 provided by the corresponding application layer protocol. 380 8. Service definitions and QoS classes are out of scope. Together 381 with the service definition any definition of service specific 382 parameters are not considered in this draft. Only the base NSIS 383 signaling protocol for transporting the QoS/service information are 384 handled. 385 9. Similarly, specific methods, protocols, and ways to express QoS 386 information in the Application/Session level are not considered 387 (e.g., SDP, SIP, RTSP, etc.). 388 10. The specification of any extensions needed to signal QoS 389 information via application level protocols (e.g. SDP(ng)), and the 390 mapping on NSIS information are considered outside of the scope of 391 NSIS working group, as this work is in the direct scope of other 392 IETF working groups (e.g. MMUSIC). 393 5 Requirements 394 This section defines more detailed requirements for a QoS signaling 395 solution, derived from consideration of the use cases/scenarios, and 396 respecting the framework, scoping assumptions, and terminology 397 considered earlier. The requirements are in subsections, grouped 398 roughly according to general technical aspects: architecture and 399 design goals, topology issues, QoS parameters, performance, 400 security, information, and flexibility. 401 Two general (and potentially contradictory) goals for the solution 402 are that it should be applicable in a very wide range of scenarios, 403 and at the same time lightweight in implementation complexity and 404 resource requirements in nodes. One approach to this is that the 405 solution could deal with certain requirements via modular components 406 or capabilities, which are optional to implement in individual 407 nodes. 408 Some of the requirements are technically contradictory. Depending on 409 the scenarios a solution applies to, one or the other requirement is 410 applicable. 411 Find in Section 6 the MUSTs, SHOULDs, and MAYs 412 5.1 Architecture and Design Goals 413 This section contains requirements related to desirable overall 414 characteristics of a solution, e.g. enabling flexibility, or 415 independence of parts of the framework. 416 5.1.1 417 Applicability for different QoS technologies. 419 The QoS signaling protocol must work with various QoS technologies. 420 The information exchanged over the signaling protocol must be in 421 such detail and quantity that it is useful for various QoS 422 technologies. 423 5.1.2 424 Resource availability information on request 425 In some scenarios, e.g., the mobile terminal scenario, it is 426 required to query, whether resources are available, without 427 performing a reservation on the resource. One solution might be a 428 feedback mechanism based on which a QoS inferred handover can take 429 place. 430 5.1.3 431 Modularity 432 A modular design allows for more lightweight implementations, if 433 fewer features are needed. Mutually exclusive solutions are 434 supported. Examples for modularity: 435 - Work over any kind of network (narrowband / broadband, error-prone 436 / reliable...) - This implies low bandwidth signaling and redundant 437 information must be supported if necessary. 438 - In case QoS requirements are soft (e.g. banking transactions, 439 gaming), fast and lightweight signaling (e.g., not more than one 440 round-trip time) 441 - Uni- and bi-directional reservations are possible 442 5.1.4 443 Decoupling of protocol and information it is carrying 444 The signaling protocol(s) used must be clearly separated from the 445 QoS control information being transported. This provides for the 446 independent development of these two aspects of the solution, and 447 allows for this control information to be carried within other 448 protocols, including application layer ones, existing ones or those 449 being developed in the future. The gained flexibility in the 450 information transported allows for the applicability of the same 451 protocol in various scenarios. 452 However, note that the information carried needs to be the same. 453 Otherwise interoperability is difficult to achieve. 454 5.1.5 455 Reuse of existing QoS provisioning 456 Reuse existing QoS functions and protocols for QoS provisioning 457 within a domain/subdomain unchanged. (Motivation: 'Don't re-invent 458 the wheel'.) 459 5.1.6 460 Avoid duplication of [sub]domain signaling functions 461 The specification of the NSIS signaling protocol should be optimized 462 to avoid duplication of existing [sub]domain QoS signaling and to 463 minimize the overall complexity. (Motivation: we don't want to 464 introduce duplicate feedback or negotiation mechanisms, or 465 complicate the work by including all possible existing QoS signaling 466 in some form. The function will be placed in the new part if it has 467 to be end-to-end, universal to all network types 468 ('simple/lightweight'), or if it has to be protected by upper layer 469 security mechanisms.) 470 The point here is that the QoS technology (lower layer stuff) gets 471 re-used unchanged, and we have new signaling above it. But, in many 472 cases the local QoS technology will contain equivalent functions to 473 the NSIS-required ones, just in a technology specific form. Examples 474 of these functions would be error/QoS violation notifications, 475 ability to query for resources and so on. So, there is a danger that 476 our 'lightweight' signaling ends up trying to carry all this 477 information all over again, and (even worse) that the 478 initiator/controller functions have to weigh up nearly equivalent 479 information coming from two directions. However, the basic problem 480 here is that the boundary between new and re-used stuff is pretty 481 shaky. The requirement is trying to scope our problem (a) to 482 eliminate the potential overlap, and (b) to keep the new NSIS stuff 483 simple. 484 However, we are aware that it is very difficult to judge what is 485 duplicated, if we want to run the protocol in various environments. 486 5.1.7 487 Independence of signaling and provisioning paradigm 488 The QoS signaling should be independent of the paradigm and 489 mechanism of QoS provisioning. The independence allows for using the 490 NSIS protocol together with various QoS technologies. 491 5.2 Signaling Flows 492 This section contains requirements related to the possible signaling 493 flows that should be supported, e.g. over what parts of the flow 494 path, between what entities (end-systems, routers, middleboxes, 495 management systems), in which direction. 496 5.2.1 497 Free placement of QoS Initiator and QoS Controllers functions 498 The protocol(s) must work in various scenarios such as host-to- 499 network-to-host, edge-to-edge, (e.g., just within one providers 500 domain), user-to-network (from end system into the network, ending, 501 e.g., at the entry to the network and vice versa), network-to- 502 network (e.g., between providers). 503 Placing the QoS controller and initiator functions at different 504 locations allows for various scenarios to work with the same or 505 similar protocols. 506 5.2.2 507 No constraint of the QoS signaling and QoS Controllers to be in 508 the data path. 510 There is a set of scenarios, where QoS signaling is not on the data 511 path. The QoS Controller being in the data path is one extreme case 512 and useful in certain cases. 513 There are going to be cases where a centralized entity will take a 514 decision about QoS requests. In this case, there's no question there 515 is no need to have data follow the signalling path. 516 There are going to be cases wiout a centralized entity managing 517 resources and the signaling will be used as a tool for resource 518 management. For various reasons (such as efficient use of expensive 519 bandwidth), one will want to have fine-grained, fast, and very 520 dynamic control of the resources in the network. - 521 There are going to be cases where there will be neither signaling 522 nor a centralized entity (overprovisioning). Nothing has to be done 523 anyway. 524 One can capture the requirement with the following wording: If one 525 views the domain with a QoS technology as a virtual router then NSIS 526 signaling used between those virtual routers must follow the same 527 path as the data. 528 Routing the signaling protocol along an independent path is desired 529 by network operators/designers. Ideally, the capability to route the 530 protocol along an independent path would give the network 531 designer/operator the option to manage bandwidth utilization through 532 the topology. 533 There are other possibilities as well. An NSIS protocol must accept 534 all of these possibilities. 535 5.2.3 536 Concealment of topology and technology information 537 The QoS protocol should allow hiding the internal structure of a QoS 538 domain from end-nodes and from other networks. Hence an adversary 539 should not be able to learn the internal structure of a network with 540 the help of the QoS protocol. 541 In various scenarios, topology information should be hidden for 542 various reasons. From a business point of view, some administrations 543 don't want to reveal the topology and technology used. 544 5.2.4 545 Optional transparency of QoS signaling to network 546 It should be possible that the QoS signaling for some flows traverse 547 path segments transparently, i.e., without interpretation at QoS 548 controllers within the network. An example would be a subdomain 549 within a core network, which only interpreted signaling for 550 aggregates established at the domain edge, with the flow-related 551 signaling passing transparently through it. 553 5.3 Additional information beyond signaling of QoS information 554 This section contains the desired signaling (messages) for other 555 purposes other than that for conveying QoS parameters. 556 5.3.1 557 Explicit release of resources 558 When a QoS reservation is no longer necessary, e.g. because the 559 application terminates, or because a mobile host experienced a hand- 560 off, it must be possible to explicitly release resources. 561 5.3.2 562 Possibility for automatic release of resources after failure 563 When the QoS Initiator goes down, the resources it requested should 564 be released, since they will no longer be necessary. 565 5.3.3 566 Possibility for automatic re-setup of resources after recovery 567 In case of a failure, the reservation can get setup again 568 automatically. It enables sort of a persistent reservation, if the 569 QoS Initiator requests it. In scenarios where the reservations are 570 on a longer time scale, this could make sense to reduce the 571 signaling load in case of failure and recovery. 572 5.3.4 573 Prompt notification of QoS violation in case of error / failure to 574 QoS Initiator and QoS Controllers 575 5.3.5 576 Feedback about success of request for QoS guarantees 577 A request for QoS must be answered at least with yes or no. However, 578 it might be useful in case of a negative answer to also get a 579 description of what might be the QoS one can successfully request 580 etc. So it might be useful to include an opaque element into the 581 answer. The element heavily depends on the service requested. 582 5.4 Layering 583 This section contains requirements related to the way the signaling 584 being considered interacts with upper layer functions (users, 585 applications, and QoS administration), and lower layer QoS 586 technologies. 587 5.4.1 588 The signaling protocol and QoS control information should be 589 application independent. 590 However, opaque application information might get transported in the 591 signaling message, without being handled in the network. Development 592 and deployment of new applications should be possible without 593 impacting the network infrastructure. Additionally, QoS protocols 594 are expected to conform to the Internet principles. 595 5.5 QoS Control Information 596 This section contains requirements related to the QoS control 597 information that needs to be exchanged. 598 5.5.1 599 Mutability information on parameters 600 It should be possible for the initiator to control the mutability of 601 the QSC information. This prevents from being changed in a non- 602 recoverable way. The initiator should be able to control what is 603 requested end to end, without the request being gradually mutated as 604 it passes through a sequence of domains. This implies that in case 605 of changes made on the parameters, the original requested ones must 606 still be available. 607 Note that we do not require anything about particular QoS paramters 608 being changed. 609 5.5.2 610 Possibility to add and remove local domain information 611 It should be possible for the QoS control functions to add and 612 remove local scope elements. E.g., at the entrance to a QoS domain 613 domain-specific information is added, which is used in this domain 614 only, and the information is removed again when a signaling message 615 leaves the domain. The motivation is in the economy of re-use the 616 protocol for domain internal signaling of various information. Where 617 additional information is needed for QoS control within a particular 618 domain, it should be possible to carry this at the same time as the 619 'end to end' information.) 620 5.5.3 621 Independence of reservation identifier 622 A reservation identifier must be used, which is independent of the 623 flow identifier, the IP address of the QoS Initiator, and the flow 624 end-points. Various scenarios in the mobility area require this 625 independence because flows resulting from handoff might have changed 626 end-points etc. but still have the same QoS requirement. 627 5.5.4 628 Seamless modification of already reserved QoS 629 In many case, the reservation needs to be updated (up or downgrade). 630 This must happen seamlessly without service interruption. At least 631 the signaling protocol must allow for it, even if some data path 632 elements might not be capable of doing so. 633 5.5.5 634 Signaling must support quantitative, qualitative, and relative QoS 635 specifications 636 5.6 Performance 637 This section discusses performance requirements and evaluation 638 criteria and the way in which these could and should be traded off 639 against each other in various parts of the solution. 640 Scalability is a must anyway. However, depending on the scenario the 641 question to which extends the protocol must be scalable. 643 5.6.1 644 Scalability in the number of messages received by a signaling 645 communication partner (QoS initiator and controller) 646 5.6.2 647 Scalability in number of hand-offs 648 5.6.3 649 Scalability in the number of interactions for setting up a 650 reservation 651 5.6.4 652 Scalability in the number of state per entity (QoS initiators and 653 QoS controllers) 654 5.6.5 655 Scalability in CPU use (end terminal and intermediate nodes) 656 5.6.6 657 Low latency in setup 658 Low latency is only needed in scenarios, where reservations are in a 659 short time scale (e.g. mobile environments), or where human 660 interaction is immediately concerned (e.g., voice communication 661 setup delay) 662 5.6.7 663 Allow for low bandwidth consumption for signaling protocol 664 Again only small sets of scenarios call for low bandwidth, mainly 665 those where wireless links are involved. 666 Note that many of the performance issues are heavily dependent on 667 the scenario assumed and are normally a trade-off between speed, 668 reliability, complexity, and scalability. The trade-off varies in 669 different parts of the network. For example, in radio access 670 networks low bandwidth consumption will overweight the low latency 671 requirement, while in core networks it may be reverse. 672 5.6.8 673 Ability to constrain load on devices 674 The NSIS architecture should give the ability to constrain the load 675 (CPU load, memory space, signaling bandwidth consumption and 676 signaling intensity) on devices where it is needed. This can be 677 achieved by many different methods, for example message aggregation, 678 by ignoring signaling message, header compression or minimizing 679 functionality. The architecture may choose any of these methods as 680 long as the requirement is met. 681 5.7 Flexibility 682 This section lists the various ways the protocol can flexibly be 683 employed. 684 5.7.1 685 Aggregation capability, including the capability to select and 686 change the level of aggregation. 687 5.7.2 688 Flexibility in the placement of the QoS initiator 690 It might be the sender or the receiver of content. But also network- 691 initiated reservations are required in various scenarios. 692 5.7.3 693 Flexibility in the initiation of re-negotiation (QoS change 694 requests) 695 Again the sender or the receiver of content might initiate a re- 696 negotiation due to various reasons, such as local resource shortage 697 (CPU, memory on end-system) or a user changed application 698 preference/profiles. But also network-initiated re-negotiation is 699 required in cases, where the network is not able to further 700 guarantee resources etc. 701 5.7.4 702 Uni / bi-directional reservation 703 Both uni-directonal as well as bi-direction reservations must be 704 possible. 705 5.8 Security 706 This section discusses security-related requirements. First a list 707 of security threats is given. 708 5.8.1 709 The QoS protocol must provide strong authentication 710 A QoS protocol must make provision for enabling various entities to 711 be authenticated against each other using data origin and/or entity 712 authentication. The QoS protocol must enable mutual authentication 713 between the two communicating entities. The term strong 714 authentication points to the fact that weak plain-text password 715 mechanisms must not be used for authentication. 716 5.8.2 717 The QoS protocol must provide means to authorize resource requests 718 This requirement demands a hook to interact with a policy entity to 719 request authorization data. This allows an authenticated entity to 720 be associated with authorization data and to verify the resource 721 request. Authorization prevents reservations by unauthorized 722 entities, reservations violating policies, theft of service and 723 additionally limits denial of service attacks against parts of the 724 network or the entire network. Additionally it might be helpful to 725 provide some means to inform other protocols of participating nodes 726 within the same administrative domain about a previous successful 727 authorization event. 728 5.8.3 729 The QoS signaling messages must provide integrity protection. 730 The integrity protection of the transmitted signaling messages 731 prevent an adversary from modifying parts of the QoS signaling 732 message and from mounting denial of service attacks against network 733 elements participating in the QoS protocol. 735 5.8.4 736 The QoS signaling messages must be replay protected. 737 To prevent replay of previous signaling messages the QoS protocol 738 must provide means to detect old messages. A solution must cover 739 issues of synchronization problems in the case of a restart or a 740 crash of a participating network element. The use of replay 741 mechanism apart from sequence numbers should be investigated. 742 5.8.5 743 The QoS signaling protocol must allow for hop-by-hop security. 744 Hop-by-Hop security is a well known and proven concept in QoS 745 protocols that allows intermediate nodes that actively participate 746 in the QoS protocol to modify the messages as required by the QoS 747 processing. Note that this requirement does not exclude end-to-end 748 or network-to-network security of a QoS reservation request. End-to- 749 end security between the initiator and the responder may be used to 750 provide protection of non-mutable data fields. Network-to-network 751 security refers to the protection of messages over various hops but 752 not in an end-to-end manner i.e. protected over a particular 753 network. 754 5.8.6 755 The QoS protocol should allow identity confidentiality and 756 location privacy. 757 Identity confidentiality enables privacy and avoids profiling of 758 entities by adversary eavesdropping the signaling traffic along the 759 path. The identity used in the process of authentication may also be 760 hidden to a limited extent from a network to which the initiator is 761 attached. It is however required that the identity provide enough 762 information for the access network to collect accounting data. 763 Location privacy is an issue for the initiator who triggers the QoS 764 protocol. In some scenarios the initiator may not be willing to 765 reveal location information to the responder. 766 5.8.7 767 The QoS protocol should prevent denial-of-service attacks against 768 signaling entities. 769 To effectively prevent denial-of-service attacks the QoS protocol 770 and the used security mechanisms should not force to do heavy 771 computation to verify a resource request prior authenticating the 772 requesting entity. Additionally the QoS protocol and the used 773 security mechanisms should not require large resource consumption 774 (for example main memory or other additional message exchanges) 775 before a successful authentication was done. 776 5.8.8 777 The QoS protocol should support confidentiality of signaling 778 messages. 779 Based on the signaling information exchanged between nodes 780 participating in the QoS protocol an adversary may learn both the 781 identities and the content of the QoS messages. To prevent this from 782 happening, confidentiality of the QoS requests in a hop-by-hop 783 manner should be provided. Note that hop-by-hop is always required 784 whenever entities actively participating in the protocol must be 785 able to read and eventually modify the content of the QoS messages. 786 This does not exclude the case where one or more network elements 787 are not required to read the information of the transmitted QoS 788 messages. 789 5.8.9 790 The QoS protocol should provide hooks to interact with protocols 791 that allow the negotiation of authentication and key management 792 protocols. 793 The negotiation of an authentication and key management protocols 794 within the QoS protocol is outside the scope of the QoS protocol. 795 This requirement originates from the fact that more than one key 796 management protocol may be used to provide security associations. So 797 both entities must be capable to use the same protocol which may be 798 difficult in a mobile environment with different requirements and 799 different protocols. The goal of such a negotiation step is to 800 determine which authentication and key management protocol to use is 801 executed prior to the execution of the chosen key management 802 protocol. The used key management protocol must however be able to 803 create a security association that matches with the one used in the 804 QoS protocol. A QoS protocol should however provide a way to 805 interact with these negotiation protocols. 806 5.8.10 The QoS protocol should provide means to interact with key 807 management protocols 808 Key management protocols typically require a larger number of 809 messages to be transmitted to allow a session key and the 810 corresponding security association to be derived. To avoid the 811 complex issue of mapping individual authentication and key 812 management protocols to a QoS protocol such a protocol is outside 813 the scope of the QoS protocol. Although the key management protocol 814 may be independent there must be a way for the QoS protocol to 815 exploit existing security associations to avoid executing a separate 816 key management protocol (or instance of the same protocol) for 817 protocols that closely operate together. If no such security 818 association exists then there should be means for the QoS protocol 819 to trigger a key management protocol to dynamically create the 820 required security associations. 821 5.9 Mobility 822 TBD 823 5.10 Interworking with other protocols and techniques 824 Hooks must be provided to enable efficient interworking between 825 various protocols and techniques including: 826 5.10.1 Interworking with IP tunneling 827 IP tunneling for various applications must be supported. More 828 specifically tunneling for IPSec tunnels are of importance. This 829 mainly impacts the identification of flows. Additionally, care needs 830 to be taken using IPSec for signaling message. 831 5.10.2 The solution should not constrain either to IPv4 or IPv6 832 5.10.3 Independence from charging model 833 Signaling must not be constrained by charging models or the charging 834 infrastructure used. However, the end-system should be able to query 835 current pay statistics and to specify user cost functions. 836 5.10.4 The QoS protocol should provide hooks for AAA protocols 837 The security mechanism should be developed with respect to be able 838 to collect usage records from one or more network elements. 839 5.11 Operational 840 5.11.1 Ability to assign transport quality to signaling messages 841 The NSIS architecture should allow the network operator to assign 842 the NSIS protocol messages a certain transport quality. As signaling 843 opens up for possible denial-of-service attacks, this requirement 844 gives the network operator a mean, but also the obligation, to 845 trade-off between signaling latency and the impact (from the 846 signaling messages) on devices within his/her network. From protocol 847 design this requirement states that the protocol messages should be 848 detectable, at least where the control and assignment of the 849 messages priority is done. 850 6 The MUSTs, SHOULDs, and MAYs 851 In order to prioritize the various requirements from Section 5, we 852 define different 'parts of the network'. In the different parts of 853 the network a particular requirement might have a different 854 priority. 855 The parts of the networks we differentiate are the host-to-first 856 router, the access network, and the core network. The host to first 857 router part includes all the layer 2 technologies to access to the 858 Internet. In many cases, there is an application and/or user running 859 on the host initiating QoS signaling. The access network can be 860 characterized by low capacity links, meadium speed IP processing 861 capabilities, and it might consist of a complete layer 2 network as 862 well. The core network characteristics include high-speed forwarding 863 capacities and interdomain QoS issues. All of them are not strictly 864 defined and should not be regarded as that, but should give a 865 feeling about where in the network we have different requirements 866 concerning QoS signaling. 867 Note that the requirement titles are listed for better reading. 869 5.1 Architecture and Design Goals 870 5.1.1 Applicability for different QoS technologies. 871 5.1.2 Resource availability information on request 872 5.1.3 Modularity 873 5.1.4 Decoupling of protocol and information it is carrying 874 5.1.5 Reuse of existing QoS provisioning 875 5.1.6 Avoid duplication of [sub]domain signaling functions 876 5.1.7 Independence of signaling and provisioning paradigm 877 ----------------------+-------------+-------------+------------+ 878 | host-to-net | access | core | 879 ----------------------+-------------+-------------+------------+ 880 5.1.1 | | | | 881 ----------------------+-------------+-------------+------------+ 882 5.1.2 | | | | 883 ----------------------+-------------+-------------+------------+ 884 5.1.3 | | | | 885 ----------------------+-------------+-------------+------------+ 886 5.1.4 | | | | 887 ----------------------+-------------+-------------+------------+ 888 5.1.5 | | | | 889 ----------------------+-------------+-------------+------------+ 890 5.1.6 | | | | 891 ----------------------+-------------+-------------+------------+ 892 5.1.7 | | | | 893 ----------------------+-------------+-------------+------------+ 894 5.2 Signaling Flows 895 5.2.1 Free placement of QoS Initiator and QoS Controllers functions 896 5.2.2 No constraint of the QoS signaling and QoS Controllers to be 897 in the data path. 898 5.2.3 Concealment of topology and technology information 899 5.2.4 Optional transparency of QoS signaling to network 900 ----------------------+-------------+-------------+------------+ 901 | host-to-net | access | core | 902 ----------------------+-------------+-------------+------------+ 903 5.2.1 | | | | 904 ----------------------+-------------+-------------+------------+ 905 5.2.2 | | | | 906 ----------------------+-------------+-------------+------------+ 907 5.2.3 | | | | 908 ----------------------+-------------+-------------+------------+ 909 5.2.4 | | | | 910 ----------------------+-------------+-------------+------------+ 911 5.3 Additional information beyond signaling of QoS information 912 5.3.1 Explicit release of resources 913 5.3.2 Possibility for automatic release of resources after failure 914 5.3.3 Possibility for automatic re-setup of resources after recovery 915 5.3.4 Prompt notification of QoS violation in case of error / 916 failure to QoS Initiator and QoS Controllers 917 5.3.5 Feedback about success of request for QoS guarantees 918 ----------------------+-------------+-------------+------------+ 919 | host-to-net | access | core | 920 ----------------------+-------------+-------------+------------+ 921 5.3.1 | | | | 922 ----------------------+-------------+-------------+------------+ 923 5.3.2 | | | | 924 ----------------------+-------------+-------------+------------+ 925 5.3.3 | | | | 926 ----------------------+-------------+-------------+------------+ 927 5.3.4 | | | | 928 ----------------------+-------------+-------------+------------+ 929 5.3.5 | | | | 930 ----------------------+-------------+-------------+------------+ 931 5.4 Layering 932 5.4.1 The signaling protocol and QoS control information should be 933 application independent. 934 ----------------------+-------------+-------------+------------+ 935 | host-to-net | access | core | 936 ----------------------+-------------+-------------+------------+ 937 5.4.1 | | | | 938 ----------------------+-------------+-------------+------------+ 939 5.5 QoS Control Information 940 5.5.1 Mutability information on parameters 941 5.5.2 Possibility to add and remove local domain information 942 5.5.3 Independence of reservation identifier 943 5.5.4 Seamless modification of already reserved QoS 944 5.5.5 Signaling must support quantitative, qualitative, and relative 945 QoS specifications 946 ----------------------+-------------+-------------+------------+ 947 | host-to-net | access | core | 948 ----------------------+-------------+-------------+------------+ 949 5.5.1 | | | | 950 ----------------------+-------------+-------------+------------+ 951 5.5.2 | | | | 952 ----------------------+-------------+-------------+------------+ 953 5.5.3 | | | | 954 ----------------------+-------------+-------------+------------+ 955 5.5.4 | | | | 956 ----------------------+-------------+-------------+------------+ 957 5.5.5 | | | | 958 ----------------------+-------------+-------------+------------+ 959 5.6 Performance 960 5.6.1 Scalability in the number of messages received by a signaling 961 communication partner (QoS initiator and controller) 962 5.6.2 Scalability in number of hand-offs 963 5.6.3 Scalability in the number of interactions for setting up a 964 reservation 965 5.6.4 Scalability in the number of state per entity (QoS initiators 966 and QoS controllers) 967 5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 968 5.6.6 Low latency in setup 969 5.6.7 Allow for low bandwidth consumption for signaling protocol 970 5.6.8 Ability to constrain load on devices 971 ----------------------+-------------+-------------+------------+ 972 | host-to-net | access | core | 973 ----------------------+-------------+-------------+------------+ 974 5.6.1 | | | | 975 ----------------------+-------------+-------------+------------+ 976 5.6.2 | | | | 977 ----------------------+-------------+-------------+------------+ 978 5.6.3 | | | | 979 ----------------------+-------------+-------------+------------+ 980 5.6.4 | | | | 981 ----------------------+-------------+-------------+------------+ 982 5.6.5 | | | | 983 ----------------------+-------------+-------------+------------+ 984 5.6.6 | | | | 985 ----------------------+-------------+-------------+------------+ 986 5.6.7 | | | | 987 ----------------------+-------------+-------------+------------+ 988 5.6.8 | | | | 989 ----------------------+-------------+-------------+------------+ 990 5.7 Flexibility 991 5.7.1 Aggregation capability, including the capability to select and 992 change the level of aggregation. 993 5.7.2 Flexibility in the placement of the QoS initiator 994 5.7.3 Flexibility in the initiation of re-negotiation (QoS change 995 requests) 996 5.7.4 Uni / bi-directional reservation 997 ----------------------+-------------+-------------+------------+ 998 | host-to-net | access | core | 999 ----------------------+-------------+-------------+------------+ 1000 5.7.1 | | | | 1001 ----------------------+-------------+-------------+------------+ 1002 5.7.2 | | | | 1003 ----------------------+-------------+-------------+------------+ 1004 5.7.3 | | | | 1005 ----------------------+-------------+-------------+------------+ 1006 5.7.4 | | | | 1007 ----------------------+-------------+-------------+------------+ 1008 5.8 Security 1009 5.8.1 The QoS protocol must provide strong authentication 1010 5.8.2 The QoS protocol must provide means to authorize resource 1011 requests 1012 5.8.3 The QoS signaling messages must provide integrity protection. 1013 5.8.4 The QoS signaling messages must be replay protected. 1014 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. 1015 5.8.6 The QoS protocol should allow identity confidentiality and 1016 location privacy. 1017 5.8.7 The QoS protocol should prevent denial-of-service attacks 1018 against signaling entities. 1019 5.8.8 The QoS protocol should support confidentiality of signaling 1020 messages. 1021 5.8.9 The QoS protocol should provide hooks to interact with 1022 protocols that allow the negotiation of authentication and key 1023 management protocols. 1024 5.8.10 The QoS protocol should provide means to interact with key 1025 management protocols. 1026 ----------------------+-------------+-------------+------------+ 1027 | host-to-net | access | core | 1028 ----------------------+-------------+-------------+------------+ 1029 5.8.1 | | | | 1030 ----------------------+-------------+-------------+------------+ 1031 5.8.2 | | | | 1032 ----------------------+-------------+-------------+------------+ 1033 5.8.3 | | | | 1034 ----------------------+-------------+-------------+------------+ 1035 5.8.4 | | | | 1036 ----------------------+-------------+-------------+------------+ 1037 5.8.5 | | | | 1038 ----------------------+-------------+-------------+------------+ 1039 5.8.6 | | | | 1040 ----------------------+-------------+-------------+------------+ 1041 5.8.7 | | | | 1042 ----------------------+-------------+-------------+------------+ 1043 5.8.8 | | | | 1044 ----------------------+-------------+-------------+------------+ 1045 5.8.9 | | | | 1046 ----------------------+-------------+-------------+------------+ 1047 5.8.10 | | | | 1048 ----------------------+-------------+-------------+------------+ 1049 5.9 Mobility 1050 5.10 Interworking with other protocols and techniques 1051 5.10.1 Interworking with IP tunneling 1052 5.10.2 The solution should not constrain either to IPv4 or IPv6 1053 5.10.3 Independence from charging model 1054 5.10.4 The QoS protocol should provide hooks for AAA protocols 1055 ----------------------+-------------+-------------+------------+ 1056 | host-to-net | access | core | 1057 ----------------------+-------------+-------------+------------+ 1058 5.10.1 | | | | 1059 ----------------------+-------------+-------------+------------+ 1060 5.10.2 | | | | 1061 ----------------------+-------------+-------------+------------+ 1062 5.10.3 | | | | 1063 ----------------------+-------------+-------------+------------+ 1064 5.10.4 | | | | 1065 ----------------------+-------------+-------------+------------+ 1066 5.11 Operational 1067 5.11.1 Ability to assign transport quality to signaling messages 1068 ----------------------+-------------+-------------+------------+ 1069 | host-to-net | access | core | 1070 ----------------------+-------------+-------------+------------+ 1071 5.11.1 | | | | 1072 ----------------------+-------------+-------------+------------+ 1073 7 References 1074 [1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem 1075 Statement", RFC 3132, June 2001. 1076 [2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP", 1077 draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress, 1078 August 2001 1079 [3] Manner. J., et al, "Mobility Related Terminology", draft-manner- 1080 seamoby-terms-02.txt, Work In Progress, July 2001. 1081 [4] 3GPP, "General Packet Radio Service (GPRS); Service Description 1082 Stage 2 v 7.7.0", TS 03.60, June 2001 1083 [5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum 1084 System, revision B", S.R0005-B, May 2001 1085 [6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling 1086 BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001 1087 [7] Partain, D., et al, "Resource Reservation Issues in Cellular 1088 Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt, 1089 Work in Progress, June 2001. 1090 [8] YESSIR - YEt another Sender Session Internet Reservations, 1091 h 1092 ttp://www.cs.columbia.edupingpan/projects/yessir.htm 1094 l 1095 [9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1096 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1097 Specification", IETF RFC 2205, 1997. 1099 [10] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G., 1100 Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource 1101 Management in Diffserv Framework", Internet draft, work in progress, 1102 draft-westberg-rmd-framework-xx.txt, 2002. 1103 [11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA 1104 Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt, 1105 Work in progress, September 2001. 1106 8 Appendix: Scenarios/Use cases 1107 In the following we describe scenarios, which are important to 1108 cover, and which allow us to discuss various requirements. Some 1109 regard this as use cases to be covered defining the use of a QoS 1110 signaling protocol. 1111 8.1 Scenario: Terminal Mobility 1112 The scenario we are looking at is the case where a mobile terminal 1113 (MT) changes from one access point to another access point. The 1114 access points are located in separate QoS domains. We assume Mobile 1115 IP to handle mobility on the network layer in this scenario and 1116 consider the various extensions (i.e., IETF proposals) to Mobile IP, 1117 in order to provide 'fast handover' for roaming Mobile Terminals. 1118 The goal to be achieved lies in providing, keeping, and adapting the 1119 requested QoS for the ongoing IP sessions in case of handover. 1120 Furthermore, the negotiation of QoS parameters with the new domain 1121 via the old connection might be needed, in order to support the 1122 different 'fast handover' proposals within the IETF. 1123 The entities involved in this scenario include a mobile terminal, 1124 access points, an access network manager, communication partners of 1125 the MT (the other end(s) of the communication association). 1126 From a technical point of view, terminal mobility means changing the 1127 access point of a mobile terminal (MT). However, technologies might 1128 change in various directions (access technology, QoS technology, 1129 administrative domain). If the access points are within one specific 1130 QoS technology (independent of access technology) we call this 1131 intra-QoS technology handoff. In the case of an inter-QoS technology 1132 handoff, one changes from e.g. a DiffServ to an IntServ domain, 1133 however still using the same access technology. Finally, if the 1134 access points are using different access technologies we call it 1135 inter-technology hand-off. 1136 The following issues are of special importance in this scenario: 1137 1) Handoff decision 1138 - The QoS management requests handoff. The QoS management can decide 1139 to change the access point, since the traffic conditions of the new 1140 access point are better supporting the QoS requirements. The metric 1141 may be different (optimized towards a single or a group/class of 1142 users). Note that the MT or the network (see below) might trigger 1143 the handoff. 1144 - The mobility management forces handoff. This can have several 1145 reasons. The operator optimizes his network, admission is no longer 1146 granted (e.g. emptied prepaid condition). Or another example is when 1147 the MT is reaching the focus of another base station. However, this 1148 might be detected via measurements of QoS on the physical layer and 1149 is therefore out of scope of QoS signaling in IP. Note again that 1150 the MT or the network (see below) might trigger the handoff. 1151 - This scenario shows that local decisions might not be enough. The 1152 rest of the path to the other end of the communication needs to be 1153 considered as well. Hand-off decisions in a QoS domain, does not 1154 only depend on the local resource availability, e.g., the wireless 1155 part, but involves the rest of the path as well. Additionally, 1156 decomposition of an end-to-end reservation might be needed, in order 1157 to change only parts of it. 1158 2) Trigger sources 1159 - Mobile terminal: If the end-system QoS management identifies 1160 another (better-suited) access point, it will request the handoff 1161 from the terminal itself. This will be especially likely in the case 1162 that two different provider networks are involved. Another important 1163 example is when the current access point bearer disappears (e.g. 1164 removing the Ethernet cable). In this case, the QoS initiator is 1165 basically located on the mobile terminal. 1166 - Network (access network manager): Sometimes, the handoff trigger 1167 will be issued from the network management to optimize the overall 1168 load situation. Most likely this will result in changing the base- 1169 station of a single providers network. Most likely the QoS initiator 1170 is located on a system within the network. 1171 3) Integration with other protocols 1172 - Interworking with other protocol must be considered in one or the 1173 other form. E.g., it might be worth combining QoS signaling between 1174 different QoS domains with mobility signaling at hand-over. 1175 4) Handover rates 1176 In mobile networks, the admission control process has to cope with 1177 far more admission requests than call setups alone would generate. 1178 For example, in the GSM (Global System for Mobile communications) 1179 case, mobility usually generates an average of one to two handovers 1180 per call. For third generation networks (such as UMTS), where it is 1181 necessary to keep radio links to several cells simultaneously 1182 (macro-diversity), the handover rate is significantly higher (see 1183 for example [11]) 1184 5) Fast reservations 1185 Handover can also cause packet losses. This happens when the 1186 processing of an admission request causes a delayed handover to the 1187 new base station. In this situation, some packets might be 1188 discarded, and the overall speech quality might be degraded 1189 significantly. Moreover, a delay in handover may cause degradation 1190 for other users. In the worst case scenario, a delay in handover may 1191 cause the connection to be dropped if the handover occurred due to 1192 bad air link quality. Therefore, it is critical that QoS signalling 1193 in connection with handover be carried out very quickly. 1194 6) Call blocking in case of overload 1195 Furthermore, when the network is overloaded, it is preferable to 1196 keep reservations for previously established flows while blocking 1197 new requests. Therefore, the resource reservation requests in 1198 connection with handover should be given higher priority than new 1199 requests for resource reservation. 1200 8.2 Scenario: Cellular Networks 1201 In this scenario, the user is using the packet service of a 3rd 1202 generation cellular system, e.g. UMTS. The region between the End 1203 Host and the edge node connecting the cellular network to another 1204 QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is 1205 considered to be a single QoS domain [4][5]. 1206 The issues in such an environment regarding QoS include: 1207 1) Cellular systems provide their own QoS technology with 1208 specialized parameters to co-ordinate the QoS provided by both the 1209 radio access and wired access network. For example, in a UMTS 1210 network, one aspect of GPRS is that it can be considered as a QoS 1211 technology; provisioning of QoS within GPRS is described mainly in 1212 terms of calling UMTS bearer classes. This QoS technology needs to 1213 be invoked with suitable parameters when a request for QoS is 1214 triggered by higher layers, and this therefore involves mapping the 1215 requested IP QoS onto these UMTS bearer classes. This request for 1216 resources might be triggered by IP signaling messages that pass 1217 across the cellular system, and possibly other QoS domains, to 1218 negotiate for network resources. Typically, cellular system specific 1219 messages invoke the underlying cellular system QoS technology in 1220 parallel with the IP QoS negotiation, to allocate the resources 1221 within the cellular system. 1222 2) The placement of QoS initiators and QoS controllers (terminology 1223 in the framework given here). The QoS initiator could be located at 1224 the End Host (triggered by applications), the GGSN/PDSN, or at a 1225 node not directly on the data path, such as a bandwidth broker. In 1226 the second case, the GGSN/PDSN could either be acting as a proxy on 1227 behalf of an End Host with little capabilities, and/or managing 1228 aggregate resources within its QoS domain (the UMTS core network). 1229 The IP signaling messages are interpreted by the QoS controllers, 1230 which may be located at the GGSN/PDSN, and in any QoS sub-domains 1231 within the cellular system. 1233 3) Initiation of IP-level QoS negotiation. IP-level QoS re- 1234 negotiation may be initiated by either the End Host, or by the 1235 network, based on current network loads, which might change 1236 depending on the location of the end host. 1237 4) The networks are designed and mainly used for speech 1238 communication (at least so far). 1239 Note that in comparison to the former scenario, the emphasis is much 1240 less on the mobility aspects, because mobility is mainly handled on 1241 the lower layer. 1242 8.3 Scenario: UMTS access 1243 The UMTS access scenario is shown in figure 3. The Proxy-Call State 1244 Control Function/Policy Control Function (P-CSCF/PCF) is the 1245 outbound SIP proxy of the visited domain, i.e. the domain where the 1246 mobile user wants to set-up a call. The Gateway GPRS Support Node 1247 (GGSN) is the egress router of the UMTS domain and connects the UMTS 1248 access network to the Edge Router (ER) of the core IP network. The 1249 P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The 1250 User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal 1251 Equipment (TE), e.g. a laptop. 1252 +--------+ 1253 +----------| P-CSCF |-------> SIP signaling 1254 / +--------+ 1255 / SIP : 1256 : +--------+ NSIS +----------------+ 1257 : | PCF |---------| QoS Controller | 1258 : +--------+ +----------------+ 1259 : : 1260 : : COPS 1261 : : 1262 +----+ +--------+ +----+ 1263 | UE |----------| GGSN |------| ER | 1264 +----+ +--------+ +----+ 1265 Figure 1: UMTS access scenario 1266 In this scenario the GGSN has the role of Access Gate. According to 1267 3GPP standardization, the PCF is responsible for the policy-based 1268 control of the end-user service in the UMTS access network (i.e. 1269 from UE to GGSN). In the current UMTS release R.5, the PCF is part 1270 of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF 1271 may evolve to an open standardized interface. In any case the PCF 1272 has all required QoS information for per-flow admission control in 1273 the UMTS access network (which it gets from the P-CSCF and/or GGSN). 1274 Thus the PCF would be the appropriate entity to host the 1275 functionality of QI, initiating the "NSIS" QoS signaling towards the 1276 core IP network. The PCF/P-CSCF has to do the mapping from codec 1277 type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP 1278 extensions to explicitly signal QoS information [7] are useful to 1279 avoid the need to store codec information in the PCF and to allow 1280 for more flexibility and accurate description of the QoS traffic 1281 parameters. The PCF also controls the GGSN to open and close the 1282 gates and to configure per-flow policers, i.e. to authorize or 1283 forbid user traffic. 1284 The QC is (of course) not part of the standard UMTS architecture. 1285 However, to achieve end-to-end QoS a QC is needed such that the PCF 1286 can request a QoS connection to the IP network. As in the previous 1287 example, the QC could manage a set of pre-provisioned resources in 1288 the IP network, i.e. bandwidth pipes, and the QC performs per-flow 1289 admission control into these pipes. In this way, a connection can be 1290 made between two UMTS access networks, and hence, end-to-end QoS can 1291 be achieved. In this case the QI and QC are clearly two separate 1292 entities. 1293 This use case clearly illustrates the need for an "NSIS" QoS 1294 signaling protocol between QI and QC. An important application of 1295 such a protocol may be its use in the inter-connection of UMTS 1296 networks over an IP backbone. 1297 8.4 Wired part of wireless network 1298 A wireless network, seen from a QoS domain perspective, usually 1299 consists of three parts: a wireless interface part (the "radio 1300 interface"), a wired part of the wireless network (i.e., Radio 1301 Access Network) and the backbone of the wireless network, as shown 1302 in Figure 2. Note that this figure should not be seen as an 1303 architectural overview of wireless networks but rather as showing 1304 the conceptual QoS domains in a wireless network. 1305 In this scenario, a mobile host can roam and perform a handover 1306 procedure between base stations/access routers. In this scenario the 1307 NSIS QoS protocol can be applied between a base station and the 1308 gateway (GW). In this case a GW can also be considered as a local 1309 handover anchor point. Furthermore, in this scenario the NSIS QoS 1310 protocol can also be applied either between two GWs, or between two 1311 edge routers (ER). 1312 |--| 1313 |GW| 1314 |--| |--| 1315 |MH|--- . 1316 |--| / |-------| . 1317 /--|base | |--| . 1318 |station|-|ER|.... 1319 |-------| |--| . |--| back- |--| |---| 1320 |----| 1321 ...|ER|.......|ER|..|BGW|.."Internet"..|host| 1322 -- |-------| |--| . |--| bone |--| |---| 1323 |----| 1324 |--| \ |base |-|ER|... . 1325 |MH| \ |station| |--| . 1327 |--|--- |-------| . MH = mobile host 1328 |--| ER = edge router 1329 <----> |GW| GW = gateway 1330 Wireless link |--| BGW = border gateway 1331 ... = interior nodes 1332 <-------------------> 1333 Wired part of wireless network 1334 <----------------------------------------> 1335 Wireless Network 1336 Figure 2. QoS architecture of wired part of wireless network 1337 Each of these parts of the wireless network impose different issues 1338 to be solved on the QoS signaling solution being used: 1339 * Wireless interface: The solution for the air interface link 1340 has to ensure flexibility and spectrum efficient transmission 1341 of IP packets. However, this link layer QoS can be solved in 1342 the same way as any other last hop problem by allowing a 1343 host to request the proper QoS profile. 1344 * Wired part of the wireless network: This is the part of 1345 the network that is closest to the base stations/access 1346 routers. It is an IP network although some parts logically 1347 perform tunneling of the end user data. In cellular networks, 1348 the wired part of the wireless network is denoted as a 1349 radio access network. 1350 This part of the wireless network has different 1351 characteristics when compared to traditional IP networks: 1352 1. The network supports a high proportion of real-time 1353 traffic. The majority of the traffic transported in the 1354 wired part of the wireless network is speech, which is 1355 very sensitive to delays and delay variation (jitter). 1356 2. The network must support mobility. Many wireless 1357 networks are able to provide a combination of soft 1358 and hard handover procedures. When handover occurs, 1359 reservations need to be established on new paths. 1360 The establishment time has to be as short as possible 1361 since long establishment times for reservations degrade 1362 the performance of the wireless network. Moreover, 1363 for maximal utilization of the radio spectrum, frequent 1364 handover operations are required. 1365 3. These links are typically rather bandwidth-limited. 1366 4. The wired transmission in such a network contains a 1367 relatively high volume of expensive leased lines. 1368 Overprovisioning might therefore be prohibitively 1369 expensive. 1371 5. The radio base stations are spread over a wide 1372 geographical area and are in general situated a large 1373 distance from the backbone. 1374 * Backbone of the wireless network: the requirements imposed 1375 by this network are similar to the requirements imposed by 1376 other types of backbone networks. 1377 Due to these very different characteristics and requirements, often 1378 contradictory, different QoS signalling solutions might be needed in 1379 each of the three network parts. 1380 8.5 Scenario: Session Mobility 1381 In this scenario, a session is moved from one end-system to another. 1382 Ongoing sessions are kept and QoS parameters need to be adapted, 1383 since it is very likely that the new device provides different 1384 capabilities. Note that it is open which entity initiates the move, 1385 which implies that the QoS initiator might be triggered by different 1386 entities. 1387 User mobility (i.e., a user changing the device and therefore moving 1388 the sessions to the new device) is considered to be a special case 1389 within the session mobility scenario. 1390 Note that this scenario is different from terminal mobility. Not the 1391 terminal (end-system) has moved to a different access point. Both 1392 terminals are still connected to an IP network at their original 1393 points. 1394 The issues include: 1395 1) Keeping the QoS guarantees negotiated implies that the end- 1396 point(s) of communication are changed without changing the 1397 reservations. 1398 2) The trigger of the session move might be the user or any other 1399 party involved in the session. 1400 8.6 Scenario: QoS reservations/negotiation from access to core network 1401 The scenario includes the signaling between access networks and core 1402 networks in order to setup and change reservations together with 1403 potential negotiation. 1404 The issues to be solved in this scenario are different from previous 1405 ones. 1406 1) The entity of reservation is most likely an aggregate. 1407 2) The time scales of reservations might be different (long living 1408 reservations of aggregates, rarer re-negotiation). 1410 3) The specification of the traffic (amount of traffic), a 1411 particular QoS is guaranteed for, needs to be changed. E.g., in case 1412 additional flows are added to the aggregate, the traffic 1413 specification of the flow needs to be added if it is not already 1414 included in the aggregates specification. 1415 4) The flow specification is more complex including network 1416 addresses and sets of different address for the source as well as 1417 for the destination of the flow. 1418 8.7 Scenario: QoS reservation/negotiation over administrative 1419 boundaries 1420 Signaling between two or more core networks to provide QoS is 1421 handled in this scenario. This might also include access to core 1422 signaling over administrative boundaries. Compared to the previous 1423 one it adds the case, where the two networks are not in the same 1424 administrative domain. Basically, it is the inter-domain/inter 1425 provider signaling which is handled in here. 1426 The domain boundary is the critical issue to be resolved. Which as 1427 various flavors of issues a QoS signaling protocol has to be 1428 concerned with. 1429 1) Competing administrations: Normally, only basic information 1430 should be exchanged, if the signaling is between competing 1431 administrations. Specifically information about core network 1432 internals (e.g., topology, technology, etc.) should not be 1433 exchanged. Some information exchange about the "access points" of 1434 the core networks (which is topology information as well) may need 1435 to be exchanged, because it is needed for proper signaling. 1436 2) Additionally, as in scenario 4, signaling most likely is based on 1437 aggregates, with all the issues raise there. 1438 3) Authorization: It is critical that the QoS initiator is 1439 authorized to perform a QoS path setup. 1440 4) Accountability: It is important to notice that signaling might be 1441 used as an entity to charge money for, therefore the interoperation 1442 with accounting needs to be available. 1443 8.8 Scenario: QoS signaling between PSTN gateways and backbone routers 1444 A PSTN gateway (i.e., host) requires information from the network 1445 regarding its ability to transport voice traffic across the network. 1446 The voice quality will suffer due to packet loss, latency and 1447 jitter. Signaling is used to identify and admit a flow for which 1448 these impairments are minimized. In addition, the disposition of 1449 the signaling request is used to allow the PSTN GW to make a call 1450 routing decision before the call is actually accepted and delivered 1451 to the final destination. 1453 PSTN gateways may handle thousands of calls simultaneously and there 1454 may be hundreds of PSTN gateways in a single provider network. These 1455 numbers are likely to increase as the size of the network increases. 1456 The point being that scalability is a major issue. 1457 There are several ways that a PSTN gateway can acquire assurances 1458 that a network can carry its traffic across the network. These 1459 include: 1460 1. Over-provisioning a high availability network. 1461 2. Handling admission control through some policy server 1462 that has a global view of the network and its resources. 1463 3. Per PSTN GW pair admission control. 1464 4. Per call admission control (where a call is defined as 1465 the 5 tuple used to carry a single RTP flow). 1466 Item 1 requires no signaling at all and is therefore outside the 1467 scope of this working group. 1468 Item 2 is really a better informed version of 1, but it is also 1469 outside the scope of this working group as it relies on a particular 1470 telephony signaling protocol rather than a packet admission control 1471 protocol. 1472 Item 3 is initially attractive as it appears to have reasonable 1473 scaling properties, however, its scaling properties only are 1474 effective in cases where there are relatively few PSTN GWs. In the 1475 more general case were a PSTN GW reduces to a single IP phone 1476 sitting behind some access network, the opportunities for 1477 aggregation are reduced and the problem reduces to item 4. 1478 Item 4 is the most general case. However, it has the most difficult 1479 scaling problems. The objective here is to place the requirements on 1480 Item 4 such that a scalable per-flow admission control protocol or 1481 protocol suite may be developed. 1482 The case where per-flow signaling extends to individual IP end- 1483 points allows the inclusion of IP phones on cable, DSL, wireless or 1484 other access networks in this scenario. 1485 Call Scenario 1486 A PSTN GW signals end-to-end for some 5 tuple defined flow a 1487 bandwidth and QoS requirement. Note that the 5 tuple might include 1488 masking/wildcarding. The access network admits this flow according 1489 to its local policy and the specific details of the access 1490 technology. 1491 At the edge router (i.e., border node), the flow is admitted, again 1492 with an optional authentication process, possibly involving an 1493 external policy server. Note that the relationship between the PSTN 1494 GW and the policy server and the routers and the policy server is 1495 outside the scope of NSIS. The edge router then admits the flow into 1496 the core of the network, possibly using some aggregation technique. 1498 At the interior nodes, the NSIS host-to-host signaling should either 1499 be ignored or invisible as the Edge router performed the admission 1500 control decision to some aggregate. 1501 At the inter-provider router (i.e., border node), again the NSIS 1502 host-to-host signaling should either be ignored or invisible as the 1503 Edge router has performed an admission control decision about an 1504 aggregate across a carrier network. 1505 8.9 PSTN trunking gateway 1506 One of the use cases for the NSIS signaling protocol is the scenario 1507 of interconnecting PSTN gateways with an IP network that supports 1508 QoS. 1509 Four different scenarios are considered here. 1510 1. 1511 In-band QoS signaling is used. In this case the Media Gateway 1512 (MG) will be acting as the QoS Initiator and the Edge Router 1513 (ER) will be the QoS Controller. Hence, the ER should do 1514 admission control (into pre-provisioned traffic trunks) for the 1515 individual traffic flows. This scenario is not further 1516 considered here. 1517 2. 1518 Out-of-band signaling in a single domain, the QoS Controller is 1519 integrated in the MGC. In this case no NSIS protocol is 1520 required. 1521 3. 1522 Out-of-band signaling in a single domain, the QoS Controller is 1523 a separate box. In this case NSIS signaling is used between the 1524 MGC and the QoS Controller. 1525 4. 1526 Out-of-band signaling between multiple domains, the QoS 1527 Controller (which may be integrated in the MGC) triggers the 1528 QoS Controller of the next domain. 1529 When the out-of-band QoS signaling is used the Media Gateway 1530 Controller (MGC) will be acting as the QoS Initiator. 1531 In the second scenario the voice provider manages a set of traffic 1532 trunks that are leased from a network provider. The MGC does the 1533 admission control in this case. Since the QoS Controller acts both 1534 as a QoS Initiator and a QoS Controller, no NSIS signaling is 1535 required. This scenario is shown in figure 1. 1536 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1537 | SS7 network |---------------------| MGC |--------------| SS7 | 1538 +-------------+ +-------+-----+---------+ +-----+ 1539 : / : \ 1540 : / : \ 1541 : / +--------:----------+ \ 1542 : MEGACO / / : \ \ 1543 : / / +-----+ \ \ 1544 : / / | NMS | \ \ 1545 : / | +-----+ | \ 1546 : : | | : 1547 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1548 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1549 +--------------+ +----+ \ / +----+ 1550 \ QoS network / 1551 +-------------------+ 1552 Figure 1: PSTN trunking gateway scenario 1553 In the third scenario, the voice provider does not lease traffic 1554 trunks in the network. Another entity may lease traffic trunks and 1555 may use a QoS Controller to do per-flow admission control. In this 1556 case the NSIS signaling is used between the MGC and the QoS 1557 Controller, which is a separate box here. Hence, the MGC acts only 1558 as a QoS Initiator. This scenario is depicted in figure 2. 1559 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1560 | SS7 network |---------------------| MGC |--------------| SS7 | 1561 +-------------+ +-------+-----+---------+ +-----+ 1562 : / : \ 1563 : / +-----+ \ 1564 : / | QC | \ 1565 : / +-----+ \ 1566 : / : \ 1567 : / +--------:----------+ \ 1568 : MEGACO : / : \ : 1569 : : / +-----+ \ : 1570 : : / | NMS | \ : 1571 : : | +-----+ | : 1572 : : | | : 1573 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1574 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1575 +--------------+ +----+ \ / +----+ 1576 \ QoS network / 1577 +-------------------+ 1578 Figure 2: PSTN trunking gateway scenario 1579 In the fourth scenario multiple transport domains are involved. In 1580 the originating network either the MGC may have an overview on the 1581 resources of the overlay network or a separate QoS Controller will 1582 have the overview. Hence, depending on this either the MGC or the 1583 QoS Controller of the originating domain will contact the QoS 1584 Controller of the next domain. The MGC always acts as a QoS 1585 Initiator and may also be acting as a QoS Controller in the first 1586 domain. 1587 8.10 Scenario: Application request end-to-end QoS path from the 1588 network 1589 This is actually the most easy case, nevertheless might be most 1590 often used in terms of number of users. So multimedia application 1591 requests a guaranteed service from an IP network. We assume here 1592 that the application is somehow able to specify the network service. 1593 The characteristics here are that many hosts might do it, but that 1594 the requested service is low capacity (bounded by the access line). 1596 Additionally, we assume no mobility and standard devices. 1597 9 Acknowledgments 1598 Quite a number of people have been involved in the discussion of the 1599 draft, adding some ideas, requirements, etc. We list them without a 1600 guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul 1601 (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas 1602 Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), 1603 Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 1604 University Berlin), Xiaoming Fu (Technical University Berlin), Hans- 1605 Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph 1606 Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya 1607 Freytsis. 1608 Some text and/or ideas for text, requirements, scenarios have been 1609 taken from a draft written by the following authors: David Partain 1610 (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), 1611 Georgios Karagiannis (Ericsson), Jukka Manner (University of 1612 Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 1613 Westberg (Ericsson), Haihong Zheng (Nokia). 1614 10 Author's Addresses 1615 Marcus Brunner (Editor) 1616 NEC Europe Ltd. 1617 Network Laboratories 1618 Adenauerplatz 6 1619 D-69115 Heidelberg 1620 Germany 1621 E-Mail: brunner@ccrle.nec.de (contact) 1622 Robert Hancock, Eleanor Hepworth 1623 Roke Manor Research Ltd 1624 Romsey, Hants, SO51 0ZN 1625 United Kingdom 1626 E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk 1627 Cornelia Kappler 1628 Siemens AG 1629 Berlin 13623 1630 Germany 1631 E-Mail: cornelia.kappler@icn.siemens.de 1632 Hannes Tschofenig 1633 Siemens AG 1634 Otto-Hahn-Ring 6 1635 81739 Munchen 1636 Germany 1637 Email: Hannes.Tschofenig@mchp.siemens.de 1638 Full Copyright Statement 1639 Copyright (C) The Internet Society (2000). All Rights Reserved. 1641 This document and translations of it may be copied and furnished to 1642 others, and derivative works that comment on or otherwise explain it 1643 or assist in its implementation may be prepared, copied, published 1644 and distributed, in whole or in part, without restriction of any 1645 kind, provided that the above copyright notice and this paragraph are 1646 included on all such copies and derivative works. However, this 1647 document itself may not be modified in any way, such as by removing 1648 the copyright notice or references to the Internet Society or other 1649 Internet organizations, except as needed for the purpose of 1650 developing Internet standards in which case the procedures for 1651 copyrights defined in the Internet Standards process must be 1652 followed, or as required to translate it into languages other than 1653 English. 1654 The limited permissions granted above are perpetual and will not be 1655 revoked by the Internet Society or its successors or assigns. 1656 This document and the information contained herein is provided on an 1657 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1658 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 1659 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1660 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1661 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1662 Open Issues/To Dos 1663 1) (OPEN) add Scenarios 1664 Do we need to add, remove, or change the scenarios? 1665 - added scenario on QoS signalling between PSTN gateways and 1666 backbone routers 1667 - added: Application request end-to-end QoS path from the network 1668 We can what ever scenario we want. The more the better to understand 1669 the issues. Nevertheless, we have to take care that we are future 1670 prove as well. 1671 2) (OPEN) Sender/receiver initiation 1672 What is the requirement concerning data sender or data receiver or 1673 both to initiate a QoS request. 1674 - does it matter who pays? 1675 - terminology text added 1676 open issue, what is a potential req (currently we say "both must be 1677 possible") 1678 3) (CLOSED) Draft organization 1679 The proposed changes include 1680 - put all the scenarios into an appendix 1681 - In Section 6 add text describing 3 different "parts of the 1682 network" 1683 -Host to first hop 1684 -access network 1685 -core networks 1686 better names are welcome, but I don't want to be religious about 1687 it 1688 - Prioritize the requirements according to the "parts of the 1689 network" (This means the the tables in Section 6 of the current 1690 draft will get three colums with the MUST, SHOULDs, and MAYs for 1691 each requirement 1692 4) (OPEN) MUSTs, SHOULDs, MAY needs discussion 1693 5) (CLOSED) Framework text. 1694 The figures have been removed, because they seamed to be misleading. 1695 the text has been revisited. I regard the issue closed until we have 1696 a clear picture about what the NSIS framework draft is about. 1697 6) (CLOSED) The requirement organization 1698 I heard some voices on the list that the grouping should be more 1699 along the lines of host-to-edge, edge to edge etc. 1700 So far I have not changed it, because I though that the requirements 1701 heavily depend on the scenario we are looking at. 1702 closed, by the change in the draft organisation (issue 3) 1703 7) (OPEN) Hemant Chaskar: Section 3.1, items 1) Handoff decision and 1704 2) Trigger sources: The handoff decision and trigger sources should 1705 be out of scope of NSIS. NSIS should rather focus only on 1706 "establishing" QoS along the packet path after handoff. 1707 needs more WG discussion, potentially even cross-WG 1708 8) (OPEN) bi-directional data path setup with one QoS request 1709 I have not seen consensus on whether to require bi-directional data 1710 path setup with QoS. 1711 - How can we actually perform bi-directional reservations when the 1712 forward and reverse paths are not reciprocal, with respect to 1713 routing topology and routing policy of network domains between 1714 sender and receiver? 1715 - The need to ensure that the return path is the same as the 1716 forwarding path is one of the problems with RSVP, particularly in a 1717 mobile environment. 1718 9) (CLOSED) Potential requirement: must be implementable in user 1719 space (on end hosts) 1720 has not been included in the req list because it seams to be 1721 implementation specific. 1722 10) (CLOSED) Potential requirement: must provide support for 1723 globally defined services as well as private services (Ruediger) 1724 replaced by issue 17 and 18, closed 1725 11) (CLOSED) Potential requirement: Flexibility in the granularity 1726 of reservation (I don't remember who brought it up, but I assume it 1727 refers to the flexibility in terms of what size the flow has. Where 1728 size can be bandwidth etc.) 1729 The assumption that QoS classes as well as service definitions are 1730 out of scope for this draft, also the flexibility is. 1731 12) (CLOSED) text replacing scalability reqs 1732 "The nsis architecture should give the ability to constrain the load 1733 (CPU load, memory space, signaling bandwidth consumption and 1734 signaling intensity) on devices where it is needed. This can be 1735 achieved by many different methods, for example message aggregation, 1736 by ignoring signaling message, header compression or minimizing 1737 functionality. The architecture may choose any of these methods as 1738 long as the requirement is met." 1739 Editor: added the above text, but did not remove scalability reqs 1740 13) (CLOSED) add operator req "Ability to assign transport quality 1741 to signaling messages" 1742 "The nsis architecture should allow the network operator to assign 1743 the nsis protocol messages a certain transport quality. As signaling 1744 opens up for possible denial-of-service attacks, this requirement 1745 gives the network operator a mean, but also the obligation, to 1746 trade-off between signaling latency and the impact (from the 1747 signaling messages) on devices within his/her network. From protocol 1748 design this requirement states that the protocol messages should be 1749 detectable, at least where the control and assignment of the 1750 messages priority is done." 1751 text has been added 1752 14) (OPEN, dependend on resolution of bi-directional) proposal to 1753 add "support grouping of microflows (possibly only for feedback)" 1754 "As a consequence of the optimization for the interactive multimedia 1755 services, the signaling should allow one unique request for several 1756 micro flows having the same origination and destination IP 1757 addresses. This is usually the case for multimedia SIP calls where 1758 the voice and video micro flows follow the same path. This grouping 1759 of requests allows optimization of the QoS processing. Note that 1760 this may be detrimental for the call setup time. The use of grouping 1761 for microflows may be restricted to teardown and/or notification 1762 messages when call setup time is a concern." 1763 open issue: first resolve the bi-directional issue which is somewhat 1764 related, because it seams to be an optimization as well 1765 15) (CLOSED) Support for preemption of sessions 1766 -might play into the fault/ error handling case 1767 -is regarded as service-specific, whether existing sessions can be 1768 pre-empted 1769 Conclusion: it is network policy to determine how to do pre-emption, 1770 not a protocol issue. 1771 16) (OPEN) Req: 5.1.9 change provisioning into better term, since 1772 different people understand different thing with provisioning 1773 open action for Anders 1774 17) (CLOSED) add assumption that QoS classes/service definitions are 1775 already known to all the parties involved in signaling before hand 1776 (before a signalling session even starts 1777 added text in Section 4.1 1778 18) (CLOSED) add exclusion of methods, protocols, and ways to 1779 express QoS 1780 Even so, this might be covered by saying that we are independent of 1781 QoS classes and service description etc. (see issue 17), I added two 1782 points to the exclusion Section 4.2. 1783 Implications: issue 20, 23, 1784 19) (CLOSED) remove req 5.2.5 IP fragmentation 1785 20) (CLOSED) remove req 5.3.2 Ability to signal life-time of a 1786 reservation 1787 is regarded service-specific therefore part of the service 1788 description 1789 added some reservation life time text service description assumption 1790 text and removed the req 1791 21) (CLOSED) remove req 5.5.4 Aggregation method specification 1792 Concerns 1793 -QI not able to know the impact of aggregation 1794 -to far down the implementation/ service definition road 1795 -leave it to the provider how a service is realized 1796 removed 1797 22) (CLOSED) remove 5.3.7 Automatic notification on available 1798 resources not been granted before 1799 regarded to complex and is heavily dependend on the service 1800 description 1801 removed 1802 23) (CLOSED) remove 5.5.3 Simple mapping to lower-layer QoS 1803 provisioning parameters 1804 this heavily depends on service definition and therefore is out of 1805 scope of this document 1806 removed 1807 24) (CLOSED) Replacing req 5.3.6 "Feedback about the actually 1808 received level of QoS guarantees" with two requirements: 1) the 1809 feedback of a request MUST include yes and no (MUST respond yes or 1810 no) 2) in case of no it MAY include an opaque service-specific 1811 information about what would be possible 1812 It is still only one requirement, but the text has been replaced. 1813 25) (CLOSED) remove req 5.10.3 Combination with Mobility management 1814 However the integration should not be a priori excluded, there is 1815 explicitly no statemant about independence of mobility management. 1816 There is more discussion for the mobility case needed anyway. 1817 26) (OPEN) interaction of NSIS with seamoby (context transfer and 1818 CAR discovery) 1819 27) (CLOSED) remove req 5.5.10 QoS conformance specification 1820 Motivation: this heavily depends on the service definition and is 1821 therefore out of scope 1822 removed 1823 28) (OPEN) new requirement on "asynchronous events from the network" 1824 The content of the message might be very service specific, but the 1825 protocol support for asynchronous events from the network might be a 1826 valuable requirement. 1827 29) (OPEN) NSIS in case of handovers 1828 30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in 1829 various dimensions) 1830 removed because it seams to be obvious 1831 31) (CLOSED) remove 5.1.8 Possibility to use the signaling protocol 1832 for existing local technologies 1833 It is contradictory to 5.1.9 and the intention behind the 1834 requirement is covered by the requierement that the QoS controller 1835 can be placed wherever needed. 1836 32) (CLOSED) add assumption: there are means for discovery of nsis 1837 entities in order to know the signaling peers (solutions include 1838 static configuration, or automatically discovered etc.) 1839 33) (OPEN) add req " highest possible network utilization" 1840 "There are networking environments that require high network 1841 utilization for various reasons, and the signaling protocol should 1842 to its best ability support high resource utilization while 1843 maintaining appropriate QoS. 1844 In networks where resources are very expensive (as is the case for 1845 many wireless networks), efficient network utilization is of 1846 critical financial importance. On the other hand there are other 1847 parts of the network where high utilization is not required. 1848 " 1849 34) (OPEN)_difference between "UMTS access scenario" "cellular 1850 network scenario", and "Wired part of wireless network" (Section 1851 8.2, 8.3, and 8.4) 1852 currently all three are included 1853 what are the essential issues? 1854 35) (OPEN) difference between the two PSTN gateway scenarios 1855 (Section 8.8 and 8.9) 1856 currently both are included 1857 what are the essential issues? 1858 36) req "Independence of reservation identifier" 1859 issue here is that this might only be valuable in mobile 1860 environments, and complicate the protocol for other environemnts. 1861 there related issues (37,38, 1862 37) ownership of a reservation 1863 The issue here is that a known party owns reservations done in the 1864 network. (which might include that the party also pays). The 1865 question arose who is allowed to tear-down, receive asynchronous 1866 notifications in case of network initiated tear-down, etc. 1867 This also relates to how certain service granted is 1868 named/identified. 1869 38) (OPEN) definition of security threats 1870 39) (OPEN) simplify security requirements section 1871 40) (OPEN) add mobility related requirements 1872 41) (CLOSED) remove req 5.5.1 Mutability information on parameters 1873 removed because it is service-specific 1874 42) (OPEN) add an assumption that QoS nmonitoring is application- 1875 specific and with it out of scope of the WG 1876 43) (OPEN) asynchronous notification of QoS Initiator, Controller, 1877 Receiver, there are security issues related. Basically, an ownership 1878 issue. Nevertheless, an asynch notifcation in case of an error, 1879 network failure etc. is specifically in areas, where longer lived 1880 sessions are setup, essential in order to notify upper layes 1881 (appluications etc. as well. 1882 44) (OPEN) req 5.1.2 resource availability info on request come back 1883 to it as soon as we have a more clear idea about service description 1884 issue 1885 45) (OPEN) 5.3.4 Possibility for automatic re-setup of resources 1886 after recovery 1887 - more thoughts in failure conditions potentially 1888 - better text 1889 - operation under overload 1890 plays into issue 46) 1891 46) (OPEN) we need multiple scenario for failure and recovery cases 1892 to derive requirements. Or a list failre cases might be a start as 1893 well. 1894 47) (OPEN) traffic engineering and route pinning 1895 I assume this would result in operational type of requirements 1896 Opinions on that? 1897 48) (CLOSED) req 5.5.5 remove Multiple levels of detail 1898 "The QSC should allow for multiple levels of detail in description. 1899 (Motivation: someone interpreting the request can tune its own level 1900 of complexity by going down to more or less levels of detail. A 1901 lightweight implementation within the core could consider only the 1902 coarsest level.)" 1903 removed, because it is service-specific 1904 49) (CLOSED) remove req 5.5.9 Signaling must support quantitative, 1905 qualitative, and relative QoS specifications 1906 removed because it is service-specific 1907 50) (CLOSED) req 5.5.6 remove Ranges in specification 1908 The QSC should allow for specification of minimum required QoS 1909 and/or desirable QoS. (Motivation: The QoS Service Classes should 1910 allow for ranges to be indicated, to minimize negotiation latency 1911 and suppress error notifications during handover events.) 1912 removed, is service specific 1913 51) (OPEN) remove 5.1.6 Avoid duplication of [sub]domain signaling 1914 functions 1915 we might to use the text somewhere else 1916 52) (OPEN) New requirement: interaction with policy 1917 this most likely is covered by an opaque token for authentication 1918 dependency on security changes 1919 53) (OPEN) add req 5.1.16. of draft-partain-...-00 Error handling 1920 and redundancy considerations 1921 Border nodes should be able to notify the users if there is an error 1922 inside the network. There are two types of network errors: 1923 - Recoverable errors: this type error can be locally repaired 1924 by the network nodes. The network nodes do not have to 1925 notify the users of the error immediately. 1926 - Unrecoverable errors: the network nodes cannot handle this 1927 type of error, and have to notify the users as soon as 1928 possible. 1929 Comments: 1930 1) notification of user in case of unrecoverable errors (has been 1931 done by notification req, or will be done by asynch notification 1932 2) recoverable error (might need to be added) req 5.3.4 is going 1933 into this direction 1934 3) what does this mean for different parts of the network 1935 in different parts of the network) 1936 4) hop-by-hop? OR right to the end? 1937 54) (CLOSED) add req 5.1.17. to assumption "Identification 1938 requirement" 1939 assumption say that the discovery of QI, QC, QR is out-of-scope of 1940 the draft 1941 55) (OPEN) 5.2.2. Allow local QoS information exchange between two 1942 border nodes 1943 "The QoS signalling protocol must be able to exchange local QoS 1944 information between edge nodes. Local QoS information might, for 1945 example, be IP addresses, severe congestion notification, 1946 notification of succesful or erroneous processing of QoS signalling 1947 messages at one border node. 1948 In some domains, the NSIS QoS signalling protocol MAY carry 1949 identification of the ingress and egress edge between the ingress- 1950 egress edges. However, the identification of edges should not be 1951 visible to the end host and only applies within one QoS 1952 administrative domain. 1953 " 1954 Comments: 1955 - service mapping is more service-specific (layering,tunneling) 1956 - the scenario to look at is a complicated service description -> in 1957 part of the network you want to change the message to something more 1958 easy, and at the other end go back to the more complicated part. 1959 -QI being everywhere might be enough 1960 -and we have already a requirement saying that intermediate node 1961 MUST be able to add/remove domain-specific information to/from 1962 signaling messages 1963 56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00 1964 -already added a req to the scalability section (issue ???), which 1965 has been provided by Anders 1966 57) (OPEN) potentially better title for text from issue 56) e.g. 1967 (?minimal impact on core?) 1968 58) (CLOSED) add req 5.3.2 from draft-partain-...-00 1969 - the fast establishment req is handled by the low setup latency 1970 req, and the scalability in handover req 1971 - added the text to the teminal mobility scenario 1972 59) (OPEN) add req: ability to deal with severe congestion (req 1973 5.3.4 of draft-partain-..-00 1974 issues are: 1975 - the use in highly utilized networks 1976 - deos it belong to failure recovery (I would assume from a service 1977 point of view this is failure 1978 - hop by hop problem (issue from Jorge) 1979 60) (OPEN) add req 5.4.3. from draft-partain-...-00 "Allow efficient 1980 QoS re-establishment after handover" 1981 "Handover is an essential function in wireless networks. After 1982 handover, QoS may need to be completely or partially re-established 1983 due to route changes. The re-establishment may be requested by the 1984 mobile node itself or triggered by the access point that the mobile 1985 node is attached to. In the first case, the QoS signalling should 1986 allow efficient QoS re-establishment after handover. Re- 1987 establishment of QoS after handover should be as quick as possible 1988 so that the mobile node does not experience service interruption or 1989 QoS degradation. The re-establishment should be localized, and not 1990 require end-to-end signalling, if possible." 1991 most likely it is already cover, please check again, whether there 1992 is something missing 1993 61) (OPEN) add req: 6.1.8 from draft-bucheli-...-00 on multicast 1994 "Multicast consideration should not impact the protocol complexity 1995 for unicast flows. Multicast support is not considered as a 1996 priority, because the targeted interactive multimedia services are 1997 mainly unicast. For this reason, if considered in the solution, 1998 multicast should not bring complexity in the unicast scenario." 1999 Opinions?