idnits 2.17.1 draft-ietf-nsis-req-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2298: '... 3) SHOULD support sender initiated,...' RFC 2119 keyword, line 2309: '...) MUSTs, SHOULDs, MAY needs discussion...' RFC 2119 keyword, line 2409: '... colums with the MUST, SHOULDs, and MA...' RFC 2119 keyword, line 2578: '...ack of a request MUST include yes and ...' RFC 2119 keyword, line 2579: '...in case of no it MAY include an opaque...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1135 has weird spacing: '...otocols that...' == Line 1136 has weird spacing: '...reement prot...' == Line 2345 has weird spacing: '...ork and if it...' == Line 2346 has weird spacing: '...ce will quick...' == Line 2445 has weird spacing: '...for the forwa...' == (2 more instances...) -- 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 8017 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 333 -- Looks like a reference, but probably isn't: 'X' on line 2985 == Missing Reference: '14' is mentioned on line 2999, but not defined == Missing Reference: '16' is mentioned on line 3003, but not defined == Missing Reference: '26' is mentioned on line 3005, but not defined == Missing Reference: '28' is mentioned on line 3009, but not defined == Missing Reference: '29' is mentioned on line 3013, but not defined == Missing Reference: '37' is mentioned on line 3016, but not defined == Missing Reference: '39' is mentioned on line 3019, but not defined == Missing Reference: '40' is mentioned on line 3021, but not defined == Missing Reference: '42' is mentioned on line 3023, but not defined == Missing Reference: '43' is mentioned on line 3026, but not defined == Missing Reference: '44' is mentioned on line 3029, but not defined == Missing Reference: '45' is mentioned on line 3033, but not defined == Missing Reference: '46' is mentioned on line 3036, but not defined == Missing Reference: '47' is mentioned on line 3039, but not defined == Missing Reference: '52' is mentioned on line 3043, but not defined == Missing Reference: '53' is mentioned on line 3050, but not defined == Missing Reference: '59' is mentioned on line 3046, but not defined == Missing Reference: '61' is mentioned on line 3047, but not defined == Missing Reference: '64' is mentioned on line 3048, but not defined == Missing Reference: '65' is mentioned on line 3050, but not defined == Missing Reference: '66' is mentioned on line 3051, but not defined == Missing Reference: '67' is mentioned on line 3052, but not defined == Missing Reference: '68' is mentioned on line 3053, but not defined == Missing Reference: '69' is mentioned on line 3055, but not defined == Missing Reference: '70' is mentioned on line 3058, but not defined == Missing Reference: '72' is mentioned on line 3060, but not defined == Unused Reference: '2' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1533, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 6 errors (**), 0 flaws (~~), 43 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group 2 Internet Draft M. Brunner (Editor) 3 Document: draft-ietf-nsis-req-03.txt NEC 4 Expires: November 2002 May 2002 6 Requirements for QoS Signaling Protocols 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document defines requirements for signaling QoS across 32 different network environments, where different network environments 33 across administrative and technology domains. To achieve wide 34 applicability of the requirements, the starting point is a diverse 35 set of scenarios/use cases concerning various types of networks and 36 application interactions. We also provide an outline structure for 37 the problem, including QoS related terminology. Taken with the 38 scenarios, this allows us to focus more precisely on which parts of 39 the overall QoS problem needs to be solved. We present the 40 assumptions and the aspects not considered within scope before 41 listing the requirements grouped according to areas such as 42 architecture and design goals, signaling flows, layering, 43 performance, flexibility, security, and mobility. 45 Table of Contents 47 Status of this Memo...................................................1 48 Abstract..............................................................2 49 Table of Contents.....................................................2 50 1 Introduction.......................................................4 51 2 Terminology........................................................5 52 3 Problem Statement and Scope........................................8 53 4 Assumptions and Exclusions........................................10 54 4.1 Assumptions and Non-Assumptions...............................10 55 4.2 Exclusions....................................................11 56 5 Requirements......................................................12 57 5.1 Architecture and Design Goals.................................13 58 5.1.1 Applicability for different QoS technologies................13 59 5.1.2 Resource availability information on request................13 60 5.1.3 Modularity..................................................13 61 5.1.4 Decoupling of protocol and information it is carrying.......14 62 5.1.5 Reuse of existing QoS provisioning..........................14 63 5.1.6 Independence of signaling and provisioning paradigm.........14 64 5.2 Signaling Flows...............................................14 65 5.2.1 Free placement of QoS Initiator and QoS Controllers functions14 66 5.2.2 No constraint of the QoS signaling and QoS Controllers to be in 67 the data path.....................................................14 68 5.2.3 Concealment of topology and technology information..........15 69 5.2.4 Optional transparency of QoS signaling to network...........15 70 5.3 Additional information beyond signaling of QoS information....16 71 5.3.1 Explicit release of resources...............................16 72 5.3.2 Possibility for automatic release of resources after failure 16 73 5.3.3 Prompt notification of QoS violation in case of error/failure 74 to QoS Initiator and QoS Controllers..............................16 75 5.3.4 Feedback about success of request for QoS guarantees........16 76 5.3.5 Allow local QoS information exchange between nodes of the same 77 administrative domain.............................................17 78 5.4 Layering......................................................17 79 5.4.1 The signaling protocol and QoS control information should be 80 application independent...........................................17 82 5.5 QoS Control Information.......................................17 83 5.5.1 Mutability information on parameters........................17 84 5.5.2 Possibility to add and remove local domain information......18 85 5.5.3 Independence of reservation identifier......................18 86 5.5.4 Seamless modification of already reserved QoS...............18 87 5.5.5 Grouping of signaling for several microflows................18 88 5.6 Performance...................................................18 89 5.6.1 Scalability in the number of messages received by a signaling 90 communication partner (QoS initiator and controller)..............19 91 5.6.2 Scalability in number of hand-offs..........................19 92 5.6.3 Scalability in the number of interactions for setting up a 93 reservation.......................................................19 94 5.6.4 Scalability in the number of state per entity (QoS initiators 95 and QoS controllers)..............................................19 96 5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 19 97 5.6.6 Low latency in setup........................................19 98 5.6.7 Allow for low bandwidth consumption for signaling protocol..19 99 5.6.8 Ability to constrain load on devices........................19 100 5.6.9 Highest possible network utilization........................19 101 5.7 Flexibility...................................................20 102 5.7.1 Aggregation capability, including the capability to select and 103 change the level of aggregation...................................20 104 5.7.2 Flexibility in the placement of the QoS initiator...........20 105 5.7.3 Flexibility in the initiation of re-negotiation (QoS change 106 requests).........................................................20 107 5.7.4 Uni / bi-directional reservation............................20 108 5.8 Security......................................................20 109 5.8.1 Authentication of signaling requests........................20 110 5.8.2 Resource Authorization......................................21 111 5.8.3 Integrity protection........................................21 112 5.8.4 Replay protection...........................................21 113 5.8.5 Hop-by-hop security.........................................21 114 5.8.6 Identity confidentiality and location privacy...............21 115 5.8.7 Denial-of-service attacks...................................22 116 5.8.8 Confidentiality of signaling messages.......................22 117 5.8.9 Ownership of a reservation..................................22 118 5.8.10 Hooks with Authentication and Key Agreement protocols......22 119 5.9 Mobility......................................................23 120 5.9.1 Allow efficient QoS re-establishment after handover.........23 121 5.10 Interworking with other protocols and techniques............23 122 5.10.1 Interworking with IP tunneling.............................23 123 5.10.2 The solution should not constrain either to IPv4 or IPv6...23 124 5.10.3 Independence from charging model...........................24 125 5.10.4 Hooks for AAA protocols....................................24 126 5.10.5 Interworking with seamless handoff protocols...............24 127 5.10.6 Interworking with non-traditional routing..................24 128 5.11 Operational.................................................24 129 5.11.1 Ability to assign transport quality to signaling messages..24 130 5.11.2 Graceful fail over.........................................24 131 6 The MUSTs, SHOULDs, and MAYs......................................24 132 7 References........................................................30 133 8 Acknowledgments...................................................30 134 9 Author's Addresses................................................31 135 10 Appendix: Scenarios/Use cases...................................31 136 10.1 Scenario: Terminal Mobility.................................32 137 10.2 Scenario: Cellular Networks.................................34 138 10.3 Scenario: UMTS access.......................................34 139 10.4 Scenario: Wired part of wireless network....................36 140 10.5 Scenario: Session Mobility..................................38 141 10.6 Scenario: QoS reservations/negotiation from access to core 142 network............................................................38 143 10.7 Scenario: QoS reservation/negotiation over administrative 144 boundaries.........................................................39 145 10.8 Scenario: QoS signaling between PSTN gateways and backbone 146 routers............................................................39 147 10.9 Scenario: PSTN trunking gateway.............................41 148 10.10 Scenario: Application request end-to-end QoS path from the 149 network............................................................42 150 10.11 Scenario: QOS for Virtual Private Networks..................42 152 1 Introduction 154 This document defines requirements for signaling QoS across 155 different network environments. It does not list any problems of 156 existing QoS signaling protocols such as RSVP. 158 In order to derive requirements for QoS signaling it is necessary to 159 first have a clear idea of the scope within which they are 160 applicable. 161 We describe a set of QoS signaling scenarios and use cases in the 162 Appendix of that document. These scenarios derive from a variety of 163 backgrounds, and help obtain a clearer picture of what is in or out 164 of scope of the NSIS work. They illustrate the problem of QoS 165 signaling from various perspectives (end-system, access network, 166 core network) and for various areas (fixed line, mobile, wireless 167 environments). As the NSIS work becomes more clearly defined, 168 scenarios will be added or dropped, or defined in more detail. 170 Based on these scenarios, we are able to define the QoS signaling 171 problem on a more abstract level. In Section 3, we thus present a 172 simple conceptual model of the QoS signaling problem. Additionally, 173 we describe the entities involved in QoS signaling and typical 174 signaling paths. In Section 4 we list assumptions and exclusions. 176 The model of Section 3 allows deriving requirements from the 177 scenarios presented in the appendix in a coherent and consistent 178 manner. Requirements are grouped according to areas such as 179 Architecture and design goals, Signaling Flows, Layering, 180 Performance, Flexibility, Security and Mobility. 182 QoS is a pretty large field with a lot of interaction with other 183 protocols, mechanisms, applications etc. In the following, some 184 thoughts from an end-system point of view and from a network point 185 of view. 187 End-system perspective: In future mobile terminals, the support of 188 adaptive applications is more and more important. Adaptively can be 189 seen as an important technique to react to QoS violations that may 190 occur frequently, e.g., in wireless environments due to changed 191 environmental and network conditions. This may result in degraded 192 end-to-end performance. It is then up to adaptive applications to 193 react to the new resource availability. Therefore, it is essential 194 to define interoperability between media-, mobility- and QoS 195 management. While most likely mobile terminals cannot assume, that 196 explicit QoS reservation schemes are available, some access networks 197 nevertheless may offer such capabilities. Applications subscribed to 198 an end-system QoS management system should be supported with a 199 dedicated QoS API to set-up, control and adapt media sessions. 201 Network perspective: QoS enabled IP networks are expected to handle 202 two different kinds of QoS granularities: per-flow QoS and per- 203 trunk/per-class QoS. Per-flow QoS might be needed in access networks 204 and may there be subject of QoS signaling. However, in the core 205 network only per-trunk or per-class QoS can be considered for 206 scalability reasons. Therefore there might be different requirements 207 on QoS signaling applying to different parts of the network. In the 208 access network QoS signaling is an interaction between end systems 209 and access routers or access network QoS managers (in the following 210 we call them QoS initiator and QoS controller). In the core network 211 QoS signaling refers to trunks or classes of traffic between core 212 and edge systems or between peering core systems. Please note that 213 this does not exclude the transport of per-flow signaling through 214 core networks. 216 It is clear from these descriptions that the subject of QoS is 217 uniquely complex and any investigation could potentially have a very 218 broad scope - so broad that it is a challenge to focus work on an 219 area, which could lead to a concrete and useful result. This is our 220 motivation for considering a set of use cases, which map out the 221 domain of application that we want to address. It is also the 222 motivation for defining a problem structure, which allows us to 223 state the boundaries of what types of functionality to consider, and 224 to list background assumptions. 226 There are several areas of the requirements related to networking 227 aspects which are incomplete, for example, interaction with host and 228 site multi-homing, use of anycast services, and so on. These issues 229 should be considered in any future requirement analysis work. 231 2 Terminology 233 In the area of Qualiaty of Service (QoS) it is quite difficult and 234 an exercise for its own to define terminology. Nevertheless, we 235 tried to list the most often used terms in the draft and tried to 236 explain them. However, don't be to religious about it, they are not 237 meant to prescribe any thing in the draft. 239 Aggregate: a group of flows, usually with similar QoS requirements, 240 which can be treated together as a whole with a single overall QoS 241 requirement for signaling and provisioning. Aggregates and flows can 242 be further aggregated together. 244 [QoS] Domain: a collection of networks under the same administrative 245 control and grouped together for administrative purposes. 247 Egress point: the router via which a path exits a domain/subdomain. 249 End Host: the end system or host, for whose flows QoS is being 250 requested and provisioned. 252 End-to-End QoS: the QoS delivered by the network between two 253 communicating end hosts. End-to-end QoS co-ordinates and enforces 254 predefined traffic management policies across multiple network 255 entities and administrative domains. 257 Edge-to-edge QoS: QoS within an administrative domain that connects 258 to other networks rather than hosts or end systems. 260 Flow: a traffic stream (sequence of IP packets between two end 261 systems) for which a specific level of QoS is to be provided. The 262 flow can be unicast (uni- or bi-directional) or multicast. 264 Flow Administration: represents the policy associated with how flows 265 should be treated in the network, for example whether and how the 266 flows should be aggregated. It may consist of both user and local 267 network management information. 269 Higher Layers: the higher layer (transport protocol and application) 270 functions that request QoS from the network layer. The request might 271 be a trigger generated within the end system, or the trigger might 272 be provided by some entity within the network (e.g. application 273 proxy or policy server). 275 Indication: feedback from QoS provisioning to indicate the current 276 QoS being provided to a flow or aggregate, and whether any 277 violations have been detected by the QoS technology being used 278 within the local domain/subdomain. 280 Ingress point: the router via which a path enters a 281 domain/subdomain. 283 Mapping: the act of transforming parameters from QSCs to values that 284 are meaningful to the actual QoS technology in use in the 285 domain/subdomain. 287 Path: the route across the networks taken by a flow or aggregate, 288 i.e. which domains/subdomains it passes through and the 289 egress/ingress points for each. 291 Path segment: the segment of a path within a single 292 domain/subdomain. 294 QoS Administration Function: a generic term for all functions 295 associated with admission control, policy control, traffic 296 engineering etc. 298 QoS Control Information: the information the governs the QoS 299 treatment to be applied to a flow or aggregate, including the QSC, 300 flow administration, and any associated security or accounting 301 information. 303 QoS Controller: this is responsible for interpreting the signaling 304 carrying the user QoS parameters, optionally inserting/modifying the 305 parameters according to local network QoS management policy, and 306 invoking local QoS provisioning mechanisms. Note that q QoS 307 controller might have very different functionality depending on 308 where in the network and in what environment they are implemented. 310 QoS Initiator: this is responsible for generating the QSCs for 311 traffic flow(s) based on user or application requirements and 312 signaling them to the network as well as invoking local QoS 313 provisioning mechanisms. This can be located in the end system, but 314 may reside elsewhere in network. 316 QoS Provisioning: the act of actually allocating resources to a flow 317 or aggregate of flows, may include mechanisms such as LSP initiation 318 for MPLS, packet scheduler configuration within a router, and so on. 319 The mechanisms depend on the overall QoS technology being used 320 within the [sub]domain. 322 QoS Service Classes (QSC): specify the QoS requirements of a traffic 323 flow or aggregate. Can be further sub-divided into user specific 324 and network related parameters 326 QoS Signaling: a way to communicate QSCs and QoS management 327 information between hosts, end systems and network devices etc. May 328 include request and response messages to facilitate negotiation/re- 329 negotiation, asynchronous feedback messages (not delivered upon 330 request) to inform End Hosts, QoS initiators and QoS controllers 331 about current QoS levels, and QoS querying facilities. 333 [QoS] Subdomain: a network within an administrative domain using a 334 uniform technology/QoS provisioning function to provision resources. 336 QoS Technology: a generic term for a set of protocols, standards and 337 mechanisms that can be used within a QoS domain/subdomain to manage 338 the QoS provided to flows or aggregates that traverse the domain. 339 Examples might include MPLS, DiffServ, and so on. A QoS technology 340 is associated with certain QoS provisioning techniques. 342 QoS Violation: occurs when the QoS applied to a flow or aggregate 343 does not meet the requested and negotiated QoS agreed for it. 345 Resource: something of value in a network infrastructure to which 346 rules or policy criteria are first applied before access is granted. 347 Examples of resources include the buffers in a router and bandwidth 348 on an interface. 350 Resource Allocation: part of a resource that has been dedicated for 351 the use of a particular traffic type for a period of time through 352 the application of policies. 354 Sender-initiated QoS signaling protocol: A sender-initiated QoS 355 signaling protocol is a protocol (see e.g., YESSIR [8], RMD [10]) 356 where the QI initiates the signaling on behalf of the sender of the 357 data. What this means is that admission control and resource 358 allocation functions are processed from the data sender towards the 359 data receiver. However, the triggering instance is not specified. 361 Receiver-initiated QoS signaling protocol: A receiver-initiated 362 protocol, (see e.g., RSVP [9]) is a protocol where the QoS 363 reservations are initiated by the QoS Receiver on behalf of the 364 receiver of the user data. What this means is that admission control 365 and resource allocation functions are processed from the data 366 receiver back towards the data sender. However, the triggering 367 instance is not specified. 369 3 Problem Statement and Scope 371 We provide in the following a preliminary architectural picture as a 372 basis for discussion. We will refer to it in the following 373 requirement section. 375 A set of issues and problems to be solved has been given at a top 376 level by the use cases/scenarios of the appendix. However, the 377 problem of QoS has an extremely wide scope and there is a great deal 378 of work already done to provide different components of the 379 solution, such as QoS technologies for example. A basic goal should 380 be to re-use these wherever possible, and to focus requirements work 381 at an early stage on those areas where a new solution is needed 382 (e.g. an especially simple one). We also try to avoid defining 383 requirements related to internal implementation aspects. 385 In this section, we present a simple conceptual model of the overall 386 QoS problem in order to identify the applicability to NSIS of 387 requirements derived from the use cases, and to clarify the scope of 388 the work, including any open issues. This model also identifies 389 further sources of requirements from external interactions with 390 other parts of an overall QoS solution, clarifies the terminology 391 used, and allows the statement of design goals about the nature of 392 the solution (see section 5). 394 Note that this model is intended not to constrain the technical 395 approach taken subsequently, simply to allow concrete phrasing of 396 requirements (e.g. requirements about placement of the QoS 397 initiator, or ability to 'drive' particular QoS technologies.) 398 Roughly, the scope of NSIS is assumed to be the interaction between 399 the QoS initiator and QoS controller(s), including selection of 400 signaling protocols to carry the QoS information, and the 401 syntax/semantics of the information that is exchanged. Further 402 statements on assumptions/exclusions are given in the next Section. 403 The main elements are: 405 1. Something that starts the request for QoS, the QoS Initiator. 407 This might be in the end system or within some other part of the 408 network. The distinguishing feature of the QoS initiator is that it 409 acts on triggers coming (directly or indirectly) from the higher 410 layers in the end systems. It needs to map the QoS requested by 411 them, and also provides feedback information to the higher layers, 412 which might be used by transport layer rate management or adaptive 413 applications. 415 2. Something that assists in managing QoS further along the path, 416 the QoS controller. 418 The QoS controller does not interact with higher layers, but 419 interacts with the QoS initiator and possibly more QoS controllers 420 on the path, edge to edge or possibly end to end. 422 3. The QoS initiator and controller(s) interact with each other, 423 path segment by path segment. This interaction involves the exchange 424 of data (QoS control information) over some signaling protocol. 426 4. The path segment traverses an underlying network (QoS domain or 427 subdomain) covering one or more IP hops. The underlying network uses 428 some local QoS technology. This QoS technology has to be provisioned 429 appropriately for the flow, and the QoS initiator does this and 430 controller(s), mapping their QoS control information to technology- 431 related QoS parameters and receiving indications about success or 432 failure in response. 434 Now concentrating more on the overall end to end (multiple QoS 435 domains) aspects, in particular: 437 1. The QoS initiator need not be located at an end system, and the 438 QoS controllers are not assumed to be located on the flow's data 439 path. However, they must be able to identify the ingress and egress 440 points for the flow path as it traverses the domain/subdomain. Any 441 signaling protocol must be able to find the appropriate QoS 442 controller and carry this ingress/egress point information. 444 2. We see the network at the level of domains/subdomains rather than 445 individual routers (except in the special case that the domain 446 contains one link). Domains are assumed to be administrative 447 entities, so security requirements apply to the signaling between 448 them. Subdomains are introduced to allow the fact a given QoS 449 provisioning mechanism may only be used within a part of a domain, 450 typically for a particular subnetwork technology boundary. 451 Aggregation can also take place at subdomain boundaries. 453 3. Any domain may contain QoS administration functions (e.g. to do 454 with traffic engineering, admission control, policy and so on). 455 These are assumed to interact with the QoS initiator and controllers 456 (and end systems) using standard mechanisms. 458 4. The placement of the QoS initiators and QoS controllers is not 459 fixed. Actually, there are two extreme cases: 461 - Each router on the data path implements a QoS controller and QoS 462 initiator. 464 - Only the end systems incorporate a QoS controller and QoS 465 initiator, which mean the end systems need to have QoS provisioning 466 capabilities. However this case does not seam to be realistic but 467 shows the flexible allocation of the controller and initiator 468 function. 470 4 Assumptions and Exclusions 472 4.1 Assumptions and Non-Assumptions 474 1. The NSIS signaling could run end to end, end to edge, or edge to 475 edge, or network-to-network ((between providers), depending on what 476 point in the network acts as the initiator, and how far towards the 477 other end of the network the signaling propagates. Although the 478 figures show QoS controllers at a very limited number of locations 479 in the network (e.g. at domain or subdomain borders, or even 480 controlling a complete domain), this is only one possible case. In 481 general, we could expect QoS controllers to become more 'dense' 482 towards the edges of the network, but this is not a requirement. An 483 overprovisioned domain might contain no QoS controllers at all (and 484 be NSIS transparent); at the other extreme, QoS controllers might be 485 placed at every router. In the latter case, QoS provisioning can be 486 carried out in a local implementation-dependent way without further 487 signaling, whereas in the case of remote QoS controllers, a 488 provisioning protocol might be needed to control the routers along 489 the path. This provisioning protocol is then independent of the end 490 to end NSIS signaling. 492 2. We do not consider 'pure' end-to-end QoS signaling that is not 493 interpreted anywhere within the network. Such signaling is an 494 application-layer issue and IETF protocols such as SIP etc. can be 495 used. 497 3. Where the signaling does cover several QoS domains or subdomains, 498 we do not exclude that different signaling protocols are used in 499 each path segment. We only place requirements on the universality of 500 the QoS control information that is being transported. (The goals 501 here would be to allow the use of signaling protocols, which are 502 matched to the characteristics of the portion of the network being 503 traversed.) Note that the outcome of NSIS work might result in 504 various protocols or various flavors of the same protocol. This 505 implies the need for the translation of information into QoS domain 506 specific format as well. 508 4. We assume that the service definitions a QoS initiator can ask 509 for are known in advance of the signaling protocol running. Service 510 definition includes QoS parameters, lifetime of QoS guarantee etc. 511 There are many ways service requesters get to know about it. There 512 might be standardized services, the definition can be negotiated 513 together with a contract, the service definition is published at a 514 Web page, etc. 516 5. We assume that there are means for the discovery of NSIS entities 517 in order to know the signaling peers (solutions include static 518 configuration, automatically discovered, or implicitly runs over the 519 right nodes, etc.) The discovery of the NSIS entities has security 520 implications that need to be addressed properly. These implications 521 largely depend on the chosen protocol. For some security mechanisms 522 (i.e. Kerberos, pre-shared secret) it is required to know the 523 identity of the other entity. Hence the discovery mechanism may 524 provide means to learn this identity, which is then later used to 525 retrieve the required keys and parameters. 527 6. NSIS assumes to operate with networks using standard ("normal") 528 L3 routing. 530 4.2 Exclusions 532 1. Development of specific mechanisms and algorithms for application 533 and transport layer adaptation are not considered, nor are the 534 protocols that would support it. 536 2. Specific mechanisms (APIs and so on) for interaction between 537 transport/applications and the network layer are not considered, 538 except to clarify the requirements on the negotiation capabilities 539 and information semantics that would be needed of the signaling 540 protocol. The same applies to application adaptation mechanisms. 542 3. Specific mechanisms for QoS provisioning within a 543 domain/subdomain are not considered. It should be possible to 544 exploit these mechanisms optimally within the end to end context. 545 Consideration of how to do this might generate new requirements for 546 NSIS however. For example, the information needed by a QoS 547 controller to manage a radio subnetwork needs to be provided by the 548 NSIS solution. 550 4. Specific mechanisms (APIs and so on) for interaction between the 551 network layer and underlying QoS provisioning mechanisms are not 552 considered. 554 5. Interaction with QoS administration capabilities is not 555 considered. Standard protocols should be used for this (e.g. COPS). 556 This may imply requirements for the sort of information that should 557 be exchanged between the NSIS network QoS entities. 559 6. Security implications related to multicasting are outside the 560 scope of the QoS signaling protocol. 562 7. Protection of non-QoS signaling messages is outside the scope of 563 the QoS protocol 565 The protection of non-signaling messages (including data traffic 566 following a reservation) is not directly considered by a signaling 567 protocol. The protection of data messages transmitted along the QoS 568 provisioned path is outside the scope of a signaling protocol. 569 Regarding data traffic there is an interaction with accounting 570 (metering) and edge routers might require packets to be integrity 571 protected to be able to securely assign incoming data traffic to a 572 particular user. 574 Additionally there might be an interaction with IPsec protected 575 traffic experiencing QoS treatment and the established state created 576 due to signaling. One example of such an interaction is the different 577 flow identification with and without IPsec protection. 579 Many security properties are likely to be application specific and 580 may be provided by the corresponding application layer protocol. 582 8. Service definitions and QoS classes are out of scope. Together 583 with the service definition any definition of service specific 584 parameters are not considered in this draft. Only the base NSIS 585 signaling protocol for transporting the QoS/service information are 586 handled. 588 9. Similarly, specific methods, protocols, and ways to express QoS 589 information in the Application/Session level are not considered 590 (e.g., SDP, SIP, RTSP, etc.). 592 10. The specification of any extensions needed to signal QoS 593 information via application level protocols (e.g. SDP(ng)), and the 594 mapping on NSIS information are considered outside of the scope of 595 NSIS working group, as this work is in the direct scope of other 596 IETF working groups (e.g. MMUSIC). 598 11. Handoff decision and trigger sources: An NSIS protocol is not 599 used to trigger handoffs in mobile IP, nor is it used to decide 600 whether to handoff or not. As soon as or in some situation even 601 before a handoff happened, an NSIS protocol might be used for 602 signaling for QoS again. However, NSIS must interwork with several 603 protocols for mobility management. 605 12. QoS monitoring is out of scope. It is heavily dependent on the 606 type of the application and or transport service, and in what 607 scenario it is used. 609 5 Requirements 610 This section defines more detailed requirements for a QoS signaling 611 solution, derived from consideration of the use cases/scenarios, and 612 respecting the framework, scoping assumptions, and terminology 613 considered earlier. The requirements are in subsections, grouped 614 roughly according to general technical aspects: architecture and 615 design goals, topology issues, QoS parameters, performance, 616 security, information, and flexibility. 618 Two general (and potentially contradictory) goals for the solution 619 are that it should be applicable in a very wide range of scenarios, 620 and at the same time lightweight in implementation complexity and 621 resource requirements in nodes. One approach to this is that the 622 solution could deal with certain requirements via modular components 623 or capabilities, which are optional to implement in individual 624 nodes. 626 Some of the requirements are technically contradictory. Depending on 627 the scenarios a solution applies to, one or the other requirement is 628 applicable. 630 Find in Section 6 the MUSTs, SHOULDs, and MAYs 632 5.1 Architecture and Design Goals 634 This section contains requirements related to desirable overall 635 characteristics of a solution, e.g. enabling flexibility, or 636 independence of parts of the framework. 638 5.1.1 Applicability for different QoS technologies. 640 The QoS signaling protocol must work with various QoS technologies. 641 The information exchanged over the signaling protocol must be in 642 such detail and quantity that it is useful for various QoS 643 technologies. 645 5.1.2 Resource availability information on request 647 In some scenarios, e.g., the mobile terminal scenario, it is 648 required to query, whether resources are available, without 649 performing a reservation on the resource. One solution might be a 650 feedback mechanism based on which a QoS inferred handover can take 651 place. 653 5.1.3 Modularity 655 A modular design allows for more lightweight implementations, if 656 fewer features are needed. Mutually exclusive solutions are 657 supported. Examples for modularity: 659 - Work over any kind of network (narrowband / broadband, error-prone 660 / reliable...) - This implies low bandwidth signaling and redundant 661 information must be supported if necessary. 663 - Uni- and bi-directional reservations are possible 664 - Extensible in the future with different add-ons for certain 665 environments or scenarios 667 5.1.4 Decoupling of protocol and information it is carrying 669 The signaling protocol(s) used must be clearly separated from the 670 QoS control information being transported. This provides for the 671 independent development of these two aspects of the solution, and 672 allows for this control information to be carried within other 673 protocols, including application layer ones, existing ones or those 674 being developed in the future. The gained flexibility in the 675 information transported allows for the applicability of the same 676 protocol in various scenarios. 677 However, note that the information carried needs to be the same. 678 Otherwise interoperability is difficult to achieve. 680 5.1.5 Reuse of existing QoS provisioning 682 Reuse existing QoS functions and protocols for QoS provisioning 683 within a domain/subdomain unchanged. (Motivation: 'Don't re-invent 684 the wheel'.) 686 5.1.6 Independence of signaling and provisioning paradigm 688 The QoS signaling should be independent of the paradigm and 689 mechanism of QoS provisioning. The independence allows for using the 690 NSIS protocol together with various QoS technologies in various 691 scenarios. 693 5.2 Signaling Flows 695 This section contains requirements related to the possible signaling 696 flows that should be supported, e.g. over what parts of the flow 697 path, between what entities (end-systems, routers, middle boxes, 698 management systems), in which direction. 700 5.2.1 Free placement of QoS Initiator and QoS Controllers functions 702 The protocol must work in various scenarios such as host-to-network- 703 to-host, edge-to-edge, (e.g., just within one providers domain), 704 user-to-network (from end system into the network, ending, e.g., at 705 the entry to the network and vice versa), network-to-network (e.g., 706 between providers). 708 Placing the QoS controller and initiator functions at different 709 locations allows for various scenarios to work with the same or 710 similar protocols. 712 5.2.2 No constraint of the QoS signaling and QoS Controllers to be in 713 the data path. 715 There is a set of scenarios, where QoS signaling is not on the data 716 path. The QoS Controller being in the data path is one extreme case 717 and useful in certain cases. 719 There are going to be cases where a centralized entity will take a 720 decision about QoS requests. In this case, there is no need to have 721 the data follow the signaling path. 723 There are going to be cases without a centralized entity managing 724 resources and the signaling will be used as a tool for resource 725 management. For various reasons (such as efficient use of expensive 726 bandwidth), one will want to have fine-grained, fast, and very 727 dynamic control of the resources in the network. 729 There are going to be cases where there will be neither signaling 730 nor a centralized entity (overprovisioning). Nothing has to be done 731 anyway. 733 One can capture the requirement with the following, different 734 wording: If one views the domain with a QoS technology as a virtual 735 router then NSIS signaling used between those virtual routers must 736 follow the same path as the data. 738 Routing the signaling protocol along an independent path is desired 739 by network operators/designers. Ideally, the capability to route the 740 protocol along an independent path would give the network 741 designer/operator the option to manage bandwidth utilization through 742 the topology. 744 There are other possibilities as well. An NSIS protocol must accept 745 all of these possibilities. 747 5.2.3 Concealment of topology and technology information 749 The QoS protocol should allow for hiding the internal structure of a 750 QoS domain from end-nodes and from other networks. Hence an 751 adversary should not be able to learn the internal structure of a 752 network with the help of the QoS protocol. 754 In various scenarios, topology information should be hidden for 755 various reasons. From a business point of view, some administrations 756 don't want to reveal the topology and technology used. 758 5.2.4 Optional transparency of QoS signaling to network 760 It should be possible that the QoS signaling for some flows traverse 761 path segments transparently, i.e., without interpretation at QoS 762 controllers within the network. An example would be a subdomain 763 within a core network, which only interpreted signaling for 764 aggregates established at the domain edge, with the flow-related 765 signaling passing transparently through it. 767 In other words, NSIS needs to work in hierarchical scenarios, where 768 big pipes/trunks are setup using NSIS signaling, but also flows 769 which run within that big pipe/trunk are setup using NSIS. 771 5.3 Additional information beyond signaling of QoS information 773 This section contains the desired signaling (messages) for other 774 purposes other than that for conveying QoS parameters. 776 5.3.1 Explicit release of resources 778 When a QoS reservation is no longer necessary, e.g. because the 779 application terminates, or because a mobile host experienced a hand- 780 off, it must be possible to explicitly release resources. In general 781 explicit release enhances the overall network utilization. 783 5.3.2 Possibility for automatic release of resources after failure 785 When the QoS Initiator goes down, the resources it requested in the 786 network should be released, since they will no longer be necessary. 788 After detection of a failure in the network, any QoS 789 controller/initiator must be able to release a reservation it is 790 involved in. For example, this may require signaling of the "Release 791 after Failure" message upstream as well as downstream, or soft state 792 timing out of reservations. 794 The goal is to prevent stale state within the network and adds 795 robustness to the operation of NSIS. So in other words, an NSIS 796 signaling protocol must provide means for an NSIS signaling unit to 797 discover and remove local stale state. 799 Note that this might need to work together with a notification 800 mechanism. 802 5.3.3 Prompt notification of QoS violation in case of error/failure to 803 QoS Initiator and QoS Controllers 805 QoS Controllers should be able to notify the QoS Initiator, if there 806 is an error inside the network. There are two types of network 807 errors: 809 Recoverable errors: the network nodes can locally repair this type 810 error. The network nodes do not have to notify the users of the 811 error immediately. This is a condition when the danger of 812 degradation (or actual short term degradation) of the provided QoS 813 was overcome by the network (QoS controller) itself. 815 Unrecoverable errors: the network nodes cannot handle this type of 816 error, and have to notify the users as soon as possible. 818 5.3.4 Feedback about success of request for QoS guarantees 819 A request for QoS must be answered at least with yes or no. However, 820 it might be useful in case of a negative answer to also get a 821 description of what might be the QoS one can successfully request 822 etc. So it might be useful to include an opaque element into the 823 answer. The element heavily depends on the service requested. 825 5.3.5 Allow local QoS information exchange between nodes of the same 826 administrative domain 828 The QoS signaling protocol must be able to exchange local QoS 829 information between QoS controllers located within one single 830 domain. Local QoS information might, for example, be IP addresses, 831 severe congestion notification, notification of successful or 832 erroneous processing of QoS signaling messages. 834 In some cases, the NSIS QoS signaling protocol may carry 835 identification of the QoS controllers located at the boundaries of a 836 domain. However, the identification of edge should not be visible to 837 the end host (QoS initiator) and only applies within one QoS 838 administrative domain. 840 5.4 Layering 842 This section contains requirements related to the way the signaling 843 being considered interacts with upper layer functions (users, 844 applications, and QoS administration), and lower layer QoS 845 technologies. 847 5.4.1 The signaling protocol and QoS control information should be 848 application independent. 850 However, opaque application information might get transported in the 851 signaling message, without being handled in the network. Development 852 and deployment of new applications should be possible without 853 impacting the network infrastructure. Additionally, QoS protocols 854 are expected to conform to the Internet principles. 856 5.5 QoS Control Information 858 This section contains requirements related to the QoS control 859 information that needs to be exchanged. 861 5.5.1 Mutability information on parameters 863 It should be possible for the initiator to control the mutability of 864 the QSC information. This prevents from being changed in a non- 865 recoverable way. The initiator should be able to control what is 866 requested end to end, without the request being gradually mutated as 867 it passes through a sequence of domains. This implies that in case 868 of changes made on the parameters, the original requested ones must 869 still be available. 871 Note that we do not require anything about particular QoS parameters 872 being changed. 874 Additionally, note that a provider or that particular QoS requested, 875 can still influence the QoS provisioning but in the signaling 876 message the request should stay the same. 878 5.5.2 Possibility to add and remove local domain information 880 It should be possible for the QoS control functions to add and 881 remove local scope elements. E.g., at the entrance to a QoS domain 882 domain-specific information is added, which is used in this domain 883 only, and the information is removed again when a signaling message 884 leaves the domain. The motivation is in the economy of re-use the 885 protocol for domain internal signaling of various information 886 pieces. Where additional information is needed for QoS control 887 within a particular domain, it should be possible to carry this at 888 the same time as the 'end to end' information.) 890 5.5.3 Independence of reservation identifier 892 A reservation identifier must be used, which is independent of the 893 flow identifier, the IP address of the QoS Initiator, and the flow 894 end-points. Various scenarios in the mobility area require this 895 independence because flows resulting from handoff might have changed 896 end-points etc. but still have the same QoS requirement. 898 5.5.4 Seamless modification of already reserved QoS 900 In many case, the reservation needs to be updated (up or downgrade). 901 This must happen seamlessly without service interruption. At least 902 the signaling protocol must allow for it, even if some data path 903 elements might not be capable of doing so. 905 5.5.5 Grouping of signaling for several microflows 907 NSIS may group signaling information for several microflow into one 908 signaling message. The goal of this is the optimization in terms of 909 setup delay, which can happen in parallel. This helps applications 910 requesting several flows at once. Also potential refreshes (in case 911 of a soft state solution) might profit of grouping. 913 However, the network must not know that a relationship between the 914 grouped flows exists. Nor is there any transactional semantic 915 allowed. It is only meant for optimization purposes and each 916 reservation is handled separately from each other. 918 5.6 Performance 920 This section discusses performance requirements and evaluation 921 criteria and the way in which these could and should be traded off 922 against each other in various parts of the solution. 924 Scalability is a must anyway. However, depending on the scenario the 925 question to which extends the protocol must be scalable. 927 5.6.1 Scalability in the number of messages received by a signaling 928 communication partner (QoS initiator and controller) 930 5.6.2 Scalability in number of hand-offs 932 5.6.3 Scalability in the number of interactions for setting up a 933 reservation 935 5.6.4 Scalability in the number of state per entity (QoS initiators and 936 QoS controllers) 938 5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 940 5.6.6 Low latency in setup 942 Low latency is only needed in scenarios, where reservations are in a 943 short time scale (e.g. handover in mobile environments), or where 944 human interaction is immediately concerned (e.g., voice 945 communication setup delay) 947 5.6.7 Allow for low bandwidth consumption for signaling protocol 949 Again only small sets of scenarios call for low bandwidth, mainly 950 those where wireless links are involved. 952 Note that many of the performance issues are heavily dependent on 953 the scenario assumed and are normally a trade-off between speed, 954 reliability, complexity, and scalability. The trade-off varies in 955 different parts of the network. For example, in radio access 956 networks low bandwidth consumption will overweight the low latency 957 requirement, while in core networks it may be reverse. 959 5.6.8 Ability to constrain load on devices 961 The NSIS architecture should give the ability to constrain the load 962 (CPU load, memory space, signaling bandwidth consumption and 963 signaling intensity) on devices where it is needed. One of the 964 reasons is that the protocol handling should have a minimal impact 965 on interior (core) nodes. 967 This can be achieved by many different methods. Examples, and this 968 are only examples, include message aggregation, by ignoring 969 signaling message, header compression, or minimizing functionality. 970 The framework may choose any method as long as the requirement is 971 met. 973 5.6.9 Highest possible network utilization 975 There are networking environments that require high network 976 utilization for various reasons, and the signaling protocol should 977 to its best ability support high resource utilization while 978 maintaining appropriate QoS. 980 In networks where resources are very expensive (as is the case for 981 many wireless networks), efficient network utilization is of 982 critical financial importance. On the other hand there are other 983 parts of the network where high utilization is not required. 985 5.7 Flexibility 987 This section lists the various ways the protocol can flexibly be 988 employed. 990 5.7.1 Aggregation capability, including the capability to select and 991 change the level of aggregation. 993 5.7.2 Flexibility in the placement of the QoS initiator 995 It might be the sender or the receiver of content. But also network- 996 initiated reservations are required in various scenarios such as 997 PSTN gateways, some VPNs, mobility. 999 5.7.3 Flexibility in the initiation of re-negotiation (QoS change 1000 requests) 1002 Again the sender or the receiver of content might initiate a re- 1003 negotiation due to various reasons, such as local resource shortage 1004 (CPU, memory on end-system) or a user changed application 1005 preference/profiles. But also network-initiated re-negotiation is 1006 required in cases, where the network is not able to further 1007 guarantee resources etc. 1009 5.7.4 Uni / bi-directional reservation 1011 Both unidirectional as well as bi-direction reservations must be 1012 possible. With bi-directional reservations we mean here reservations 1013 having the same end-points. But the path in the two directions does 1014 not need to be the same. 1016 The goal of a bi-directional reservation is mainly an optimization 1017 in terms of setup delay. There is no requirements on constrains such 1018 as use the same data path etc. 1020 5.8 Security 1022 This section discusses security-related requirements. For a 1023 discussion of security threats see [12]. 1025 5.8.1 Authentication of signaling requests 1027 A signaling protocol must make provision for enabling various 1028 entities to be authenticated against each other using strong 1029 authentication mechanisms. The term strong authentication points to 1030 the fact that weak plain-text password mechanisms must not be used 1031 for authentication. 1033 5.8.2 Resource Authorization 1035 The signaling protocol must provide means to authorize resource 1036 requests. This requirement demands a hook to interact with a policy 1037 entity to request authorization data. This allows an authenticated 1038 entity to be associated with authorization data and to verify the 1039 resource request. Authorization prevents reservations by unauthorized 1040 entities, reservations violating policies, theft of service and 1041 additionally limits denial of service attacks against parts of the 1042 network or the entire network caused by unrestricted reservations. 1043 Additionally it might be helpful to provide some means to inform 1044 other protocols of participating nodes within the same administrative 1045 domain about a previous successful authorization event. 1047 5.8.3 Integrity protection 1049 The signaling protocol must provide means to protect the message 1050 payloads against modifications. Integrity protection prevents an 1051 adversary from modifying with parts of the signaling message and from 1052 mounting denial of service or theft of service type of attacks 1053 against network elements participating in the protocol execution. 1055 5.8.4 Replay protection 1057 To prevent replay of previous signaling messages the signaling 1058 protocol must provide means to detect old i.e. already transmitted 1059 signaling messages. A solution must cover issues of synchronization 1060 problems in the case of a restart or a crash of a participating 1061 network element. The use of replay mechanism apart from sequence 1062 numbers should be investigated. 1064 5.8.5 Hop-by-hop security 1066 Hop-by-Hop security is a well known and proven concept in Quality-of- 1067 Service and other signaling protocols that allows intermediate nodes 1068 that actively participate in the protocol to modify the messages as 1069 it is required by processing rule. Note that this requirement does 1070 not exclude end-to-end or network-to-network security of a signaling 1071 message. End-to-end security between the initiator and the responder 1072 may be used to provide protection of non-mutable data fields. 1073 Network-to-network security refers to the protection of messages over 1074 various hops but not in an end-to-end manner i.e. protected over a 1075 particular network. 1077 5.8.6 Identity confidentiality and location privacy 1079 Identity confidentiality enables privacy and avoids profiling of 1080 entities by adversary eavesdropping the signaling traffic along the 1081 path. The identity used in the process of authentication may also be 1082 hidden to a limited extent from a network to which the initiator is 1083 attached. It is however required that the identity provides enough 1084 information for the nodes in the access network to collect accounting 1085 data. 1087 Location privacy is an issue for the initiator who triggers the 1088 signaling protocol. In some scenarios the initiator may not be 1089 willing to reveal location information to the responder as part the 1090 signaling procedure. 1091 The signaling protocol should provide means to protect the identity 1092 confidentiality and as far as possible location privacy. 1094 5.8.7 Denial-of-service attacks 1096 To effectively prevent denial-of-service attacks it is necessary that 1097 the used security and protocol mechanisms should not require the 1098 execution of heavy computation to verify a resource request prior 1099 authenticating the requesting entity. Additionally the signaling 1100 protocol and the used security mechanisms should not require large 1101 resource consumption (for example main memory or other additional 1102 message exchanges) before a successful authentication was done. A 1103 signaling protocol should provide prevention of DoS attacks. 1105 5.8.8 Confidentiality of signaling messages 1107 Based on the signaling information exchanged between nodes 1108 participating in the signaling protocol an adversary may learn both 1109 the identities and the content of the signaling messages. To prevent 1110 this from happening, confidentiality of the signaling message in a 1111 hop-by-hop manner may be provided. Note that the protection can be 1112 provided on a hop-by-hop basis for most message payloads since it is 1113 required that entities which actively participating in the signaling 1114 protocol must be able to read and eventually modify the content of 1115 the signaling messages. 1117 5.8.9 Ownership of a reservation 1119 When existing reservations have to be modified then there is a need 1120 to use a reservation identifier to uniquely identify the established 1121 state. A signaling protocol must provide the appropriate security 1122 protection to prevent other entities to modify state without having 1123 the proper ownership. 1125 5.8.10 Hooks with Authentication and Key Agreement protocols 1127 This requirement covers two subsequent steps before a signaling 1128 protocol is executed and the required hooks. First there is a need to 1129 agree on a specific authentication protocol. Later this protocol is 1130 executed and provides authentication and establishes the desired 1131 security associations. Using these security associations it is then 1132 possible to exchange secured signaling messages. 1134 The signaling protocol should provide hooks to interact with 1135 protocols that allow the negotiation of authentication and key 1136 agreement protocols. Although the negotiation of an authentication 1137 and key management protocol within the signaling protocol may be 1138 outside the scope it is still required to trigger this exchange in 1139 case that no such security association is available. 1141 This requirement originates from the fact that more than one key 1142 management protocol may be used to provide a security association for 1143 the signaling protocol. Hence the communicating entities must be 1144 capable to agree on a specific authentication. The selected 1145 authentication and key agreement protocol must however be able to 1146 create a security association that can be used within the signaling 1147 protocol. 1149 Key management protocols typically require a larger number of 1150 messages to be transmitted to allow a session key and the 1151 corresponding security association to be derived. To avoid the 1152 complex issue of embedding individual authentication and key 1153 agreement protocols into a specific signaling protocol it is required 1154 that most of these protocols are executed independently (prior to the 1155 signaling protocol) and although the key management protocol may be 1156 independent there must be a way for the signaling protocol to access 1157 and use available (i.e. already established) security associations to 1158 avoid executing a separate key management protocol (or instance of 1159 the same protocol) for protocols that closely operate together. If no 1160 such security association exists then there should be means for the 1161 signaling protocol to dynamically trigger such a protocol. 1163 5.9 Mobility 1165 5.9.1 Allow efficient QoS re-establishment after handover 1167 Handover is an essential function in wireless networks. After 1168 handover, QoS may need to be completely or partially re-established 1169 due to route changes. The re-establishment may be requested by the 1170 mobile node itself or triggered by the access point that the mobile 1171 node is attached to. In the first case, the QoS signaling should 1172 allow efficient QoS re-establishment after handover. Re- 1173 establishment of QoS after handover should be as quick as possible 1174 so that the mobile node does not experience service interruption or 1175 QoS degradation. The re-establishment should be localized, and not 1176 require end-to-end signaling, if possible. 1178 5.10 Interworking with other protocols and techniques 1180 Hooks must be provided to enable efficient interworking between 1181 various protocols and techniques including: 1183 5.10.1 Interworking with IP tunneling 1185 IP tunneling for various applications must be supported. More 1186 specifically tunneling for IPSec tunnels are of importance. This 1187 mainly impacts the identification of flows. Using IPsec parts of 1188 information for flow identification (e.g. transport protocol 1189 information), this information is not accessible for classification 1190 etc. 1192 5.10.2 The solution should not constrain either to IPv4 or IPv6 1193 5.10.3 Independence from charging model 1195 Signaling must not be constrained by charging models or the charging 1196 infrastructure used. 1198 5.10.4 Hooks for AAA protocols 1200 The security mechanism should be developed with respect to be able 1201 to collect usage records from one or more network elements. 1203 5.10.5 Interworking with seamless handoff protocols 1205 An NSIS protocol should interwork with seamless handoff protocols 1206 such as context transfer and candidate access router (CAR) 1207 discovery. The goal to achieve is that signaling for QoS works fast 1208 enough in case of a handoff, where that protocols might help in one 1209 way or the other. 1211 5.10.6 Interworking with non-traditional routing 1213 NSIS assumes traditional routing, but networks, which do non- 1214 traditional L3 routing, should not break it. 1216 5.11 Operational 1218 5.11.1 Ability to assign transport quality to signaling messages. 1220 The NSIS architecture should allow the network operator to assign 1221 the NSIS protocol messages a certain transport quality. As signaling 1222 opens up for possible denial-of-service attacks, this requirement 1223 gives the network operator a mean, but also the obligation, to 1224 trade-off between signaling latency and the impact (from the 1225 signaling messages) on devices within his/her network. From protocol 1226 design this requirement states that the protocol messages should be 1227 detectable, at least where the control and assignment of the 1228 messages priority is done. 1230 Furthermore, the protocol design must take into account reliability 1231 concerns. 1233 Communication reliability is seen as part of the quality assigned to 1234 signaling messages. So procedures must define how an NSIS signaling 1235 systems behaves if some kind of request it sent stays without 1236 answer. The basic transport protocol to be used between adjacent 1237 NSIS units must ensure message integrity and reliable transport. 1239 5.11.2 Graceful fail over 1241 Any unit participating in NSIS signaling must not cause further 1242 damage to other systems involved in NSIS signaling when it has to go 1243 out of service. 1245 6 The MUSTs, SHOULDs, and MAYs 1246 In order to prioritize the various requirements from Section 5, we 1247 define different 'parts of the network'. In the different parts of 1248 the network a particular requirement might have a different 1249 priority. 1251 The parts of the networks we differentiate are the host-to-first 1252 router, the access network, and the core network. The host to first 1253 router part includes all the layer 2 technologies to access to the 1254 Internet. In many cases, there is an application and/or user running 1255 on the host initiating QoS signaling. The access network can be 1256 characterized by low capacity links, medium speed IP processing 1257 capabilities, and it might consist of a complete layer 2 networks as 1258 well. The core network characteristics include high-speed forwarding 1259 capacities and interdomain QoS issues. All of them are not strictly 1260 defined and should not be regarded as that, but should give a 1261 feeling about where in the network we have different requirements 1262 concerning QoS signaling. 1264 Note that the requirement titles are listed for better reading. 1266 5.1 Architecture and Design Goals 1267 5.1.1 Applicability for different QoS technologies. 1268 5.1.2 Resource availability information on request 1269 5.1.3 Modularity 1270 5.1.4 Decoupling of protocol and information it is carrying 1271 5.1.5 Reuse of existing QoS provisioning 1272 5.1.6 Independence of signaling and provisioning paradigm 1274 ----------------------+-------------+-------------+------------+ 1275 | host-to-net | access | core | 1276 ----------------------+-------------+-------------+------------+ 1277 5.1.1 | | | | 1278 ----------------------+-------------+-------------+------------+ 1279 5.1.2 | | | | 1280 ----------------------+-------------+-------------+------------+ 1281 5.1.3 | | | | 1282 ----------------------+-------------+-------------+------------+ 1283 5.1.4 | | | | 1284 ----------------------+-------------+-------------+------------+ 1285 5.1.5 | | | | 1286 ----------------------+-------------+-------------+------------+ 1287 5.1.6 | | | | 1288 ----------------------+-------------+-------------+------------+ 1290 5.2 Signaling Flows 1291 5.2.1 Free placement of QoS Initiator and QoS Controllers functions 1293 5.2.2 No constraint of the QoS signaling and QoS Controllers to be 1294 in the data path. 1295 5.2.3 Concealment of topology and technology information 1296 5.2.4 Optional transparency of QoS signaling to network 1298 ----------------------+-------------+-------------+------------+ 1299 | host-to-net | access | core | 1300 ----------------------+-------------+-------------+------------+ 1301 5.2.1 | | | | 1302 ----------------------+-------------+-------------+------------+ 1303 5.2.2 | | | | 1304 ----------------------+-------------+-------------+------------+ 1305 5.2.3 | | | | 1306 ----------------------+-------------+-------------+------------+ 1307 5.2.4 | | | | 1308 ----------------------+-------------+-------------+------------+ 1310 5.3 Additional information beyond signaling of QoS information 1311 5.3.1 Explicit release of resources 1312 5.3.2 Possibility for automatic release of resources after failure 1313 5.3.3 Possibility for automatic re-setup of resources after recovery 1314 5.3.4 Prompt notification of QoS violation in case of error / 1315 failure to QoS Initiator and QoS Controllers 1316 5.3.5 Feedback about success of request for QoS guarantees 1317 5.3.6 Allow local QoS information exchange between nodes of the same 1318 administrative domain 1320 ----------------------+-------------+-------------+------------+ 1321 | host-to-net | access | core | 1322 ----------------------+-------------+-------------+------------+ 1323 5.3.1 | | | | 1324 ----------------------+-------------+-------------+------------+ 1325 5.3.2 | | | | 1326 ----------------------+-------------+-------------+------------+ 1327 5.3.3 | | | | 1328 ----------------------+-------------+-------------+------------+ 1329 5.3.4 | | | | 1330 ----------------------+-------------+-------------+------------+ 1331 5.3.5 | | | | 1332 ----------------------+-------------+-------------+------------+ 1333 5.3.6 | | | | 1334 ----------------------+-------------+-------------+------------+ 1336 5.4 Layering 1338 5.4.1 The signaling protocol and QoS control information should be 1339 application independent. 1341 ----------------------+-------------+-------------+------------+ 1342 | host-to-net | access | core | 1343 ----------------------+-------------+-------------+------------+ 1344 5.4.1 | | | | 1345 ----------------------+-------------+-------------+------------+ 1347 5.5 QoS Control Information 1349 5.5.1 Mutability information on parameters 1350 5.5.2 Possibility to add and remove local domain information 1351 5.5.3 Independence of reservation identifier 1352 5.5.4 Seamless modification of already reserved QoS 1353 5.5.5 Signaling must support quantitative, qualitative, and relative 1354 QoS specifications 1356 ----------------------+-------------+-------------+------------+ 1357 | host-to-net | access | core | 1358 ----------------------+-------------+-------------+------------+ 1359 5.5.1 | | | | 1360 ----------------------+-------------+-------------+------------+ 1361 5.5.2 | | | | 1362 ----------------------+-------------+-------------+------------+ 1363 5.5.3 | | | | 1364 ----------------------+-------------+-------------+------------+ 1365 5.5.4 | | | | 1366 ----------------------+-------------+-------------+------------+ 1367 5.5.5 | | | | 1368 ----------------------+-------------+-------------+------------+ 1370 5.6 Performance 1372 5.6.1 Scalability in the number of messages received by a signaling 1373 communication partner (QoS initiator and controller) 1374 5.6.2 Scalability in number of hand-offs 1375 5.6.3 Scalability in the number of interactions for setting up a 1376 reservation 1377 5.6.4 Scalability in the number of state per entity (QoS initiators 1378 and QoS controllers) 1379 5.6.5 Scalability in CPU use (end terminal and intermediate nodes) 1380 5.6.6 Low latency in setup 1381 5.6.7 Allow for low bandwidth consumption for signaling protocol 1382 5.6.8 Ability to constrain load on devices 1383 5.6.9 Highest possible network utilization 1385 ----------------------+-------------+-------------+------------+ 1386 | host-to-net | access | core | 1387 ----------------------+-------------+-------------+------------+ 1388 5.6.1 | | | | 1389 ----------------------+-------------+-------------+------------+ 1390 5.6.2 | | | | 1391 ----------------------+-------------+-------------+------------+ 1392 5.6.3 | | | | 1393 ----------------------+-------------+-------------+------------+ 1394 5.6.4 | | | | 1395 ----------------------+-------------+-------------+------------+ 1396 5.6.5 | | | | 1397 ----------------------+-------------+-------------+------------+ 1398 5.6.6 | | | | 1399 ----------------------+-------------+-------------+------------+ 1400 5.6.7 | | | | 1401 ----------------------+-------------+-------------+------------+ 1402 5.6.8 | | | | 1403 ----------------------+-------------+-------------+------------+ 1404 5.6.9 | | | | 1405 ----------------------+-------------+-------------+------------+ 1406 5.7 Flexibility 1408 5.7.1 Aggregation capability, including the capability to select and 1409 change the level of aggregation. 1410 5.7.2 Flexibility in the placement of the QoS initiator 1411 5.7.3 Flexibility in the initiation of re-negotiation (QoS change 1412 requests) 1413 5.7.4 Uni / bi-directional reservation 1415 ----------------------+-------------+-------------+------------+ 1416 | host-to-net | access | core | 1417 ----------------------+-------------+-------------+------------+ 1418 5.7.1 | | | | 1419 ----------------------+-------------+-------------+------------+ 1420 5.7.2 | | | | 1421 ----------------------+-------------+-------------+------------+ 1422 5.7.3 | | | | 1423 ----------------------+-------------+-------------+------------+ 1424 5.7.4 | | | | 1425 ----------------------+-------------+-------------+------------+ 1427 5.8 Security 1429 5.8.1 The QoS protocol must provide strong authentication 1430 5.8.2 The QoS protocol must provide means to authorize resource 1431 requests 1432 5.8.3 The QoS signaling messages must provide integrity protection. 1433 5.8.4 The QoS signaling messages must be replay protected. 1434 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. 1435 5.8.6 The QoS protocol should allow identity confidentiality and 1436 location privacy. 1437 5.8.7 The QoS protocol should prevent denial-of-service attacks 1438 against signaling entities. 1439 5.8.8 The QoS protocol should support confidentiality of signaling 1440 messages. 1441 5.8.9 The QoS protocol should provide hooks to interact with 1442 protocols that allow the negotiation of authentication and key 1443 management protocols. 1444 5.8.10 The QoS protocol should provide means to interact with key 1445 management protocols. 1447 ----------------------+-------------+-------------+------------+ 1448 | host-to-net | access | core | 1449 ----------------------+-------------+-------------+------------+ 1450 5.8.1 | | | | 1451 ----------------------+-------------+-------------+------------+ 1452 5.8.2 | | | | 1453 ----------------------+-------------+-------------+------------+ 1454 5.8.3 | | | | 1455 ----------------------+-------------+-------------+------------+ 1456 5.8.4 | | | | 1457 ----------------------+-------------+-------------+------------+ 1458 5.8.5 | | | | 1459 ----------------------+-------------+-------------+------------+ 1460 5.8.6 | | | | 1461 ----------------------+-------------+-------------+------------+ 1462 5.8.7 | | | | 1463 ----------------------+-------------+-------------+------------+ 1464 5.8.8 | | | | 1465 ----------------------+-------------+-------------+------------+ 1466 5.8.9 | | | | 1467 ----------------------+-------------+-------------+------------+ 1468 5.8.10 | | | | 1469 ----------------------+-------------+-------------+------------+ 1471 5.9 Mobility 1473 5.9.1 Allow efficient QoS re-establishment after handover 1474 ----------------------+-------------+-------------+------------+ 1475 | host-to-net | access | core | 1476 ----------------------+-------------+-------------+------------+ 1477 5.9.1 | | | | 1478 ----------------------+-------------+-------------+------------+ 1480 5.10 Interworking with other protocols and techniques 1482 5.10.1 Interworking with IP tunneling 1483 5.10.2 The solution should not constrain either to IPv4 or IPv6 1485 5.10.3 Independence from charging model 1486 5.10.4 The QoS protocol should provide hooks for AAA protocols 1487 5.10.5 Interworking with seamless handoff protocols 1488 5.10.6 Interworking with non-traditional routing 1490 ----------------------+-------------+-------------+------------+ 1491 | host-to-net | access | core | 1492 ----------------------+-------------+-------------+------------+ 1493 5.10.1 | | | | 1494 ----------------------+-------------+-------------+------------+ 1495 5.10.2 | | | | 1496 ----------------------+-------------+-------------+------------+ 1497 5.10.3 | | | | 1498 ----------------------+-------------+-------------+------------+ 1499 5.10.4 | | | | 1500 ----------------------+-------------+-------------+------------+ 1501 5.10.5 | | | | 1502 ----------------------+-------------+-------------+------------+ 1503 5.10.6 | | | | 1504 ----------------------+-------------+-------------+------------+ 1506 5.11 Operational 1507 5.11.1 Ability to assign transport quality to signaling messages 1509 ----------------------+-------------+-------------+------------+ 1510 | host-to-net | access | core | 1511 ----------------------+-------------+-------------+------------+ 1512 5.11.1 | | | | 1513 ----------------------+-------------+-------------+------------+ 1515 7 References 1517 [1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem 1518 Statement", RFC 3132, June 2001. 1520 [2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP", 1521 draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress, 1522 August 2001 1524 [3] Manner. J., et al, "Mobility Related Terminology", draft-manner- 1525 seamoby-terms-02.txt, Work In Progress, July 2001. 1527 [4] 3GPP, "General Packet Radio Service (GPRS); Service Description 1528 Stage 2 v 7.7.0", TS 03.60, June 2001 1530 [5] 3GPP2, "Network Reference Model for cdma2000 Spread Spectrum 1531 System, revision B", S.R0005-B, May 2001 1533 [6] Bradner, S., Mankin, A., "Report of the Next Steps in Signaling 1534 BOF", draft-bradner-nsis-bof-00.txt, Work in Progress, July 2001 1536 [7] Partain, D., et al, "Resource Reservation Issues in Cellular 1537 Radio Access Networks", draft-westberg-rmd-cellular-issues-00.txt, 1538 Work in Progress, June 2001. 1540 [8] YESSIR - YEt another Sender Session Internet Reservations, 1541 http://www.cs.columbia.edupingpan/projects/yessir.html 1543 [9] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1544 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1545 Specification", IETF RFC 2205, 1997. 1547 [10] Westberg, L., Jacobsson, M., Partain, D., Karagiannis, G., 1548 Oosthoek, S., Rexhepi, V., Szabo, R., Wallentin, P., "Resource 1549 Management in Diffserv Framework", Internet draft, work in progress, 1550 draft-westberg-rmd-framework-xx.txt, 2002. 1552 [11] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA 1553 Radio Access Network", IETF Draft, draft-kempf-cdma-appl-02.txt, 1554 Work in progress, September 2001. 1556 [12] Tschofenig, H., "NSIS Threats", , May 2002. 1559 8 Acknowledgments 1561 Quite a number of people have been involved in the discussion of the 1562 draft, adding some ideas, requirements, etc. We list them without a 1563 guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul 1564 (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas 1565 Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), 1566 Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 1567 University Berlin), Xiaoming Fu (Technical University Berlin), Hans- 1568 Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph 1569 Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya 1570 Freytsis. 1572 Some text and/or ideas for text, requirements, scenarios have been 1573 taken from a draft written by the following authors: David Partain 1574 (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), 1575 Georgios Karagiannis (Ericsson), Jukka Manner (University of 1576 Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 1577 Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have 1578 actively contributed new text to the draft as well. 1580 Another draft impacting this draft has been written by Sven Van den 1581 Bosch, Maarten Buchli, and Danny Goderis. These people contributed 1582 also with new text. 1584 9 Author's Addresses 1586 Marcus Brunner (Editor) 1587 NEC Europe Ltd. 1588 Network Laboratories 1589 Adenauerplatz 6 1590 D-69115 Heidelberg 1591 Germany 1592 E-Mail: brunner@ccrle.nec.de (contact) 1594 Robert Hancock, Eleanor Hepworth 1595 Roke Manor Research Ltd 1596 Romsey, Hants, SO51 0ZN 1597 United Kingdom 1598 E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk 1600 Cornelia Kappler 1601 Siemens AG 1602 Berlin 13623 1603 Germany 1604 E-Mail: cornelia.kappler@icn.siemens.de 1606 Hannes Tschofenig 1607 Siemens AG 1608 Otto-Hahn-Ring 6 1609 81739 Munchen 1610 Germany 1611 Email: Hannes.Tschofenig@mchp.siemens.de 1613 10 Appendix: Scenarios/Use cases 1615 In the following we describe scenarios, which are important to 1616 cover, and which allow us to discuss various requirements. Some 1617 regard this as use cases to be covered defining the use of a QoS 1618 signaling protocol. 1620 10.1 Scenario: Terminal Mobility 1622 The scenario we are looking at is the case where a mobile terminal 1623 (MT) changes from one access point to another access point. The 1624 access points are located in separate QoS domains. We assume Mobile 1625 IP to handle mobility on the network layer in this scenario and 1626 consider the various extensions (i.e., IETF proposals) to Mobile IP, 1627 in order to provide 'fast handover' for roaming Mobile Terminals. 1628 The goal to be achieved lies in providing, keeping, and adapting the 1629 requested QoS for the ongoing IP sessions in case of handover. 1630 Furthermore, the negotiation of QoS parameters with the new domain 1631 via the old connection might be needed, in order to support the 1632 different 'fast handover' proposals within the IETF. 1634 The entities involved in this scenario include a mobile terminal, 1635 access points, an access network manager, communication partners of 1636 the MT (the other end(s) of the communication association). 1637 From a technical point of view, terminal mobility means changing the 1638 access point of a mobile terminal (MT). However, technologies might 1639 change in various directions (access technology, QoS technology, 1640 administrative domain). If the access points are within one specific 1641 QoS technology (independent of access technology) we call this 1642 intra-QoS technology handoff. In the case of an inter-QoS technology 1643 handoff, one changes from e.g. a DiffServ to an IntServ domain, 1644 however still using the same access technology. Finally, if the 1645 access points are using different access technologies we call it 1646 inter-technology hand-off. 1648 The following issues are of special importance in this scenario: 1650 1) Handoff decision 1652 - The QoS management requests handoff. The QoS management can decide 1653 to change the access point, since the traffic conditions of the new 1654 access point are better supporting the QoS requirements. The metric 1655 may be different (optimized towards a single or a group/class of 1656 users). Note that the MT or the network (see below) might trigger 1657 the handoff. 1659 - The mobility management forces handoff. This can have several 1660 reasons. The operator optimizes his network, admission is no longer 1661 granted (e.g. emptied prepaid condition). Or another example is when 1662 the MT is reaching the focus of another base station. However, this 1663 might be detected via measurements of QoS on the physical layer and 1664 is therefore out of scope of QoS signaling in IP. Note again that 1665 the MT or the network (see below) might trigger the handoff. 1667 - This scenario shows that local decisions might not be enough. The 1668 rest of the path to the other end of the communication needs to be 1669 considered as well. Hand-off decisions in a QoS domain, does not 1670 only depend on the local resource availability, e.g., the wireless 1671 part, but involves the rest of the path as well. Additionally, 1672 decomposition of an end-to-end reservation might be needed, in order 1673 to change only parts of it. 1675 2) Trigger sources 1677 - Mobile terminal: If the end-system QoS management identifies 1678 another (better-suited) access point, it will request the handoff 1679 from the terminal itself. This will be especially likely in the case 1680 that two different provider networks are involved. Another important 1681 example is when the current access point bearer disappears (e.g. 1682 removing the Ethernet cable). In this case, the QoS initiator is 1683 basically located on the mobile terminal. 1685 - Network (access network manager): Sometimes, the handoff trigger 1686 will be issued from the network management to optimize the overall 1687 load situation. Most likely this will result in changing the base- 1688 station of a single providers network. Most likely the QoS initiator 1689 is located on a system within the network. 1691 3) Integration with other protocols 1693 - Interworking with other protocol must be considered in one or the 1694 other form. E.g., it might be worth combining QoS signaling between 1695 different QoS domains with mobility signaling at hand-over. 1697 4) Handover rates 1699 In mobile networks, the admission control process has to cope with 1700 far more admission requests than call setups alone would generate. 1701 For example, in the GSM (Global System for Mobile communications) 1702 case, mobility usually generates an average of one to two handovers 1703 per call. For third generation networks (such as UMTS), where it is 1704 necessary to keep radio links to several cells simultaneously 1705 (macro-diversity), the handover rate is significantly higher (see 1706 for example [11]) 1708 5) Fast reservations 1710 Handover can also cause packet losses. This happens when the 1711 processing of an admission request causes a delayed handover to the 1712 new base station. In this situation, some packets might be 1713 discarded, and the overall speech quality might be degraded 1714 significantly. Moreover, a delay in handover may cause degradation 1715 for other users. In the worst-case scenario, a delay in handover may 1716 cause the connection to be dropped if the handover occurred due to 1717 bad air link quality. Therefore, it is critical that QoS signaling 1718 in connection with handover be carried out very quickly. 1720 6) Call blocking in case of overload 1722 Furthermore, when the network is overloaded, it is preferable to 1723 keep reservations for previously established flows while blocking 1724 new requests. Therefore, the resource reservation requests in 1725 connection with handover should be given higher priority than new 1726 requests for resource reservation. 1728 10.2 Scenario: Cellular Networks 1730 In this scenario, the user is using the packet service of a 3rd 1731 generation cellular system, e.g. UMTS. The region between the End 1732 Host and the edge node connecting the cellular network to another 1733 QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is 1734 considered to be a single QoS domain [4][5]. 1736 The issues in such an environment regarding QoS include: 1738 1) Cellular systems provide their own QoS technology with 1739 specialized parameters to co-ordinate the QoS provided by both the 1740 radio access and wired access network. For example, in a UMTS 1741 network, one aspect of GPRS is that it can be considered as a QoS 1742 technology; provisioning of QoS within GPRS is described mainly in 1743 terms of calling UMTS bearer classes. This QoS technology needs to 1744 be invoked with suitable parameters when higher layers trigger a 1745 request for QoS, and this therefore involves mapping the requested 1746 IP QoS onto these UMTS bearer classes. This request for resources 1747 might be triggered by IP signaling messages that pass across the 1748 cellular system, and possibly other QoS domains, to negotiate for 1749 network resources. Typically, cellular system specific messages 1750 invoke the underlying cellular system QoS technology in parallel 1751 with the IP QoS negotiation, to allocate the resources within the 1752 cellular system. 1754 2) The placement of QoS initiators and QoS controllers (terminology 1755 in the framework given here). The QoS initiator could be located at 1756 the End Host (triggered by applications), the GGSN/PDSN, or at a 1757 node not directly on the data path, such as a bandwidth broker. In 1758 the second case, the GGSN/PDSN could either be acting as a proxy on 1759 behalf of an End Host with little capabilities, and/or managing 1760 aggregate resources within its QoS domain (the UMTS core network). 1761 The IP signaling messages are interpreted by the QoS controllers, 1762 which may be located at the GGSN/PDSN, and in any QoS sub-domains 1763 within the cellular system. 1765 3) Initiation of IP-level QoS negotiation. IP-level QoS re- 1766 negotiation may be initiated by either the End Host, or by the 1767 network, based on current network loads, which might change 1768 depending on the location of the end host. 1770 4) The networks are designed and mainly used for speech 1771 communication (at least so far). 1773 Note that in comparison to the former scenario, the emphasis is much 1774 less on the mobility aspects, because mobility is mainly handled on 1775 the lower layer. 1777 10.3 Scenario: UMTS access 1778 The UMTS access scenario is shown in figure 3. The Proxy-Call State 1779 Control Function/Policy Control Function (P-CSCF/PCF) is the 1780 outbound SIP proxy of the visited domain, i.e. the domain where the 1781 mobile user wants to set-up a call. The Gateway GPRS Support Node 1782 (GGSN) is the egress router of the UMTS domain and connects the UMTS 1783 access network to the Edge Router (ER) of the core IP network. The 1784 P-CSCF/PCF communicates with the GGSN via the COPS protocol [4]. The 1785 User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal 1786 Equipment (TE), e.g. a laptop. 1788 +--------+ 1789 +----------| P-CSCF |-------> SIP signaling 1790 / +--------+ 1791 / SIP : 1792 : +--------+ NSIS +----------------+ 1793 : | PCF |---------| QoS Controller | 1794 : +--------+ +----------------+ 1795 : : 1796 : : COPS 1797 : : 1798 +----+ +--------+ +----+ 1799 | UE |----------| GGSN |------| ER | 1800 +----+ +--------+ +----+ 1802 Figure 1: UMTS access scenario 1804 In this scenario the GGSN has the role of Access Gate. According to 1805 3GPP standardization, the PCF is responsible for the policy-based 1806 control of the end-user service in the UMTS access network (i.e. 1807 from UE to GGSN). In the current UMTS release R.5, the PCF is part 1808 of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF 1809 may evolve to an open standardized interface. In any case the PCF 1810 has all required QoS information for per-flow admission control in 1811 the UMTS access network (which it gets from the P-CSCF and/or GGSN). 1812 Thus the PCF would be the appropriate entity to host the 1813 functionality of QI, initiating the "NSIS" QoS signaling towards the 1814 core IP network. The PCF/P-CSCF has to do the mapping from codec 1815 type (derived from SIP/SDP signaling) to IP traffic descriptor. SDP 1816 extensions to explicitly signal QoS information [7] are useful to 1817 avoid the need to store codec information in the PCF and to allow 1818 for more flexibility and accurate description of the QoS traffic 1819 parameters. The PCF also controls the GGSN to open and close the 1820 gates and to configure per-flow policers, i.e. to authorize or 1821 forbid user traffic. 1823 The QC is (of course) not part of the standard UMTS architecture. 1824 However, to achieve end-to-end QoS a QC is needed such that the PCF 1825 can request a QoS connection to the IP network. As in the previous 1826 example, the QC could manage a set of pre-provisioned resources in 1827 the IP network, i.e. bandwidth pipes, and the QC performs per-flow 1828 admission control into these pipes. In this way, a connection can be 1829 made between two UMTS access networks, and hence, end-to-end QoS can 1830 be achieved. In this case the QI and QC are clearly two separate 1831 entities. 1832 This use case clearly illustrates the need for an "NSIS" QoS 1833 signaling protocol between QI and QC. An important application of 1834 such a protocol may be its use in the inter-connection of UMTS 1835 networks over an IP backbone. 1837 10.4 Scenario: Wired part of wireless network 1839 A wireless network, seen from a QoS domain perspective, usually 1840 consists of three parts: a wireless interface part (the "radio 1841 interface"), a wired part of the wireless network (i.e., Radio 1842 Access Network) and the backbone of the wireless network, as shown 1843 in Figure 2. Note that this figure should not be seen as an 1844 architectural overview of wireless networks but rather as showing 1845 the conceptual QoS domains in a wireless network. 1847 In this scenario, a mobile host can roam and perform a handover 1848 procedure between base stations/access routers. In this scenario the 1849 NSIS QoS protocol can be applied between a base station and the 1850 gateway (GW). In this case a GW can also be considered as a local 1851 handover anchor point. Furthermore, in this scenario the NSIS QoS 1852 protocol can also be applied either between two GWs, or between two 1853 edge routers (ER). 1855 |--| 1856 |GW| 1857 |--| |--| 1858 |MH|--- . 1859 |--| / |-------| . 1860 /--|base | |--| . 1861 |station|-|ER|.... 1862 |-------| |--| . |--| back- |--| |---| 1863 |----| 1865 ...|ER|.......|ER|..|BGW|.."Internet"..|host| 1866 -- |-------| |--| . |--| bone |--| |---| 1867 |----| 1868 |--| \ |base |-|ER|... . 1869 |MH| \ |station| |--| . 1870 |--|--- |-------| . MH = mobile host 1871 |--| ER = edge router 1872 <----> |GW| GW = gateway 1873 Wireless link |--| BGW = border gateway 1874 ... = interior nodes 1875 <-------------------> 1876 Wired part of wireless network 1878 <----------------------------------------> 1879 Wireless Network 1881 Figure 2. QoS architecture of wired part of wireless network 1883 Each of these parts of the wireless network impose different issues 1884 to be solved on the QoS signaling solution being used: 1886 * Wireless interface: The solution for the air interface link 1887 has to ensure flexibility and spectrum efficient transmission 1888 of IP packets. However, this link layer QoS can be solved in 1889 the same way as any other last hop problem by allowing a 1890 host to request the proper QoS profile. 1892 * Wired part of the wireless network: This is the part of 1893 the network that is closest to the base stations/access 1894 routers. It is an IP network although some parts logically 1895 perform tunneling of the end user data. In cellular networks, 1896 the wired part of the wireless network is denoted as a 1897 radio access network. 1899 This part of the wireless network has different 1900 characteristics when compared to traditional IP networks: 1902 1. The network supports a high proportion of real-time 1903 traffic. The majority of the traffic transported in the 1904 wired part of the wireless network is speech, which is 1905 very sensitive to delays and delay variation (jitter). 1907 2. The network must support mobility. Many wireless 1908 networks are able to provide a combination of soft 1909 and hard handover procedures. When handover occurs, 1910 reservations need to be established on new paths. 1911 The establishment time has to be as short as possible 1912 since long establishment times for reservations degrade 1913 the performance of the wireless network. Moreover, 1914 for maximal utilization of the radio spectrum, frequent 1915 handover operations are required. 1917 3. These links are typically rather bandwidth-limited. 1919 4. The wired transmission in such a network contains a 1920 relatively high volume of expensive leased lines. 1921 Overprovisioning might therefore be prohibitively 1922 expensive. 1924 5. The radio base stations are spread over a wide 1925 geographical area and are in general situated a large 1926 distance from the backbone. 1928 * Backbone of the wireless network: the requirements imposed 1929 by this network are similar to the requirements imposed by 1930 other types of backbone networks. 1932 Due to these very different characteristics and requirements, often 1933 contradictory, different QoS signaling solutions might be needed in 1934 each of the three network parts. 1936 10.5 Scenario: Session Mobility 1938 In this scenario, a session is moved from one end-system to another. 1939 Ongoing sessions are kept and QoS parameters need to be adapted, 1940 since it is very likely that the new device provides different 1941 capabilities. Note that it is open which entity initiates the move, 1942 which implies that the QoS initiator might be triggered by different 1943 entities. 1945 User mobility (i.e., a user changing the device and therefore moving 1946 the sessions to the new device) is considered to be a special case 1947 within the session mobility scenario. 1949 Note that this scenario is different from terminal mobility. Not the 1950 terminal (end-system) has moved to a different access point. Both 1951 terminals are still connected to an IP network at their original 1952 points. 1954 The issues include: 1956 1) Keeping the QoS guarantees negotiated implies that the end- 1957 point(s) of communication are changed without changing the 1958 reservations. 1960 2) The trigger of the session move might be the user or any other 1961 party involved in the session. 1963 10.6 Scenario: QoS reservations/negotiation from access to core 1964 network 1966 The scenario includes the signaling between access networks and core 1967 networks in order to setup and change reservations together with 1968 potential negotiation. 1970 The issues to be solved in this scenario are different from previous 1971 ones. 1973 1) The entity of reservation is most likely an aggregate. 1975 2) The time scales of reservations might be different (long living 1976 reservations of aggregates, rarer re-negotiation). 1978 3) The specification of the traffic (amount of traffic), a 1979 particular QoS is guaranteed for, needs to be changed. E.g., in case 1980 additional flows are added to the aggregate, the traffic 1981 specification of the flow needs to be added if it is not already 1982 included in the aggregates specification. 1984 4) The flow specification is more complex including network 1985 addresses and sets of different address for the source as well as 1986 for the destination of the flow. 1988 10.7 Scenario: QoS reservation/negotiation over administrative 1989 boundaries 1991 Signaling between two or more core networks to provide QoS is 1992 handled in this scenario. This might also include access to core 1993 signaling over administrative boundaries. Compared to the previous 1994 one it adds the case, where the two networks are not in the same 1995 administrative domain. Basically, it is the inter-domain/inter 1996 provider signaling which is handled in here. 1998 The domain boundary is the critical issue to be resolved. Which as 1999 various flavors of issues a QoS signaling protocol has to be 2000 concerned with. 2002 1) Competing administrations: Normally, only basic information 2003 should be exchanged, if the signaling is between competing 2004 administrations. Specifically information about core network 2005 internals (e.g., topology, technology, etc.) should not be 2006 exchanged. Some information exchange about the "access points" of 2007 the core networks (which is topology information as well) may need 2008 to be exchanged, because it is needed for proper signaling. 2010 2) Additionally, as in scenario 4, signaling most likely is based on 2011 aggregates, with all the issues raise there. 2013 3) Authorization: It is critical that the QoS initiator is 2014 authorized to perform a QoS path setup. 2016 4) Accountability: It is important to notice that signaling might be 2017 used as an entity to charge money for, therefore the interoperation 2018 with accounting needs to be available. 2020 10.8 Scenario: QoS signaling between PSTN gateways and backbone 2021 routers 2023 A PSTN gateway (i.e., host) requires information from the network 2024 regarding its ability to transport voice traffic across the network. 2025 The voice quality will suffer due to packet loss, latency and 2026 jitter. Signaling is used to identify and admit a flow for which 2027 these impairments are minimized. In addition, the disposition of 2028 the signaling request is used to allow the PSTN GW to make a call 2029 routing decision before the call is actually accepted and delivered 2030 to the final destination. 2032 PSTN gateways may handle thousands of calls simultaneously and there 2033 may be hundreds of PSTN gateways in a single provider network. These 2034 numbers are likely to increase as the size of the network increases. 2035 The point being that scalability is a major issue. 2037 There are several ways that a PSTN gateway can acquire assurances 2038 that a network can carry its traffic across the network. These 2039 include: 2041 1. Over-provisioning a high availability network. 2043 2. Handling admission control through some policy server 2044 that has a global view of the network and its resources. 2045 3. Per PSTN GW pair admission control. 2046 4. Per call admission control (where a call is defined as 2047 the 5 tuple used to carry a single RTP flow). 2049 Item 1 requires no signaling at all and is therefore outside the 2050 scope of this working group. 2052 Item 2 is really a better informed version of 1, but it is also 2053 outside the scope of this working group as it relies on a particular 2054 telephony signaling protocol rather than a packet admission control 2055 protocol. 2057 Item 3 is initially attractive as it appears to have reasonable 2058 scaling properties, however, its scaling properties only are 2059 effective in cases where there are relatively few PSTN GWs. In the 2060 more general case were a PSTN GW reduces to a single IP phone 2061 sitting behind some access network, the opportunities for 2062 aggregation are reduced and the problem reduces to item 4. 2064 Item 4 is the most general case. However, it has the most difficult 2065 scaling problems. The objective here is to place the requirements on 2066 Item 4 such that a scalable per-flow admission control protocol or 2067 protocol suite may be developed. 2069 The case where per-flow signaling extends to individual IP end- 2070 points allows the inclusion of IP phones on cable, DSL, wireless or 2071 other access networks in this scenario. 2073 Call Scenario 2075 A PSTN GW signals end-to-end for some 5 tuple defined flow a 2076 bandwidth and QoS requirement. Note that the 5 tuple might include 2077 masking/wildcarding. The access network admits this flow according 2078 to its local policy and the specific details of the access 2079 technology. 2081 At the edge router (i.e., border node), the flow is admitted, again 2082 with an optional authentication process, possibly involving an 2083 external policy server. Note that the relationship between the PSTN 2084 GW and the policy server and the routers and the policy server is 2085 outside the scope of NSIS. The edge router then admits the flow into 2086 the core of the network, possibly using some aggregation technique. 2088 At the interior nodes, the NSIS host-to-host signaling should either 2089 be ignored or invisible as the Edge router performed the admission 2090 control decision to some aggregate. 2092 At the inter-provider router (i.e., border node), again the NSIS 2093 host-to-host signaling should either be ignored or invisible as the 2094 Edge router has performed an admission control decision about an 2095 aggregate across a carrier network. 2097 10.9 Scenario: PSTN trunking gateway 2099 One of the use cases for the NSIS signaling protocol is the scenario 2100 of interconnecting PSTN gateways with an IP network that supports 2101 QoS. 2102 Four different scenarios are considered here. 2103 1. In-band QoS signaling is used. In this case the Media Gateway 2104 (MG) will be acting as the QoS Initiator and the Edge Router 2105 (ER) will be the QoS Controller. Hence, the ER should do 2106 admission control (into pre-provisioned traffic trunks) for the 2107 individual traffic flows. This scenario is not further 2108 considered here. 2109 2. Out-of-band signaling in a single domain, the QoS Controller is 2110 integrated in the MGC. In this case no NSIS protocol is 2111 required. 2112 3. Out-of-band signaling in a single domain, the QoS Controller is 2113 a separate box. In this case NSIS signaling is used between the 2114 MGC and the QoS Controller. 2115 4. Out-of-band signaling between multiple domains, the QoS 2116 Controller (which may be integrated in the MGC) triggers the 2117 QoS Controller of the next domain. 2119 When the out-of-band QoS signaling is used the Media Gateway 2120 Controller (MGC) will be acting as the QoS Initiator. 2122 In the second scenario the voice provider manages a set of traffic 2123 trunks that are leased from a network provider. The MGC does the 2124 admission control in this case. Since the QoS Controller acts both 2125 as a QoS Initiator and a QoS Controller, no NSIS signaling is 2126 required. This scenario is shown in figure 1. 2128 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 2129 | SS7 network |---------------------| MGC |--------------| SS7 | 2130 +-------------+ +-------+-----+---------+ +-----+ 2131 : / : \ 2132 : / : \ 2133 : / +--------:----------+ \ 2134 : MEGACO / / : \ \ 2135 : / / +-----+ \ \ 2136 : / / | NMS | \ \ 2137 : / | +-----+ | \ 2138 : : | | : 2139 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 2140 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 2141 +--------------+ +----+ \ / +----+ 2142 \ QoS network / 2143 +-------------------+ 2145 Figure 1: PSTN trunking gateway scenario 2147 In the third scenario, the voice provider does not lease traffic 2148 trunks in the network. Another entity may lease traffic trunks and 2149 may use a QoS Controller to do per-flow admission control. In this 2150 case the NSIS signaling is used between the MGC and the QoS 2151 Controller, which is a separate box here. Hence, the MGC acts only 2152 as a QoS Initiator. This scenario is depicted in figure 2. 2154 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 2155 | SS7 network |---------------------| MGC |--------------| SS7 | 2156 +-------------+ +-------+-----+---------+ +-----+ 2157 : / : \ 2158 : / +-----+ \ 2159 : / | QC | \ 2160 : / +-----+ \ 2161 : / : \ 2162 : / +--------:----------+ \ 2163 : MEGACO : / : \ : 2164 : : / +-----+ \ : 2165 : : / | NMS | \ : 2166 : : | +-----+ | : 2167 : : | | : 2168 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 2169 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 2170 +--------------+ +----+ \ / +----+ 2171 \ QoS network / 2172 +-------------------+ 2174 Figure 2: PSTN trunking gateway scenario 2176 In the fourth scenario multiple transport domains are involved. In 2177 the originating network either the MGC may have an overview on the 2178 resources of the overlay network or a separate QoS Controller will 2179 have the overview. Hence, depending on this either the MGC or the 2180 QoS Controller of the originating domain will contact the QoS 2181 Controller of the next domain. The MGC always acts as a QoS 2182 Initiator and may also be acting as a QoS Controller in the first 2183 domain. 2185 10.10 Scenario: Application request end-to-end QoS path from the 2186 network 2188 This is actually the easiest case, nevertheless might be most often 2189 used in terms of number of users. So multimedia application requests 2190 a guaranteed service from an IP network. We assume here that the 2191 application is somehow able to specify the network service. The 2192 characteristics here are that many hosts might do it, but that the 2193 requested service is low capacity (bounded by the access line). 2194 Additionally, we assume no mobility and standard devices. 2196 10.11 Scenario: QOS for Virtual Private Networks 2198 In a Virtual Private Network (VPN) a variety of tunnels might be 2199 used between its edges. These tunnels could be for example, IP-Sec, 2200 GRE, and IP-IP. One of the most significant issues in VPNs is 2201 related to how a flow is identified and what quality a flow gets. A 2202 flow identification might consist among others of the transport 2203 protocol port numbers. In an IP-Sec tunnel this will be problematic 2204 since the transport protocol information is encrypted. 2206 There are two types of L3 VPNs, distinguished by where the endpoints 2207 of the tunnels exist. The endpoints of the tunnels may either be on 2208 the customer (CPE) or the provider equipment or provider edge (PE). 2210 Virtual Private networks are also likely to request bandwidth or 2211 other type of service in addition to the premium services the PSTN 2212 GW are likely to use. 2214 Tunnel end points at the Customer premises 2216 When the endpoints are the CPE, the CPE may want to signal across 2217 the public IP network for a particular amount of bandwidth and QoS 2218 for the tunnel aggregate. Such signaling may be useful when a 2219 customer wants to vary their network cost with demand, rather than 2220 paying a flat rate. Such signaling exists between the two CPE 2221 routers. Intermediate access and edge routers perform the same exact 2222 call admission control, authentication and aggregation functions 2223 performed by the corresponding routers in the PSTN GW scenario with 2224 the exception that the endpoints are the CPE tunnel endpoints rather 2225 than PSTN GWs and the 5-tuple used to describe the RTP flow is 2226 replaced with the corresponding flow spec to uniquely identify the 2227 tunnels. Tunnels may be of any variety (e.g. IP-Sec, GRE, IP-IP). 2229 In such a scenario, NSIS would actually allow partly for customer 2230 managed VPNs, which means a customer can setup VPNs by subsequent 2231 NSIS signaling to various end-point. Plus the tunnel end-points are 2232 not necessarily bound to an application. The customer administrator 2233 might be the one triggering NSIS signaling. 2235 Tunnel end points at the provider premises 2237 In the case were the tunnel end-points exist on the provider edge, 2238 requests for bandwidth may be signaled either per flow, where a flow 2239 is defined from a customers address space, or between customer 2240 sites. 2242 In the case of per flow signaling, the PE router must map the 2243 bandwidth request to the tunnel carrying traffic to the destination 2244 specified in the flow spec. Such a tunnel is a member of an 2245 aggregate to which the flow must be admitted. In this case, the 2246 operation of admission control is very similar to the case of the 2247 PSTN GW with the additional level of indirection imposed by the VPN 2248 tunnel. Therefore, authentication, accounting and policing may be 2249 required on the PE router. 2251 In the case of per site signaling, a site would need to be 2252 identified. This may be accomplished by specifying the network 2253 serviced at that site through an IP prefix. In this case, the 2254 admission control function is performed on the aggregate to the PE 2255 router connected to the site in question. 2257 Full Copyright Statement 2259 Copyright (C) The Internet Society (2000). All Rights Reserved. 2260 This document and translations of it may be copied and furnished to 2261 others, and derivative works that comment on or otherwise explain it 2262 or assist in its implementation may be prepared, copied, published 2263 and distributed, in whole or in part, without restriction of any 2264 kind, provided that the above copyright notice and this paragraph are 2265 included on all such copies and derivative works. However, this 2266 document itself may not be modified in any way, such as by removing 2267 the copyright notice or references to the Internet Society or other 2268 Internet organizations, except as needed for the purpose of 2269 developing Internet standards in which case the procedures for 2270 copyrights defined in the Internet Standards process must be 2271 followed, or as required to translate it into languages other than 2272 English. 2273 The limited permissions granted above are perpetual and will not be 2274 revoked by the Internet Society or its successors or assigns. 2275 This document and the information contained herein is provided on an 2276 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2277 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 2278 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2279 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2280 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2282 Open Issues/To Dos 2284 2) (OPEN) Sender/receiver initiation 2286 What is the requirement concerning data sender or data receiver or 2287 both to initiate a QoS request. 2289 Terminology text added 2291 open issue, what is a potential req (currently we say "both must be 2292 possible") 2294 Proposals: 2295 1)should be optimized for sender initiated 2296 2) remove the requirement, because it is not relevant if we allow 2297 for third party QoS initiators 2298 3) SHOULD support sender initiated, MAY support reciever initiated 2300 Issues: 2301 - does it matter who pays? 2303 - for sender initiated, can we support implicit signaling 2304 (bundling the QoS requests with other signaling - registration, 2305 etc.)? 2307 - For reciever initiated, do we need protection against spamming - 2308 how do we protect against unwanted changes? 2309 4) (OPEN) MUSTs, SHOULDs, MAY needs discussion 2311 28) (OPEN) new requirement on "asynchronous events from the network" 2313 The content of the message might be very service specific, but the 2314 protocol support for asynchronous events from the network might be a 2315 valuable requirement. We have something about notification in case 2316 of errors/failures. 2318 Asynchronous notification of QoS Initiator, Controller, Receiver, 2319 there are security issues related. Basically, an ownership issue. 2320 Nevertheless, an asynch notifcation in case of an error, network 2321 failure etc. is specifically in areas, where longer lived sessions 2322 are setup, essential in order to notify upper layers. 2324 44) (OPEN) req resource availability info on request come back to it 2325 as soon as we have a more clear idea about service description issue 2327 53) (OPEN) Error handling 2329 Comments: 2330 1) notification of user in case of unrecoverable errors (has been 2331 done by notification requirement, or will be done by asynch 2332 notification, issue 43) 2333 A description of both types of errors (recoverable, unrecoverable) 2334 are listed in Section 5.3.4. 2336 2) hop-by-hop? OR right to the end? 2338 3) What is potential value to notify about recoverable errors? 2339 Proposal: not hop by hop, but QoS controller to QoS initiator 2341 59) (OPEN) add req: ability to deal with severe congestion (req 2342 5.3.4 of draft-partain-..-00 2344 issues are: 2345 - occurs in a highly utilised network and if it is not solved very 2346 fast then the network performance will quickly collapse 2347 - deos it belong to failure recovery (I would assume from a service 2348 point of view this is failure 2349 - hop by hop problem (issue from Jorge) 2350 - What difference does it make (from the QoS perspective) if the 2351 provided QoS degraded due to hardware failure on a device or due to 2352 congestion caused by failures on some other devices? What is 2353 required from the protocol is to signal this failure to other 2354 participants (QCs or QI) in the hope that they can do something 2355 meaningful (e.g. re-routing) to correct the problem or tear down the 2356 flow. 2358 65) (OPEN) Request to add req: Unexpected situations and error 2359 restistance 2360 An NSIS protocol must define behaviour of NSIS signaling units 2361 during unexpected situations. Unexpected situtions are unknown 2362 messages, parameters and parameter settings as well as receiption of 2363 unexpected messages (e.g. a "Reservation Confirmation" without prior 2364 "Reservation Request"). 2366 Related to Open issues (53) and requirement 5.3.4. 2367 This requirement is emphasizing to many details that might not be 2368 necessary 2370 Req 5.3.4 refers to behaviour in the case of problems in the data 2371 plane. My suggestion here is about unexpected events/errors in the 2372 control plane. If you think that this point carries to many details, 2373 let's split it up in several individual requirements. 2375 72) (OPEN) request to add "Error notification and error location" 2377 "An NSIS signaling node rejecting or releasing a reservation must 2378 indicate its identity. NSIS signalling should indicate why a 2379 requested resource is not or no longer available. " 2381 Compared to 5.3.4 this is about problems on the control plane 2383 Closed Issues 2385 1) (CLOSED) add Scenarios 2386 Do we need to add, remove, or change the scenarios? 2387 - added scenario on QoS signalling between PSTN gateways and 2388 backbone routers 2389 - added: Application request end-to-end QoS path from the network 2390 - added VPN scenario 2391 We can add what ever scenario we want. The more the better to 2392 understand the issues. Nevertheless, we have to take care that we 2393 are future prove as well. 2395 3) (CLOSED) Draft organization 2397 The proposed changes include 2398 - put all the scenarios into an appendix 2399 - In Section 6 add text describing 3 different "parts of the 2400 network" 2401 -Host to first hop 2402 -access network 2403 -core networks 2404 better names are welcome, but I don't want to be religious about 2405 it 2407 - Prioritize the requirements according to the "parts of the 2408 network" (This means the the tables in Section 6 of the current 2409 draft will get three colums with the MUST, SHOULDs, and MAYs for 2410 each requirement 2412 5) (CLOSED) Framework text. 2413 The figures have been removed, because they seamed to be misleading. 2414 the text has been revisited. I regard the issue closed until we have 2415 a clear picture about what the NSIS framework draft is about. 2417 6) (CLOSED) The requirement organization 2418 I heard some voices on the list that the grouping should be more 2419 along the lines of host-to-edge, edge to edge etc. 2420 So far I have not changed it, because I though that the requirements 2421 heavily depend on the scenario we are looking at. 2423 closed, by the change in the draft organisation (issue 3) 2425 7) (CLOSED) Hemant Chaskar: Section 3.1, items 1) Handoff decision 2426 and 2) Trigger sources: The handoff decision and trigger sources 2427 should be out of scope of NSIS. NSIS should rather focus only on 2428 "establishing" QoS along the packet path after handoff. 2430 added exclusion 2432 8) (CLOSED) bi-directional data path setup with one QoS request 2433 I have not seen consensus on whether to require bi-directional data 2434 path setup with QoS. 2436 Q: How can we actually perform bi-directional reservations when the 2437 forward and reverse paths are not reciprocal, with respect to 2438 routing topology and routing policy of network domains between 2439 sender and receiver? 2441 A: bi-directional data path setup does not need to use the same 2442 return path as the forwarding path. The only requirement to achieve 2443 a bi-directional reservation is that the sender for the forwarding 2444 path is also the receiver for the return path and that the receiver 2445 for the forwarding path is also the sender for the return path. 2447 - The need to ensure that the return path is the same as the 2448 forwarding path is one of the problems with RSVP, particularly in a 2449 mobile environment. 2451 added some explanations that we do not require the same path, and 2452 that the goal is an optimization of the setup delay 2454 9) (CLOSED) Potential requirement: must be implementable in user 2455 space (on end hosts) 2457 has not been included in the req list because it seams to be 2458 implementation specific. 2460 10) (CLOSED) Potential requirement: must provide support for 2461 globally defined services as well as private services (Ruediger) 2463 replaced by issue 17 and 18, closed 2465 11) (CLOSED) Potential requirement: Flexibility in the granularity 2466 of reservation (I don't remember who brought it up, but I assume it 2467 refers to the flexibility in terms of what size the flow has. Where 2468 size can be bandwidth etc.) 2469 The assumption that QoS classes as well as service definitions are 2470 out of scope for this draft, also the flexibility is. 2472 12) (CLOSED) text replacing scalability reqs 2474 "The nsis architecture should give the ability to constrain the load 2475 (CPU load, memory space, signaling bandwidth consumption and 2476 signaling intensity) on devices where it is needed. This can be 2477 achieved by many different methods, for example message aggregation, 2478 by ignoring signaling message, header compression or minimizing 2479 functionality. The architecture may choose any of these methods as 2480 long as the requirement is met." 2482 Editor: added the draft text, but did not remove scalability reqs 2484 13) (CLOSED) add operator req "Ability to assign transport quality 2485 to signaling messages" 2486 "The nsis architecture should allow the network operator to assign 2487 the nsis protocol messages a certain transport quality. As signaling 2488 opens up for possible denial-of-service attacks, this requirement 2489 gives the network operator a mean, but also the obligation, to 2490 trade-off between signaling latency and the impact (from the 2491 signaling messages) on devices within his/her network. From protocol 2492 design this requirement states that the protocol messages should be 2493 detectable, at least where the control and assignment of the 2494 messages priority is done." 2496 text has been added 2498 14) (CLOSED) proposal to add "support grouping of microflows 2499 (possibly only for feedback)" 2500 "As a consequence of the optimization for the interactive multimedia 2501 services, the signaling should allow one unique request for several 2502 micro flows having the same origination and destination IP 2503 addresses. This is usually the case for multimedia SIP calls where 2504 the voice and video micro flows follow the same path. This grouping 2505 of requests allows optimization of the QoS processing. Note that 2506 this may be detrimental for the call setup time. The use of grouping 2507 for microflows may be restricted to teardown and/or notification 2508 messages when call setup time is a concern." 2510 Should not be restrict to teardown and/or notification, it might be 2511 useful also for the procedure that refreshes reservation states 2513 added that requirement. 2515 15) (CLOSED) Support for preemption of sessions 2516 -might play into the fault/ error handling case 2517 -is regarded as service-specific, whether existing sessions can be 2518 pre-empted 2519 Conclusion: it is network policy to determine how to do pre-emption, 2520 not a protocol issue. 2522 16) (CLOSED) Req: 5.1.9 change provisioning into better term, since 2523 different people understand different thing with provisioning 2525 we did not find a better word 2527 17) (CLOSED) add assumption that QoS classes/service definitions are 2528 already known to all the parties involved in signaling before hand 2529 (before a signalling session even starts 2531 added text in Section 4.1 2533 18) (CLOSED) add exclusion of methods, protocols, and ways to 2534 express QoS 2535 Even so, this might be covered by saying that we are independent of 2536 QoS classes and service description etc. (see issue 17), I added two 2537 points to the exclusion Section 4.2. 2539 Implications: issue 20, 23, 2541 19) (CLOSED) remove req 5.2.5 IP fragmentation 2543 20) (CLOSED) remove req 5.3.2 Ability to signal life-time of a 2544 reservation 2546 is regarded service-specific therefore part of the service 2547 description 2549 added some reservation life time text service description assumption 2550 text and removed the req 2552 21) (CLOSED) remove req 5.5.4 Aggregation method specification 2554 Concerns 2555 -QI not able to know the impact of aggregation 2556 -to far down the implementation/ service definition road 2557 -leave it to the provider how a service is realized 2559 removed 2561 22) (CLOSED) remove 5.3.7 Automatic notification on available 2562 resources not been granted before 2564 regarded to complex and is heavily dependend on the service 2565 description 2567 removed 2569 23) (CLOSED) remove 5.5.3 Simple mapping to lower-layer QoS 2570 provisioning parameters 2572 this heavily depends on service definition and therefore is out of 2573 scope of this document 2575 removed 2576 24) (CLOSED) Replacing req 5.3.6 "Feedback about the actually 2577 received level of QoS guarantees" with two requirements: 1) the 2578 feedback of a request MUST include yes and no (MUST respond yes or 2579 no) 2) in case of no it MAY include an opaque service-specific 2580 information about what would be possible 2582 It is still only one requirement, but the text has been replaced. 2584 25) (CLOSED) remove req 5.10.3 Combination with Mobility management 2586 However the integration should not be a priori excluded, there is 2587 explicitly no statemant about independence of mobility management. 2589 There is more discussion for the mobility case needed anyway. 2591 26) (CLOSED) interaction of NSIS with seamoby (context transfer and 2592 CAR discovery) 2594 added requirement, that NSIS should interwork with seamoby protocols 2596 27) (CLOSED) remove req 5.5.10 QoS conformance specification 2597 Motivation: this heavily depends on the service definition and is 2598 therefore out of scope 2600 removed 2602 29) (CLOSED) NSIS in case of handovers 2603 issue 26, mentions that NSIS should interwork with handoffs 2605 30) (CLOSED) remove 5.1.7 Avoid modularity with large overhead (in 2606 various dimensions) 2608 removed because it seams to be obvious 2610 31) (CLOSED) remove 5.1.8 Possibility to use the signaling protocol 2611 for existing local technologies 2613 It is contradictory to 5.1.9 and the intention behind the 2614 requirement is covered by the requierement that the QoS controller 2615 can be placed wherever needed. 2617 32) (CLOSED) add assumption: there are means for discovery of nsis 2618 entities in order to know the signaling peers (solutions include 2619 static configuration, or automatically discovered etc.) 2621 33) (CLOSED) add req " highest possible network utilization" 2622 "There are networking environments that require high network 2623 utilization for various reasons, and the signaling protocol should 2624 to its best ability support high resource utilization while 2625 maintaining appropriate QoS. 2627 In networks where resources are very expensive (as is the case for 2628 many wireless networks), efficient network utilization is of 2629 critical financial importance. On the other hand there are other 2630 parts of the network where high utilization is not required. 2631 " 2633 req added 2635 34) (CLOSED)_difference between "UMTS access scenario" "cellular 2636 network scenario", and "Wired part of wireless network" (Section 2637 8.2, 8.3, and 8.4) 2639 all three are included. 2640 The only common point between the three scenarios is that they are 2641 related to cellular networks. Section 8.4 is introducing the 2642 scenario used in the radio access network of cellular networks. 2643 Sections 8.2 and Section 8.3 are discussing other parts of the 2644 cellular network. 2646 35) (CLOSED) difference between the two PSTN gateway scenarios 2647 (Section 8.8 and 8.9) 2649 currently both are included, they might be merged, sionce one seams 2650 to be more general than the other 2652 36) (CLOSED) req "Independence of reservation identifier" 2653 issue here is that this might only be valuable in mobile 2654 environments, and complicate the protocol for other environments. 2656 there are related issues (37,38, 2658 37) (CLOSED) ownership of a reservation 2660 The issue here is that a known party owns reservations done in the 2661 network. (which might include that the party also pays). The 2662 question arose who is allowed to tear-down, receive asynchronous 2663 notifications in case of network initiated tear-down, etc. 2665 This also relates to how certain service granted is 2666 named/identified. 2668 req 5.8.9 added (renamed) 2670 38) (CLOSED) definition of security threats 2671 handled in draft-tschofenig-nsis-threats-00.txt 2673 39) (CLOSED) simplify security requirements section 2674 done 2676 40) (CLOSED) add mobility related requirements 2677 we have some mobility related requirements, but do not need to add 2678 more 2679 41) (CLOSED) remove req 5.5.1 Mutability information on parameters 2680 removed because it is service-specific 2682 42) (CLOSED) add an assumption that QoS monitoring is application- 2683 specific and with it out of scope of the WG (done) 2685 43) (CLOSED) asynchronous notification of QoS Initiator, Controller, 2686 Receiver, there are security issues related. Basically, an ownership 2687 issue. Nevertheless, an asynch notifcation in case of an error, 2688 network failure etc. is specifically in areas, where longer lived 2689 sessions are setup, essential in order to notify upper layers, 2690 applications etc. as well. 2692 45) (CLOSED) 5.3.4 Possibility for automatic re-setup of resources 2693 after recovery 2694 - more thoughts in failure conditions potentially 2695 - better text 2696 - operation under overload 2697 plays into issue 46) 2699 The requirement has been removed: 2701 "Possibility for automatic re-setup of resources after recovery 2703 In case of a failure, the reservation can get setup again 2704 automatically. It enables sort of a persistent reservation, if the 2705 QoS Initiator requests it. In scenarios where the reservations are 2706 on a longer time scale, this could make sense to reduce the 2707 signaling load in case of failure and recovery." 2709 46) (CLOSED) we might need multiple scenarios for failure and 2710 recovery cases to derive requirements. Or a list of failure cases 2711 might be a start as well. 2713 47) (CLOSED) traffic engineering and route pinning 2714 added Assumption: NSIS should work with networks using standard L3 2715 routing. 2717 added requirement: NSIS should not be broken by networks which do 2718 non-traditional L3 routing. 2720 48) (CLOSED) req 5.5.5 remove Multiple levels of detail 2722 "The QSC should allow for multiple levels of detail in description. 2723 (Motivation: someone interpreting the request can tune its own level 2724 of complexity by going down to more or less levels of detail. A 2725 lightweight implementation within the core could consider only the 2726 coarsest level.)" 2728 removed, because it is service-specific 2730 49) (CLOSED) remove req 5.5.9 Signaling must support quantitative, 2731 qualitative, and relative QoS specifications 2732 removed because it is service-specific 2734 50) (CLOSED) req 5.5.6 remove Ranges in specification 2736 The QSC should allow for specification of minimum required QoS 2737 and/or desirable QoS. (Motivation: The QoS Service Classes should 2738 allow for ranges to be indicated, to minimize negotiation latency 2739 and suppress error notifications during handover events.) 2741 removed, is service specific 2743 51) (CLOSED) remove 5.1.6 Avoid duplication of [sub]domain signaling 2744 functions 2746 we might use the requirement text somewhere else: 2748 Heading: Avoid duplication of [sub]domain signaling functions 2750 The specification of the NSIS signaling protocol should be optimized 2751 to avoid duplication of existing [sub]domain QoS signaling and to 2752 minimize the overall complexity. (Motivation: we don't want to 2753 introduce duplicate feedback or negotiation mechanisms, or 2754 complicate the work by including all possible existing QoS signaling 2755 in some form. The function will be placed in the new part if it has 2756 to be end-to-end, universal to all network types 2757 ('simple/lightweight'), or if it has to be protected by upper layer 2758 security mechanisms.) 2760 The point here is that the QoS technology (lower layer stuff) gets 2761 re-used unchanged, and we have new signaling above it. But, in many 2762 cases the local QoS technology will contain equivalent functions to 2763 the NSIS-required ones, just in a technology specific form. Examples 2764 of these functions would be error/QoS violation notifications, 2765 ability to query for resources and so on. So, there is a danger that 2766 our 'lightweight' signaling ends up trying to carry all this 2767 information all over again, and (even worse) that the 2768 initiator/controller functions have to weigh up nearly equivalent 2769 information coming from two directions. However, the basic problem 2770 here is that the boundary between new and re-used stuff is pretty 2771 shaky. The requirement is trying to scope our problem (a) to 2772 eliminate the potential overlap, and (b) to keep the new NSIS stuff 2773 simple. 2775 However, we are aware that it is very difficult to judge what is 2776 duplicated, if we want to run the protocol in various environments. 2778 52) (CLOSED) New requirement: interaction with policy 2779 Is part of the AAA solution or service definition, and we require 2780 that NSIS interworks with AAA 2782 54) (CLOSED) add req 5.1.17. to assumption "Identification 2783 requirement" 2784 assumption say that the discovery of QI, QC, QR is out-of-scope of 2785 the draft 2787 55) (CLOSED) add from draft-partain-nsis-requirements-00.txt req 2788 5.2.2. Allow local QoS information exchange between two border 2789 nodes 2791 "The QoS signalling protocol must be able to exchange local QoS 2792 information between edge nodes. Local QoS information might, for 2793 example, be IP addresses, severe congestion notification, 2794 notification of succesful or erroneous processing of QoS signalling 2795 messages at one border node. 2797 In some domains, the NSIS QoS signalling protocol MAY carry 2798 identification of the ingress and egress edge between the ingress- 2799 egress edges. However, the identification of edges should not be 2800 visible to the end host and only applies within one QoS 2801 administrative domain. 2802 " 2804 Comments: 2805 - service mapping is more service-specific (layering,tunneling) 2806 - the scenario to look at is a complicated service description -> in 2807 part of the network you want to change the message to something more 2808 easy, and at the other end go back to the more complicated part. 2809 -QI being everywhere might be enough 2810 -and we have already a requirement saying that intermediate node 2811 MUST be able to add/remove domain-specific information to/from 2812 signaling messages 2814 56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00 2815 -already added a req to the scalability section (issue ???), which 2816 has been provided by Anders 2818 57) (CLOSED) potentially better title for text from issue 56) e.g. 2819 (��minimal impact on core��) 2821 58) (CLOSED) add req 5.3.2 from draft-partain-...-00 2823 - the fast establishment req is handled by the low setup latency 2824 req, and the scalability in handover req 2826 - added the text to the teminal mobility scenario 2828 - added text " time scale (e.g., handover in mobile environments)," 2829 to req 2831 60) (CLOSED) add req 5.4.3. from draft-partain-...-00 "Allow 2832 efficient QoS re-establishment after handover" 2834 "Handover is an essential function in wireless networks. After 2835 handover, QoS may need to be completely or partially re-established 2836 due to route changes. The re-establishment may be requested by the 2837 mobile node itself or triggered by the access point that the mobile 2838 node is attached to. In the first case, the QoS signalling should 2839 allow efficient QoS re-establishment after handover. Re- 2840 establishment of QoS after handover should be as quick as possible 2841 so that the mobile node does not experience service interruption or 2842 QoS degradation. The re-establishment should be localized, and not 2843 require end-to-end signalling, if possible." 2845 - most likely it is already cover, please check again, whether there 2846 is something missing 2847 - added it again under the mobility requiremments 2849 61) (CLOSED) add req: 6.1.8 from draft-bucheli-...-00 on multicast 2850 "Multicast consideration should not impact the protocol complexity 2851 for unicast flows. Multicast support is not considered as a 2852 priority, because the targeted interactive multimedia services are 2853 mainly unicast. For this reason, if considered in the solution, 2854 multicast should not bring complexity in the unicast scenario." 2856 not added 2857 --------------------------------------------------- 2858 starting from -02 version 2859 --------------------------------------------------- 2861 62) (CLOSED) Request to add VPN scenario 2862 - Related to issue 1) 2863 - Difference of VPN scenario compared to what we already have is 2864 missing 2866 added the scenario 2868 63) (CLOSED) added Sven Van den Bosch, Maarten Buchli, and Danny 2869 Goderis to acknowledgement section. 2871 64) (CLOSED) Request to add req: Backwards compatibility 2872 A later version of an NSIS protocol must be backwards compatible 2873 with earlier versions of an NSIS protocol. 2875 we can take of this if we have NSIS. 2877 66) (CLOSED) Request to add req: Default behaviour 2878 An NSIS protocol must define default behaviours and parameter 2879 settings wherever applicable. 2880 Is assumed to be normal practice. 2882 67) (CLOSED) Request to add req: Extendability 2883 An NSIS protocol must provide means to enhance a protocol with 2884 future procedures, messages, parameters and parameter settings. 2886 This was refering mostly to the service specific part of the 2887 protocol. 2888 could be a part of the modularity requirement 5.1.3 2890 68) (CLOSED) Request to add req: Preventation of stale state 2891 An NSIS signalling protocol must provide means for an NSIS signaling 2892 unit to discover and remove local stale state. This may for example 2893 be done by means like soft state and periodic flooding or by a 2894 polling mechanism and hard state signaling. 2896 Might already be covered in other requirements, could also be that 2897 the solutions known are solutions for different problems. I think 2898 distributed garbage collection could also be a solution. 2900 merged this text into requirement 5.3.2 2902 69) (CLOSED) Request to add req: Reliable Communication 2903 NSIS signaling procedures, connectivity between units involved in 2904 NSIS signaling as well as the basic transport protocol used by NSIS 2905 must provide a maximum of communication reliability. Procedures must 2906 define how an NSIS signaling systems behaves if some kind of request 2907 it sent stays without answer (this could require e.g. be timers, 2908 number of message retransmits and release messages). 2909 An NSIS signaling unit must be able to check its connectivity to an 2910 adjacent NSIS signaling unit at any time (this requirement must 2911 however not result in a DoS attack tool - the frequency of these 2912 checks must be limited, and flow control may be useful). 2913 The basic transport protocol to be used between adjacent NSIS units 2914 must ensure message integrity and reliable transport. 2916 MUST/SHOULD ensure error- and loss free transmission of signaling 2917 information. 2919 Added some of the text to req 5.11.1 2921 70) (CLOSED) Request to add req: Smooth breakdown 2922 A unit participating in NSIS signaling must no cause further damage 2923 to other systems involved in NSIS signaling when it has to go out of 2924 service. 2926 added as requirement 5.11.2 2928 71) (CLOSED) Changed text "5.6.8: Ability to constrain load on 2929 devices" to 2931 The NSIS architecture should give the ability to constrain the load 2932 (CPU load, memory space, signaling bandwidth consumption and 2933 signaling intensity) on devices where it is needed. This can be 2934 achieved by many different methods. Examples, and this are only 2935 examples, include message aggregation, by ignoring signaling 2936 message, header compression, or minimizing functionality. The 2937 framework may choose any method as long as the requirement is met. 2939 -------------------------- 2940 starting from -03 version 2941 -------------------------- 2943 73) (CLOSED) add table of contents 2944 ------------------------------------------------------ 2945 Change Log Version 01 -> 02 2946 - added issues 62-72 2948 - added some discussion text to open issues 2950 - req " highest possible network utilization" added (issue 33, 2951 closed) 2953 - issues closed: 34 (UMTS scenarios), 35 (PSTN gatway scenarios), 2955 - removed req "Avoid duplication of [sub]domain signaling 2956 functions", issue 51 2958 - Section 5.3.4: added explanation of recoverable and unrecoverable 2959 errors (issue 53) 2961 - added the following requirement: (closed issue 55) Allow local QoS 2962 information exchange between nodes of the saeme administrative 2963 domain 2965 The QoS signaling protocol must be able to exchange local QoS 2966 information between QoS controllers located within one single 2967 domain. Local QoS information might, for example, be IP addresses, 2968 severe congestion notification, notification of successful or 2969 erroneous processing of QoS signaling messages. 2970 In some cases, the NSIS QoS signalling protocol may carry 2971 identification of the QoS controllers located at the boundaries of a 2972 domain. However, the identification of edge should not be visible to 2973 the end host (QoS initiator) and only applies within one QoS 2974 administrative domain. 2976 - closed issue 57: add text about "Minimal impact on interior (core) 2977 nodes" to requirement 5.6.8 "Ability to constrain load on devices" 2979 - added requirement "Allow efficient QoS re-establishment after 2980 handover", closed issue 60. 2982 - changed text in 5.3.2 2984 ------------------------------------------------------ 2985 Change Log Version 02 -> 03 ([X] specify the open issue above) 2987 [1] Scenarios add/change/remove (e.g. VPN). 2988 Question: scenarios covering signalling for things other than QoS? 2989 Georgios/Lars will provide justification & if successful Marcus will 2990 add it. (done) 2992 [7] Handoff decision and trigger sources (in or out of scope). 2993 Agreed: NSIS is not going to solve this problem, has to interact 2994 with protocols that do. Add text to exclusions section. (done) 2996 [8] NSIS should allow bidirectional reservations as an optimisation 2997 where the network topology allows it. (done) 2999 [14] Grouping of microflows. Added (as a MAY, probably). Network 3000 does not need to know relationship exists. Add justification of why 3001 this is an optimization. (done) 3003 [16] Closed. (done) 3005 [26] Interaction with seamoby. Add requirement to say that we are 3006 interworking in the area of mobility protocols (e.g. CT and CAR 3007 discovery). (done) 3009 [28] Asynchronous events from the network. REH & Sven to propose 3010 wording including some motivation as examples. Issues to do with 3011 locality and scenarios. (resilience draft from Sven) 3013 [29] NSIS in case of handovers. No change needed concerning 3014 handovers. (closed the issue: done) 3016 [37] Ownership of a reservation. Close issue and handle it within 3017 security section. (done, changed security req text) 3019 [39] Simplify security section. (done) 3021 [40] Mobility requirements - don't add. Closed. (done) 3023 [42] Add assumption that QoS monitoring is application/service 3024 specific and out of scope. (done) 3026 [43] Notification of QI/QC/QR. Closed earlier. (done, put together 3027 with issue 28) 3029 [44] Resource availability query. Query not as 'real' reservation 3030 is part of service definition. May need new requirement about 3031 endpoint controlling locality of signalling. 3033 [45] Automatic re-installation. Removed, leave open option to supply 3034 text for new requirement. (done) 3036 [46] Scenarios for failure and recovery cases. Remove, invite 3037 individual contributions. (done) 3039 [47] Traffic engineering and route pinning issues. Assumption: NSIS 3040 should work with networks using standard L3 routing. NSIS should not 3041 be broken by networks which do non-traditional L3 routing. (done) 3043 [52] Closed. Aspect of AAA (authentication --> authorisation) 3044 solution or service definition. (done) 3045 [53] Sven et al. to write submissions. 3046 [59] Covered under [53]. 3047 [61] Closed. (done) 3048 [64] Closed (no new text except maybe motherhood statements). (done) 3050 [65] Considered [53]. 3051 [66] Closed (not included elsewhere).(done) 3052 [67] Closed (already covered). (done) 3053 [68] Merge with 5.3.2 to reflect wanting to avoid stale state 3054 (somehow). (done) 3055 [69] Closed (already covered in transport service quality 3056 requirement). Protocol design must take into account reliability 3057 concerns. (done) 3058 [70] Add something about graceful failover to general protocol 3059 requirements section. (done) 3060 [72] Closed. Should be possible for NSIS to transport useful error 3061 messages. 3063 - changed security text 3064 - rearranged open issues (open ones on top)