idnits 2.17.1 draft-ietf-nsis-req-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. 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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2002) is 7887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 1261 looks like a reference -- Missing reference section? '2' on line 1265 looks like a reference -- Missing reference section? '3' on line 1269 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Brunner (Editor) 3 Internet Draft NEC 4 Category: Informational August 2002 6 Requirements for 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 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 This document defines requirements for signaling across different 36 network environments, where different network environments across 37 administrative and technology domains. Signaling is mainly though 38 for QoS such as [1], however in recent year several other 39 applications of signaling have been defined such as signaling for 40 MPLS label distribution [2]. To achieve wide applicability of the 41 requirements, the starting point is a diverse set of scenarios/use 42 cases concerning various types of networks and application 43 interactions. We also provide an outline structure for the problem, 44 including related terminology. Taken with the scenarios, this allows 45 us to focus more precisely on which parts of the overall problem 46 need to be solved. We present the assumptions and the aspects not 47 considered within scope before listing the requirements grouped 48 according to areas such as architecture and design goals, signaling 49 flows, layering, performance, flexibility, security, and mobility. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 53 this document are to be interpreted as described in RFC 2119. 55 Table of Contents 57 Status of this Memo................................................1 58 Abstract...........................................................1 59 Table of Contents..................................................2 60 1 Introduction...................................................3 61 2 Terminology....................................................4 62 3 Problem Statement and Scope....................................6 63 4 Assumptions and Exclusions.....................................8 64 4.1 Assumptions and Non-Assumptions..............................8 65 4.2 Exclusions...................................................9 66 5 Requirements..................................................11 67 5.1 Architecture and Design Goals...............................11 68 5.1.1 MUST be applicable for different technologies...............11 69 5.1.2 Resource availability information on request................12 70 5.1.3 NSIS MUST be designed modular...............................12 71 5.1.4 NSIS MUST decouple protocol and information.................12 72 5.1.5 NSIS MUST reuse existing QoS provisioning...................12 73 5.1.6 Independence of signaling and provisioning paradigm.........12 74 5.1.7 Application independence....................................13 75 5.2 Signaling Flows.............................................13 76 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder......13 77 5.2.2 No constraint of the signaling and NSIS Forwarders to be in 78 the data path.....................................................13 79 5.2.3 Concealment of topology and technology information..........14 80 5.2.4 Transparency of signaling to network........................14 81 5.3 Additional information beyond signaling for a service.......14 82 5.3.1 Explicit release of resources...............................14 83 5.3.2 Possibility for automatic release of resources after failure15 84 5.3.3 Notifications sent upstream.................................15 85 5.3.4 Feedback about success of service request...................16 86 5.3.5 Local information exchange..................................16 87 5.4 Control Information.........................................16 88 5.4.1 Mutability information on parameters........................16 89 5.4.2 Possibility to add and remove local domain information......17 90 5.4.3 Independence of reservation identifier......................17 91 5.4.4 Seamless modification of already reserved resources.........17 92 5.4.5 Grouping of signaling for several microflows................17 93 5.5 Performance.................................................17 94 5.5.1 Scalability.................................................18 95 5.5.2 Low latency in setup........................................18 96 5.5.3 Allow for low bandwidth consumption for signaling protocol..18 97 5.5.4 Ability to constrain load on devices........................18 98 5.5.5 Highest possible network utilization........................19 99 5.6 Flexibility.................................................19 100 5.6.1 Flow aggregation............................................19 101 5.6.2 Flexibility in the placement of the NSIS Initiator..........19 102 5.6.3 Flexibility in the initiation of re-negotiation.............19 103 5.6.4 Uni / bi-directional reservation............................19 104 5.7 Security....................................................20 105 5.7.1 Authentication of signaling requests........................20 106 5.7.2 Resource Authorization......................................20 107 5.7.3 Integrity protection........................................20 108 5.7.4 Replay protection...........................................20 109 5.7.5 Hop-by-hop security.........................................20 110 5.7.6 Identity confidentiality and location privacy...............21 111 5.7.7 Denial-of-service attacks...................................21 112 5.7.8 Confidentiality of signaling messages.......................21 113 5.7.9 Ownership of a reservation..................................21 114 5.7.10 Hooks with Authentication and Key Agreement protocols......22 115 5.8 Mobility....................................................22 116 5.8.1 Allow efficient QoS re-establishment after handover.........22 117 5.9 Interworking with other protocols and techniques............23 118 5.9.1 MUST interwork with IP tunneling............................23 119 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6......23 120 5.9.3 MUST be independent from charging model.....................23 121 5.9.4 SHOULD provide hooks for AAA protocols......................23 122 5.9.5 SHOULD interwork with seamless handoff protocols............23 123 5.9.6 MAY interwork with non-traditional routing..................23 124 5.10 Operational................................................23 125 5.10.1 Ability to assign transport quality to signaling messages..23 126 5.10.2 Graceful fail over.........................................24 127 5.10.3 Graceful handling of NSIS entity problems..................24 128 6 Security Considerations.......................................24 129 7 Reference.....................................................24 130 8 Acknowledgments...............................................24 131 9 Author's Addresses............................................25 132 10 Appendix: Scenarios/Use cases.................................25 133 10.1 Terminal Mobility..........................................25 134 10.2 Cellular Networks..........................................27 135 10.3 UMTS access................................................28 136 10.4 Wired part of wireless network.............................30 137 10.5 Session Mobility...........................................31 138 10.6 QoS reservations/negotiation from access to core network...32 139 10.7 QoS reservation/negotiation over administrative boundaries.32 140 10.8 QoS signaling between PSTN gateways and backbone routers...33 141 10.9 PSTN trunking gateway......................................34 142 10.10 Application request end-to-end QoS path from the network...36 144 1 Introduction 146 This document defines requirements for signaling across different 147 network environments. It does not list any problems of existing 148 signaling protocols such as RSVP [1]. 150 In order to derive requirements for signaling it is necessary to 151 first have a clear idea of the scope within which they are 152 applicable. 154 We describe a set of QoS signaling scenarios and use cases in the 155 Appendix of that document. These scenarios derive from a variety of 156 backgrounds, and help obtain a clearer picture of what is in or out 157 of scope of the NSIS work. They illustrate the problem of QoS 158 signaling from various perspectives (end-system, access network, 159 core network) and for various areas (fixed line, mobile, wireless 160 environments). 162 Based on these scenarios, we are able to define the signaling 163 problem on a more abstract level. In Section 3, we thus present a 164 simple conceptual model of the signaling problem. Additionally, we 165 describe the entities involved in signaling and typical signaling 166 paths. In Section 4 we list assumptions and exclusions. 168 The model of Section 3 allows deriving requirements from the 169 scenarios presented in the appendix in a coherent and consistent 170 manner. Requirements are grouped according to areas such as 171 Architecture and design goals, Signaling Flows, Layering, 172 Performance, Flexibility, Security and Mobility. 174 QoS is a pretty large field with a lot of interaction with other 175 protocols, mechanisms, applications etc. However, it is not the 176 only field where signaling is used in the Internet. Even if this 177 requirement documents mainly used QoS as the sample application 178 other application should be possible. 180 It is clear that the subject of QoS is uniquely complex and any 181 investigation could potentially have a very broad scope - so broad 182 that it is a challenge to focus work on an area, which could lead to 183 a concrete and useful result. This is our motivation for considering 184 a set of use cases, which map out the domain of application that we 185 want to address. It is also the motivation for defining a problem 186 structure, which allows us to state the boundaries of what types of 187 functionality to consider, and to list background assumptions. 189 There are several areas of the requirements related to networking 190 aspects which are incomplete, for example, interaction with host and 191 site multi-homing, use of anycast services, and so on. These issues 192 should be considered in any future analysis work. 194 2 Terminology 196 In the area of Quality of Service (QoS) it is quite difficult and an 197 exercise for its own to define terminology. Nevertheless, we tried 198 to list the most often used terms in the draft and tried to explain 199 them. However, don't be to religious about it, they are not meant to 200 prescribe any thing in the draft. 202 NSIS Domain (ND) - Administrative domain where an NSIS protocol 203 signals for a resource or set of resources. 205 NSIS Entity (NE) - the function within a node, which implements an 206 NSIS protocol. 208 NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR, 209 which may interact with local resource management function (RMF) for 210 this purpose. NSIS Forwarder also propagates NSIS signaling further 211 through the network. It is responsible for interpreting the 212 signaling carrying the user parameters, optionally inserting or 213 modifying the parameters according to domain network management 214 policy. 216 NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for 217 a network resource based on user or application requirements. This 218 can be located in the end system, but may reside elsewhere in 219 network. 221 NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and 222 can optionally interact with applications as well. 224 Resource Management Function (RMF) - an abstract concept, 225 representing the management of resources in a domain or a node. 227 Egress point: the router via which a path exits a domain/subdomain. 229 End Host: the end system or host, for whose flows QoS is being 230 requested and provisioned. 232 End-to-End QoS: the QoS delivered by the network between two 233 communicating end hosts. End-to-end QoS co-ordinates and enforces 234 predefined traffic management policies across multiple network 235 entities and administrative domains. 237 Edge-to-edge QoS: QoS within an administrative domain that connects 238 to other networks rather than hosts or end systems. 240 Flow: a traffic stream (sequence of IP packets between two end 241 systems) for which a specific level of QoS is to be provided. The 242 flow can be unicast (uni- or bi-directional) or multicast. 244 Higher Layers: the higher layer (transport protocol and application) 245 functions that request QoS from the network layer. The request might 246 be a trigger generated within the end system, or the trigger might 247 be provided by some entity within the network (e.g. application 248 proxy or policy server). 250 Indication: feedback from QoS provisioning to indicate the current 251 QoS being provided to a flow or aggregate, and whether any 252 violations have been detected by the QoS technology is being used 253 within the local domain/subdomain. 255 Ingress point: the router via which a path enters a 256 domain/subdomain. 258 Path: the route across the networks taken by a flow or aggregate, 259 i.e. which domains/subdomains it passes through and the 260 egress/ingress points for each. 262 Path segment: the segment of a path within a single 263 domain/subdomain. 265 Control Information: the information the governs for instance the 266 QoS treatment to be applied to a flow or aggregate, including the 267 service class, flow administration, and any associated security or 268 accounting information. 270 QoS Provisioning: the act of actually allocating resources to a flow 271 or aggregate of flows, may include mechanisms such as LSP initiation 272 for MPLS, packet scheduler configuration within a router, and so on. 273 The mechanisms depend on the overall QoS technology being used 274 within the domain. 276 Subdomain: a network within an administrative domain using a uniform 277 technology, e.g., a single QoS provisioning function to provision 278 resources. 280 QoS Technology: a generic term for a set of protocols, standards and 281 mechanisms that can be used within a QoS domain/subdomain to manage 282 the QoS provided to flows or aggregates that traverse the domain. 283 Examples might include MPLS, DiffServ, and so on. A QoS technology 284 is associated with certain QoS provisioning techniques. 286 Resource: something of value in a network infrastructure to which 287 rules or policy criteria are first applied before access is granted. 288 Examples of resources include the buffers in a router and bandwidth 289 on an interface. 291 Resource Allocation: part of a resource that has been dedicated for 292 the use of a particular traffic type for a period of time through 293 the application of policies. 295 Sender-initiated signaling protocol: A sender-initiated signaling 296 protocol is a protocol where the NI initiates the signaling on 297 behalf of the sender of the data. What this means is that admission 298 control and resource allocation functions are processed from the 299 data sender towards the data receiver. However, the triggering 300 instance is not specified. 302 Receiver-initiated signaling protocol: A receiver-initiated 303 protocol, (see e.g., RSVP [1]) is a protocol where the NSIS 304 Responder on behalf of the receiver of the user data initiates the 305 reservations. What this means is that admission control and resource 306 allocation functions are processed from the data receiver back 307 towards the data sender. However, the triggering instance is not 308 specified. 310 3 Problem Statement and Scope 312 We provide in the following a preliminary architectural picture as a 313 basis for discussion. We will refer to it in the following 314 requirement section. 316 A set of issues and problems to be solved has been given at a top 317 level by the use cases/scenarios of the appendix. However, the 318 problem of QoS has an extremely wide scope and there is a great deal 319 of work already done to provide different components of the 320 solution, such as QoS technologies for example. A basic goal should 321 be to re-use these wherever possible, and to focus requirements work 322 at an early stage on those areas where a new solution is needed 323 (e.g. an especially simple one). We also try to avoid defining 324 requirements related to internal implementation aspects. 326 In this section, we present a simple conceptual model of the overall 327 problem in order to identify the applicability to NSIS of 328 requirements derived from the use cases, and to clarify the scope of 329 the work, including any open issues. This model also identifies 330 further sources of requirements from external interactions with 331 other parts of an overall solution, clarifies the terminology used, 332 and allows the statement of design goals about the nature of the 333 solution (see section 5). 335 Note that this model is intended not to constrain the technical 336 approach taken subsequently, simply to allow concrete phrasing of 337 requirements (e.g. requirements about placement of the NSIS 338 Initiator, or ability to 'drive' particular QoS technologies.) 340 Roughly, the scope of NSIS is assumed to be the interaction between 341 the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder 342 including a protocol to carry the information, and the 343 syntax/semantics of the information that is exchanged. Further 344 statements on assumptions/exclusions are given in the next Section. 346 The main elements are: 348 1. Something that starts the request for resources, the NSIS 349 Initiator. 351 This might be in the end system or within some other part of the 352 network. The distinguishing feature of the NSIS Initiator is that it 353 acts on triggers coming (directly or indirectly) from the higher 354 layers in the end systems. It needs to map the resources requested 355 by them, and also provides feedback information to the higher 356 layers, which might be used by transport layer rate management or 357 adaptive applications. 359 2. Something that assists in managing resources further along the 360 path, the NSIS Forwarder. 362 The NSIS Forwarder does not interact with higher layers, but 363 interacts with the NSIS Initiator and possibly more NSIS Forwarders 364 on the path, edge-to-edge or possibly end-to-end. 366 3. The NSIS Initiator and NSIS Forwarder(s) interact with each 367 other, path segment by path segment. This interaction involves the 368 exchange of data (resources control information) over some signaling 369 protocol. 371 4. The path segment traverses an underlying network covering one or 372 more IP hops. The underlying network uses some local QoS technology. 373 This QoS technology has to be provisioned appropriately for the 374 service requested. An NSIS Forwarder maps service-specific 375 information to technology-related QoS parameters and receiving 376 indications about success or failure in response. 378 Now concentrating more on the overall end to end (multiple domain) 379 aspects, in particular: 381 1. The NSIS Initiator need not be located at an end system, and the 382 NSIS Forwarders are not assumed to be located on the flow's data 383 path. However, they must be able to identify the ingress and egress 384 points for the flow path as it traverses the domain/subdomain. Any 385 signaling protocol must be able to find the appropriate NSIS 386 Forwarder and carry this ingress/egress point information. 388 2. We see the network at the level of domains/subdomains rather than 389 individual routers (except in the special case that the domain 390 contains one link). Domains are assumed to be administrative 391 entities, so security requirements apply to the signaling between 392 them. 394 3. Any domain may contain Resource Management Function (e.g. to do 395 with traffic engineering, admission control, policy and so on). 396 These are assumed to interact with the NSIS Initiator and 397 Controllers (and end systems) using standard mechanisms. 399 4. The placement of the NSIS Initiators and NSIS Forwarders is not 400 fixed. 402 4 Assumptions and Exclusions 404 4.1 Assumptions and Non-Assumptions 406 1. The NSIS signaling could run end to end, end to edge, or edge to 407 edge, or network-to-network ((between providers), depending on what 408 point in the network acts as the initiator, and how far towards the 409 other end of the network the signaling propagates. Although the 410 figures show NSIS Forwarders at a very limited number of locations 411 in the network (e.g. at domain or subdomain borders, or even 412 controlling a complete domain), this is only one possible case. In 413 general, we could expect NSIS Forwarders to become more 'dense' 414 towards the edges of the network, but this is not a requirement. An 415 over-provisioned domain might contain no NSIS Forwarders at all (and 416 be NSIS transparent); at the other extreme, NSIS Forwarders might be 417 placed at every router. In the latter case, QoS provisioning can be 418 carried out in a local implementation-dependent way without further 419 signaling, whereas in the case of remote NSIS Forwarders, a 420 provisioning protocol might be needed to control the routers along 421 the path. This provisioning protocol is then independent of the end- 422 to-end NSIS signaling. 424 2. We do not consider 'pure' end-to-end signaling that is not 425 interpreted anywhere within the network. Such signaling is an 426 application-layer issue and IETF protocols such as SIP etc. can be 427 used. 429 3. Where the signaling does cover several NSIS domains or 430 subdomains, we do not exclude that different signaling protocols are 431 used in each path segment. We only place requirements on the 432 universality of the control information that is being transported. 433 (The goals here would be to allow the use of signaling protocols, 434 which are matched to the characteristics of the portion of the 435 network being traversed.) Note that the outcome of NSIS work might 436 result in various protocols or various flavors of the same protocol. 437 This implies the need for the translation of information into domain 438 specific format as well. 440 4. We assume that the service definitions a NSIS Initiator can ask 441 for are known in advance of the signaling protocol running. Service 442 definition includes QoS parameters, lifetime of QoS guarantee etc., 443 or any other service-specific parameters. 445 There are many ways service requesters get to know about it. There 446 might be standardized services, the definition can be negotiated 447 together with a contract, the service definition is published at a 448 Web page, etc. 450 5. We assume that there are means for the discovery of NSIS entities 451 in order to know the signaling peers (solutions include static 452 configuration, automatically discovered, or implicitly runs over the 453 right nodes, etc.) The discovery of the NSIS entities has security 454 implications that need to be addressed properly. These implications 455 largely depend on the chosen protocol. For some security mechanisms 456 (i.e. Kerberos, pre-shared secret) it is required to know the 457 identity of the other entity. Hence the discovery mechanism may 458 provide means to learn this identity, which is then later used to 459 retrieve the required keys and parameters. 461 6. NSIS assumes to operate with networks using standard ("normal") 462 L3 routing. Where "normal" is not specified more exactly on purpose. 464 4.2 Exclusions 466 1. Development of specific mechanisms and algorithms for application 467 and transport layer adaptation are not considered, nor are the 468 protocols that would support it. 470 2. Specific mechanisms (APIs and so on) for interaction between 471 transport/applications and the network layer are not considered, 472 except to clarify the requirements on the negotiation capabilities 473 and information semantics that would be needed of the signaling 474 protocol. The same applies to application adaptation mechanisms. 476 3. Specific mechanisms for QoS provisioning within a 477 domain/subdomain are not considered. However, NSIS can be used for 478 signaling within a domain/subdomain performing QoS provisioning. It 479 should be possible to exploit these mechanisms optimally within the 480 end-to-end context. Consideration of how to do this might generate 481 new requirements for NSIS however. For example, the information 482 needed by a NSIS Forwarder to manage a radio subnetwork needs to be 483 provided by the NSIS solution. 485 4. Specific mechanisms (APIs and so on) for interaction between the 486 network layer and underlying QoS provisioning mechanisms are not 487 considered. 489 5. Interaction with resource management capabilities is not 490 considered. Standard protocols should be used for this (e.g. COPS). 491 This may imply requirements for the sort of information that should 492 be exchanged between the NSIS entities. 494 6. Security implications related to multicasting are outside the 495 scope of the signaling protocol. 497 7. Protection of non-signaling messages is outside the scope of the 498 protocol 500 The protection of non-signaling messages (including data traffic 501 following a reservation) is not directly considered by a signaling 502 protocol. The protection of data messages transmitted along the 503 provisioned path is outside the scope of a signaling protocol. 504 Regarding data traffic there is an interaction with accounting 505 (metering) and edge routers might require packets to be integrity 506 protected to be able to securely assign incoming data traffic to a 507 particular user. 509 Additionally there might be an interaction with IPSec protected 510 traffic experiencing QoS treatment and the established state created 511 due to signaling. One example of such an interaction is the different 512 flow identification with and without IPSec protection. 514 Many security properties are likely to be application specific and 515 may be provided by the corresponding application layer protocol. 517 8. Service definitions and in particular QoS classes are out of 518 scope. Together with the service definition any definition of 519 service specific parameters are not considered in this draft. Only 520 the base NSIS signaling protocol for transporting the service 521 information are handled. 523 9. Similarly, specific methods, protocols, and ways to express 524 QoS/service information in the Application/Session level are not 525 considered (e.g., SDP, SIP, RTSP, etc.). 527 10. The specification of any extensions needed to signal information 528 via application level protocols (e.g. SDP), and the mapping on NSIS 529 information are considered outside of the scope of NSIS working 530 group, as this work is in the direct scope of other IETF working 531 groups (e.g. MMUSIC). 533 11. Handoff decision and trigger sources: An NSIS protocol is not 534 used to trigger handoffs in mobile IP, nor is it used to decide 535 whether to handoff or not. As soon as or in some situation even 536 before a handoff happened, an NSIS protocol might be used for 537 signaling for QoS again. However, NSIS MUST interwork with several 538 protocols for mobility management. 540 12. QoS monitoring is out of scope. It is heavily dependent on the 541 type of the application and or transport service, and in what 542 scenario it is used. 544 5 Requirements 546 This section defines more detailed requirements for a signaling 547 solution, derived from consideration of the use cases/scenarios 548 described in the appendix, and respecting the framework, scoping 549 assumptions, and terminology considered earlier. The requirements 550 are in subsections, grouped roughly according to general technical 551 aspects: architecture and design goals, topology issues, parameters, 552 performance, security, information, and flexibility. 554 Two general (and potentially contradictory) goals for the solution 555 are that it should be applicable in a very wide range of scenarios, 556 and at the same time lightweight in implementation complexity and 557 resource requirements in nodes. One approach to this is that the 558 solution could deal with certain requirements via modular components 559 or capabilities, which are optional to implement in individual 560 nodes. 562 Some of the requirements are technically contradictory. Depending on 563 the scenarios a solution applies to, one or the other requirement is 564 applicable. 566 In order to prioritize the various requirements we define different 567 'parts of the network'. In the different parts of the network a 568 particular requirement might have a different priority. 570 The parts of the networks we differentiate are the host-to-first 571 router, the access network, and the core network. The host to first 572 router part includes all the layer 2 technologies to access to the 573 Internet. In many cases, there is an application and/or user running 574 on the host initiating signaling. The access network can be 575 characterized by low capacity links, medium speed IP processing 576 capabilities, and it might consist of a complete layer 2 network as 577 well. The core network characteristics include high-speed forwarding 578 capacities and inter-domain issues. All of them are not strictly 579 defined and should not be regarded as that, but should give a 580 feeling about where in the network we have different requirements 581 concerning signaling. 583 5.1 Architecture and Design Goals 585 This section contains requirements related to desirable overall 586 characteristics of a solution, e.g. enabling flexibility, or 587 independence of parts of the framework. 589 5.1.1 MUST be applicable for different technologies. 591 The signaling protocol MUST work with various QoS technologies as 592 well as other technologies needing signaling. The information 593 exchanged over the signaling protocol must be in such detail and 594 quantity that it is useful for various technologies. 596 5.1.2 Resource availability information on request 598 In some scenarios, e.g., the mobile terminal scenario, it is 599 required to query, whether resources are available, without 600 performing a reservation on the resource. One solution might be a 601 feedback mechanism based on which a QoS inferred handover can take 602 place. So NSIS SHOULD provide a mechanism to check whether resources 603 are available without performing a reservation 605 5.1.3 NSIS MUST be designed modular 607 A modular design allows for more lightweight implementations, if 608 fewer features are needed. Mutually exclusive solutions are 609 supported. Examples for modularity: 611 - Work over any kind of network (narrowband versus broadband, error- 612 prone versus reliable, ...). This implies low bandwidth signaling 613 and redundant information MUST be supported if necessary. 615 - Uni- and bi-directional reservations are possible 617 - Extensible in the future with different add-ons for certain 618 environments or scenarios 620 - Protocol layering, where appropriate. This means NSIS MUST provide 621 a base protocol, which can be adapted to different environments. 623 5.1.4 NSIS MUST decouple protocol and information 625 The signaling protocol MUST be clearly separated from the control 626 information being transported. This provides for the independent 627 development of these two aspects of the solution, and allows for 628 this control information to be carried within other protocols, 629 including application layer ones, existing ones or those being 630 developed in the future. The gained flexibility in the information 631 transported allows for the applicability of the same protocol in 632 various scenarios. 634 However, note that the information carried needs to be the 635 standardized; otherwise interoperability is difficult to achieve. 637 5.1.5 NSIS MUST reuse existing QoS provisioning 639 Reuse existing functions and protocols for QoS provisioning within a 640 domain/subdomain unchanged. (Motivation: 'Don't re-invent the 641 wheel'.) 643 5.1.6 Independence of signaling and provisioning paradigm 645 The signaling MUST be independent of the paradigm and mechanism of 646 provisioning. E.g., in the case of signaling for QoS, the 647 independence of the signaling protocol from the QoS provisioning 648 allows for using the NSIS protocol together with various QoS 649 technologies in various scenarios. 651 5.1.7 Application independence 653 The signaling protocol MUST be independent of the application. The 654 control information SHOULD be application independent, because we 655 look into network level signaling. 657 The requirement relates to the way the signaling interacts with 658 upper layer functions (users, applications, and QoS administration), 659 and lower layer QoS technologies. 661 Opaque application information MAY get transported in the signaling 662 message, without being handled in the network. Development and 663 deployment of new applications SHOULD be possible without impacting 664 the network infrastructure. 666 5.2 Signaling Flows 668 This section contains requirements related to the possible signaling 669 flows that should be supported, e.g. over what parts of the flow 670 path, between what entities (end-systems, routers, middle boxes, 671 management systems), in which direction. 673 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder 675 The protocol MUST work in various scenarios such as host-to-network- 676 to-host, edge-to-edge, (e.g., just within one providers domain), 677 user-to-network (from end system into the network, ending, e.g., at 678 the entry to the network and vice versa), and network-to-network 679 (e.g., between providers). 681 Placing the NSIS Forwarder and NSIS Initiator functions at different 682 locations allows for various scenarios to work with the same 683 protocol. 685 5.2.2 No constraint of the signaling and NSIS Forwarders to be in the 686 data path. 688 There is a set of scenarios, where signaling is not on the data 689 path. The NSIS Forwarder being in the data path is one extreme case 690 and useful in many cases. Therefore the case of having NSIS entities 691 on the data path only MUST be allowed. 693 There are going to be cases where a centralized entity will take a 694 decision about service requests. In this case, there is no need to 695 have the data follow the signaling path. 697 There are going to be cases without a centralized entity managing 698 resources and the signaling will be used as a tool for resource 699 management. For various reasons (such as efficient use of expensive 700 bandwidth), one will want to have fine-grained, fast, and very 701 dynamic control of the resources in the network. 703 There are going to be cases where there will be neither signaling 704 nor a centralized entity (over-provisioning). Nothing has to be done 705 anyway. 707 One can capture the requirement with the following, different 708 wording: If one views the domain with a QoS technology as a virtual 709 router then NSIS signaling used between those virtual routers MUST 710 follow the same path as the data. 712 Routing the signaling protocol along an independent path is desired 713 by network operators/designers. Ideally, the capability to route the 714 protocol along an independent path would give the network 715 designer/operator the option to manage bandwidth utilization through 716 the topology. 718 There are other possibilities as well. An NSIS protocol MUST accept 719 all of these possibilities with a strong focus on the on-path 720 signaling. 722 5.2.3 Concealment of topology and technology information 724 The NSIS protocol SHOULD allow for hiding the internal structure of 725 a NSIS domain from end-nodes and from other networks. Hence an 726 adversary should not be able to learn the internal structure of a 727 network with the help of the signaling protocol. 729 In various scenarios, topology information SHOULD be hidden for 730 various reasons. From a business point of view, some administrations 731 don't want to reveal the topology and technology used. 733 5.2.4 Transparency of signaling to network 735 It SHOULD be possible that the signaling for some flows traverse 736 path segments transparently, i.e., without interpretation at NSIS 737 Forwarders within the network. An example would be a subdomain 738 within a core network, which only interpreted signaling for 739 aggregates established at the domain edge, with the flow-related 740 signaling passing transparently through it. 742 In other words, NSIS SHOULD work in hierarchical scenarios, where 743 big pipes/trunks are setup using NSIS signaling, but also flows 744 which run within that big pipe/trunk are setup using NSIS. 746 5.3 Additional information beyond signaling for a service 748 5.3.1 Explicit release of resources 750 When a resource reservation is no longer necessary, e.g. because the 751 application terminates, or because a mobile host experienced a hand- 752 off, it MUST be possible to explicitly release resources. In general 753 explicit release enhances the overall network utilization. 755 5.3.2 Possibility for automatic release of resources after failure 757 When the NSIS Initiator goes down, the resources it requested in the 758 network SHOULD be released, since they will no longer be necessary. 760 After detection of a failure in the network, any NSIS 761 Forwarder/Initiator MUST be able to release a reservation it is 762 involved in. For example, this may require signaling of the "Release 763 after Failure" message upstream as well as downstream, or soft state 764 timing out of reservations. 766 The goal is to prevent stale state within the network and adds 767 robustness to the operation of NSIS. So in other words, an NSIS 768 signaling protocol or mechanisms MUST provide means for an NSIS 769 entity to discover and remove local stale state. 771 Note that this might need to work together with a notification 772 mechanism. 774 5.3.3 Notifications sent upstream 776 NSIS Forwarders SHOULD be able to notify the NSIS Initiator or any 777 other NSIS Forwarder upstream, if there is a state change inside the 778 network. There are various types of network changes for instance 779 among them: 781 Recoverable errors: the network nodes can locally repair this type 782 error. The network nodes do not have to notify the users of the 783 error immediately. This is a condition when the danger of 784 degradation (or actual short term degradation) of the provided QoS 785 was overcome by the network (NSIS Forwarder) itself. 787 Unrecoverable errors: the network nodes cannot handle this type of 788 error, and have to notify the users as soon as possible. 790 QoS degradation/severe congestion: In case the service cannot be 791 provided completely but partially only. 793 Repair indication: If an error occurred and it has been fixed, this 794 triggers the sending of a notification. 796 Service upgrade available: If a previously requested better service 797 becomes available. 799 The content of the notification is very service specific, but it is 800 must at least carry type information. Additionally, it may carry the 801 location of the state change. 803 The notifications may or may not be in response to a NSIS message. 804 This means an NSIS entity has to be able to handle notifications at 805 any time. 807 Note however, that there are a number of security consideration 808 needs to be solved with notification, even more important if the 809 notification is sent without prior request (asynchronously). The 810 problem basically is, that everybody could send notifications to any 811 NSIS entity and the NSIS entity most likely reacts on the 812 notification. E.g., if it gets an error notification it might 813 teardown the reservation, even if everything is ok. So the 814 notification might depend on security associations between the 815 sender of the notification and its receiver. If a hop-by-hop 816 security mechanism is chosen, this implies also that notifications 817 need to be sent on the reverse path. 819 5.3.4 Feedback about success of service request 821 A request for service MUST be answered at least with yes or no. 822 However, it MAY be useful in case of a negative answer to also get a 823 description of what amount of resources a request is possible. So an 824 opaque element MAY be included into the answer. The element heavily 825 depends on the service requested. 827 5.3.5 Local information exchange 829 The signaling protocol MUST be able to exchange local information 830 between NSIS Forwarders located within one single administrative 831 domain. Local information might, for example, be IP addresses, 832 severe congestion notification, notification of successful or 833 erroneous processing of signaling messages. 835 In some cases, the NSIS signaling protocol MAY carry identification 836 of the NSIS Forwarders located at the boundaries of a domain. 837 However, the identification of edge should not be visible to the end 838 host (NSIS Initiator) and only applies within one administrative 839 domain. 841 5.4 Control Information 843 This section contains requirements related to the control 844 information that needs to be exchanged. 846 5.4.1 Mutability information on parameters 848 It SHOULD be possible for the NSIS initiator to control the 849 mutability of the signaled information. This prevents from being 850 changed in a non-recoverable way. The NSIS initiator SHOULD be able 851 to control what is requested end to end, without the request being 852 gradually mutated as it passes through a sequence of domains. This 853 implies that in case of changes made on the parameters, the original 854 requested ones must still be available. 856 Note that we do not require anything about particular parameters 857 being changed. 859 Additionally, note that a provider or that particular services 860 requested, can still influence the QoS provisioning but in the 861 signaling message the request should stay the same. 863 5.4.2 Possibility to add and remove local domain information 865 It SHOULD be possible for the Resource Management Function to add 866 and remove local scope elements. E.g., at the entrance to a domain 867 domain-specific information is added, which is used in this domain 868 only, and the information is removed again when a signaling message 869 leaves the domain. The motivation is in the economy of re-use the 870 protocol for domain internal signaling of various information 871 pieces. Where additional information is needed within a particular 872 domain, it should be possible to carry this at the same time as the 873 end-to-end information. 875 5.4.3 Independence of reservation identifier 877 A reservation identifier, which is independent of the flow 878 identifier (flow end-points), MUST be used. Various scenarios in the 879 mobility area require this independence because flows resulting from 880 handoff might have changed end-points etc. but still have the same 881 service requirement. Also several proxy-based signaling methods 882 might profit from such as independence. 884 5.4.4 Seamless modification of already reserved resources 886 In many case, the reservation needs to be updated (up or downgrade). 887 This SHOULD happen seamlessly without service interruption. At least 888 the signaling protocol should allow for it, even if some data path 889 elements might not be capable of doing so. 891 5.4.5 Grouping of signaling for several micro-flows 893 NSIS MAY group signaling information for several micro-flow into one 894 signaling message. The goal of this is the optimization in terms of 895 setup delay, which can happen in parallel. This helps applications 896 requesting several flows at once. Also potential refreshes (in case 897 of a soft state solution) might profit of grouping. 899 However, the network MUST NOT know that a relationship between the 900 grouped flows exists. There MUST NOT be any transactional semantic 901 associated with the grouping. It is only meant for optimization 902 purposes and each reservation MUST be handled separately from each 903 other. 905 5.5 Performance 907 This section discusses performance requirements and evaluation 908 criteria and the way in which these could and should be traded off 909 against each other in various parts of the solution. 911 Scalability is a must anyway. However, depending on the scenario the 912 question to which extends the protocol must be scalable. 914 Note that many of the performance issues are heavily dependent on 915 the scenario assumed and are normally a trade-off between speed, 916 reliability, complexity, and scalability. The trade-off varies in 917 different parts of the network. For example, in radio access 918 networks low bandwidth consumption will overweight the low latency 919 requirement, while in core networks it may be reverse. 921 5.5.1 Scalability 923 NSIS MUST be scalable in the number of messages received by a 924 signaling communication partner (NSIS Initiator, NSIS Forwarder, and 925 NSIS Responder). The major concern lies in the core of the network, 926 where large numbers of messages arrive. 928 It MUST be scalable in number of hand-offs in mobile environments. 929 This mainly applies in access networks, because the core is 930 transparent to mobility in most cases. 932 It MUST be scalable in the number of interactions for setting up a 933 reservation. This applies for end-systems setting up several 934 reservations. Some servers might be expected to setup a large number 935 of reservations. 937 Scalability in the number of state per entity MUST be achieved for 938 NSIS Forwarders in the core of the network. 940 And Scalability in CPU use MUST be achieved on end terminals in case 941 of many reservations at the same time and intermediate nodes mainly 942 in the core. 944 5.5.2 Low latency in setup 946 NSIS SHOULD allow for low latency setup of reservations. This is 947 only needed in scenarios, where reservations are in a short time 948 scale (e.g. handover in mobile environments), or where human 949 interaction is immediately concerned (e.g., voice communication 950 setup delay). 952 5.5.3 Allow for low bandwidth consumption for signaling protocol 954 NSIS MUST allow for low bandwidth consumption in certain access 955 networks. Again only small sets of scenarios call for low bandwidth, 956 mainly those where wireless links are involved. 958 5.5.4 Ability to constrain load on devices 960 The NSIS architecture SHOULD give the ability to constrain the load 961 (CPU load, memory space, signaling bandwidth consumption and 962 signaling intensity) on devices where it is needed. One of the 963 reasons is that the protocol handling should have a minimal impact 964 on interior (core) nodes. 966 This can be achieved by many different methods. Examples, and this 967 are only examples, include message aggregation, by ignoring 968 signaling message, header compression, or minimizing functionality. 969 The framework may choose any method as long as the requirement is 970 met. 972 5.5.5 Highest possible network utilization 974 There are networking environments that require high network 975 utilization for various reasons, and the signaling protocol SHOULD 976 to its best ability support high resource utilization while 977 maintaining appropriate QoS. 979 In networks where resources are very expensive (as is the case for 980 many wireless networks), efficient network utilization is of 981 critical financial importance. On the other hand there are other 982 parts of the network where high utilization is not required. 984 5.6 Flexibility 986 This section lists the various ways the protocol can flexibly be 987 employed. 989 5.6.1 Flow aggregation 991 NSIS MUST allow for flow aggregation, including the capability to 992 select and change the level of aggregation. 994 5.6.2 Flexibility in the placement of the NSIS Initiator 996 NSIS MUST be flexible in placing an NSIS Initiator. The NSIS 997 Initiator might be the sender or the receiver of content. But also 998 network-initiated reservations MUST be available in various 999 scenarios such as PSTN gateways, some VPNs, and mobility. 1001 5.6.3 Flexibility in the initiation of re-negotiation 1003 The sender or the receiver of content SHOULD be able to initiate a 1004 re-negotiation or change the reservation due to various reasons, 1005 such as local resource shortage (CPU, memory on end-system) or a 1006 user changed application preference/profiles. But also network- 1007 initiated re-negotiation SHOULD be supported in cases, where the 1008 network is not able to further guarantee resources etc. 1010 5.6.4 Uni / bi-directional reservation 1012 Both unidirectional as well as bi-direction reservations SHOULD be 1013 possible. With bi-directional reservations we mean here reservations 1014 having the same end-points. But the path in the two directions does 1015 not need to be the same. 1017 The goal of a bi-directional reservation is mainly an optimization 1018 in terms of setup delay. There is no requirements on constrains such 1019 as use the same data path etc. 1021 5.7 Security 1023 This section discusses security-related requirements. For a 1024 discussion of security threats see [3]. The NSIS protocol MUST 1025 provide means for security, but it MUST be allowed that nodes 1026 implementing NSIS signaling do not need use the security means. 1028 5.7.1 Authentication of signaling requests 1030 A signaling protocol MUST make provision for enabling various 1031 entities to be authenticated against each other using strong 1032 authentication mechanisms. The term strong authentication points to 1033 the fact that weak plain-text password mechanisms must not be used 1034 for authentication. 1036 5.7.2 Resource Authorization 1038 The signaling protocol MUST provide means to authorize resource 1039 requests. This requirement demands a hook to interact with a policy 1040 entity to request authorization data. This allows an authenticated 1041 entity to be associated with authorization data and to verify the 1042 resource request. Authorization prevents reservations by unauthorized 1043 entities, reservations violating policies, and theft of service. 1044 Additionally it limits denial of service attacks against parts of the 1045 network or the entire network caused by unrestricted reservations. 1046 Additionally it might be helpful to provide some means to inform 1047 other protocols of participating nodes within the same administrative 1048 domain about a previous successful authorization event. 1050 5.7.3 Integrity protection 1052 The signaling protocol MUST provide means to protect the message 1053 payloads against modifications. Integrity protection prevents an 1054 adversary from modifying parts of the signaling message and from 1055 mounting denial of service or theft of service type of attacks 1056 against network elements participating in the protocol execution. 1058 5.7.4 Replay protection 1060 To prevent replay of previous signaling messages the signaling 1061 protocol MUST provide means to detect old i.e. already transmitted 1062 signaling messages. A solution must cover issues of synchronization 1063 problems in the case of a restart or a crash of a participating 1064 network element. The use of replay mechanism apart from sequence 1065 numbers should be investigated. 1067 5.7.5 Hop-by-hop security 1069 Hop-by-Hop security SHOULD be supported. It is a well known and 1070 proven concept in Quality-of-Service and other signaling protocols 1071 that allows intermediate nodes that actively participate in the 1072 protocol to modify the messages as it is required by processing rule. 1073 Note that this requirement does not exclude end-to-end or network-to- 1074 network security of a signaling message. End-to-end security between 1075 the initiator and the responder may be used to provide protection of 1076 non-mutable data fields. Network-to-network security refers to the 1077 protection of messages over various hops but not in an end-to-end 1078 manner i.e. protected over a particular network. 1080 5.7.6 Identity confidentiality and location privacy 1082 Identity confidentiality SHOULD be supported. It enables privacy and 1083 avoids profiling of entities by adversary eavesdropping the signaling 1084 traffic along the path. The identity used in the process of 1085 authentication may also be hidden to a limited extent from a network 1086 to which the initiator is attached. However the identity MUST provide 1087 enough information for the nodes in the access network to collect 1088 accounting data. 1089 Location privacy MAY be supported. It is an issue for the initiator 1090 who triggers the signaling protocol. In some scenarios the initiator 1091 may not be willing to reveal location information to the responder as 1092 part the signaling procedure. 1094 5.7.7 Denial-of-service attacks 1096 A signaling protocol SHOULD provide prevention of DoS attacks. 1097 To effectively prevent denial-of-service attacks it is necessary that 1098 the used security and protocol mechanisms MUST have low computation 1099 complexity to verify a resource request prior authenticating the 1100 requesting entity. Additionally the signaling protocol and the used 1101 security mechanisms SHOULD NOT require large resource consumption 1102 (for example main memory or other additional message exchanges) 1103 before a successful authentication was done. 1105 5.7.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.7.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.7.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 implementation SHOULD provide hooks to 1135 interact with protocols that allow the negotiation of authentication 1136 and key agreement protocols. Although the negotiation of an 1137 authentication and key management protocol within the signaling 1138 protocol may be outside the scope it is still required to trigger 1139 this exchange in case that no such security association is available. 1140 This requirement originates from the fact that more than one key 1141 management protocol may be used to provide a security association for 1142 the signaling protocol. Hence the communicating entities must be 1143 capable to agree on a specific authentication. The selected 1144 authentication and key agreement protocol must however be able to 1145 create a security association that can be used within the signaling 1146 protocol. 1148 Key management protocols typically require a larger number of 1149 messages to be transmitted to allow a session key and the 1150 corresponding security association to be derived. To avoid the 1151 complex issue of embedding individual authentication and key 1152 agreement protocols into a specific signaling protocol it is required 1153 that most of these protocols are executed independently (prior to the 1154 signaling protocol) and although the key management protocol may be 1155 independent there must be a way for the signaling protocol to access 1156 and use available (i.e. already established) security associations to 1157 avoid executing a separate key management protocol (or instance of 1158 the same protocol) for protocols that closely operate together. If no 1159 such security association exists then there SHOULD be means for the 1160 signaling protocol to dynamically trigger such a protocol. 1162 5.8 Mobility 1164 5.8.1 Allow efficient QoS re-establishment after handover 1166 Handover is an essential function in wireless networks. After 1167 handover, the reservation may need to be completely or partially re- 1168 established due to route changes. The re-establishment may be 1169 requested by the mobile node itself or triggered by the access point 1170 that the mobile node is attached to. In the first case, the 1171 signaling MUST allow efficient re-establishment after handover. Re- 1172 establishment after handover MUST be as quick as possible so that 1173 the mobile node does not experience service interruption or service 1174 degradation. The re-establishment SHOULD be localized, and not 1175 require end-to-end signaling. 1177 5.9 Interworking with other protocols and techniques 1179 Hooks SHOULD be provided to enable efficient interworking between 1180 various protocols and techniques including: 1182 5.9.1 MUST interwork with IP tunneling 1184 IP tunneling for various applications MUST be supported. More 1185 specifically tunneling for IPSec tunnels are of importance as 1186 discussed in Section 4.2. This mainly impacts the identification of 1187 flows. Using IPSec parts of information used for flow identification 1188 (e.g. transport protocol information and ports) may not be accessible 1189 due to encryption. 1191 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 1193 5.9.3 MUST be independent from charging model 1195 Signaling MUST NOT be constrained by charging models or the charging 1196 infrastructure used. 1198 5.9.4 SHOULD provide 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.9.5 SHOULD interwork 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 works fast enough 1208 in case of a handoff, where that protocols might help in one way or 1209 the other. 1211 5.9.6 MAY interwork with non-traditional routing 1213 NSIS assumes traditional routing, but networks, which do non- 1214 traditional L3 routing, should not break it. 1216 5.10 Operational 1218 5.10.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. Communication reliability is seen as part of the quality 1232 assigned to signaling messages. So procedures MUST be defined how an 1233 NSIS signaling system behaves if some kind of request it sent stays 1234 without answer. The basic transport protocol to be used between 1235 adjacent NSIS units MAY ensure message integrity and reliable 1236 transport. 1238 5.10.2 Graceful fail over 1240 Any unit participating in NSIS signaling MUST NOT cause further 1241 damage to other systems involved in NSIS signaling when it has to go 1242 out of service. 1244 5.10.3 Graceful handling of NSIS entity problems 1246 NSIS peers SHOULD be able to detect the malfunctioning peer. It may 1247 notify the NSIS Initiator or another NSIS entity involved in the 1248 signaling process. The NSIS peer may handle the problem itself e.g. 1249 switching to a backup NSIS entity. In the latter case note that 1250 synchronization of state between the primary and the backup entity 1251 is needed. 1253 6 Security Considerations 1255 Section 5.8 of this draft provides security related requirements of 1256 a signaling protocol. Another document describes security threads 1257 for NSIS [3]. 1259 7 Reference 1261 [1] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1262 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1263 Specification", RFC 2205, September 1997. 1265 [2] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, 1266 "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 1267 2001. 1269 [3] Tschofenig, H., "NSIS Threats", , May 2002. 1272 8 Acknowledgments 1274 Quite a number of people have been involved in the discussion of the 1275 draft, adding some ideas, requirements, etc. We list them without a 1276 guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul 1277 (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas 1278 Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), 1279 Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 1280 University Berlin), Xiaoming Fu (Technical University Berlin), Hans- 1281 Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph 1282 Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya 1283 Freytsis. 1285 Some text and/or ideas for text, requirements, scenarios have been 1286 taken from a draft written by the following authors: David Partain 1287 (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), 1288 Georgios Karagiannis (Ericsson), Jukka Manner (University of 1289 Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 1290 Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have 1291 actively contributed new text to the draft as well. 1293 Another draft impacting this draft has been written by Sven Van den 1294 Bosch, Maarten Buchli, and Danny Goderis. These people contributed 1295 also with new text. 1297 9 Author's Addresses 1299 Marcus Brunner (Editor) 1300 NEC Europe Ltd. 1301 Network Laboratories 1302 Adenauerplatz 6 1303 D-69115 Heidelberg 1304 Germany 1305 E-Mail: brunner@ccrle.nec.de (contact) 1307 Robert Hancock, Eleanor Hepworth 1308 Roke Manor Research Ltd 1309 Romsey, Hants, SO51 0ZN 1310 United Kingdom 1311 E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk 1313 Cornelia Kappler 1314 Siemens AG 1315 Berlin 13623 1316 Germany 1317 E-Mail: cornelia.kappler@icn.siemens.de 1319 Hannes Tschofenig 1320 Siemens AG 1321 Otto-Hahn-Ring 6 1322 81739 Munchen 1323 Germany 1324 Email: Hannes.Tschofenig@mchp.siemens.de 1326 10 Appendix: Scenarios/Use cases 1328 In the following we describe scenarios, which are important to 1329 cover, and which allow us to discuss various requirements. Some 1330 regard this as use cases to be covered defining the use of a QoS 1331 signaling protocol. 1333 10.1 Terminal Mobility 1335 The scenario we are looking at is the case where a mobile terminal 1336 (MT) changes from one access point to another access point. The 1337 access points are located in separate QoS domains. We assume Mobile 1338 IP to handle mobility on the network layer in this scenario and 1339 consider the various extensions (i.e., IETF proposals) to Mobile IP, 1340 in order to provide 'fast handover' for roaming Mobile Terminals. 1341 The goal to be achieved lies in providing, keeping, and adapting the 1342 requested QoS for the ongoing IP sessions in case of handover. 1343 Furthermore, the negotiation of QoS parameters with the new domain 1344 via the old connection might be needed, in order to support the 1345 different 'fast handover' proposals within the IETF. 1347 The entities involved in this scenario include a mobile terminal, 1348 access points, an access network manager, communication partners of 1349 the MT (the other end(s) of the communication association). 1350 From a technical point of view, terminal mobility means changing the 1351 access point of a mobile terminal (MT). However, technologies might 1352 change in various directions (access technology, QoS technology, 1353 administrative domain). If the access points are within one specific 1354 QoS technology (independent of access technology) we call this 1355 intra-QoS technology handoff. In the case of an inter-QoS technology 1356 handoff, one changes from e.g. a DiffServ to an IntServ domain, 1357 however still using the same access technology. Finally, if the 1358 access points are using different access technologies we call it 1359 inter-technology hand-off. 1361 The following issues are of special importance in this scenario: 1363 1) Handoff decision 1365 - The QoS management requests handoff. The QoS management can decide 1366 to change the access point, since the traffic conditions of the new 1367 access point are better supporting the QoS requirements. The metric 1368 may be different (optimized towards a single or a group/class of 1369 users). Note that the MT or the network (see below) might trigger 1370 the handoff. 1372 - The mobility management forces handoff. This can have several 1373 reasons. The operator optimizes his network, admission is no longer 1374 granted (e.g. emptied prepaid condition). Or another example is when 1375 the MT is reaching the focus of another base station. However, this 1376 might be detected via measurements of QoS on the physical layer and 1377 is therefore out of scope of QoS signaling in IP. Note again that 1378 the MT or the network (see below) might trigger the handoff. 1380 - This scenario shows that local decisions might not be enough. The 1381 rest of the path to the other end of the communication needs to be 1382 considered as well. Hand-off decisions in a QoS domain, does not 1383 only depend on the local resource availability, e.g., the wireless 1384 part, but involves the rest of the path as well. Additionally, 1385 decomposition of an end-to-end reservation might be needed, in order 1386 to change only parts of it. 1388 2) Trigger sources 1389 - Mobile terminal: If the end-system QoS management identifies 1390 another (better-suited) access point, it will request the handoff 1391 from the terminal itself. This will be especially likely in the case 1392 that two different provider networks are involved. Another important 1393 example is when the current access point bearer disappears (e.g. 1394 removing the Ethernet cable). In this case, the NSIS Initiator is 1395 basically located on the mobile terminal. 1397 - Network (access network manager): Sometimes, the handoff trigger 1398 will be issued from the network management to optimize the overall 1399 load situation. Most likely this will result in changing the base- 1400 station of a single providers network. Most likely the NSIS 1401 Initiator is located on a system within the network. 1403 3) Integration with other protocols 1405 - Interworking with other protocol must be considered in one or the 1406 other form. E.g., it might be worth combining QoS signaling between 1407 different QoS domains with mobility signaling at hand-over. 1409 4) Handover rates 1411 In mobile networks, the admission control process has to cope with 1412 far more admission requests than call setups alone would generate. 1413 For example, in the GSM (Global System for Mobile communications) 1414 case, mobility usually generates an average of one to two handovers 1415 per call. For third generation networks (such as UMTS), where it is 1416 necessary to keep radio links to several cells simultaneously 1417 (macro-diversity), the handover rate is significantly higher. 1419 5) Fast reservations 1421 Handover can also cause packet losses. This happens when the 1422 processing of an admission request causes a delayed handover to the 1423 new base station. In this situation, some packets might be 1424 discarded, and the overall speech quality might be degraded 1425 significantly. Moreover, a delay in handover may cause degradation 1426 for other users. In the worst-case scenario, a delay in handover may 1427 cause the connection to be dropped if the handover occurred due to 1428 bad air link quality. Therefore, it is critical that QoS signaling 1429 in connection with handover be carried out very quickly. 1431 6) Call blocking in case of overload 1433 Furthermore, when the network is overloaded, it is preferable to 1434 keep reservations for previously established flows while blocking 1435 new requests. Therefore, the resource reservation requests in 1436 connection with handover should be given higher priority than new 1437 requests for resource reservation. 1439 10.2 Cellular Networks 1441 In this scenario, the user is using the packet service of a 3rd 1442 generation cellular system, e.g. UMTS. The region between the End 1443 Host and the edge node connecting the cellular network to another 1444 QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is 1445 considered to be a single QoS domain. 1447 The issues in such an environment regarding QoS include: 1449 1) Cellular systems provide their own QoS technology with 1450 specialized parameters to co-ordinate the QoS provided by both the 1451 radio access and wired access network. For example, in a UMTS 1452 network, one aspect of GPRS is that it can be considered as a QoS 1453 technology; provisioning of QoS within GPRS is described mainly in 1454 terms of calling UMTS bearer classes. This QoS technology needs to 1455 be invoked with suitable parameters when higher layers trigger a 1456 request for QoS, and this therefore involves mapping the requested 1457 IP QoS onto these UMTS bearer classes. This request for resources 1458 might be triggered by IP signaling messages that pass across the 1459 cellular system, and possibly other QoS domains, to negotiate for 1460 network resources. Typically, cellular system specific messages 1461 invoke the underlying cellular system QoS technology in parallel 1462 with the IP QoS negotiation, to allocate the resources within the 1463 cellular system. 1465 2) The placement of NSIS Initiators and NSIS Forwarders (terminology 1466 in the framework given here). The NSIS Initiator could be located at 1467 the End Host (triggered by applications), the GGSN/PDSN, or at a 1468 node not directly on the data path, such as a bandwidth broker. In 1469 the second case, the GGSN/PDSN could either be acting as a proxy on 1470 behalf of an End Host with little capabilities, and/or managing 1471 aggregate resources within its QoS domain (the UMTS core network). 1472 The IP signaling messages are interpreted by the NSIS Forwarders, 1473 which may be located at the GGSN/PDSN, and in any QoS sub-domains 1474 within the cellular system. 1476 3) Initiation of IP-level QoS negotiation. IP-level QoS re- 1477 negotiation may be initiated by either the End Host, or by the 1478 network, based on current network loads, which might change 1479 depending on the location of the end host. 1481 4) The networks are designed and mainly used for speech 1482 communication (at least so far). 1484 Note that in comparison to the former scenario, the emphasis is much 1485 less on the mobility aspects, because mobility is mainly handled on 1486 the lower layer. 1488 10.3 UMTS access 1490 The UMTS access scenario is shown in figure 3. The Proxy-Call State 1491 Control Function/Policy Control Function (P-CSCF/PCF) is the 1492 outbound SIP proxy of the visited domain, i.e. the domain where the 1493 mobile user wants to set-up a call. The Gateway GPRS Support Node 1494 (GGSN) is the egress router of the UMTS domain and connects the UMTS 1495 access network to the Edge Router (ER) of the core IP network. The 1496 P-CSCF/PCF communicates with the GGSN via the COPS protocol. The 1497 User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal 1498 Equipment (TE), e.g. a laptop. 1500 +--------+ 1501 +----------| P-CSCF |-------> SIP signaling 1502 / +--------+ 1503 / SIP : 1504 : +--------+ NSIS +----------------+ 1505 : | PCF |---------| NSIS Forwarder | 1506 : +--------+ +----------------+ 1507 : : 1508 : : COPS 1509 : : 1510 +----+ +--------+ +----+ 1511 | UE |----------| GGSN |------| ER | 1512 +----+ +--------+ +----+ 1514 Figure 1: UMTS access scenario 1516 In this scenario the GGSN has the role of Access Gate. According to 1517 3GPP standardization, the PCF is responsible for the policy-based 1518 control of the end-user service in the UMTS access network (i.e. 1519 from UE to GGSN). In the current UMTS release R.5, the PCF is part 1520 of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF 1521 may evolve to an open standardized interface. In any case the PCF 1522 has all required QoS information for per-flow admission control in 1523 the UMTS access network (which it gets from the P-CSCF and/or GGSN). 1524 Thus the PCF would be the appropriate entity to host the 1525 functionality of NSIS Initiator, initiating the "NSIS" QoS signaling 1526 towards the core IP network. The PCF/P-CSCF has to do the mapping 1527 from codec type (derived from SIP/SDP signaling) to IP traffic 1528 descriptor. SDP extensions to explicitly signal QoS information are 1529 useful to avoid the need to store codec information in the PCF and 1530 to allow for more flexibility and accurate description of the QoS 1531 traffic parameters. The PCF also controls the GGSN to open and close 1532 the gates and to configure per-flow policers, i.e. to authorize or 1533 forbid user traffic. 1535 The NSIS Forwarder is (of course) not part of the standard UMTS 1536 architecture. However, to achieve end-to-end QoS a NSIS Forwarder is 1537 needed such that the PCF can request a QoS connection to the IP 1538 network. As in the previous example, the NSIS Forwarder could manage 1539 a set of pre-provisioned resources in the IP network, i.e. bandwidth 1540 pipes, and the NSIS Forwarder performs per-flow admission control 1541 into these pipes. In this way, a connection can be made between two 1542 UMTS access networks, and hence, end-to-end QoS can be achieved. In 1543 this case the NSIS Initiator and NSIS Forwarder are clearly two 1544 separate entities. 1545 This use case clearly illustrates the need for an "NSIS" QoS 1546 signaling protocol between NSIS Initiator and NSIS Forwarder. An 1547 important application of such a protocol may be its use in the 1548 inter-connection of UMTS networks over an IP backbone. 1550 10.4 Wired part of wireless network 1552 A wireless network, seen from a QoS domain perspective, usually 1553 consists of three parts: a wireless interface part (the "radio 1554 interface"), a wired part of the wireless network (i.e., Radio 1555 Access Network) and the backbone of the wireless network, as shown 1556 in Figure 2. Note that this figure should not be seen as an 1557 architectural overview of wireless networks but rather as showing 1558 the conceptual QoS domains in a wireless network. 1560 In this scenario, a mobile host can roam and perform a handover 1561 procedure between base stations/access routers. In this scenario the 1562 NSIS QoS protocol can be applied between a base station and the 1563 gateway (GW). In this case a GW can also be considered as a local 1564 handover anchor point. Furthermore, in this scenario the NSIS QoS 1565 protocol can also be applied either between two GWs, or between two 1566 edge routers (ER). 1568 |--| 1569 |GW| 1570 |--| |--| 1571 |MH|--- . 1572 |--| / |-------| . 1573 /--|base | |--| . 1574 |station|-|ER|... 1575 |-------| |--| . |--| back- |--| |---| |----| 1576 ..|ER|.......|ER|..|BGW|.."Internet"..|host| 1577 -- |-------| |--| . |--| bone |--| |---| |----| 1578 |--| \ |base |-|ER|... . 1579 |MH| \ |station| |--| . 1580 |--|--- |-------| . MH = mobile host 1581 |--| ER = edge router 1582 <----> |GW| GW = gateway 1583 Wireless link |--| BGW = border gateway 1584 ... = interior nodes 1585 <-------------------> 1586 Wired part of wireless network 1588 <----------------------------------------> 1589 Wireless Network 1591 Figure 2. QoS architecture of wired part of wireless network 1593 Each of these parts of the wireless network impose different issues 1594 to be solved on the QoS signaling solution being used: 1596 - Wireless interface: The solution for the air interface link 1597 has to ensure flexibility and spectrum efficient transmission 1598 of IP packets. However, this link layer QoS can be solved in 1599 the same way as any other last hop problem by allowing a 1600 host to request the proper QoS profile. 1602 - Wired part of the wireless network: This is the part of 1603 the network that is closest to the base stations/access 1604 routers. It is an IP network although some parts logically 1605 perform tunneling of the end user data. In cellular networks, 1606 the wired part of the wireless network is denoted as a 1607 radio access network. 1609 This part of the wireless network has different 1610 characteristics when compared to traditional IP networks: 1612 1. The network supports a high proportion of real-time 1613 traffic. The majority of the traffic transported in the 1614 wired part of the wireless network is speech, which is 1615 very sensitive to delays and delay variation (jitter). 1617 2. The network must support mobility. Many wireless 1618 networks are able to provide a combination of soft 1619 and hard handover procedures. When handover occurs, 1620 reservations need to be established on new paths. 1621 The establishment time has to be as short as possible 1622 since long establishment times for reservations degrade 1623 the performance of the wireless network. Moreover, 1624 for maximal utilization of the radio spectrum, frequent 1625 handover operations are required. 1627 3. These links are typically rather bandwidth-limited. 1629 4. The wired transmission in such a network contains a 1630 relatively high volume of expensive leased lines. 1631 Overprovisioning might therefore be prohibitively 1632 expensive. 1634 5. The radio base stations are spread over a wide 1635 geographical area and are in general situated a large 1636 distance from the backbone. 1638 - Backbone of the wireless network: the requirements imposed 1639 by this network are similar to the requirements imposed by 1640 other types of backbone networks. 1642 Due to these very different characteristics and requirements, often 1643 contradictory, different QoS signaling solutions might be needed in 1644 each of the three network parts. 1646 10.5 Session Mobility 1648 In this scenario, a session is moved from one end-system to another. 1649 Ongoing sessions are kept and QoS parameters need to be adapted, 1650 since it is very likely that the new device provides different 1651 capabilities. Note that it is open which entity initiates the move, 1652 which implies that the NSIS Initiator might be triggered by 1653 different entities. 1655 User mobility (i.e., a user changing the device and therefore moving 1656 the sessions to the new device) is considered to be a special case 1657 within the session mobility scenario. 1659 Note that this scenario is different from terminal mobility. Not the 1660 terminal (end-system) has moved to a different access point. Both 1661 terminals are still connected to an IP network at their original 1662 points. 1664 The issues include: 1666 1) Keeping the QoS guarantees negotiated implies that the end- 1667 point(s) of communication are changed without changing the 1668 reservations. 1670 2) The trigger of the session move might be the user or any other 1671 party involved in the session. 1673 10.6 QoS reservations/negotiation from access to core network 1675 The scenario includes the signaling between access networks and core 1676 networks in order to setup and change reservations together with 1677 potential negotiation. 1679 The issues to be solved in this scenario are different from previous 1680 ones. 1682 1) The entity of reservation is most likely an aggregate. 1684 2) The time scales of reservations might be different (long living 1685 reservations of aggregates, rarer re-negotiation). 1687 3) The specification of the traffic (amount of traffic), a 1688 particular QoS is guaranteed for, needs to be changed. E.g., in case 1689 additional flows are added to the aggregate, the traffic 1690 specification of the flow needs to be added if it is not already 1691 included in the aggregates specification. 1693 4) The flow specification is more complex including network 1694 addresses and sets of different address for the source as well as 1695 for the destination of the flow. 1697 10.7 QoS reservation/negotiation over administrative boundaries 1699 Signaling between two or more core networks to provide QoS is 1700 handled in this scenario. This might also include access to core 1701 signaling over administrative boundaries. Compared to the previous 1702 one it adds the case, where the two networks are not in the same 1703 administrative domain. Basically, it is the inter-domain/inter 1704 provider signaling which is handled in here. 1706 The domain boundary is the critical issue to be resolved. Which as 1707 various flavors of issues a QoS signaling protocol has to be 1708 concerned with. 1710 1) Competing administrations: Normally, only basic information 1711 should be exchanged, if the signaling is between competing 1712 administrations. Specifically information about core network 1713 internals (e.g., topology, technology, etc.) should not be 1714 exchanged. Some information exchange about the "access points" of 1715 the core networks (which is topology information as well) may need 1716 to be exchanged, because it is needed for proper signaling. 1718 2) Additionally, as in scenario 4, signaling most likely is based on 1719 aggregates, with all the issues raise there. 1721 3) Authorization: It is critical that the NSIS Initiator is 1722 authorized to perform a QoS path setup. 1724 4) Accountability: It is important to notice that signaling might be 1725 used as an entity to charge money for, therefore the interoperation 1726 with accounting needs to be available. 1728 10.8 QoS signaling between PSTN gateways and backbone routers 1730 A PSTN gateway (i.e., host) requires information from the network 1731 regarding its ability to transport voice traffic across the network. 1732 The voice quality will suffer due to packet loss, latency and 1733 jitter. Signaling is used to identify and admit a flow for which 1734 these impairments are minimized. In addition, the disposition of 1735 the signaling request is used to allow the PSTN GW to make a call 1736 routing decision before the call is actually accepted and delivered 1737 to the final destination. 1739 PSTN gateways may handle thousands of calls simultaneously and there 1740 may be hundreds of PSTN gateways in a single provider network. These 1741 numbers are likely to increase as the size of the network increases. 1742 The point being that scalability is a major issue. 1744 There are several ways that a PSTN gateway can acquire assurances 1745 that a network can carry its traffic across the network. These 1746 include: 1748 1. Over-provisioning a high availability network. 1749 2. Handling admission control through some policy server 1750 that has a global view of the network and its resources. 1751 3. Per PSTN GW pair admission control. 1752 4. Per call admission control (where a call is defined as 1753 the 5 tuple used to carry a single RTP flow). 1755 Item 1 requires no signaling at all and is therefore outside the 1756 scope of this working group. 1758 Item 2 is really a better informed version of 1, but it is also 1759 outside the scope of this working group as it relies on a particular 1760 telephony signaling protocol rather than a packet admission control 1761 protocol. 1763 Item 3 is initially attractive, as it appears to have reasonable 1764 scaling properties, however, its scaling properties only are 1765 effective in cases where there are relatively few PSTN GWs. In the 1766 more general case were a PSTN GW reduces to a single IP phone 1767 sitting behind some access network, the opportunities for 1768 aggregation are reduced and the problem reduces to item 4. 1770 Item 4 is the most general case. However, it has the most difficult 1771 scaling problems. The objective here is to place the requirements on 1772 Item 4 such that a scalable per-flow admission control protocol or 1773 protocol suite may be developed. 1775 The case where per-flow signaling extends to individual IP end- 1776 points allows the inclusion of IP phones on cable, DSL, wireless or 1777 other access networks in this scenario. 1779 Call Scenario 1781 A PSTN GW signals end-to-end for some 5 tuple defined flow a 1782 bandwidth and QoS requirement. Note that the 5 tuple might include 1783 masking/wildcarding. The access network admits this flow according 1784 to its local policy and the specific details of the access 1785 technology. 1787 At the edge router (i.e., border node), the flow is admitted, again 1788 with an optional authentication process, possibly involving an 1789 external policy server. Note that the relationship between the PSTN 1790 GW and the policy server and the routers and the policy server is 1791 outside the scope of NSIS. The edge router then admits the flow into 1792 the core of the network, possibly using some aggregation technique. 1794 At the interior nodes, the NSIS host-to-host signaling should either 1795 be ignored or invisible as the Edge router performed the admission 1796 control decision to some aggregate. 1798 At the inter-provider router (i.e., border node), again the NSIS 1799 host-to-host signaling should either be ignored or invisible as the 1800 Edge router has performed an admission control decision about an 1801 aggregate across a carrier network. 1803 10.9 PSTN trunking gateway 1805 One of the use cases for the NSIS signaling protocol is the scenario 1806 of interconnecting PSTN gateways with an IP network that supports 1807 QoS. 1808 Four different scenarios are considered here. 1809 1. In-band QoS signaling is used. In this case the Media Gateway 1810 (MG) will be acting as the NSIS Initiator and the Edge Router 1811 (ER) will be the NSIS Forwarder. Hence, the ER should do 1812 admission control (into pre-provisioned traffic trunks) for the 1813 individual traffic flows. This scenario is not further 1814 considered here. 1816 2. Out-of-band signaling in a single domain, the NSIS Forwarder is 1817 integrated in the MGC. In this case no NSIS protocol is 1818 required. 1819 3. Out-of-band signaling in a single domain, the NSIS Forwarder is 1820 a separate box. In this case NSIS signaling is used between the 1821 MGC and the NSIS Forwarder. 1822 4. Out-of-band signaling between multiple domains, the NSIS 1823 Forwarder (which may be integrated in the MGC) triggers the 1824 NSIS Forwarder of the next domain. 1826 When the out-of-band QoS signaling is used the Media Gateway 1827 Controller (MGC) will be acting as the NSIS Initiator. 1829 In the second scenario the voice provider manages a set of traffic 1830 trunks that are leased from a network provider. The MGC does the 1831 admission control in this case. Since the NSIS Forwarder acts both 1832 as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is 1833 required. This scenario is shown in figure 1. 1835 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1836 | SS7 network |---------------------| MGC |--------------| SS7 | 1837 +-------------+ +-------+-----+---------+ +-----+ 1838 : / : \ 1839 : / : \ 1840 : / +--------:----------+ \ 1841 : MEGACO / / : \ \ 1842 : / / +-----+ \ \ 1843 : / / | NMS | \ \ 1844 : / | +-----+ | \ 1845 : : | | : 1846 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1847 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1848 +--------------+ +----+ \ / +----+ 1849 \ QoS network / 1850 +-------------------+ 1852 Figure 1: PSTN trunking gateway scenario 1854 In the third scenario, the voice provider does not lease traffic 1855 trunks in the network. Another entity may lease traffic trunks and 1856 may use a NSIS Forwarder to do per-flow admission control. In this 1857 case the NSIS signaling is used between the MGC and the NSIS 1858 Forwarder, which is a separate box here. Hence, the MGC acts only as 1859 a NSIS Initiator. This scenario is depicted in figure 2. 1861 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1862 | SS7 network |---------------------| MGC |--------------| SS7 | 1863 +-------------+ +-------+-----+---------+ +-----+ 1864 : / : \ 1865 : / +-----+ \ 1866 : / | NSIS Forwarder | 1867 \ 1868 : / +-----+ \ 1869 : / : \ 1870 : / +--------:----------+ \ 1871 : MEGACO : / : \ : 1872 : : / +-----+ \ : 1873 : : / | NMS | \ : 1874 : : | +-----+ | : 1875 : : | | : 1876 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1877 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1878 +--------------+ +----+ \ / +----+ 1879 \ QoS network / 1880 +-------------------+ 1882 Figure 2: PSTN trunking gateway scenario 1884 In the fourth scenario multiple transport domains are involved. In 1885 the originating network either the MGC may have an overview on the 1886 resources of the overlay network or a separate NSIS Forwarder will 1887 have the overview. Hence, depending on this either the MGC or the 1888 NSIS Forwarder of the originating domain will contact the NSIS 1889 Forwarder of the next domain. The MGC always acts as a NSIS 1890 Initiator and may also be acting as a NSIS Forwarder in the first 1891 domain. 1893 10.10 Application request end-to-end QoS path from the network 1895 This is actually the easiest case, nevertheless might be most often 1896 used in terms of number of users. So multimedia application requests 1897 a guaranteed service from an IP network. We assume here that the 1898 application is somehow able to specify the network service. The 1899 characteristics here are that many hosts might do it, but that the 1900 requested service is low capacity (bounded by the access line). 1901 Additionally, we assume no mobility and standard devices. 1903 QOS for Virtual Private Networks 1905 In a Virtual Private Network (VPN) a variety of tunnels might be 1906 used between its edges. These tunnels could be for example, IP-Sec, 1907 GRE, and IP-IP. One of the most significant issues in VPNs is 1908 related to how a flow is identified and what quality a flow gets. A 1909 flow identification might consist among others of the transport 1910 protocol port numbers. In an IP-Sec tunnel this will be problematic 1911 since the transport protocol information is encrypted. 1913 There are two types of L3 VPNs, distinguished by where the endpoints 1914 of the tunnels exist. The endpoints of the tunnels may either be on 1915 the customer (CPE) or the provider equipment or provider edge (PE). 1917 Virtual Private networks are also likely to request bandwidth or 1918 other type of service in addition to the premium services the PSTN 1919 GW are likely to use. 1921 Tunnel end points at the Customer premises 1922 When the endpoints are the CPE, the CPE may want to signal across 1923 the public IP network for a particular amount of bandwidth and QoS 1924 for the tunnel aggregate. Such signaling may be useful when a 1925 customer wants to vary their network cost with demand, rather than 1926 paying a flat rate. Such signaling exists between the two CPE 1927 routers. Intermediate access and edge routers perform the same exact 1928 call admission control, authentication and aggregation functions 1929 performed by the corresponding routers in the PSTN GW scenario with 1930 the exception that the endpoints are the CPE tunnel endpoints rather 1931 than PSTN GWs and the 5-tuple used to describe the RTP flow is 1932 replaced with the corresponding flow spec to uniquely identify the 1933 tunnels. Tunnels may be of any variety (e.g. IP-Sec, GRE, IP-IP). 1935 In such a scenario, NSIS would actually allow partly for customer 1936 managed VPNs, which means a customer can setup VPNs by subsequent 1937 NSIS signaling to various end-point. Plus the tunnel end-points are 1938 not necessarily bound to an application. The customer administrator 1939 might be the one triggering NSIS signaling. 1941 Tunnel end points at the provider premises 1943 In the case were the tunnel end-points exist on the provider edge, 1944 requests for bandwidth may be signaled either per flow, where a flow 1945 is defined from a customers address space, or between customer 1946 sites. 1948 In the case of per flow signaling, the PE router must map the 1949 bandwidth request to the tunnel carrying traffic to the destination 1950 specified in the flow spec. Such a tunnel is a member of an 1951 aggregate to which the flow must be admitted. In this case, the 1952 operation of admission control is very similar to the case of the 1953 PSTN GW with the additional level of indirection imposed by the VPN 1954 tunnel. Therefore, authentication, accounting and policing may be 1955 required on the PE router. 1957 In the case of per site signaling, a site would need to be 1958 identified. This may be accomplished by specifying the network 1959 serviced at that site through an IP prefix. In this case, the 1960 admission control function is performed on the aggregate to the PE 1961 router connected to the site in question. 1963 Full Copyright Statement 1965 Copyright (C) The Internet Society (2002). All Rights Reserved. 1967 This document and translations of it may be copied and furnished to 1968 others, and derivative works that comment on or otherwise explain it 1969 or assist in its implementation may be prepared, copied, published 1970 and distributed, in whole or in part, without restriction of any 1971 kind, provided that the above copyright notice and this paragraph are 1972 included on all such copies and derivative works. However, this 1973 document itself may not be modified in any way, such as by removing 1974 the copyright notice or references to the Internet Society or other 1975 Internet organizations, except as needed for the purpose of 1976 developing Internet standards in which case the procedures for 1977 copyrights defined in the Internet Standards process must be 1978 followed, or as required to translate it into languages other than 1979 English. 1981 The limited permissions granted above are perpetual and will not be 1982 revoked by the Internet Society or its successors or assigns. 1984 This document and the information contained herein is provided on an 1985 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1986 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 1987 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1988 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1989 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.