idnits 2.17.00 (12 Aug 2021) /tmp/idnits10900/draft-ietf-nsis-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 20) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 2038: '... 3) SHOULD support sender initiated,...' RFC 2119 keyword, line 2065: '... colums with the MUST, SHOULDs, and MA...' RFC 2119 keyword, line 2068: '...) MUSTs, SHOULDs, MAY needs discussion...' RFC 2119 keyword, line 2235: '...ack of a request MUST include yes and ...' RFC 2119 keyword, line 2236: '...in case of no it MAY include an opaque...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2103 has weird spacing: '...for the forwa...' == Line 2304 has weird spacing: '...io used in th...' == Line 2364 has weird spacing: '...neering and r...' == Line 2499 has weird spacing: '...ork and if it...' == Line 2500 has weird spacing: '...ce will quick...' -- 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 (May 2002) is 7311 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 226 == Unused Reference: '1' is defined on line 1316, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1319, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1323, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1332, 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: 8 errors (**), 0 flaws (~~), 18 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group 3 Internet Draft M. Brunner (Editor) 4 Document: draft-ietf-nsis-req-02.txt NEC 5 Expires: November 2002 May 2002 7 Requirements for QoS Signaling Protocols 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines requirements for signaling QoS across 33 different network environments. To achieve wide applicability of the 34 requirements, the starting point is a diverse set of scenarios/use 35 cases concerning various types of networks and application 36 interactions. We also provide an outline structure for the problem, 37 including QoS related terminology. Taken with the scenarios, this 38 allows us to focus more precisely on which parts of the overall QoS 39 problem needs to be solved. We present the assumptions and the 40 aspects not considered within scope before listing the requirements 41 grouped according to areas such as architecture and design goals, 42 signaling flows, layering, performance, flexibility, security, and 43 mobility. 45 1 Introduction 47 This document defines requirements for signaling QoS across 48 different network environments. It does not list any problems of 49 existing QoS signaling protocols such as RSVP. 51 In order to derive requirements for QoS signaling it is necessary to 52 first have a clear idea of the scope within which they are 53 applicable. 54 We describe a set of QoS signaling scenarios and use cases in the 55 Appendix of that document. These scenarios derive from a variety of 56 backgrounds, and help obtain a clearer picture of what is in or out 57 of scope of the NSIS work. They illustrate the problem of QoS 58 signaling from various perspectives (end-system, access network, 59 core network) and for various areas (fixed line, mobile, wireless 60 environments). As the NSIS work becomes more clearly defined, 61 scenarios will be added or dropped, or defined in more detail. 63 Based on these scenarios, we are able to define the QoS signaling 64 problem on a more abstract level. In Section 3, we thus present a 65 simple conceptual model of the QoS signaling problem, describe the 66 entities involved in QoS signaling, and typical signaling paths. In 67 Section 4 we list assumptions and exclusions. 69 The model of Section 3 allows deriving requirements from the 70 scenarios presented in the appendix in a coherent and consistent 71 manner. Requirements are grouped according to areas such as 72 Architecture and design goals, Signaling Flows, Layering, 73 Performance, Flexibility, Security and Mobility. 75 QoS is a pretty large field with a lot of interaction with other 76 protocols, mechanisms, applications etc. In the following, some 77 thoughts from an end-system point of view and from a network point 78 of view. 80 End-system perspective: In future mobile terminals, the support of 81 adaptive applications is more and more important. Adaptively can be 82 seen as an important technique to react to QoS violations that may 83 occur frequently, e.g., in wireless environments due to changed 84 environmental and network conditions. This may result in degraded 85 end-to-end performance. It is then up to adaptive applications to 86 react to the new resource availability. Therefore, it is essential 87 to define interoperability between media-, mobility- and QoS 88 management. While most likely mobile terminals cannot assume, that 89 explicit QoS reservation schemes are available, some access networks 90 nevertheless may offer such capabilities. Applications subscribed to 91 an end-system QoS management system should be supported with a 92 dedicated QoS API to set-up, control and adapt media sessions. 94 Network perspective: QoS enabled IP networks are expected to handle 95 two different kinds of QoS granularities: per-flow QoS and per- 96 trunk/per-class QoS. Per-flow QoS might be needed in access networks 97 and may there be subject of QoS signaling. However, in the core 98 network only per-trunk or per-class QoS can be considered for 99 scalability reasons. Therefore there might be different requirements 100 on QoS signaling applying to different parts of the network. In the 101 access network QoS signaling is an interaction between end systems 102 and access routers or access network QoS managers (in the following 103 we call them QoS initiator and QoS controller). In the core network 104 QoS signaling refers to trunks or classes of traffic between core 105 and edge systems or between peering core systems. Please note that 106 this does not exclude the transport of per-flow signaling through 107 core networks. 109 It is clear from these descriptions that the subject of QoS is 110 uniquely complex and any investigation could potentially have a very 111 broad scope - so broad that it is a challenge to focus work on an 112 area which could lead to a concrete and useful result. This is our 113 motivation for considering a set of use cases, which map out the 114 domain of application that we want to address. It is also the 115 motivation for defining a problem structure, which allows us to 116 state the boundaries of what types of functionality to consider, and 117 to list background assumptions. 119 There are several areas of the requirements related to networking 120 aspects which are incomplete, for example, interaction with host and 121 site multi-homing, use of anycast services, and so on. These issues 122 should be considered in any future requirement analysis work. 124 2 Terminology 126 In the area of Qualiaty of Service (QoS) it is quite difficult and 127 an exercise for its own to define terminology. Nevertheless, we 128 tried to list the most often used terms in the draft and tried to 129 explain them. However, don't be to religious about it, they are not 130 meant to prescribe any thing in the draft. 132 Aggregate: a group of flows, usually with similar QoS requirements, 133 which can be treated together as a whole with a single overall QoS 134 requirement for signaling and provisioning. Aggregates and flows can 135 be further aggregated together. 137 [QoS] Domain: a collection of networks under the same administrative 138 control and grouped together for administrative purposes. 140 Egress point: the router via which a path exits a domain/subdomain. 142 End Host: the end system or host, for whose flows QoS is being 143 requested and provisioned. 145 End-to-End QoS: the QoS delivered by the network between two 146 communicating end hosts. End-to-end QoS co-ordinates and enforces 147 predefined traffic management policies across multiple network 148 entities and administrative domains. 150 Edge-to-edge QoS: QoS within an administrative domain that connects 151 to other networks rather than hosts or end systems. 153 Flow: a traffic stream (sequence of IP packets between two end 154 systems) for which a specific level of QoS is to be provided. The 155 flow can be unicast (uni- or bi-directional) or multicast. 157 Flow Administration: represents the policy associated with how flows 158 should be treated in the network, for example whether and how the 159 flows should be aggregated. It may consist of both user and local 160 network management information. 162 Higher Layers: the higher layer (transport protocol and application) 163 functions that request QoS from the network layer. The request might 164 be a trigger generated within the end system, or the trigger might 165 be provided by some entity within the network (e.g. application 166 proxy or policy server). 168 Indication: feedback from QoS provisioning to indicate the current 169 QoS being provided to a flow or aggregate, and whether any 170 violations have been detected by the QoS technology being used 171 within the local domain/subdomain. 173 Ingress point: the router via which a path enters a 174 domain/subdomain. 176 Mapping: the act of transforming parameters from QSCs to values that 177 are meaningful to the actual QoS technology in use in the 178 domain/subdomain. 180 Path: the route across the networks taken by a flow or aggregate, 181 i.e. which domains/subdomains it passes through and the 182 egress/ingress points for each. 184 Path segment: the segment of a path within a single 185 domain/subdomain. 187 QoS Administration Function: a generic term for all functions 188 associated with admission control, policy control, traffic 189 engineering etc. 191 QoS Control Information: the information the governs the QoS 192 treatment to be applied to a flow or aggregate, including the QSC, 193 flow administration, and any associated security or accounting 194 information. 196 QoS Controller: this is responsible for interpreting the signaling 197 carrying the user QoS parameters, optionally inserting/modifying the 198 parameters according to local network QoS management policy, and 199 invoking local QoS provisioning mechanisms. Note that q QoS 200 controller might have very different functionality depending on 201 where in the network and in what environment they are implemented. 203 QoS Initiator: this is responsible for generating the QSCs for 204 traffic flow(s) based on user or application requirements and 205 signaling them to the network as well as invoking local QoS 206 provisioning mechanisms. This can be located in the end system, but 207 may reside elsewhere in network. 209 QoS Provisioning: the act of actually allocating resources to a flow 210 or aggregate of flows, may include mechanisms such as LSP initiation 211 for MPLS, packet scheduler configuration within a router, and so on. 212 The mechanisms depend on the overall QoS technology being used 213 within the [sub]domain. 215 QoS Service Classes (QSC): specify the QoS requirements of a traffic 216 flow or aggregate. Can be further sub-divided into user specific 217 and network related parameters 219 QoS Signaling: a way to communicate QSCs and QoS management 220 information between hosts, end systems and network devices etc. May 221 include request and response messages to facilitate negotiation/re- 222 negotiation, asynchronous feedback messages (not delivered upon 223 request) to inform End Hosts, QoS initiators and QoS controllers 224 about current QoS levels, and QoS querying facilities. 226 [QoS] Subdomain: a network within an administrative domain using a 227 uniform technology/QoS provisioning function to provision resources. 229 QoS Technology: a generic term for a set of protocols, standards and 230 mechanisms that can be used within a QoS domain/subdomain to manage 231 the QoS provided to flows or aggregates that traverse the domain. 232 Examples might include MPLS, DiffServ, and so on. A QoS technology 233 is associated with certain QoS provisioning techniques. 235 QoS Violation: occurs when the QoS applied to a flow or aggregate 236 does not meet the requested and negotiated QoS agreed for it. 238 Resource: something of value in a network infrastructure to which 239 rules or policy criteria are first applied before access is granted. 240 Examples of resources include the buffers in a router and bandwidth 241 on an interface. 243 Resource Allocation: part of a resource that has been dedicated for 244 the use of a particular traffic type for a period of time through 245 the application of policies. 247 Sender-initiated QoS signaling protocol: A sender-initiated QoS 248 signaling protocol is a protocol (see e.g., YESSIR [8], RMD [10]) 249 where the QI initiates the signaling on behalf of the sender of the 250 data. What this means is that admission control and resource 251 allocation functions are processed from the data sender towards the 252 data receiver. However, the triggering instance is not specified. 254 Receiver-initiated QoS signalling protocol: A receiver-initiated 255 protocol, (see e.g., RSVP [9]) is a protocol where the QoS 256 reservations are initiated by the QoS Reiceiver on behalf of the 257 receiver of the user data. What this means is that admission control 258 and resource allocation functions are processed from the data 259 receiver back towards the data sender. However, the triggering 260 instance is not specified. 262 3 Problem Statement and Scope 264 We provide in the following a preliminary architectural picture as a 265 basis for discussion. We will refer to it in the following 266 requirement section. 268 A set of issues and problems to be solved has been given at a top 269 level by the use cases/scenarios of the appendix. However, the 270 problem of QoS has an extremely wide scope and there is a great deal 271 of work already done to provide different components of the 272 solution, such as QoS technologies for example. A basic goal should 273 be to re-use these wherever possible, and to focus requirements work 274 at an early stage on those areas where a new solution is needed 275 (e.g. an especially simple one). We also try to avoid defining 276 requirements related to internal implementation aspects. 278 In this section, we present a simple conceptual model of the overall 279 QoS problem in order to identify the applicability to NSIS of 280 requirements derived from the use cases, and to clarify the scope of 281 the work, including any open issues. This model also identifies 282 further sources of requirements from external interactions with 283 other parts of an overall QoS solution, clarifies the terminology 284 used, and allows the statement of design goals about the nature of 285 the solution (see section 5). 287 Note that this model is intended not to constrain the technical 288 approach taken subsequently, simply to allow concrete phrasing of 289 requirements (e.g. requirements about placement of the QoS 290 initiator, or ability to 'drive' particular QoS technologies.) 292 Roughly, the scope of NSIS is assumed to be the interaction between 293 the QoS initiator and QoS controller(s), including selection of 294 signaling protocols to carry the QoS information, and the 295 syntax/semantics of the information that is exchanged. Further 296 statements on assumptions/exclusions are given in the next Section. 297 The main elements are: 299 1. Something that starts the request for QoS, the QoS Initiator. 301 This might be in the end system or within some other part of the 302 network. The distinguishing feature of the QoS initiator is that it 303 acts on triggers coming (directly or indirectly) from the higher 304 layers in the end systems. It needs to map the QoS requested by 305 them, and also provides feedback information to the higher layers 306 which might be used by transport layer rate management or adaptive 307 applications. 309 2. Something that assists in managing QoS further along the path, 310 the QoS controller. 312 The QoS controller does not interact with higher layers, but 313 interacts with the QoS initiator and possibly more QoS controllers 314 on the path, edge to edge or possibly end to end. 316 3. The QoS initiator and controller(s) interact with each other, 317 path segment by path segment. This interaction involves the exchange 318 of data (QoS control information) over some signaling protocol. 320 4. The path segment traverses an underlying network (QoS domain or 321 subdomain) covering one or more IP hops. The underlying network uses 322 some local QoS technology. This QoS technology has to be provisioned 323 appropriately for the flow, and this is done by the QoS initiator 324 and controller(s), mapping their QoS control information to 325 technology-related QoS parameters and receiving indications about 326 success or failure in response. 328 Now concentrating more on the overall end to end (multiple QoS 329 domains) aspects, in particular: 331 1. The QoS initiator need not be located at an end system, and the 332 QoS controllers are not assumed to be located on the flow's data 333 path. However, they must be able to identify the ingress and egress 334 points for the flow path as it traverses the domain/subdomain. Any 335 signaling protocol must be able to find the appropriate QoS 336 controller and carry this ingress/egress point information. 338 2. We see the network at the level of domains/subdomains rather than 339 individual routers (except in the special case that the domain 340 contains one link). Domains are assumed to be administrative 341 entities, so security requirements apply to the signaling between 342 them. Subdomains are introduced to allow the fact a given QoS 343 provisioning mechanism may only be used within a part of a domain, 344 typically for a particular subnetwork technology boundary. 345 Aggregation can also take place at subdomain boundaries. 347 3. Any domain may contain QoS administration functions (e.g. to do 348 with traffic engineering, admission control, policy and so on). 350 These are assumed to interact with the QoS initiator and controllers 351 (and end systems) using standard mechanisms. 353 4. The placement of the QoS initiators and QoS controllers is not 354 fixed. Actually, there are two extreme cases: 356 - Each router on the data path implements a QoS controller and QoS 357 initiator. 359 - Only the end systems incorporate a QoS controller and QoS 360 initiator, which means the end systems need to have QoS provisioning 361 capabilities. However this case does not seam to be realistic but 362 shows the flexible allocation of the controller and initiator 363 function. 365 4 Assumptions and Exclusions 367 4.1 Assumptions and Non-Assumptions 369 1. The NSIS signaling could run end to end, end to edge, or edge to 370 edge, or network-to-network ((between providers), depending on what 371 point in the network acts as the initiator, and how far towards the 372 other end of the network the signaling propagates. Although the 373 figures show QoS controllers at a very limited number of locations 374 in the network (e.g. at domain or subdomain borders, or even 375 controlling a complete domain), this is only one possible case. In 376 general, we could expect QoS controllers to become more 'dense' 377 towards the edges of the network, but this is not a requirement. An 378 overprovisioned domain might contain no QoS controllers at all (and 379 be NSIS transparent); at the other extreme, QoS controllers might be 380 placed at every router. In the latter case, QoS provisioning can be 381 carried out in a local implementation-dependent way without further 382 signalling, whereas in the case of remote QoS controllers, a 383 provisioning protocol might be needed to control the routers along 384 the path. This provisioning protocol is then independent of the end 385 to end NSIS signalling. 387 2. We do not consider 'pure' end-to-end QoS signaling that is not 388 interpreted anywhere within the network. Such signaling is an 389 application-layer issue and IETF protocols such as SIP etc. can be 390 used. 392 3. Where the signaling does cover several QoS domains or subdomains, 393 we do not exclude that different signaling protocols are used in 394 each path segment. We only place requirements on the universality of 395 the QoS control information that is being transported. (The goals 396 here would be to allow the use of signaling protocols which are 397 matched to the characteristics of the portion of the network being 398 traversed.) Note that the outcome of NSIS work might result in 399 various protocols or various flavors of the same protocol. This 400 implies the need for the translation of information into QoS domain 401 specific format as well. 403 4. We assume that the service definitions a QoS initiator can ask 404 for are known in advance of the signaling protocol running. Service 405 definition includes QoS parameters, life-time of QoS guarantee etc. 406 There are many ways a service requester get to know about it. There 407 might be standardized services, the definition can be negotiated 408 together with a contract, the service definition is published at a 409 Web-page, etc. 411 5. We assume that there are means for the discovery of NSIS entities 412 in order to know the signaling peers (solutions include static 413 configuration, automatically discovered, or implicitly runs over the 414 right nodes, etc.) 416 4.2 Exclusions 418 1. Development of specific mechanisms and algorithms for application 419 and transport layer adaptation are not considered, nor are the 420 protocols that would support it. 422 2. Specific mechanisms (APIs and so on) for interaction between 423 transport/applications and the network layer are not considered, 424 except to clarify the requirements on the negotiation capabilities 425 and information semantics that would be needed of the signaling 426 protocol. The same applies to application adaptation mechanisms. 428 3. Specific mechanisms for QoS provisioning within a 429 domain/subdomain are not considered. It should be possible to 430 exploit these mechanisms optimally within the end to end context. 431 Consideration of how to do this might generate new requirements for 432 NSIS however. For example, the information needed by an QoS 433 controller to manage a radio subnetwork needs to be provided by the 434 NSIS solution. 436 4. Specific mechanisms (APIs and so on) for interaction between the 437 network layer and underlying QoS provisioning mechanisms are not 438 considered. 440 5. Interaction with QoS administration capabilities is not 441 considered. Standard protocols should be used for this (e.g. COPS). 442 This may imply requirements for the sort of information that should 443 be exchanged between the NSIS network QoS entities. 445 6. Security issues related to multicasting are outside the scope of 446 the QoS signaling protocol. 448 Since multicasting is currently not an issue for the QoS protocol, 449 security issues related to multicast are outside the scope. 450 Multicast security may additionally be an application issue that is 451 also outside the scope of the QoS protocol. 453 7. Protection of non-QoS signaling messages is outside the scope of 454 the QoS protocol 455 Security protection of data messages transmitted along the 456 established QoS path is outside the scope of the QoS protocol. These 457 security properties are likely to be application specific and may be 458 provided by the corresponding application layer protocol. 460 8. Service definitions and QoS classes are out of scope. Together 461 with the service definition any definition of service specific 462 parameters are not considered in this draft. Only the base NSIS 463 signaling protocol for transporting the QoS/service information are 464 handled. 466 9. Similarly, specific methods, protocols, and ways to express QoS 467 information in the Application/Session level are not considered 468 (e.g., SDP, SIP, RTSP, etc.). 470 10. The specification of any extensions needed to signal QoS 471 information via application level protocols (e.g. SDP(ng)), and the 472 mapping on NSIS information are considered outside of the scope of 473 NSIS working group, as this work is in the direct scope of other 474 IETF working groups (e.g. MMUSIC). 476 5 Requirements 478 This section defines more detailed requirements for a QoS signaling 479 solution, derived from consideration of the use cases/scenarios, and 480 respecting the framework, scoping assumptions, and terminology 481 considered earlier. The requirements are in subsections, grouped 482 roughly according to general technical aspects: architecture and 483 design goals, topology issues, QoS parameters, performance, 484 security, information, and flexibility. 486 Two general (and potentially contradictory) goals for the solution 487 are that it should be applicable in a very wide range of scenarios, 488 and at the same time lightweight in implementation complexity and 489 resource requirements in nodes. One approach to this is that the 490 solution could deal with certain requirements via modular components 491 or capabilities, which are optional to implement in individual 492 nodes. 494 Some of the requirements are technically contradictory. Depending on 495 the scenarios a solution applies to, one or the other requirement is 496 applicable. 498 Find in Section 6 the MUSTs, SHOULDs, and MAYs 500 5.1 Architecture and Design Goals 502 This section contains requirements related to desirable overall 503 characteristics of a solution, e.g. enabling flexibility, or 504 independence of parts of the framework. 506 5.1.1 Applicability for different QoS technologies. 508 The QoS signaling protocol must work with various QoS technologies. 509 The information exchanged over the signaling protocol must be in 510 such detail and quantity that it is useful for various QoS 511 technologies. 513 5.1.2 Resource availability information on request 515 In some scenarios, e.g., the mobile terminal scenario, it is 516 required to query, whether resources are available, without 517 performing a reservation on the resource. One solution might be a 518 feedback mechanism based on which a QoS inferred handover can take 519 place. 521 5.1.3 Modularity 523 A modular design allows for more lightweight implementations, if 524 fewer features are needed. Mutually exclusive solutions are 525 supported. Examples for modularity: 527 - Work over any kind of network (narrowband / broadband, error-prone 528 / reliable...) - This implies low bandwidth signaling and redundant 529 information must be supported if necessary. 531 - In case QoS requirements are soft (e.g. banking transactions, 532 gaming), fast and lightweight signaling (e.g., not more than one 533 round-trip time) 535 - Uni- and bi-directional reservations are possible 537 5.1.4 Decoupling of protocol and information it is carrying 539 The signaling protocol(s) used must be clearly separated from the 540 QoS control information being transported. This provides for the 541 independent development of these two aspects of the solution, and 542 allows for this control information to be carried within other 543 protocols, including application layer ones, existing ones or those 544 being developed in the future. The gained flexibility in the 545 information transported allows for the applicability of the same 546 protocol in various scenarios. 547 However, note that the information carried needs to be the same. 548 Otherwise interoperability is difficult to achieve. 550 5.1.5 Reuse of existing QoS provisioning 552 Reuse existing QoS functions and protocols for QoS provisioning 553 within a domain/subdomain unchanged. (Motivation: 'Don't re-invent 554 the wheel'.) 556 5.1.6 Independence of signaling and provisioning paradigm 558 The QoS signaling should be independent of the paradigm and 559 mechanism of QoS provisioning. The independence allows for using the 560 NSIS protocol together with various QoS technologies. 562 5.2 Signaling Flows 564 This section contains requirements related to the possible signaling 565 flows that should be supported, e.g. over what parts of the flow 566 path, between what entities (end-systems, routers, middleboxes, 567 management systems), in which direction. 569 5.2.1 Free placement of QoS Initiator and QoS Controllers functions 571 The protocol(s) must work in various scenarios such as host-to- 572 network-to-host, edge-to-edge, (e.g., just within one providers 573 domain), user-to-network (from end system into the network, ending, 574 e.g., at the entry to the network and vice versa), network-to- 575 network (e.g., between providers). 577 Placing the QoS controller and initiator functions at different 578 locations allows for various scenarios to work with the same or 579 similar protocols. 581 5.2.2 No constraint of the QoS signaling and QoS Controllers to be in 582 the data path. 584 There is a set of scenarios, where QoS signaling is not on the data 585 path. The QoS Controller being in the data path is one extreme case 586 and useful in certain cases. 588 There are going to be cases where a centralized entity will take a 589 decision about QoS requests. In this case, there's no question there 590 is no need to have data follow the signalling path. 592 There are going to be cases wiout a centralized entity managing 593 resources and the signaling will be used as a tool for resource 594 management. For various reasons (such as efficient use of expensive 595 bandwidth), one will want to have fine-grained, fast, and very 596 dynamic control of the resources in the network. - 598 There are going to be cases where there will be neither signaling 599 nor a centralized entity (overprovisioning). Nothing has to be done 600 anyway. 602 One can capture the requirement with the following wording: If one 603 views the domain with a QoS technology as a virtual router then NSIS 604 signaling used between those virtual routers must follow the same 605 path as the data. 607 Routing the signaling protocol along an independent path is desired 608 by network operators/designers. Ideally, the capability to route the 609 protocol along an independent path would give the network 610 designer/operator the option to manage bandwidth utilization through 611 the topology. 613 There are other possibilities as well. An NSIS protocol must accept 614 all of these possibilities. 616 5.2.3 Concealment of topology and technology information 618 The QoS protocol should allow hiding the internal structure of a QoS 619 domain from end-nodes and from other networks. Hence an adversary 620 should not be able to learn the internal structure of a network with 621 the help of the QoS protocol. 623 In various scenarios, topology information should be hidden for 624 various reasons. From a business point of view, some administrations 625 don't want to reveal the topology and technology used. 627 5.2.4 Optional transparency of QoS signaling to network 629 It should be possible that the QoS signaling for some flows traverse 630 path segments transparently, i.e., without interpretation at QoS 631 controllers within the network. An example would be a subdomain 632 within a core network, which only interpreted signaling for 633 aggregates established at the domain edge, with the flow-related 634 signaling passing transparently through it. 636 5.3 Additional information beyond signaling of QoS information 638 This section contains the desired signaling (messages) for other 639 purposes other than that for conveying QoS parameters. 641 5.3.1 Explicit release of resources 643 When a QoS reservation is no longer necessary, e.g. because the 644 application terminates, or because a mobile host experienced a hand- 645 off, it must be possible to explicitly release resources. 647 5.3.2 Possibility for automatic release of resources after failure 649 When the QoS Initiator goes down, the resources it requested in the 650 network should be released, since they will no longer be necessary. 652 After detection of a failure in the network, any QoS 653 controller/initiator must be able to release a reservation it is 654 involved in. For example, this may require signaling of the "Release 655 after Failure" message upstream as well as downstream, or soft state 656 timing out of reservations. 658 Note that this might need to work together with a notification 659 mechanism. 661 5.3.3 Possibility for automatic re-setup of resources after recovery 663 In case of a failure, the reservation can get setup again 664 automatically. It enables sort of a persistent reservation, if the 665 QoS Initiator requests it. In scenarios where the reservations are 666 on a longer time scale, this could make sense to reduce the 667 signaling load in case of failure and recovery. 669 5.3.4 Prompt notification of QoS violation in case of error/failure to 670 QoS Initiator and QoS Controllers 672 QoS Controllers should be able to notify the QoS Initiator, if there 673 is an error inside the network. There are two types of network 674 errors: 676 Recoverable errors: This type error can be locally repaired by the 677 network nodes. The network nodes do not have to notify the users of 678 the error immediately. This is a condition when the danger of 679 degradation (or actual short term degradation) of the provided QoS 680 was overcome by the network (QoS controller) itself. 682 Unrecoverable errors: the network nodes cannot handle this type of 683 error, and have to notify the users as soon as possible. 685 5.3.5 Feedback about success of request for QoS guarantees 687 A request for QoS must be answered at least with yes or no. However, 688 it might be useful in case of a negative answer to also get a 689 description of what might be the QoS one can successfully request 690 etc. So it might be useful to include an opaque element into the 691 answer. The element heavily depends on the service requested. 693 5.3.6 Allow local QoS information exchange between nodes of the same 694 administrative domain 696 The QoS signaling protocol must be able to exchange local QoS 697 information between QoS controllers located within one single 698 domain. Local QoS information might, for example, be IP addresses, 699 severe congestion notification, notification of successful or 700 erroneous processing of QoS signaling messages. 702 In some cases, the NSIS QoS signalling protocol may carry 703 identification of the QoS controllers located at the boundaries of a 704 domain. However, the identification of edge should not be visible to 705 the end host (QoS initiator) and only applies within one QoS 706 administrative domain. 708 5.4 Layering 710 This section contains requirements related to the way the signaling 711 being considered interacts with upper layer functions (users, 712 applications, and QoS administration), and lower layer QoS 713 technologies. 715 5.4.1 The signaling protocol and QoS control information should be 716 application independent. 718 However, opaque application information might get transported in the 719 signaling message, without being handled in the network. Development 720 and deployment of new applications should be possible without 721 impacting the network infrastructure. Additionally, QoS protocols 722 are expected to conform to the Internet principles. 724 5.5 QoS Control Information 726 This section contains requirements related to the QoS control 727 information that needs to be exchanged. 729 5.5.1 Mutability information on parameters 731 It should be possible for the initiator to control the mutability of 732 the QSC information. This prevents from being changed in a non- 733 recoverable way. The initiator should be able to control what is 734 requested end to end, without the request being gradually mutated as 735 it passes through a sequence of domains. This implies that in case 736 of changes made on the parameters, the original requested ones must 737 still be available. 739 Note that we do not require anything about particular QoS paramters 740 being changed. 742 5.5.2 Possibility to add and remove local domain information 744 It should be possible for the QoS control functions to add and 745 remove local scope elements. E.g., at the entrance to a QoS domain 746 domain-specific information is added, which is used in this domain 747 only, and the information is removed again when a signaling message 748 leaves the domain. The motivation is in the economy of re-use the 749 protocol for domain internal signaling of various information. Where 750 additional information is needed for QoS control within a particular 751 domain, it should be possible to carry this at the same time as the 752 'end to end' information.) 754 5.5.3 Independence of reservation identifier 756 A reservation identifier must be used, which is independent of the 757 flow identifier, the IP address of the QoS Initiator, and the flow 758 end-points. Various scenarios in the mobility area require this 759 independence because flows resulting from handoff might have changed 760 end-points etc. but still have the same QoS requirement. 762 5.5.4 Seamless modification of already reserved QoS 764 In many case, the reservation needs to be updated (up or downgrade). 765 This must happen seamlessly without service interruption. At least 766 the signaling protocol must allow for it, even if some data path 767 elements might not be capable of doing so. 769 5.5.5 Signaling must support quantitative, qualitative, and relative 770 QoS specifications 771 5.6 Performance 773 This section discusses performance requirements and evaluation 774 criteria and the way in which these could and should be traded off 775 against each other in various parts of the solution. 777 Scalability is a must anyway. However, depending on the scenario the 778 question to which extends the protocol must be scalable. 780 5.6.1 Scalability in the number of messages received by a signaling 781 communication partner (QoS initiator and controller) 783 5.6.2 Scalability in number of hand-offs 785 5.6.3 Scalability in the number of interactions for setting up a 786 reservation 788 5.6.4 Scalability in the number of state per entity (QoS initiators and 789 QoS controllers) 791 5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 793 5.6.6 Low latency in setup 795 Low latency is only needed in scenarios, where reservations are in a 796 short time scale (e.g. handover in mobile environments), or where 797 human interaction is immediately concerned (e.g., voice 798 communication setup delay) 800 5.6.7 Allow for low bandwidth consumption for signaling protocol 802 Again only small sets of scenarios call for low bandwidth, mainly 803 those where wireless links are involved. 805 Note that many of the performance issues are heavily dependent on 806 the scenario assumed and are normally a trade-off between speed, 807 reliability, complexity, and scalability. The trade-off varies in 808 different parts of the network. For example, in radio access 809 networks low bandwidth consumption will overweight the low latency 810 requirement, while in core networks it may be reverse. 812 5.6.8 Ability to constrain load on devices 814 The NSIS architecture should give the ability to constrain the load 815 (CPU load, memory space, signaling bandwidth consumption and 816 signaling intensity) on devices where it is needed. One of the 817 reasons is that the protocol handling should have a minimal impact 818 on interior (core) nodes. 820 This can be achieved by many different methods. Examples, and this 821 are only examples, include message aggregation, by ignoring 822 signaling message, header compression, or minimizing functionality. 823 The framework may choose any method as long as the requirement is 824 met. 826 5.6.9 Highest possible network utilization 828 There are networking environments that require high network 829 utilization for various reasons, and the signaling protocol should 830 to its best ability support high resource utilization while 831 maintaining appropriate QoS. 833 In networks where resources are very expensive (as is the case for 834 many wireless networks), efficient network utilization is of 835 critical financial importance. On the other hand there are other 836 parts of the network where high utilization is not required. 838 5.7 Flexibility 840 This section lists the various ways the protocol can flexibly be 841 employed. 843 5.7.1 Aggregation capability, including the capability to select and 844 change the level of aggregation. 846 5.7.2 Flexibility in the placement of the QoS initiator 848 It might be the sender or the receiver of content. But also network- 849 initiated reservations are required in various scenarios. 851 5.7.3 Flexibility in the initiation of re-negotiation (QoS change 852 requests) 854 Again the sender or the receiver of content might initiate a re- 855 negotiation due to various reasons, such as local resource shortage 856 (CPU, memory on end-system) or a user changed application 857 preference/profiles. But also network-initiated re-negotiation is 858 required in cases, where the network is not able to further 859 guarantee resources etc. 861 5.7.4 Uni / bi-directional reservation 863 Both uni-directonal as well as bi-direction reservations must be 864 possible. 866 5.8 Security 868 This section discusses security-related requirements. First a list 869 of security threats is given. 871 5.8.1 The QoS protocol must provide strong authentication 873 A QoS protocol must make provision for enabling various entities to 874 be authenticated against each other using data origin and/or entity 875 authentication. The QoS protocol must enable mutual authentication 876 between the two communicating entities. The term strong 877 authentication points to the fact that weak plain-text password 878 mechanisms must not be used for authentication. 880 5.8.2 The QoS protocol must provide means to authorize resource 881 requests 883 This requirement demands a hook to interact with a policy entity to 884 request authorization data. This allows an authenticated entity to 885 be associated with authorization data and to verify the resource 886 request. Authorization prevents reservations by unauthorized 887 entities, reservations violating policies, theft of service and 888 additionally limits denial of service attacks against parts of the 889 network or the entire network. Additionally it might be helpful to 890 provide some means to inform other protocols of participating nodes 891 within the same administrative domain about a previous successful 892 authorization event. 894 5.8.3 The QoS signaling messages must provide integrity protection. 896 The integrity protection of the transmitted signaling messages 897 prevent an adversary from modifying parts of the QoS signaling 898 message and from mounting denial of service attacks against network 899 elements participating in the QoS protocol. 901 5.8.4 The QoS signaling messages must be replay protected. 903 To prevent replay of previous signaling messages the QoS protocol 904 must provide means to detect old messages. A solution must cover 905 issues of synchronization problems in the case of a restart or a 906 crash of a participating network element. The use of replay 907 mechanism apart from sequence numbers should be investigated. 909 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. 911 Hop-by-Hop security is a well known and proven concept in QoS 912 protocols that allows intermediate nodes that actively participate 913 in the QoS protocol to modify the messages as required by the QoS 914 processing. Note that this requirement does not exclude end-to-end 915 or network-to-network security of a QoS reservation request. End-to- 916 end security between the initiator and the responder may be used to 917 provide protection of non-mutable data fields. Network-to-network 918 security refers to the protection of messages over various hops but 919 not in an end-to-end manner i.e. protected over a particular 920 network. 922 5.8.6 The QoS protocol should allow identity confidentiality and 923 location privacy. 925 Identity confidentiality enables privacy and avoids profiling of 926 entities by adversary eavesdropping the signaling traffic along the 927 path. The identity used in the process of authentication may also be 928 hidden to a limited extent from a network to which the initiator is 929 attached. It is however required that the identity provide enough 930 information for the access network to collect accounting data. 931 Location privacy is an issue for the initiator who triggers the QoS 932 protocol. In some scenarios the initiator may not be willing to 933 reveal location information to the responder. 935 5.8.7 The QoS protocol should prevent denial-of-service attacks against 936 signaling entities. 938 To effectively prevent denial-of-service attacks the QoS protocol 939 and the used security mechanisms should not force to do heavy 940 computation to verify a resource request prior authenticating the 941 requesting entity. Additionally the QoS protocol and the used 942 security mechanisms should not require large resource consumption 943 (for example main memory or other additional message exchanges) 944 before a successful authentication was done. 946 5.8.8 The QoS protocol should support confidentiality of signaling 947 messages. 949 Based on the signaling information exchanged between nodes 950 participating in the QoS protocol an adversary may learn both the 951 identities and the content of the QoS messages. To prevent this from 952 happening, confidentiality of the QoS requests in a hop-by-hop 953 manner should be provided. Note that hop-by-hop is always required 954 whenever entities actively participating in the protocol must be 955 able to read and eventually modify the content of the QoS messages. 956 This does not exclude the case where one or more network elements 957 are not required to read the information of the transmitted QoS 958 messages. 960 5.8.9 The QoS protocol should provide hooks to interact with protocols 961 that allow the negotiation of authentication and key management 962 protocols. 964 The negotiation of an authentication and key management protocols 965 within the QoS protocol is outside the scope of the QoS protocol. 966 This requirement originates from the fact that more than one key 967 management protocol may be used to provide security associations. So 968 both entities must be capable to use the same protocol which may be 969 difficult in a mobile environment with different requirements and 970 different protocols. The goal of such a negotiation step is to 971 determine which authentication and key management protocol to use is 972 executed prior to the execution of the chosen key management 973 protocol. The used key management protocol must however be able to 974 create a security association that matches with the one used in the 975 QoS protocol. A QoS protocol should however provide a way to 976 interact with these negotiation protocols. 978 5.8.10 The QoS protocol should provide means to interact with key 979 management protocols 980 Key management protocols typically require a larger number of 981 messages to be transmitted to allow a session key and the 982 corresponding security association to be derived. To avoid the 983 complex issue of mapping individual authentication and key 984 management protocols to a QoS protocol such a protocol is outside 985 the scope of the QoS protocol. Although the key management protocol 986 may be independent there must be a way for the QoS protocol to 987 exploit existing security associations to avoid executing a separate 988 key management protocol (or instance of the same protocol) for 989 protocols that closely operate together. If no such security 990 association exists then there should be means for the QoS protocol 991 to trigger a key management protocol to dynamically create the 992 required security associations. 994 5.9 Mobility 996 5.9.1 Allow efficient QoS re-establishment after handover 998 Handover is an essential function in wireless networks. After 999 handover, QoS may need to be completely or partially re-established 1000 due to route changes. The re-establishment may be requested by the 1001 mobile node itself or triggered by the access point that the mobile 1002 node is attached to. In the first case, the QoS signalling should 1003 allow efficient QoS re-establishment after handover. Re- 1004 establishment of QoS after handover should be as quick as possible 1005 so that the mobile node does not experience service interruption or 1006 QoS degradation. The re-establishment should be localized, and not 1007 require end-to-end signalling, if possible. 1009 TBD 1011 5.10 Interworking with other protocols and techniques 1013 Hooks must be provided to enable efficient interworking between 1014 various protocols and techniques including: 1016 5.10.1 Interworking with IP tunneling 1018 IP tunneling for various applications must be supported. More 1019 specifically tunneling for IPSec tunnels are of importance. This 1020 mainly impacts the identification of flows. Additionally, care needs 1021 to be taken using IPSec for signaling message. 1023 5.10.2 The solution should not constrain either to IPv4 or IPv6 1025 5.10.3 Independence from charging model 1027 Signaling must not be constrained by charging models or the charging 1028 infrastructure used. However, the end-system should be able to query 1029 current pay statistics and to specify user cost functions. 1031 5.10.4 The QoS protocol should provide hooks for AAA protocols 1032 The security mechanism should be developed with respect to be able 1033 to collect usage records from one or more network elements. 1035 5.11 Operational 1037 5.11.1 Ability to assign transport quality to signaling messages 1038 The NSIS architecture should allow the network operator to assign 1039 the NSIS protocol messages a certain transport quality. As signaling 1040 opens up for possible denial-of-service attacks, this requirement 1041 gives the network operator a mean, but also the obligation, to 1042 trade-off between signaling latency and the impact (from the 1043 signaling messages) on devices within his/her network. From protocol 1044 design this requirement states that the protocol messages should be 1045 detectable, at least where the control and assignment of the 1046 messages priority is done. 1048 6 The MUSTs, SHOULDs, and MAYs 1050 In order to prioritize the various requirements from Section 5, we 1051 define different 'parts of the network'. In the different parts of 1052 the network a particular requirement might have a different 1053 priority. 1055 The parts of the networks we differentiate are the host-to-first 1056 router, the access network, and the core network. The host to first 1057 router part includes all the layer 2 technologies to access to the 1058 Internet. In many cases, there is an application and/or user running 1059 on the host initiating QoS signaling. The access network can be 1060 characterized by low capacity links, meadium speed IP processing 1061 capabilities, and it might consist of a complete layer 2 network as 1062 well. The core network characteristics include high-speed forwarding 1063 capacities and interdomain QoS issues. All of them are not strictly 1064 defined and should not be regarded as that, but should give a 1065 feeling about where in the network we have different requirements 1066 concerning QoS signaling. 1068 Note that the requirement titles are listed for better reading. 1070 5.1 Architecture and Design Goals 1071 5.1.1 Applicability for different QoS technologies. 1072 5.1.2 Resource availability information on request 1073 5.1.3 Modularity 1074 5.1.4 Decoupling of protocol and information it is carrying 1075 5.1.5 Reuse of existing QoS provisioning 1076 5.1.6 Independence of signaling and provisioning paradigm 1078 ----------------------+-------------+-------------+------------+ 1079 | host-to-net | access | core | 1080 ----------------------+-------------+-------------+------------+ 1081 5.1.1 | | | | 1082 ----------------------+-------------+-------------+------------+ 1083 5.1.2 | | | | 1084 ----------------------+-------------+-------------+------------+ 1085 5.1.3 | | | | 1086 ----------------------+-------------+-------------+------------+ 1087 5.1.4 | | | | 1088 ----------------------+-------------+-------------+------------+ 1089 5.1.5 | | | | 1090 ----------------------+-------------+-------------+------------+ 1091 5.1.6 | | | | 1092 ----------------------+-------------+-------------+------------+ 1094 5.2 Signaling Flows 1095 5.2.1 Free placement of QoS Initiator and QoS Controllers functions 1097 5.2.2 No constraint of the QoS signaling and QoS Controllers to be 1098 in the data path. 1099 5.2.3 Concealment of topology and technology information 1100 5.2.4 Optional transparency of QoS signaling to network 1102 ----------------------+-------------+-------------+------------+ 1103 | host-to-net | access | core | 1104 ----------------------+-------------+-------------+------------+ 1105 5.2.1 | | | | 1106 ----------------------+-------------+-------------+------------+ 1107 5.2.2 | | | | 1108 ----------------------+-------------+-------------+------------+ 1109 5.2.3 | | | | 1110 ----------------------+-------------+-------------+------------+ 1111 5.2.4 | | | | 1112 ----------------------+-------------+-------------+------------+ 1114 5.3 Additional information beyond signaling of QoS information 1115 5.3.1 Explicit release of resources 1116 5.3.2 Possibility for automatic release of resources after failure 1117 5.3.3 Possibility for automatic re-setup of resources after recovery 1118 5.3.4 Prompt notification of QoS violation in case of error / 1119 failure to QoS Initiator and QoS Controllers 1120 5.3.5 Feedback about success of request for QoS guarantees 1121 5.3.6 Allow local QoS information exchange between nodes of the same 1122 administrative domain 1124 ----------------------+-------------+-------------+------------+ 1125 | host-to-net | access | core | 1126 ----------------------+-------------+-------------+------------+ 1127 5.3.1 | | | | 1128 ----------------------+-------------+-------------+------------+ 1129 5.3.2 | | | | 1130 ----------------------+-------------+-------------+------------+ 1131 5.3.3 | | | | 1132 ----------------------+-------------+-------------+------------+ 1133 5.3.4 | | | | 1134 ----------------------+-------------+-------------+------------+ 1135 5.3.5 | | | | 1136 ----------------------+-------------+-------------+------------+ 1137 5.3.6 | | | | 1138 ----------------------+-------------+-------------+------------+ 1139 5.4 Layering 1141 5.4.1 The signaling protocol and QoS control information should be 1142 application independent. 1144 ----------------------+-------------+-------------+------------+ 1145 | host-to-net | access | core | 1146 ----------------------+-------------+-------------+------------+ 1147 5.4.1 | | | | 1148 ----------------------+-------------+-------------+------------+ 1150 5.5 QoS Control Information 1152 5.5.1 Mutability information on parameters 1153 5.5.2 Possibility to add and remove local domain information 1154 5.5.3 Independence of reservation identifier 1155 5.5.4 Seamless modification of already reserved QoS 1156 5.5.5 Signaling must support quantitative, qualitative, and relative 1157 QoS specifications 1159 ----------------------+-------------+-------------+------------+ 1160 | host-to-net | access | core | 1161 ----------------------+-------------+-------------+------------+ 1162 5.5.1 | | | | 1163 ----------------------+-------------+-------------+------------+ 1164 5.5.2 | | | | 1165 ----------------------+-------------+-------------+------------+ 1166 5.5.3 | | | | 1167 ----------------------+-------------+-------------+------------+ 1168 5.5.4 | | | | 1169 ----------------------+-------------+-------------+------------+ 1170 5.5.5 | | | | 1171 ----------------------+-------------+-------------+------------+ 1173 5.6 Performance 1175 5.6.1 Scalability in the number of messages received by a signaling 1176 communication partner (QoS initiator and controller) 1177 5.6.2 Scalability in number of hand-offs 1178 5.6.3 Scalability in the number of interactions for setting up a 1179 reservation 1180 5.6.4 Scalability in the number of state per entity (QoS initiators 1181 and QoS controllers) 1182 5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 1183 5.6.6 Low latency in setup 1184 5.6.7 Allow for low bandwidth consumption for signaling protocol 1185 5.6.8 Ability to constrain load on devices 1186 5.6.9 Highest possible network utilization 1188 ----------------------+-------------+-------------+------------+ 1189 | host-to-net | access | core | 1190 ----------------------+-------------+-------------+------------+ 1191 5.6.1 | | | | 1192 ----------------------+-------------+-------------+------------+ 1193 5.6.2 | | | | 1194 ----------------------+-------------+-------------+------------+ 1195 5.6.3 | | | | 1196 ----------------------+-------------+-------------+------------+ 1197 5.6.4 | | | | 1198 ----------------------+-------------+-------------+------------+ 1199 5.6.5 | | | | 1200 ----------------------+-------------+-------------+------------+ 1201 5.6.6 | | | | 1202 ----------------------+-------------+-------------+------------+ 1203 5.6.7 | | | | 1204 ----------------------+-------------+-------------+------------+ 1205 5.6.8 | | | | 1206 ----------------------+-------------+-------------+------------+ 1207 5.6.9 | | | | 1208 ----------------------+-------------+-------------+------------+ 1210 5.7 Flexibility 1212 5.7.1 Aggregation capability, including the capability to select and 1213 change the level of aggregation. 1214 5.7.2 Flexibility in the placement of the QoS initiator 1215 5.7.3 Flexibility in the initiation of re-negotiation (QoS change 1216 requests) 1217 5.7.4 Uni / bi-directional reservation 1219 ----------------------+-------------+-------------+------------+ 1220 | host-to-net | access | core | 1221 ----------------------+-------------+-------------+------------+ 1222 5.7.1 | | | | 1223 ----------------------+-------------+-------------+------------+ 1224 5.7.2 | | | | 1225 ----------------------+-------------+-------------+------------+ 1226 5.7.3 | | | | 1227 ----------------------+-------------+-------------+------------+ 1228 5.7.4 | | | | 1229 ----------------------+-------------+-------------+------------+ 1231 5.8 Security 1233 5.8.1 The QoS protocol must provide strong authentication 1234 5.8.2 The QoS protocol must provide means to authorize resource 1235 requests 1236 5.8.3 The QoS signaling messages must provide integrity protection. 1237 5.8.4 The QoS signaling messages must be replay protected. 1238 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. 1239 5.8.6 The QoS protocol should allow identity confidentiality and 1240 location privacy. 1241 5.8.7 The QoS protocol should prevent denial-of-service attacks 1242 against signaling entities. 1243 5.8.8 The QoS protocol should support confidentiality of signaling 1244 messages. 1246 5.8.9 The QoS protocol should provide hooks to interact with 1247 protocols that allow the negotiation of authentication and key 1248 management protocols. 1249 5.8.10 The QoS protocol should provide means to interact with key 1250 management protocols. 1252 ----------------------+-------------+-------------+------------+ 1253 | host-to-net | access | core | 1254 ----------------------+-------------+-------------+------------+ 1255 5.8.1 | | | | 1256 ----------------------+-------------+-------------+------------+ 1257 5.8.2 | | | | 1258 ----------------------+-------------+-------------+------------+ 1259 5.8.3 | | | | 1260 ----------------------+-------------+-------------+------------+ 1261 5.8.4 | | | | 1262 ----------------------+-------------+-------------+------------+ 1263 5.8.5 | | | | 1264 ----------------------+-------------+-------------+------------+ 1265 5.8.6 | | | | 1266 ----------------------+-------------+-------------+------------+ 1267 5.8.7 | | | | 1268 ----------------------+-------------+-------------+------------+ 1269 5.8.8 | | | | 1270 ----------------------+-------------+-------------+------------+ 1271 5.8.9 | | | | 1272 ----------------------+-------------+-------------+------------+ 1273 5.8.10 | | | | 1274 ----------------------+-------------+-------------+------------+ 1276 5.9 Mobility 1278 5.9.1 Allow efficient QoS re-establishment after handover 1279 ----------------------+-------------+-------------+------------+ 1280 | host-to-net | access | core | 1281 ----------------------+-------------+-------------+------------+ 1282 5.9.1 | | | | 1283 ----------------------+-------------+-------------+------------+ 1285 5.10 Interworking with other protocols and techniques 1287 5.10.1 Interworking with IP tunneling 1288 5.10.2 The solution should not constrain either to IPv4 or IPv6 1290 5.10.3 Independence from charging model 1291 5.10.4 The QoS protocol should provide hooks for AAA protocols 1293 ----------------------+-------------+-------------+------------+ 1294 | host-to-net | access | core | 1295 ----------------------+-------------+-------------+------------+ 1296 5.10.1 | | | | 1297 ----------------------+-------------+-------------+------------+ 1298 5.10.2 | | | | 1299 ----------------------+-------------+-------------+------------+ 1300 5.10.3 | | | | 1301 ----------------------+-------------+-------------+------------+ 1302 5.10.4 | | | | 1303 ----------------------+-------------+-------------+------------+ 1305 5.11 Operational 1306 5.11.1 Ability to assign transport quality to signaling messages 1308 ----------------------+-------------+-------------+------------+ 1309 | host-to-net | access | core | 1310 ----------------------+-------------+-------------+------------+ 1311 5.11.1 | | | | 1312 ----------------------+-------------+-------------+------------+ 1314 7 References 1316 [1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem 1317 Statement", RFC 3132, June 2001. 1319 [2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP", 1320 draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress, 1321 August 2001 1323 [3] Manner. J., et al, "Mobility Related Terminology", draft-manner- 1324 seamoby-terms-02.txt, Work In Progress, July 2001. 1326 [4] 3GPP, "General Packet Radio Service (GPRS); Service Description 1327 Stage 2 v 7.7.0", TS 03.60, June 2001 1329 [5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum 1330 System, revision B", S.R0005-B, May 2001 1332 [6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling 1333 BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001 1335 [7] Partain, D., et al, "Resource Reservation Issues in Cellular 1336 Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt, 1337 Work in Progress, June 2001. 1339 [8] YESSIR - YEt another Sender Session Internet Reservations, 1340 http://www.cs.columbia.edupingpan/projects/yessir.html 1342 [9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1343 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1344 Specification", IETF RFC 2205, 1997. 1346 [10] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G., 1347 Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource 1348 Management in Diffserv Framework", Internet draft, work in progress, 1349 draft-westberg-rmd-framework-xx.txt, 2002. 1351 [11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA 1352 Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt, 1353 Work in progress, September 2001. 1355 8 Appendix: Scenarios/Use cases 1357 In the following we describe scenarios, which are important to 1358 cover, and which allow us to discuss various requirements. Some 1359 regard this as use cases to be covered defining the use of a QoS 1360 signaling protocol. 1362 8.1 Scenario: Terminal Mobility 1364 The scenario we are looking at is the case where a mobile terminal 1365 (MT) changes from one access point to another access point. The 1366 access points are located in separate QoS domains. We assume Mobile 1367 IP to handle mobility on the network layer in this scenario and 1368 consider the various extensions (i.e., IETF proposals) to Mobile IP, 1369 in order to provide 'fast handover' for roaming Mobile Terminals. 1370 The goal to be achieved lies in providing, keeping, and adapting the 1371 requested QoS for the ongoing IP sessions in case of handover. 1372 Furthermore, the negotiation of QoS parameters with the new domain 1373 via the old connection might be needed, in order to support the 1374 different 'fast handover' proposals within the IETF. 1376 The entities involved in this scenario include a mobile terminal, 1377 access points, an access network manager, communication partners of 1378 the MT (the other end(s) of the communication association). 1379 From a technical point of view, terminal mobility means changing the 1380 access point of a mobile terminal (MT). However, technologies might 1381 change in various directions (access technology, QoS technology, 1382 administrative domain). If the access points are within one specific 1383 QoS technology (independent of access technology) we call this 1384 intra-QoS technology handoff. In the case of an inter-QoS technology 1385 handoff, one changes from e.g. a DiffServ to an IntServ domain, 1386 however still using the same access technology. Finally, if the 1387 access points are using different access technologies we call it 1388 inter-technology hand-off. 1390 The following issues are of special importance in this scenario: 1392 1) Handoff decision 1394 - The QoS management requests handoff. The QoS management can decide 1395 to change the access point, since the traffic conditions of the new 1396 access point are better supporting the QoS requirements. The metric 1397 may be different (optimized towards a single or a group/class of 1398 users). Note that the MT or the network (see below) might trigger 1399 the handoff. 1401 - The mobility management forces handoff. This can have several 1402 reasons. The operator optimizes his network, admission is no longer 1403 granted (e.g. emptied prepaid condition). Or another example is when 1404 the MT is reaching the focus of another base station. However, this 1405 might be detected via measurements of QoS on the physical layer and 1406 is therefore out of scope of QoS signaling in IP. Note again that 1407 the MT or the network (see below) might trigger the handoff. 1409 - This scenario shows that local decisions might not be enough. The 1410 rest of the path to the other end of the communication needs to be 1411 considered as well. Hand-off decisions in a QoS domain, does not 1412 only depend on the local resource availability, e.g., the wireless 1413 part, but involves the rest of the path as well. Additionally, 1414 decomposition of an end-to-end reservation might be needed, in order 1415 to change only parts of it. 1417 2) Trigger sources 1419 - Mobile terminal: If the end-system QoS management identifies 1420 another (better-suited) access point, it will request the handoff 1421 from the terminal itself. This will be especially likely in the case 1422 that two different provider networks are involved. Another important 1423 example is when the current access point bearer disappears (e.g. 1424 removing the Ethernet cable). In this case, the QoS initiator is 1425 basically located on the mobile terminal. 1427 - Network (access network manager): Sometimes, the handoff trigger 1428 will be issued from the network management to optimize the overall 1429 load situation. Most likely this will result in changing the base- 1430 station of a single providers network. Most likely the QoS initiator 1431 is located on a system within the network. 1433 3) Integration with other protocols 1435 - Interworking with other protocol must be considered in one or the 1436 other form. E.g., it might be worth combining QoS signaling between 1437 different QoS domains with mobility signaling at hand-over. 1439 4) Handover rates 1441 In mobile networks, the admission control process has to cope with 1442 far more admission requests than call setups alone would generate. 1443 For example, in the GSM (Global System for Mobile communications) 1444 case, mobility usually generates an average of one to two handovers 1445 per call. For third generation networks (such as UMTS), where it is 1446 necessary to keep radio links to several cells simultaneously 1447 (macro-diversity), the handover rate is significantly higher (see 1448 for example [11]) 1450 5) Fast reservations 1452 Handover can also cause packet losses. This happens when the 1453 processing of an admission request causes a delayed handover to the 1454 new base station. In this situation, some packets might be 1455 discarded, and the overall speech quality might be degraded 1456 significantly. Moreover, a delay in handover may cause degradation 1457 for other users. In the worst case scenario, a delay in handover may 1458 cause the connection to be dropped if the handover occurred due to 1459 bad air link quality. Therefore, it is critical that QoS signalling 1460 in connection with handover be carried out very quickly. 1462 6) Call blocking in case of overload 1464 Furthermore, when the network is overloaded, it is preferable to 1465 keep reservations for previously established flows while blocking 1466 new requests. Therefore, the resource reservation requests in 1467 connection with handover should be given higher priority than new 1468 requests for resource reservation. 1470 8.2 Scenario: Cellular Networks 1472 In this scenario, the user is using the packet service of a 3rd 1473 generation cellular system, e.g. UMTS. The region between the End 1474 Host and the edge node connecting the cellular network to another 1475 QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is 1476 considered to be a single QoS domain [4][5]. 1478 The issues in such an environment regarding QoS include: 1480 1) Cellular systems provide their own QoS technology with 1481 specialized parameters to co-ordinate the QoS provided by both the 1482 radio access and wired access network. For example, in a UMTS 1483 network, one aspect of GPRS is that it can be considered as a QoS 1484 technology; provisioning of QoS within GPRS is described mainly in 1485 terms of calling UMTS bearer classes. This QoS technology needs to 1486 be invoked with suitable parameters when a request for QoS is 1487 triggered by higher layers, and this therefore involves mapping the 1488 requested IP QoS onto these UMTS bearer classes. This request for 1489 resources might be triggered by IP signaling messages that pass 1490 across the cellular system, and possibly other QoS domains, to 1491 negotiate for network resources. Typically, cellular system specific 1492 messages invoke the underlying cellular system QoS technology in 1493 parallel with the IP QoS negotiation, to allocate the resources 1494 within the cellular system. 1496 2) The placement of QoS initiators and QoS controllers (terminology 1497 in the framework given here). The QoS initiator could be located at 1498 the End Host (triggered by applications), the GGSN/PDSN, or at a 1499 node not directly on the data path, such as a bandwidth broker. In 1500 the second case, the GGSN/PDSN could either be acting as a proxy on 1501 behalf of an End Host with little capabilities, and/or managing 1502 aggregate resources within its QoS domain (the UMTS core network). 1503 The IP signaling messages are interpreted by the QoS controllers, 1504 which may be located at the GGSN/PDSN, and in any QoS sub-domains 1505 within the cellular system. 1507 3) Initiation of IP-level QoS negotiation. IP-level QoS re- 1508 negotiation may be initiated by either the End Host, or by the 1509 network, based on current network loads, which might change 1510 depending on the location of the end host. 1512 4) The networks are designed and mainly used for speech 1513 communication (at least so far). 1515 Note that in comparison to the former scenario, the emphasis is much 1516 less on the mobility aspects, because mobility is mainly handled on 1517 the lower layer. 1519 8.3 Scenario: UMTS access 1521 The UMTS access scenario is shown in figure 3. The Proxy-Call State 1522 Control Function/Policy Control Function (P-CSCF/PCF) is the 1523 outbound SIP proxy of the visited domain, i.e. the domain where the 1524 mobile user wants to set-up a call. The Gateway GPRS Support Node 1525 (GGSN) is the egress router of the UMTS domain and connects the UMTS 1526 access network to the Edge Router (ER) of the core IP network. The 1527 P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The 1528 User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal 1529 Equipment (TE), e.g. a laptop. 1531 +--------+ 1532 +----------| P-CSCF |-------> SIP signaling 1533 / +--------+ 1534 / SIP : 1535 : +--------+ NSIS +----------------+ 1536 : | PCF |---------| QoS Controller | 1537 : +--------+ +----------------+ 1538 : : 1539 : : COPS 1540 : : 1541 +----+ +--------+ +----+ 1542 | UE |----------| GGSN |------| ER | 1543 +----+ +--------+ +----+ 1545 Figure 1: UMTS access scenario 1547 In this scenario the GGSN has the role of Access Gate. According to 1548 3GPP standardization, the PCF is responsible for the policy-based 1549 control of the end-user service in the UMTS access network (i.e. 1550 from UE to GGSN). In the current UMTS release R.5, the PCF is part 1551 of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF 1552 may evolve to an open standardized interface. In any case the PCF 1553 has all required QoS information for per-flow admission control in 1554 the UMTS access network (which it gets from the P-CSCF and/or GGSN). 1555 Thus the PCF would be the appropriate entity to host the 1556 functionality of QI, initiating the "NSIS" QoS signaling towards the 1557 core IP network. The PCF/P-CSCF has to do the mapping from codec 1558 type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP 1559 extensions to explicitly signal QoS information [7] are useful to 1560 avoid the need to store codec information in the PCF and to allow 1561 for more flexibility and accurate description of the QoS traffic 1562 parameters. The PCF also controls the GGSN to open and close the 1563 gates and to configure per-flow policers, i.e. to authorize or 1564 forbid user traffic. 1566 The QC is (of course) not part of the standard UMTS architecture. 1567 However, to achieve end-to-end QoS a QC is needed such that the PCF 1568 can request a QoS connection to the IP network. As in the previous 1569 example, the QC could manage a set of pre-provisioned resources in 1570 the IP network, i.e. bandwidth pipes, and the QC performs per-flow 1571 admission control into these pipes. In this way, a connection can be 1572 made between two UMTS access networks, and hence, end-to-end QoS can 1573 be achieved. In this case the QI and QC are clearly two separate 1574 entities. 1575 This use case clearly illustrates the need for an "NSIS" QoS 1576 signaling protocol between QI and QC. An important application of 1577 such a protocol may be its use in the inter-connection of UMTS 1578 networks over an IP backbone. 1580 8.4 Wired part of wireless network 1582 A wireless network, seen from a QoS domain perspective, usually 1583 consists of three parts: a wireless interface part (the "radio 1584 interface"), a wired part of the wireless network (i.e., Radio 1585 Access Network) and the backbone of the wireless network, as shown 1586 in Figure 2. Note that this figure should not be seen as an 1587 architectural overview of wireless networks but rather as showing 1588 the conceptual QoS domains in a wireless network. 1590 In this scenario, a mobile host can roam and perform a handover 1591 procedure between base stations/access routers. In this scenario the 1592 NSIS QoS protocol can be applied between a base station and the 1593 gateway (GW). In this case a GW can also be considered as a local 1594 handover anchor point. Furthermore, in this scenario the NSIS QoS 1595 protocol can also be applied either between two GWs, or between two 1596 edge routers (ER). 1598 |--| 1599 |GW| 1600 |--| |--| 1601 |MH|--- . 1602 |--| / |-------| . 1603 /--|base | |--| . 1604 |station|-|ER|.... 1605 |-------| |--| . |--| back- |--| |---| 1606 |----| 1608 ...|ER|.......|ER|..|BGW|.."Internet"..|host| 1609 -- |-------| |--| . |--| bone |--| |---| 1610 |----| 1611 |--| \ |base |-|ER|... . 1612 |MH| \ |station| |--| . 1613 |--|--- |-------| . MH = mobile host 1614 |--| ER = edge router 1615 <----> |GW| GW = gateway 1616 Wireless link |--| BGW = border gateway 1617 ... = interior nodes 1618 <-------------------> 1619 Wired part of wireless network 1621 <----------------------------------------> 1622 Wireless Network 1624 Figure 2. QoS architecture of wired part of wireless network 1626 Each of these parts of the wireless network impose different issues 1627 to be solved on the QoS signaling solution being used: 1629 * Wireless interface: The solution for the air interface link 1630 has to ensure flexibility and spectrum efficient transmission 1631 of IP packets. However, this link layer QoS can be solved in 1632 the same way as any other last hop problem by allowing a 1633 host to request the proper QoS profile. 1635 * Wired part of the wireless network: This is the part of 1636 the network that is closest to the base stations/access 1637 routers. It is an IP network although some parts logically 1638 perform tunneling of the end user data. In cellular networks, 1639 the wired part of the wireless network is denoted as a 1640 radio access network. 1642 This part of the wireless network has different 1643 characteristics when compared to traditional IP networks: 1645 1. The network supports a high proportion of real-time 1646 traffic. The majority of the traffic transported in the 1647 wired part of the wireless network is speech, which is 1648 very sensitive to delays and delay variation (jitter). 1650 2. The network must support mobility. Many wireless 1651 networks are able to provide a combination of soft 1652 and hard handover procedures. When handover occurs, 1653 reservations need to be established on new paths. 1654 The establishment time has to be as short as possible 1655 since long establishment times for reservations degrade 1656 the performance of the wireless network. Moreover, 1657 for maximal utilization of the radio spectrum, frequent 1658 handover operations are required. 1660 3. These links are typically rather bandwidth-limited. 1662 4. The wired transmission in such a network contains a 1663 relatively high volume of expensive leased lines. 1664 Overprovisioning might therefore be prohibitively 1665 expensive. 1667 5. The radio base stations are spread over a wide 1668 geographical area and are in general situated a large 1669 distance from the backbone. 1671 * Backbone of the wireless network: the requirements imposed 1672 by this network are similar to the requirements imposed by 1673 other types of backbone networks. 1675 Due to these very different characteristics and requirements, often 1676 contradictory, different QoS signalling solutions might be needed in 1677 each of the three network parts. 1679 8.5 Scenario: Session Mobility 1681 In this scenario, a session is moved from one end-system to another. 1682 Ongoing sessions are kept and QoS parameters need to be adapted, 1683 since it is very likely that the new device provides different 1684 capabilities. Note that it is open which entity initiates the move, 1685 which implies that the QoS initiator might be triggered by different 1686 entities. 1688 User mobility (i.e., a user changing the device and therefore moving 1689 the sessions to the new device) is considered to be a special case 1690 within the session mobility scenario. 1692 Note that this scenario is different from terminal mobility. Not the 1693 terminal (end-system) has moved to a different access point. Both 1694 terminals are still connected to an IP network at their original 1695 points. 1697 The issues include: 1699 1) Keeping the QoS guarantees negotiated implies that the end- 1700 point(s) of communication are changed without changing the 1701 reservations. 1703 2) The trigger of the session move might be the user or any other 1704 party involved in the session. 1706 8.6 Scenario: QoS reservations/negotiation from access to core network 1708 The scenario includes the signaling between access networks and core 1709 networks in order to setup and change reservations together with 1710 potential negotiation. 1712 The issues to be solved in this scenario are different from previous 1713 ones. 1715 1) The entity of reservation is most likely an aggregate. 1717 2) The time scales of reservations might be different (long living 1718 reservations of aggregates, rarer re-negotiation). 1720 3) The specification of the traffic (amount of traffic), a 1721 particular QoS is guaranteed for, needs to be changed. E.g., in case 1722 additional flows are added to the aggregate, the traffic 1723 specification of the flow needs to be added if it is not already 1724 included in the aggregates specification. 1726 4) The flow specification is more complex including network 1727 addresses and sets of different address for the source as well as 1728 for the destination of the flow. 1730 8.7 Scenario: QoS reservation/negotiation over administrative 1731 boundaries 1733 Signaling between two or more core networks to provide QoS is 1734 handled in this scenario. This might also include access to core 1735 signaling over administrative boundaries. Compared to the previous 1736 one it adds the case, where the two networks are not in the same 1737 administrative domain. Basically, it is the inter-domain/inter 1738 provider signaling which is handled in here. 1740 The domain boundary is the critical issue to be resolved. Which as 1741 various flavors of issues a QoS signaling protocol has to be 1742 concerned with. 1744 1) Competing administrations: Normally, only basic information 1745 should be exchanged, if the signaling is between competing 1746 administrations. Specifically information about core network 1747 internals (e.g., topology, technology, etc.) should not be 1748 exchanged. Some information exchange about the "access points" of 1749 the core networks (which is topology information as well) may need 1750 to be exchanged, because it is needed for proper signaling. 1752 2) Additionally, as in scenario 4, signaling most likely is based on 1753 aggregates, with all the issues raise there. 1755 3) Authorization: It is critical that the QoS initiator is 1756 authorized to perform a QoS path setup. 1758 4) Accountability: It is important to notice that signaling might be 1759 used as an entity to charge money for, therefore the interoperation 1760 with accounting needs to be available. 1762 8.8 Scenario: QoS signaling between PSTN gateways and backbone routers 1764 A PSTN gateway (i.e., host) requires information from the network 1765 regarding its ability to transport voice traffic across the network. 1766 The voice quality will suffer due to packet loss, latency and 1767 jitter. Signaling is used to identify and admit a flow for which 1768 these impairments are minimized. In addition, the disposition of 1769 the signaling request is used to allow the PSTN GW to make a call 1770 routing decision before the call is actually accepted and delivered 1771 to the final destination. 1773 PSTN gateways may handle thousands of calls simultaneously and there 1774 may be hundreds of PSTN gateways in a single provider network. These 1775 numbers are likely to increase as the size of the network increases. 1776 The point being that scalability is a major issue. 1778 There are several ways that a PSTN gateway can acquire assurances 1779 that a network can carry its traffic across the network. These 1780 include: 1782 1. Over-provisioning a high availability network. 1783 2. Handling admission control through some policy server 1784 that has a global view of the network and its resources. 1785 3. Per PSTN GW pair admission control. 1786 4. Per call admission control (where a call is defined as 1787 the 5 tuple used to carry a single RTP flow). 1789 Item 1 requires no signaling at all and is therefore outside the 1790 scope of this working group. 1792 Item 2 is really a better informed version of 1, but it is also 1793 outside the scope of this working group as it relies on a particular 1794 telephony signaling protocol rather than a packet admission control 1795 protocol. 1797 Item 3 is initially attractive as it appears to have reasonable 1798 scaling properties, however, its scaling properties only are 1799 effective in cases where there are relatively few PSTN GWs. In the 1800 more general case were a PSTN GW reduces to a single IP phone 1801 sitting behind some access network, the opportunities for 1802 aggregation are reduced and the problem reduces to item 4. 1804 Item 4 is the most general case. However, it has the most difficult 1805 scaling problems. The objective here is to place the requirements on 1806 Item 4 such that a scalable per-flow admission control protocol or 1807 protocol suite may be developed. 1809 The case where per-flow signaling extends to individual IP end- 1810 points allows the inclusion of IP phones on cable, DSL, wireless or 1811 other access networks in this scenario. 1813 Call Scenario 1815 A PSTN GW signals end-to-end for some 5 tuple defined flow a 1816 bandwidth and QoS requirement. Note that the 5 tuple might include 1817 masking/wildcarding. The access network admits this flow according 1818 to its local policy and the specific details of the access 1819 technology. 1821 At the edge router (i.e., border node), the flow is admitted, again 1822 with an optional authentication process, possibly involving an 1823 external policy server. Note that the relationship between the PSTN 1824 GW and the policy server and the routers and the policy server is 1825 outside the scope of NSIS. The edge router then admits the flow into 1826 the core of the network, possibly using some aggregation technique. 1828 At the interior nodes, the NSIS host-to-host signaling should either 1829 be ignored or invisible as the Edge router performed the admission 1830 control decision to some aggregate. 1832 At the inter-provider router (i.e., border node), again the NSIS 1833 host-to-host signaling should either be ignored or invisible as the 1834 Edge router has performed an admission control decision about an 1835 aggregate across a carrier network. 1837 8.9 PSTN trunking gateway 1839 One of the use cases for the NSIS signaling protocol is the scenario 1840 of interconnecting PSTN gateways with an IP network that supports 1841 QoS. 1842 Four different scenarios are considered here. 1843 1. In-band QoS signaling is used. In this case the Media Gateway 1844 (MG) will be acting as the QoS Initiator and the Edge Router 1845 (ER) will be the QoS Controller. Hence, the ER should do 1846 admission control (into pre-provisioned traffic trunks) for the 1847 individual traffic flows. This scenario is not further 1848 considered here. 1849 2. Out-of-band signaling in a single domain, the QoS Controller is 1850 integrated in the MGC. In this case no NSIS protocol is 1851 required. 1852 3. Out-of-band signaling in a single domain, the QoS Controller is 1853 a separate box. In this case NSIS signaling is used between the 1854 MGC and the QoS Controller. 1855 4. Out-of-band signaling between multiple domains, the QoS 1856 Controller (which may be integrated in the MGC) triggers the 1857 QoS Controller of the next domain. 1859 When the out-of-band QoS signaling is used the Media Gateway 1860 Controller (MGC) will be acting as the QoS Initiator. 1862 In the second scenario the voice provider manages a set of traffic 1863 trunks that are leased from a network provider. The MGC does the 1864 admission control in this case. Since the QoS Controller acts both 1865 as a QoS Initiator and a QoS Controller, no NSIS signaling is 1866 required. This scenario is shown in figure 1. 1868 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1869 | SS7 network |---------------------| MGC |--------------| SS7 | 1870 +-------------+ +-------+-----+---------+ +-----+ 1871 : / : \ 1872 : / : \ 1873 : / +--------:----------+ \ 1874 : MEGACO / / : \ \ 1875 : / / +-----+ \ \ 1876 : / / | NMS | \ \ 1877 : / | +-----+ | \ 1878 : : | | : 1879 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1880 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1881 +--------------+ +----+ \ / +----+ 1882 \ QoS network / 1883 +-------------------+ 1884 Figure 1: PSTN trunking gateway scenario 1886 In the third scenario, the voice provider does not lease traffic 1887 trunks in the network. Another entity may lease traffic trunks and 1888 may use a QoS Controller to do per-flow admission control. In this 1889 case the NSIS signaling is used between the MGC and the QoS 1890 Controller, which is a separate box here. Hence, the MGC acts only 1891 as a QoS Initiator. This scenario is depicted in figure 2. 1893 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1894 | SS7 network |---------------------| MGC |--------------| SS7 | 1895 +-------------+ +-------+-----+---------+ +-----+ 1896 : / : \ 1897 : / +-----+ \ 1898 : / | QC | \ 1899 : / +-----+ \ 1900 : / : \ 1901 : / +--------:----------+ \ 1902 : MEGACO : / : \ : 1903 : : / +-----+ \ : 1904 : : / | NMS | \ : 1905 : : | +-----+ | : 1906 : : | | : 1907 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1908 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1909 +--------------+ +----+ \ / +----+ 1910 \ QoS network / 1911 +-------------------+ 1913 Figure 2: PSTN trunking gateway scenario 1915 In the fourth scenario multiple transport domains are involved. In 1916 the originating network either the MGC may have an overview on the 1917 resources of the overlay network or a separate QoS Controller will 1918 have the overview. Hence, depending on this either the MGC or the 1919 QoS Controller of the originating domain will contact the QoS 1920 Controller of the next domain. The MGC always acts as a QoS 1921 Initiator and may also be acting as a QoS Controller in the first 1922 domain. 1924 8.10 Scenario: Application request end-to-end QoS path from the 1925 network 1927 This is actually the most easy case, nevertheless might be most 1928 often used in terms of number of users. So multimedia application 1929 requests a guaranteed service from an IP network. We assume here 1930 that the application is somehow able to specify the network service. 1931 The characteristics here are that many hosts might do it, but that 1932 the requested service is low capacity (bounded by the access line). 1933 Additionally, we assume no mobility and standard devices. 1935 9 Acknowledgments 1937 Quite a number of people have been involved in the discussion of the 1938 draft, adding some ideas, requirements, etc. We list them without a 1939 guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul 1940 (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas 1941 Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), 1942 Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 1943 University Berlin), Xiaoming Fu (Technical University Berlin), Hans- 1944 Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph 1945 Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya 1946 Freytsis. 1948 Some text and/or ideas for text, requirements, scenarios have been 1949 taken from a draft written by the following authors: David Partain 1950 (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), 1951 Georgios Karagiannis (Ericsson), Jukka Manner (University of 1952 Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 1953 Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have 1954 actively contributed new text to the draft as well. 1956 Another draft impacting this draft has been written by Sven Van den 1957 Bosch, Maarten Buchli, and Danny Goderis. These people contributed 1958 also with new text. 1960 10 Author's Addresses 1962 Marcus Brunner (Editor) 1963 NEC Europe Ltd. 1964 Network Laboratories 1965 Adenauerplatz 6 1966 D-69115 Heidelberg 1967 Germany 1968 E-Mail: brunner@ccrle.nec.de (contact) 1970 Robert Hancock, Eleanor Hepworth 1971 Roke Manor Research Ltd 1972 Romsey, Hants, SO51 0ZN 1973 United Kingdom 1974 E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk 1976 Cornelia Kappler 1977 Siemens AG 1978 Berlin 13623 1979 Germany 1980 E-Mail: cornelia.kappler@icn.siemens.de 1982 Hannes Tschofenig 1983 Siemens AG 1984 Otto-Hahn-Ring 6 1985 81739 Munchen 1986 Germany 1987 Email: Hannes.Tschofenig@mchp.siemens.de 1988 Full Copyright Statement 1989 Copyright (C) The Internet Society (2000). All Rights Reserved. 1990 This document and translations of it may be copied and furnished to 1991 others, and derivative works that comment on or otherwise explain it 1992 or assist in its implementation may be prepared, copied, published 1993 and distributed, in whole or in part, without restriction of any 1994 kind, provided that the above copyright notice and this paragraph are 1995 included on all such copies and derivative works. However, this 1996 document itself may not be modified in any way, such as by removing 1997 the copyright notice or references to the Internet Society or other 1998 Internet organizations, except as needed for the purpose of 1999 developing Internet standards in which case the procedures for 2000 copyrights defined in the Internet Standards process must be 2001 followed, or as required to translate it into languages other than 2002 English. 2003 The limited permissions granted above are perpetual and will not be 2004 revoked by the Internet Society or its successors or assigns. 2005 This document and the information contained herein is provided on an 2006 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2007 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 2008 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2009 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2010 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2012 Open Issues/To Dos 2014 1) (OPEN) add Scenarios 2015 Do we need to add, remove, or change the scenarios? 2016 - added scenario on QoS signalling between PSTN gateways and 2017 backbone routers 2018 - added: Application request end-to-end QoS path from the network 2020 We can what ever scenario we want. The more the better to understand 2021 the issues. Nevertheless, we have to take care that we are future 2022 prove as well. 2024 2) (OPEN) Sender/receiver initiation 2026 What is the requirement concerning data sender or data receiver or 2027 both to initiate a QoS request. 2029 Terminology text added 2031 open issue, what is a potential req (currently we say "both must be 2032 possible") 2034 Proposals: 2035 1)should be optimized for sender initiated 2036 2) remove the requirement, because it is not relevant if we allow 2037 for third party QoS initiators 2038 3) SHOULD support sender initiated, MAY support reciever initiated 2040 Issues: 2042 - does it matter who pays? 2044 - for sender initiated, can we support implicit signaling 2045 (bundling the QoS requests with other signaling - registration, 2046 etc.)? 2048 - For reciever initiated, do we need protection against spamming - 2049 how do we protect against unwanted changes? 2051 3) (CLOSED) Draft organization 2053 The proposed changes include 2054 - put all the scenarios into an appendix 2055 - In Section 6 add text describing 3 different "parts of the 2056 network" 2057 -Host to first hop 2058 -access network 2059 -core networks 2060 better names are welcome, but I don't want to be religious about 2061 it 2063 - Prioritize the requirements according to the "parts of the 2064 network" (This means the the tables in Section 6 of the current 2065 draft will get three colums with the MUST, SHOULDs, and MAYs for 2066 each requirement 2068 4) (OPEN) MUSTs, SHOULDs, MAY needs discussion 2070 5) (CLOSED) Framework text. 2071 The figures have been removed, because they seamed to be misleading. 2072 the text has been revisited. I regard the issue closed until we have 2073 a clear picture about what the NSIS framework draft is about. 2075 6) (CLOSED) The requirement organization 2076 I heard some voices on the list that the grouping should be more 2077 along the lines of host-to-edge, edge to edge etc. 2078 So far I have not changed it, because I though that the requirements 2079 heavily depend on the scenario we are looking at. 2081 closed, by the change in the draft organisation (issue 3) 2083 7) (OPEN) Hemant Chaskar: Section 3.1, items 1) Handoff decision and 2084 2) Trigger sources: The handoff decision and trigger sources should 2085 be out of scope of NSIS. NSIS should rather focus only on 2086 "establishing" QoS along the packet path after handoff. 2088 needs more WG discussion, potentially even cross-WG 2090 8) (OPEN) bi-directional data path setup with one QoS request 2091 I have not seen consensus on whether to require bi-directional data 2092 path setup with QoS. 2094 Q: How can we actually perform bi-directional reservations when the 2095 forward and reverse paths are not reciprocal, with respect to 2096 routing topology and routing policy of network domains between 2097 sender and receiver? 2099 A: bi-directional data path setup does not need to use the same 2100 return path as the forwarding path. The only requirement to achieve 2101 a bi-directional reservation is that the sender for the forwarding 2102 path is also the receiver for the return path and that the receiver 2103 for the forwarding path is also the sender for the return path. 2105 - The need to ensure that the return path is the same as the 2106 forwarding path is one of the problems with RSVP, particularly in a 2107 mobile environment. 2109 9) (CLOSED) Potential requirement: must be implementable in user 2110 space (on end hosts) 2112 has not been included in the req list because it seams to be 2113 implementation specific. 2115 10) (CLOSED) Potential requirement: must provide support for 2116 globally defined services as well as private services (Ruediger) 2118 replaced by issue 17 and 18, closed 2120 11) (CLOSED) Potential requirement: Flexibility in the granularity 2121 of reservation (I don't remember who brought it up, but I assume it 2122 refers to the flexibility in terms of what size the flow has. Where 2123 size can be bandwidth etc.) 2125 The assumption that QoS classes as well as service definitions are 2126 out of scope for this draft, also the flexibility is. 2128 12) (CLOSED) text replacing scalability reqs 2130 "The nsis architecture should give the ability to constrain the load 2131 (CPU load, memory space, signaling bandwidth consumption and 2132 signaling intensity) on devices where it is needed. This can be 2133 achieved by many different methods, for example message aggregation, 2134 by ignoring signaling message, header compression or minimizing 2135 functionality. The architecture may choose any of these methods as 2136 long as the requirement is met." 2138 Editor: added the draft text, but did not remove scalability reqs 2140 13) (CLOSED) add operator req "Ability to assign transport quality 2141 to signaling messages" 2142 "The nsis architecture should allow the network operator to assign 2143 the nsis protocol messages a certain transport quality. As signaling 2144 opens up for possible denial-of-service attacks, this requirement 2145 gives the network operator a mean, but also the obligation, to 2146 trade-off between signaling latency and the impact (from the 2147 signaling messages) on devices within his/her network. From protocol 2148 design this requirement states that the protocol messages should be 2149 detectable, at least where the control and assignment of the 2150 messages priority is done." 2152 text has been added 2154 14) (OPEN, dependend on resolution of bi-directional) proposal to 2155 add "support grouping of microflows (possibly only for feedback)" 2156 "As a consequence of the optimization for the interactive multimedia 2157 services, the signaling should allow one unique request for several 2158 micro flows having the same origination and destination IP 2159 addresses. This is usually the case for multimedia SIP calls where 2160 the voice and video micro flows follow the same path. This grouping 2161 of requests allows optimization of the QoS processing. Note that 2162 this may be detrimental for the call setup time. The use of grouping 2163 for microflows may be restricted to teardown and/or notification 2164 messages when call setup time is a concern." 2166 open issue: first resolve the bi-directional issue which is somewhat 2167 related, because it seams to be an optimization as well 2169 Should not be restrict to teardown and/or notification, it might be 2170 useful also for the procedure that refreshes reservation states 2172 15) (CLOSED) Support for preemption of sessions 2173 -might play into the fault/ error handling case 2174 -is regarded as service-specific, whether existing sessions can be 2175 pre-empted 2176 Conclusion: it is network policy to determine how to do pre-emption, 2177 not a protocol issue. 2179 16) (OPEN) Req: 5.1.9 change provisioning into better term, since 2180 different people understand different thing with provisioning 2182 open action for Anders 2184 17) (CLOSED) add assumption that QoS classes/service definitions are 2185 already known to all the parties involved in signaling before hand 2186 (before a signalling session even starts 2188 added text in Section 4.1 2190 18) (CLOSED) add exclusion of methods, protocols, and ways to 2191 express QoS 2192 Even so, this might be covered by saying that we are independent of 2193 QoS classes and service description etc. (see issue 17), I added two 2194 points to the exclusion Section 4.2. 2196 Implications: issue 20, 23, 2198 19) (CLOSED) remove req 5.2.5 IP fragmentation 2199 20) (CLOSED) remove req 5.3.2 Ability to signal life-time of a 2200 reservation 2202 is regarded service-specific therefore part of the service 2203 description 2205 added some reservation life time text service description assumption 2206 text and removed the req 2208 21) (CLOSED) remove req 5.5.4 Aggregation method specification 2210 Concerns 2211 -QI not able to know the impact of aggregation 2212 -to far down the implementation/ service definition road 2213 -leave it to the provider how a service is realized 2215 removed 2217 22) (CLOSED) remove 5.3.7 Automatic notification on available 2218 resources not been granted before 2220 regarded to complex and is heavily dependend on the service 2221 description 2223 removed 2225 23) (CLOSED) remove 5.5.3 Simple mapping to lower-layer QoS 2226 provisioning parameters 2228 this heavily depends on service definition and therefore is out of 2229 scope of this document 2231 removed 2233 24) (CLOSED) Replacing req 5.3.6 "Feedback about the actually 2234 received level of QoS guarantees" with two requirements: 1) the 2235 feedback of a request MUST include yes and no (MUST respond yes or 2236 no) 2) in case of no it MAY include an opaque service-specific 2237 information about what would be possible 2239 It is still only one requirement, but the text has been replaced. 2241 25) (CLOSED) remove req 5.10.3 Combination with Mobility management 2243 However the integration should not be a priori excluded, there is 2244 explicitly no statemant about independence of mobility management. 2246 There is more discussion for the mobility case needed anyway. 2248 26) (OPEN) interaction of NSIS with seamoby (context transfer and 2249 CAR discovery) 2251 27) (CLOSED) remove req 5.5.10 QoS conformance specification 2252 Motivation: this heavily depends on the service definition and is 2253 therefore out of scope 2255 removed 2257 28) (OPEN) new requirement on "asynchronous events from the network" 2259 The content of the message might be very service specific, but the 2260 protocol support for asynchronous events from the network might be a 2261 valuable requirement. We have something about notification in case 2262 of errors/failures. 2264 29) (OPEN) NSIS in case of handovers 2265 The whole mobility area needs to be defined 2267 30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in 2268 various dimensions) 2270 removed because it seams to be obvious 2272 31) (CLOSED) remove 5.1.8 Possibility to use the signaling protocol 2273 for existing local technologies 2275 It is contradictory to 5.1.9 and the intention behind the 2276 requirement is covered by the requierement that the QoS controller 2277 can be placed wherever needed. 2279 32) (CLOSED) add assumption: there are means for discovery of nsis 2280 entities in order to know the signaling peers (solutions include 2281 static configuration, or automatically discovered etc.) 2283 33) (CLOSED) add req " highest possible network utilization" 2284 "There are networking environments that require high network 2285 utilization for various reasons, and the signaling protocol should 2286 to its best ability support high resource utilization while 2287 maintaining appropriate QoS. 2289 In networks where resources are very expensive (as is the case for 2290 many wireless networks), efficient network utilization is of 2291 critical financial importance. On the other hand there are other 2292 parts of the network where high utilization is not required. 2293 " 2295 req added 2297 34) (CLOSED)_difference between "UMTS access scenario" "cellular 2298 network scenario", and "Wired part of wireless network" (Section 2299 8.2, 8.3, and 8.4) 2301 all three are included. 2302 The only common point between the three scenarios is that they are 2303 related to cellular networks. Section 8.4 is introducing the 2304 scenario used in the radio access network of cellular networks. 2306 Sections 8.2 and Section 8.3 are discussing other parts of the 2307 cellular network. 2309 35) (CLOSED) difference between the two PSTN gateway scenarios 2310 (Section 8.8 and 8.9) 2312 currently both are included, they might be merged, sionce one seams 2313 to be more general than the other 2315 36) (OPEN) req "Independence of reservation identifier" 2316 issue here is that this might only be valuable in mobile 2317 environments, and complicate the protocol for other environemnts. 2319 there are related issues (37,38, 2321 37) (OPEN) ownership of a reservation 2323 The issue here is that a known party owns reservations done in the 2324 network. (which might include that the party also pays). The 2325 question arose who is allowed to tear-down, receive asynchronous 2326 notifications in case of network initiated tear-down, etc. 2328 This also relates to how certain service granted is 2329 named/identified. 2331 38) (OPEN) definition of security threats 2333 39) (OPEN) simplify security requirements section 2335 40) (OPEN) add mobility related requirements 2337 41) (CLOSED) remove req 5.5.1 Mutability information on parameters 2338 removed because it is service-specific 2340 42) (OPEN) add an assumption that QoS nmonitoring is application- 2341 specific and with it out of scope of the WG 2343 43) (OPEN) asynchronous notification of QoS Initiator, Controller, 2344 Receiver, there are security issues related. Basically, an ownership 2345 issue. Nevertheless, an asynch notifcation in case of an error, 2346 network failure etc. is specifically in areas, where longer lived 2347 sessions are setup, essential in order to notify upper layes 2348 (appluications etc. as well. 2350 44) (OPEN) req 5.1.2 resource availability info on request come back 2351 to it as soon as we have a more clear idea about service description 2352 issue 2354 45) (OPEN) 5.3.4 Possibility for automatic re-setup of resources 2355 after recovery 2356 - more thoughts in failure conditions potentially 2357 - better text 2358 - operation under overload 2359 plays into issue 46) 2360 46) (OPEN) we need multiple scenario for failure and recovery cases 2361 to derive requirements. Or a list failre cases might be a start as 2362 well. 2364 47) (OPEN) traffic engineering and route pinning 2365 I assume this would result in operational type of requirements 2366 Opinions on that? 2368 48) (CLOSED) req 5.5.5 remove Multiple levels of detail 2370 "The QSC should allow for multiple levels of detail in description. 2371 (Motivation: someone interpreting the request can tune its own level 2372 of complexity by going down to more or less levels of detail. A 2373 lightweight implementation within the core could consider only the 2374 coarsest level.)" 2376 removed, because it is service-specific 2378 49) (CLOSED) remove req 5.5.9 Signaling must support quantitative, 2379 qualitative, and relative QoS specifications 2381 removed because it is service-specific 2383 50) (CLOSED) req 5.5.6 remove Ranges in specification 2385 The QSC should allow for specification of minimum required QoS 2386 and/or desirable QoS. (Motivation: The QoS Service Classes should 2387 allow for ranges to be indicated, to minimize negotiation latency 2388 and suppress error notifications during handover events.) 2390 removed, is service specific 2392 51) (CLOSED) remove 5.1.6 Avoid duplication of [sub]domain signaling 2393 functions 2395 we might use the requirement text somewhere else: 2397 Heading: Avoid duplication of [sub]domain signaling functions 2399 The specification of the NSIS signaling protocol should be optimized 2400 to avoid duplication of existing [sub]domain QoS signaling and to 2401 minimize the overall complexity. (Motivation: we don't want to 2402 introduce duplicate feedback or negotiation mechanisms, or 2403 complicate the work by including all possible existing QoS signaling 2404 in some form. The function will be placed in the new part if it has 2405 to be end-to-end, universal to all network types 2406 ('simple/lightweight'), or if it has to be protected by upper layer 2407 security mechanisms.) 2409 The point here is that the QoS technology (lower layer stuff) gets 2410 re-used unchanged, and we have new signaling above it. But, in many 2411 cases the local QoS technology will contain equivalent functions to 2412 the NSIS-required ones, just in a technology specific form. Examples 2413 of these functions would be error/QoS violation notifications, 2414 ability to query for resources and so on. So, there is a danger that 2415 our 'lightweight' signaling ends up trying to carry all this 2416 information all over again, and (even worse) that the 2417 initiator/controller functions have to weigh up nearly equivalent 2418 information coming from two directions. However, the basic problem 2419 here is that the boundary between new and re-used stuff is pretty 2420 shaky. The requirement is trying to scope our problem (a) to 2421 eliminate the potential overlap, and (b) to keep the new NSIS stuff 2422 simple. 2424 However, we are aware that it is very difficult to judge what is 2425 duplicated, if we want to run the protocol in various environments. 2427 52) (OPEN) New requirement: interaction with policy 2428 this most likely is covered by an opaque token for authentication 2429 dependency on security changes 2431 53) (OPEN) Section 5.3. Error handling 2433 Comments: 2434 1) notification of user in case of unrecoverable errors (has been 2435 done by notification requirement, or will be done by asynch 2436 notification, issue 43) 2437 A description of both types of errors (recoverable, unrecoverable) 2438 are listed in Section 5.3.4. 2440 2) hop-by-hop? OR right to the end? 2442 3) What is potential value to notify about recoverable errors? 2443 Proposal: not hop by hop, but QoS controller to QoS initiator 2445 54) (CLOSED) add req 5.1.17. to assumption "Identification 2446 requirement" 2447 assumption say that the discovery of QI, QC, QR is out-of-scope of 2448 the draft 2450 55) (CLOSED) add from draft-partain-nsis-requirements-00.txt req 2451 5.2.2. Allow local QoS information exchange between two border 2452 nodes 2454 "The QoS signalling protocol must be able to exchange local QoS 2455 information between edge nodes. Local QoS information might, for 2456 example, be IP addresses, severe congestion notification, 2457 notification of succesful or erroneous processing of QoS signalling 2458 messages at one border node. 2460 In some domains, the NSIS QoS signalling protocol MAY carry 2461 identification of the ingress and egress edge between the ingress- 2462 egress edges. However, the identification of edges should not be 2463 visible to the end host and only applies within one QoS 2464 administrative domain. 2466 " 2468 Comments: 2469 - service mapping is more service-specific (layering,tunneling) 2470 - the scenario to look at is a complicated service description -> in 2471 part of the network you want to change the message to something more 2472 easy, and at the other end go back to the more complicated part. 2473 -QI being everywhere might be enough 2474 -and we have already a requirement saying that intermediate node 2475 MUST be able to add/remove domain-specific information to/from 2476 signaling messages 2478 56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00 2479 -already added a req to the scalability section (issue ???), which 2480 has been provided by Anders 2482 57) (CLOSED) potentially better title for text from issue 56) e.g. 2483 (ôminimal impact on coreö) 2485 58) (CLOSED) add req 5.3.2 from draft-partain-...-00 2487 - the fast establishment req is handled by the low setup latency 2488 req, and the scalability in handover req 2490 - added the text to the teminal mobility scenario 2492 - added text " time scale (e.g., handover in mobile environments)," 2493 to req 2495 59) (OPEN) add req: ability to deal with severe congestion (req 2496 5.3.4 of draft-partain-..-00 2498 issues are: 2499 - occurs in a highly utilised network and if it is not solved very 2500 fast then the network performance will quickly collapse 2501 - deos it belong to failure recovery (I would assume from a service 2502 point of view this is failure 2503 - hop by hop problem (issue from Jorge) 2504 - What difference does it make (from the QoS perspective) if the 2505 provided QoS degraded due to hardware failure on a device or due to 2506 congestion caused by failures on some other devices? What is 2507 required from the protocol is to signal this failure to other 2508 participants (QCs or QI) in the hope that they can do something 2509 meaningful (e.g. re-routing) to correct the problem or tear down the 2510 flow. 2512 60) (CLOSED) add req 5.4.3. from draft-partain-...-00 "Allow 2513 efficient QoS re-establishment after handover" 2515 "Handover is an essential function in wireless networks. After 2516 handover, QoS may need to be completely or partially re-established 2517 due to route changes. The re-establishment may be requested by the 2518 mobile node itself or triggered by the access point that the mobile 2519 node is attached to. In the first case, the QoS signalling should 2520 allow efficient QoS re-establishment after handover. Re- 2521 establishment of QoS after handover should be as quick as possible 2522 so that the mobile node does not experience service interruption or 2523 QoS degradation. The re-establishment should be localized, and not 2524 require end-to-end signalling, if possible." 2526 - most likely it is already cover, please check again, whether there 2527 is something missing 2528 - added it again under the mobility requiremments 2530 61) (OPEN) add req: 6.1.8 from draft-bucheli-...-00 on multicast 2531 "Multicast consideration should not impact the protocol complexity 2532 for unicast flows. Multicast support is not considered as a 2533 priority, because the targeted interactive multimedia services are 2534 mainly unicast. For this reason, if considered in the solution, 2535 multicast should not bring complexity in the unicast scenario." 2537 Opinions? 2539 --------------------------------------------------- 2540 starting from -02 version 2541 --------------------------------------------------- 2543 62) (OPEN) Request to add VPN scenario 2544 - Related to issue 1) 2545 - Difference of VPN scenario compared to what we already have is 2546 missing 2548 63) (CLOSED) added Sven Van den Bosch, Maarten Buchli, and Danny 2549 Goderis to acknowledgement section. 2551 64) (OPEN) Request to add req: Backwards compatibility 2552 A later version of an NSIS protocol must be backwards compatible 2553 with earlier versions of an NSIS protocol. 2555 65) (OPEN) Request to add req: Unexpected situations and error 2556 restistance 2557 An NSIS protocol must define behaviour of NSIS signaling units 2558 during unexpected situations. Unexpected situtions are unknown 2559 messages, parameters and parameter settings as well as receiption of 2560 unexpected messages (e.g. a "Reservation Confirmation" without prior 2561 "Reservation Request"). 2563 Related to Open issues (53) and requirement 5.3.4. 2564 This requirement is emphasizing to many details that might not be 2565 necessary 2567 Req 5.3.4 refers to behaviour in the case of problems in the data 2568 plane. My suggestion here is about unexpected events/errors in the 2569 control plane. If you think that this point carries to many details, 2570 let's split it up in several individual requirements. 2572 66) (OPEN) Request to add req: Default behaviour 2573 An NSIS protocol must define default behaviours and parameter 2574 settings wherever applicable. 2576 67) (OPEN) Request to add req: Extendability 2577 An NSIS protocol must provide means to enhance a protocol with 2578 future procedures, messages, parameters and parameter settings. 2580 This was refering mostly to the service specific part of the 2581 protocol. 2582 could be a part of the modularity requirement 5.1.3 2584 68) (OPEN) Request to add req: Preventation of stale state 2585 An NSIS signalling protocol must provide means for an NSIS signaling 2586 unit to discover and remove local stale state. This may for example 2587 be done by means like soft state and periodic flooding or by a 2588 polling mechanism and hard state signaling. 2590 Might already be covered in other requirements, could also be that 2591 the solutions known are solutions for different problems. I think 2592 distributed garbage collection could also be a solution. 2594 69) (OPEN) Request to add req: Reliable Communication 2595 NSIS signaling procedures, connectivity between units involved in 2596 NSIS signaling as well as the basic transport protocol used by NSIS 2597 must provide a maximum of communication reliability. Procedures must 2598 define how an NSIS signaling systems behaves if some kind of request 2599 it sent stays without answer (this could require e.g. be timers, 2600 number of message retransmits and release messages). 2601 An NSIS signaling unit must be able to check its connectivity to an 2602 adjacent NSIS signaling unit at any time (this requirement must 2603 however not result in a DoS attack tool - the frequency of these 2604 checks must be limited, and flow control may be useful). 2605 The basic transport protocol to be used between adjacent NSIS units 2606 must ensure message integrity and reliable transport. 2608 MUST/SHOULD ensure error- and loss free transmission of signaling 2609 information. 2611 Do we really require this? Isn't this a soft state versus hard state 2612 issue? 2614 70) (OPEN) Request to add req: Smooth breakdown 2615 A unit participating in NSIS signaling must no cause further damage 2616 to other systems involved in NSIS signaling when it has to go out of 2617 service. 2619 71) (CLOSED) Changed text "5.6.8: Ability to constrain load on 2620 devices" to 2622 The NSIS architecture should give the ability to constrain the load 2623 (CPU load, memory space, signaling bandwidth consumption and 2624 signaling intensity) on devices where it is needed. This can be 2625 achieved by many different methods. Examples, and this are only 2626 examples, include message aggregation, by ignoring signaling 2627 message, header compression, or minimizing functionality. The 2628 framework may choose any method as long as the requirement is met. 2630 72) (OPEN) request to add "Error notification and error location" 2632 "An NSIS signaling node rejecting or releasing a reservation must 2633 indicate its identity. NSIS signalling should indicate why a 2634 requested resource is not or no longer available. " 2636 Compared to 5.3.4 this is about problems on the control plane 2637 ------------------------------------------------------ 2638 Change Log Version 01 -> 02 2639 - added issues 62-72 2641 - added some discussion text to open issues 2643 - req " highest possible network utilization" added (issue 33, 2644 closed) 2646 - issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios), 2648 - removed req "Avoid duplication of [sub]domain signaling 2649 functions", issue 51 2651 - Section 5.3.4: added explanation of recoverable and unrecoverable 2652 errors (issue 53) 2654 - added the following requirement: (closed issue 55) Allow local QoS 2655 information exchange between nodes of the saeme administrative 2656 domain 2658 The QoS signaling protocol must be able to exchange local QoS 2659 information between QoS controllers located within one single 2660 domain. Local QoS information might, for example, be IP addresses, 2661 severe congestion notification, notification of successful or 2662 erroneous processing of QoS signaling messages. 2663 In some cases, the NSIS QoS signalling protocol may carry 2664 identification of the QoS controllers located at the boundaries of a 2665 domain. However, the identification of edge should not be visible to 2666 the end host (QoS initiator) and only applies within one QoS 2667 administrative domain. 2669 - closed issue 57: add text about "Minimal impact on interior (core) 2670 nodes" to requirement 5.6.8 "Ability to constrain load on devices" 2672 - added requirement "Allow efficient QoS re-establishment after 2673 handover", closed issue 60. 2675 - changed text in 5.3.2