idnits 2.17.1 draft-ietf-nsis-req-05.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RSVP-TE], [RSVP]), 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 (November 2002) is 7832 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 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 November 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 mean 37 across administrative and technology domains. Signaling is mainly 38 though for QoS such as [RSVP], however in recent year several other 39 applications of signaling have been defined such as signaling for 40 MPLS label distribution [RSVP-TE]. To achieve wide applicability of 41 the requirements, the starting point is a diverse set of 42 scenarios/use cases concerning various types of networks and 43 application interactions. This memo present the assumptions and the 44 aspects not considered within scope before listing the requirements 45 grouped according to areas such as architecture and design goals, 46 signaling flows, layering, performance, flexibility, security, and 47 mobility. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC 2119. 53 Table of Contents 54 Status of this Memo................................................1 55 Abstract...........................................................1 56 Table of Contents..................................................1 57 1 Introduction.....................................................2 58 2 Terminology......................................................3 59 3 Problem Statement and Scope......................................5 60 4 Assumptions and Exclusions.......................................6 61 4.1 Assumptions and Non-Assumptions................................6 62 4.2 Exclusions.....................................................7 63 5 Requirements.....................................................9 64 5.1 Architecture and Design Goals..................................9 65 5.2 Signaling Flows...............................................11 66 5.3 Messaging.....................................................12 67 5.4 Control Information...........................................14 68 5.5 Performance...................................................15 69 5.6 Flexibility...................................................17 70 5.7 Security......................................................18 71 5.8 Mobility......................................................20 72 5.9 Interworking with other protocols and techniques..............21 73 5.10 Operational..................................................21 74 6 Security Considerations.........................................22 75 7 References......................................................22 76 8 Acknowledgments.................................................22 77 9 Author's Addresses..............................................23 78 10 Appendix: Scenarios/Use cases..................................23 79 10.1 Terminal Mobility............................................24 80 10.2 Cellular Networks............................................26 81 10.3 UMTS access..................................................27 82 10.4 Wired part of wireless network...............................28 83 10.5 Session Mobility.............................................29 84 10.6 QoS reservations/negotiation from access to core network.....30 85 10.7 QoS reservation/negotiation over administrative boundaries...30 86 10.8 QoS signaling between PSTN gateways and backbone routers.....31 87 10.9 PSTN trunking gateway........................................32 88 10.10 Application request end-to-end QoS path from the network....34 90 1 Introduction 92 This document defines requirements for signaling across different 93 network environments. It does not list any problems of existing 94 signaling protocols such as [RSVP]. 96 In order to derive requirements for signaling it is necessary to 97 first have an idea of the scope within which they are applicable. 98 Therefore, we describe a set of signaling scenarios and use cases in 99 the Appendix of that document. These scenarios derive from a variety 100 of backgrounds, and help obtain a clearer picture of what is in or 101 out of scope of the NSIS work. They illustrate the problem of 102 signaling from various perspectives (end-system, access network, 103 core network) and for various areas (fixed line, mobile, wireless 104 environments). Most of them are targeted towards QoS, because that 105 was the primary target of signaling. 107 QoS and signaling for QoS is a pretty large field with a lot of 108 interaction with other protocols, mechanisms, applications etc. 109 However, it is not the only field where signaling is used in the 110 Internet. Even if this requirement documents mainly used QoS as the 111 sample application other application must be possible. 113 There are several areas of the requirements related to networking 114 aspects which are incomplete, for example, interaction with host and 115 site multi-homing, use of anycast services, and so on. These issues 116 should be considered in any future analysis work. 118 Based on the scenarios, we are able to define the signaling problem 119 on a more abstract level. In Section 3, we thus present a simple 120 conceptual model of the signaling problem. Additionally, we describe 121 the entities involved in signaling and typical signaling paths. In 122 Section 4 we list assumptions and exclusions. 124 2 Terminology 126 We try to list the most often used terms in the document. However, 127 don't be to religious about it, they are not meant to prescribe any 128 solution in the document. 130 Resource Management Function (RMF): An abstract concept, 131 representing the management of resources in a domain or a node. 133 NSIS Domain (ND): Administrative domain where an NSIS protocol 134 signals for a resource or set of resources. 136 NSIS Entity (NE): The function within a node, which implements an 137 NSIS protocol. 139 NSIS Forwarder (NF): NSIS Entity on the path between a NI and NR, 140 which may interact with local resource management function (RMF) for 141 this purpose. NSIS Forwarder also propagates NSIS signaling further 142 through the network. It is responsible for interpreting the 143 signaling carrying the user parameters, optionally inserting or 144 modifying the parameters according to domain network management 145 policy. 147 NSIS Initiator (NI): NSIS Entity that initiates NSIS signaling for a 148 network resource based on user or application requirements. This can 149 be located in the end system, but may reside elsewhere in network. 151 NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and 152 can optionally interact with applications as well. 154 Flow: A traffic stream (sequence of IP packets between two end 155 systems) for which a specific packet level treatment is provided. 156 The flow can be unicast (uni- or bi-directional) or multicast. 158 Higher Layers: The higher layer (transport protocol and application) 159 functions that request QoS or any other service from the network 160 layer. The request might be a trigger generated within the end 161 system, or the trigger might be provided by some entity within the 162 network (e.g. application proxy or policy server). 164 Path: the route across the networks taken by a flow or aggregate, 165 i.e. which domains/subdomains it passes through and the 166 egress/ingress points for each. 168 Path Segment: The segment of a path within a single 169 domain/subdomain. 171 Control Information: the information the governs for instance the 172 QoS treatment to be applied to a flow or aggregate, including the 173 service class, flow administration, and any associated security or 174 accounting information. 176 Provisioning: the act of actually allocating resources to a flow or 177 aggregate of flows, may include mechanisms such as LSP initiation 178 for MPLS, packet scheduler configuration within a router, and so on. 179 The mechanisms depend on the overall technology and application 180 being used within the domain. 182 Subdomain: a network within an administrative domain using a uniform 183 technology, e.g., a single QoS provisioning function to provision 184 resources. 186 QoS Technology: a generic term for a set of protocols, standards and 187 mechanisms that can be used within a QoS domain/subdomain to manage 188 the QoS provided to flows or aggregates that traverse the domain. 189 Examples might include MPLS, DiffServ, and so on. A QoS technology 190 is associated with certain QoS provisioning techniques. 192 Resource: something of value in a network infrastructure to which 193 rules or policy criteria are first applied before access is granted. 194 Examples of resources include the buffers in a router and bandwidth 195 on an interface. 197 Resource Allocation: part of a resource that has been dedicated for 198 the use of a particular traffic type for a period of time through 199 the application of policies. 201 Sender-initiated signaling protocol: A sender-initiated signaling 202 protocol is a protocol where the NI initiates the signaling on 203 behalf of the sender of the data. What this means is that admission 204 control and resource allocation functions are processed from the 205 data sender towards the data receiver. However, the triggering 206 instance is not specified. 208 Receiver-initiated signaling protocol: A receiver-initiated 209 protocol, (see e.g., [RSVP]) is a protocol where the NSIS Responder 210 on behalf of the receiver of the user data initiates the 211 reservations. What this means is that admission control and resource 212 allocation functions are processed from the data receiver back 213 towards the data sender. However, the triggering instance is not 214 specified. 216 3 Problem Statement and Scope 218 We provide in the following a preliminary architectural picture as a 219 basis for discussion. We will refer to it in the following 220 requirement section. 222 A basic goal should be to re-use these wherever possible, and to 223 focus requirements work at an early stage on those areas where a new 224 solution is needed (e.g. an especially simple one). We also try to 225 avoid defining requirements related to internal implementation 226 aspects. 228 Note that this model is intended not to constrain the technical 229 approach taken subsequently, simply to allow concrete phrasing of 230 requirements (e.g. requirements about placement of the NSIS 231 Initiator.) 233 Roughly, the scope of NSIS is assumed to be the interaction between 234 the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder 235 including a protocol to carry the information, and the 236 syntax/semantics of the information that is exchanged. Further 237 statements on assumptions/exclusions are given in the next Section. 239 The main elements are: 241 1. Something that starts the request for resources, the NSIS 242 Initiator. 244 This might be in the end system or within some other part of the 245 network. The distinguishing feature of the NSIS Initiator is that it 246 acts on triggers coming (directly or indirectly) from the higher 247 layers in the end systems. It needs to map the resources requested 248 by them, and also provides feedback information to the higher 249 layers, which might be used by transport layer rate management or 250 adaptive applications. 252 2. Something that assists in managing resources further along the 253 path, the NSIS Forwarder. 255 The NSIS Forwarder does not interact with higher layers, but 256 interacts with the NSIS Initiator and possibly more NSIS Forwarders 257 on the path, edge-to-edge or possibly end-to-end. 259 3. The NSIS Initiator and NSIS Forwarder(s) interact with each 260 other, path segment by path segment. This interaction involves the 261 exchange of data (resources control information) over some signaling 262 protocol. 264 4. The path segment traverses an underlying network covering one or 265 more IP hops. The underlying network might use locally different 266 technology. For instance, QoS technology has to be provisioned 267 appropriately for the service requested. An NSIS Forwarder maps 268 service-specific information to technology-related QoS parameters 269 and receiving indications about success or failure in response. 271 Now concentrating more on the overall end to end (multiple domain) 272 aspects, in particular: 274 1. The NSIS Initiator need not be located at an end system, and the 275 NSIS Forwarders are not assumed to be located on the flow's data 276 path. However, they must be able to identify the ingress and egress 277 points for the flow path as it traverses the domain/subdomain. Any 278 signaling protocol must be able to find the appropriate NSIS 279 Forwarder and carry this ingress/egress point information. 281 2. We see the network at the level of domains/subdomains rather than 282 individual routers (except in the special case that the domain 283 contains one link). Domains are assumed to be administrative 284 entities, so security requirements apply to the signaling between 285 them. 287 3. Any domain may contain Resource Management Function (e.g. to do 288 with traffic engineering, admission control, policy and so on). 289 These are assumed to interact with the NSIS Initiator and 290 Controllers (and end systems) using standard mechanisms. 292 4. The placement of the NSIS Initiators and NSIS Forwarders is not 293 fixed. 295 4 Assumptions and Exclusions 297 4.1 Assumptions and Non-Assumptions 299 1. The NSIS signaling could run end to end, end to edge, or edge to 300 edge, or network-to-network ((between providers), depending on what 301 point in the network acts as the initiator, and how far towards the 302 other end of the network the signaling propagates. In general, we 303 could expect NSIS Forwarders to become more 'dense' towards the 304 edges of the network, but this is not a requirement. An over- 305 provisioned domain might contain no NSIS Forwarders at all (and be 306 NSIS transparent); at the other extreme, NSIS Forwarders might be 307 placed at every router. In the latter case, provisioning can be 308 carried out in a local implementation-dependent way without further 309 signaling, whereas in the case of remote NSIS Forwarders, a 310 provisioning protocol might be needed to control the routers along 311 the path. This provisioning protocol is then independent of the end- 312 to-end NSIS signaling. 314 2. We do not consider 'pure' end-to-end signaling that is not 315 interpreted anywhere within the network. Such signaling is an 316 application-layer issue and IETF protocols such as SIP etc. can be 317 used. 319 3. Where the signaling does cover several NSIS domains or 320 subdomains, we do not exclude that different signaling protocols are 321 used in each path segment. We only place requirements on the 322 universality of the control information that is being transported. 323 (The goals here would be to allow the use of signaling protocols, 324 which are matched to the characteristics of the portion of the 325 network being traversed.) Note that the outcome of NSIS work might 326 result in various protocols or various flavors of the same protocol. 327 This implies the need for the translation of information into domain 328 specific format as well. 330 4. We assume that the service definitions a NSIS Initiator can ask 331 for are known in advance of the signaling protocol running. For 332 instance in the QoS example, the service definition includes QoS 333 parameters, lifetime of QoS guarantee etc., or any other service- 334 specific parameters. 336 There are many ways service requesters get to know about it. There 337 might be standardized services, the definition can be negotiated 338 together with a contract, the service definition is published at a 339 Web page, etc. 341 5. We assume that there are means for the discovery of NSIS entities 342 in order to know the signaling peers (solutions include static 343 configuration, automatically discovered, or implicitly runs over the 344 right nodes, etc.) The discovery of the NSIS entities has security 345 implications that need to be addressed properly. These implications 346 largely depend on the chosen protocol. For some security mechanisms 347 (i.e. Kerberos, pre-shared secret) it is required to know the 348 identity of the other entity. Hence the discovery mechanism may 349 provide means to learn this identity, which is then later used to 350 retrieve the required keys and parameters. 352 6. NSIS assumes to operate with networks using standard ("normal") 353 L3 routing. Where "normal" is not specified more exactly on purpose. 355 4.2 Exclusions 357 1. Development of specific mechanisms and algorithms for application 358 and transport layer adaptation are not considered, nor are the 359 protocols that would support it. 361 2. Specific mechanisms (APIs and so on) for interaction between 362 transport/applications and the network layer are not considered, 363 except to clarify the requirements on the negotiation capabilities 364 and information semantics that would be needed of the signaling 365 protocol. The same applies to application adaptation mechanisms. 367 3. Specific mechanisms for provisioning within a domain/subdomain 368 are not considered. However, NSIS can be used for signaling within a 369 domain/subdomain performing provisioning. For instance in the QoS 370 example, it means that the setting of QoS mechanisms in a domain is 371 out of scope, but if we have a tunnels, NSIS could also be used for 372 tunnel setup with QoS guaranties. It should be possible to exploit 373 these mechanisms optimally within the end-to-end context. 374 Consideration of how to do this might generate new requirements for 375 NSIS however. For example, the information needed by a NSIS 376 Forwarder to manage a radio subnetwork needs to be provided by the 377 NSIS solution. 379 4. Specific mechanisms (APIs and so on) for interaction between the 380 network layer and underlying provisioning mechanisms are not 381 considered. 383 5. Interaction with resource management capabilities is not 384 considered. Standard protocols should be used for this (e.g. COPS). 385 This may imply requirements for the sort of information that should 386 be exchanged between the NSIS entities. 388 6. Security implications related to multicasting are outside the 389 scope of the signaling protocol. 391 7. Protection of non-signaling messages is outside the scope of the 392 protocol 394 The protection of non-signaling messages (including data traffic 395 following a reservation) is not directly considered by a signaling 396 protocol. The protection of data messages transmitted along the 397 provisioned path is outside the scope of a signaling protocol. 398 Regarding data traffic there is an interaction with accounting 399 (metering) and edge routers might require packets to be integrity 400 protected to be able to securely assign incoming data traffic to a 401 particular user. 403 Additionally there might be an interaction with IPSec protected 404 traffic experiencing service-specific treatment and the established 405 state created due to signaling. One example of such an interaction is 406 the different flow identification with and without IPSec protection. 408 Many security properties are likely to be application specific and 409 may be provided by the corresponding application layer protocol. 411 8. Service definitions and in particular QoS services and classes 412 are out of scope. Together with the service definition any 413 definition of service specific parameters are not considered in this 414 document. Only the base NSIS signaling protocol for transporting the 415 service information are handled. 417 9. Similarly, specific methods, protocols, and ways to express 418 service information in the Application/Session level are not 419 considered (e.g., SDP, SIP, RTSP, etc.). 421 10. The specification of any extensions needed to signal information 422 via application level protocols (e.g. SDP), and the mapping on NSIS 423 information are considered outside of the scope of NSIS working 424 group, as this work is in the direct scope of other IETF working 425 groups (e.g. MMUSIC). 427 11. Handoff decision and trigger sources: An NSIS protocol is not 428 used to trigger handoffs in mobile IP, nor is it used to decide 429 whether to handoff or not. As soon as or in some situation even 430 before a handoff happened, an NSIS protocol might be used for 431 signaling for the particular service again. The basic underlying 432 assumption is that the route comes first (defining the path) and the 433 signaling comes after it (following the path). This doesn't prevent 434 a signaling application at some node interacting with something that 435 modifies the path, but the requirement is then just for NSIS to live 436 with that possibility. However, NSIS must interwork with several 437 protocols for mobility management. 439 12. Service monitoring is out of scope. It is heavily dependent on 440 the type of the application and or transport service, and in what 441 scenario it is used. 443 5 Requirements 445 This section defines more detailed requirements for a signaling 446 solution, derived from consideration of the use cases/scenarios 447 described in the appendix, and respecting the framework, scoping 448 assumptions, and terminology considered earlier. The requirements 449 are in subsections, grouped roughly according to general technical 450 aspects: architecture and design goals, topology issues, parameters, 451 performance, security, information, and flexibility. 453 Two general (and potentially contradictory) goals for the solution 454 are that it should be applicable in a very wide range of scenarios, 455 and at the same time lightweight in implementation complexity and 456 resource requirements in nodes. One approach to this is that the 457 solution could deal with certain requirements via modular components 458 or capabilities, which are optional to implement in individual 459 nodes. 461 In order to prioritize the various requirements we define different 462 'parts of the network'. In the different parts of the network a 463 particular requirement might have a different priority. 465 The parts of the networks we differentiate are the host-to-first 466 router, the access network, and the core network. The host to first 467 router part includes all the layer 2 technologies to access to the 468 Internet. In many cases, there is an application and/or user running 469 on the host initiating signaling. The access network can be 470 characterized by low capacity links, medium speed IP processing 471 capabilities, and it might consist of a complete layer 2 network as 472 well. The core network characteristics include high-speed forwarding 473 capacities and inter-domain issues. These divisions between network 474 types are not strict and do not appear in all networks, but where 475 they do exist they may influence signaling requirements and will be 476 highlighted as necessary. 478 5.1 Architecture and Design Goals 480 This section contains requirements related to desirable overall 481 characteristics of a solution, e.g. enabling flexibility, or 482 independence of parts of the framework. 484 5.1.1 MUST be applicable for different technologies. 486 The signaling protocol MUST work with various QoS and non-QoS 487 technologies. The basic information exchanged over the signaling 488 protocol MUST be in such detail and quantity that it is useful for 489 various technologies. 491 5.1.2 SHOULD provide resource availability information on request 493 NSIS SHOULD provide a mechanism to check whether resources are 494 available without performing a reservation. In some scenarios, e.g., 495 the mobile terminal scenario, it is required to query, whether 496 resources are available, without performing a reservation on the 497 resource. 499 5.1.3 NSIS MUST be designed modular 501 A modular design allows for more lightweight implementations, if 502 fewer features are needed. Mutually exclusive solutions are 503 supported. Examples for modularity: 505 - Work over any kind of network (narrowband versus broadband, error- 506 prone versus reliable, ...). This implies low bandwidth signaling 507 and redundant information MUST be supported if necessary. 509 - Uni- and bi-directional reservations are possible 511 - Extensible in the future with different add-ons for certain 512 environments or scenarios 514 - Protocol layering, where appropriate. This means NSIS MUST provide 515 a base protocol, which can be adapted to different environments. 517 5.1.4 NSIS MUST decouple protocol and information 519 The signaling protocol MUST be clearly separated from the control 520 information being transported. This provides for the independent 521 development of these two aspects of the solution, and allows for 522 this control information to be carried within other protocols, 523 including application layer ones, existing ones or those being 524 developed in the future. The gained flexibility in the information 525 transported allows for the applicability of the same protocol in 526 various scenarios. 528 However, note that the information carried needs to be the 529 standardized; otherwise interoperability is difficult to achieve. 531 5.1.5 NSIS MUST reuse existing provisioning 533 Reuse existing functions and protocols for provisioning within a 534 domain/subdomain unchanged. (Motivation: 'Don't re-invent the 535 wheel'.) 537 5.1.6 Independence of signaling and provisioning paradigm 539 The signaling MUST be independent of the paradigm and mechanism of 540 provisioning. E.g., in the case of signaling for QoS, the 541 independence of the signaling protocol from the QoS provisioning 542 allows for using the NSIS protocol together with various QoS 543 technologies in various scenarios. 545 5.1.7 Application independence 547 The signaling protocol MUST be independent of the application. The 548 control information SHOULD be application independent, because we 549 look into network level signaling. 551 The requirement relates to the way the signaling interacts with 552 upper layer functions (users, applications, and QoS administration), 553 and lower layer technologies. 555 Opaque application information MAY get transported in the signaling 556 message, without being handled in the network. Development and 557 deployment of new applications SHOULD be possible without impacting 558 the network infrastructure. 560 5.2 Signaling Flows 562 This section contains requirements related to the possible signaling 563 flows that should be supported, e.g. over what parts of the flow 564 path, between what entities (end-systems, routers, middle boxes, 565 management systems), in which direction. 567 5.2.1 Free placement of NSIS Initiator, Forwarder, Responder 569 The protocol MUST work in various scenarios such as host-to-network- 570 to-host, edge-to-edge, (e.g., just within one providers domain), 571 user-to-network (from end system into the network, ending, e.g., at 572 the entry to the network and vice versa), and network-to-network 573 (e.g., between providers). 575 Placing the NSIS Forwarder and NSIS Initiator functions at different 576 locations allows for various scenarios to work with the same 577 protocol. 579 5.2.2 No constraint of the signaling and NSIS Forwarders to be in the 580 data path. 582 There is a set of scenarios, where signaling is not on the data 583 path. The NSIS Forwarder being in the data path is one extreme case 584 and useful in many cases. Therefore the case of having NSIS entities 585 on the data path only MUST be allowed. 587 There are going to be cases where a centralized entity will take a 588 decision about service requests. In this case, there is no need to 589 have the data follow the signaling path. 591 There are going to be cases without a centralized entity managing 592 resources and the signaling will be used as a tool for resource 593 management. For various reasons (such as efficient use of expensive 594 bandwidth), one will want to have fine-grained, fast, and very 595 dynamic control of the resources in the network. 597 There are going to be cases where there will be neither signaling 598 nor a centralized entity (over-provisioning). Nothing has to be done 599 anyway. 601 One can capture the requirement with the following, different 602 wording: If one views the domain as a virtual router then NSIS 603 signaling used between those virtual routers MUST follow the same 604 path as the data. 606 Routing the signaling protocol along an independent path is desired 607 by network operators/designers. Ideally, the capability to route the 608 protocol along an independent path would give the network 609 designer/operator the option to manage bandwidth utilization through 610 the topology. 612 There are other possibilities as well. An NSIS protocol MUST accept 613 all of these possibilities with a strong focus on the on-path 614 signaling. 616 5.2.3 Concealment of topology and technology information 618 The NSIS protocol SHOULD allow for hiding the internal structure of 619 a NSIS domain from end-nodes and from other networks. Hence an 620 adversary should not be able to learn the internal structure of a 621 network with the help of the signaling protocol. 623 In various scenarios, topology information should be hidden for 624 various reasons. From a business point of view, some administrations 625 don't want to reveal the topology and technology used. 627 5.2.4 Transparency of signaling to network 629 It SHOULD be possible that the signaling for some flows traverse 630 path segments transparently, i.e., without interpretation at NSIS 631 Forwarders within the network. An example would be a subdomain 632 within a core network, which only interpreted signaling for 633 aggregates established at the domain edge, with the flow-related 634 signaling passing transparently through it. 636 In other words, NSIS SHOULD work in hierarchical scenarios, where 637 big pipes/trunks are setup using NSIS signaling, but also flows 638 which run within that big pipe/trunk are setup using NSIS. 640 5.3 Messaging 642 5.3.1 Explicit release of resources 643 When a resource reservation is no longer necessary, e.g. because the 644 application terminates, or because a mobile host experienced a hand- 645 off, it MUST be possible to explicitly release resources. In general 646 explicit release enhances the overall network utilization. 648 5.3.2 Possibility for automatic release of resources after failure 650 When the NSIS Initiator goes down, the resources it requested in the 651 network SHOULD be released, since they will no longer be necessary. 653 After detection of a failure in the network, any NSIS 654 Forwarder/Initiator MUST be able to release a reservation it is 655 involved in. For example, this may require signaling of the "Release 656 after Failure" message upstream as well as downstream, or soft state 657 timing out of reservations. 659 The goal is to prevent stale state within the network and adds 660 robustness to the operation of NSIS. So in other words, an NSIS 661 signaling protocol or mechanisms MUST provide means for an NSIS 662 entity to discover and remove local stale state. 664 Note that this might need to work together with a notification 665 mechanism. 667 5.3.3 Notifications sent upstream 669 NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS 670 Forwarder upstream, if there is a state change inside the network. 671 There are various types of network changes for instance among them: 673 Recoverable errors: the network nodes can locally repair this type 674 error. The network nodes do not have to notify the users of the 675 error immediately. This is a condition when the danger of 676 degradation (or actual short term degradation) of the provided 677 service was overcome by the network (NSIS Forwarder) itself. 679 Unrecoverable errors: the network nodes cannot handle this type of 680 error, and have to notify the users as soon as possible. 682 Service degradation/severe congestion: In case the service cannot be 683 provided completely but partially only. 685 Repair indication: If an error occurred and it has been fixed, this 686 triggers the sending of a notification. 688 Service upgrade available: If a previously requested better service 689 becomes available. 691 The content of the notification is very service specific, but it is 692 must at least carry type information. Additionally, it may carry the 693 location of the state change. 695 The notifications may or may not be in response to a NSIS message. 696 This means an NSIS entity has to be able to handle notifications at 697 any time. 699 Note however, that there are a number of security consideration 700 needs to be solved with notification, even more important if the 701 notification is sent without prior request (asynchronously). The 702 problem basically is, that everybody could send notifications to any 703 NSIS entity and the NSIS entity most likely reacts on the 704 notification. E.g., if it gets an error notification it might 705 teardown the reservation, even if everything is ok. So the 706 notification might depend on security associations between the 707 sender of the notification and its receiver. If a hop-by-hop 708 security mechanism is chosen, this implies also that notifications 709 need to be sent on the reverse path. 711 5.3.4 Feedback about success of service request 713 A request for service MUST be answered at least with yes or no. 714 However, it may be useful in case of a negative answer to also get a 715 description of what amount of resources a request is possible. So an 716 opaque element MAY be included into the answer. The element heavily 717 depends on the service requested. 719 5.3.5 Local information exchange 721 The signaling protocol MUST be able to exchange local information 722 between NSIS Forwarders located within one single administrative 723 domain. Local information might, for example, be IP addresses, 724 severe congestion notification, notification of successful or 725 erroneous processing of signaling messages. 727 In some cases, the NSIS signaling protocol MAY carry identification 728 of the NSIS Forwarders located at the boundaries of a domain. 729 However, the identification of edge should not be visible to the end 730 host (NSIS Initiator) and only applies within one administrative 731 domain. 733 5.4 Control Information 735 This section contains requirements related to the control 736 information that needs to be exchanged. 738 5.4.1 Mutability information on parameters 740 It SHOULD be possible for the NSIS initiator to control the 741 mutability of the signaled information. This prevents from being 742 changed in a non-recoverable way. The NSIS initiator SHOULD be able 743 to control what is requested end to end, without the request being 744 gradually mutated as it passes through a sequence of domains. This 745 implies that in case of changes made on the parameters, the original 746 requested ones must still be available. 748 Note that we do not require anything about particular parameters 749 being changed. 751 Additionally, note that a provider or that particular services 752 requested, can still influence the provisioning but in the signaling 753 message the request should stay the same. 755 5.4.2 Possibility to add and remove local domain information 757 It SHOULD be possible for the Resource Management Function to add 758 and remove local scope elements. E.g., at the entrance to a domain 759 domain-specific information is added, which is used in this domain 760 only, and the information is removed again when a signaling message 761 leaves the domain. The motivation is in the economy of re-use the 762 protocol for domain internal signaling of various information 763 pieces. Where additional information is needed within a particular 764 domain, it should be possible to carry this at the same time as the 765 end-to-end information. 767 5.4.3 Independence of reservation identifier 769 A reservation identifier MUST be independent of the flow identifier 770 (flow end-points). Various scenarios in the mobility area require 771 this independence because flows resulting from handoff might have 772 changed end-points etc. but still have the same service requirement. 773 Also several proxy-based signaling methods profit from such as 774 independence. 776 5.4.4 Seamless modification of already reserved resources 778 In many case, the reservation needs to be updated (up or downgrade). 779 This SHOULD happen seamlessly without service interruption. At least 780 the signaling protocol should allow for it, even if some data path 781 elements might not be capable of doing so. 783 5.4.5 Grouping of signaling for several micro-flows 785 NSIS MAY group signaling information for several micro-flow into one 786 signaling message. The goal of this is the optimization in terms of 787 setup delay, which can happen in parallel. This helps applications 788 requesting several flows at once. Also potential refreshes (in case 789 of a soft state solution) might profit of grouping. 791 However, the network MUST NOT know that a relationship between the 792 grouped flows exists. There MUST NOT be any transactional semantic 793 associated with the grouping. It is only meant for optimization 794 purposes and each reservation MUST be handled separately from each 795 other. 797 5.5 Performance 799 This section discusses performance requirements and evaluation 800 criteria and the way in which these could and should be traded off 801 against each other in various parts of the solution. 803 Scalability is a must anyway. However, depending on the scenario the 804 question to which extends the protocol must be scalable. 806 Note that many of the performance issues are heavily dependent on 807 the scenario assumed and are normally a trade-off between speed, 808 reliability, complexity, and scalability. The trade-off varies in 809 different parts of the network. For example, in radio access 810 networks low bandwidth consumption will overweight the low latency 811 requirement, while in core networks it may be reverse. 813 5.5.1 Scalability 815 NSIS MUST be scalable in the number of messages received by a 816 signaling communication partner (NSIS Initiator, NSIS Forwarder, and 817 NSIS Responder). The major concern lies in the core of the network, 818 where large numbers of messages arrive. 820 It MUST be scalable in number of hand-offs in mobile environments. 821 This mainly applies in access networks, because the core is 822 transparent to mobility in most cases. 824 It MUST be scalable in the number of interactions for setting up a 825 reservation. This applies for end-systems setting up several 826 reservations. Some servers might be expected to setup a large number 827 of reservations. 829 Scalability in the number of state per entity MUST be achieved for 830 NSIS Forwarders in the core of the network. 832 And Scalability in CPU use MUST be achieved on end terminals in case 833 of many reservations at the same time and intermediate nodes mainly 834 in the core. 836 5.5.2 Low latency in setup 838 NSIS SHOULD allow for low latency setup of reservations. This is 839 only needed in scenarios, where reservations are in a short time 840 scale (e.g. handover in mobile environments), or where human 841 interaction is immediately concerned (e.g., voice communication 842 setup delay). 844 5.5.3 Allow for low bandwidth consumption for signaling protocol 846 NSIS MUST allow for low bandwidth consumption in certain access 847 networks. Again only small sets of scenarios call for low bandwidth, 848 mainly those where wireless links are involved. 850 5.5.4 Ability to constrain load on devices 852 The NSIS architecture SHOULD give the ability to constrain the load 853 (CPU load, memory space, signaling bandwidth consumption and 854 signaling intensity) on devices where it is needed. One of the 855 reasons is that the protocol handling should have a minimal impact 856 on interior (core) nodes. 858 This can be achieved by many different methods. Examples, and this 859 are only examples, include message aggregation, by ignoring 860 signaling message, header compression, or minimizing functionality. 861 The framework may choose any method as long as the requirement is 862 met. 864 5.5.5 Highest possible network utilization 866 There are networking environments that require high network 867 utilization for various reasons, and the signaling protocol SHOULD 868 to its best ability support high resource utilization while 869 maintaining appropriate service quality. 871 In networks where resources are very expensive (as is the case for 872 many wireless networks), efficient network utilization is of 873 critical financial importance. On the other hand there are other 874 parts of the network where high utilization is not required. 876 5.6 Flexibility 878 This section lists the various ways the protocol can flexibly be 879 employed. 881 5.6.1 Flow aggregation 883 NSIS MUST allow for flow aggregation, including the capability to 884 select and change the level of aggregation. 886 5.6.2 Flexibility in the placement of the NSIS Initiator 888 NSIS MUST be flexible in placing an NSIS Initiator. The NSIS 889 Initiator might be the sender or the receiver of content. But also 890 network-initiated reservations MUST be available in various 891 scenarios such as PSTN gateways, some VPNs, and mobility. 893 5.6.3 Flexibility in the initiation of re-negotiation 895 The NSIS Initiator or the NSIS Responder SHOULD be able to initiate 896 a re-negotiation or change the reservation due to various reasons, 897 such as local resource shortage (CPU, memory on end-system) or a 898 user changed application preference/profiles. 900 5.6.4 SOULD support network-initiated re-negotiation 902 NSIS SHOULD support network-initiated re-negotiation. This is used 903 in cases, where the network is not able to further guarantee 904 resources and want to e.g. downgrade a reservation. 906 5.6.5 Uni / bi-directional reservation 907 Both unidirectional as well as bi-direction reservations SHOULD be 908 possible. With bi-directional reservations we mean here reservations 909 having the same end-points. But the path in the two directions does 910 not need to be the same. 912 The goal of a bi-directional reservation is mainly an optimization 913 in terms of setup delay. There is no requirements on constrains such 914 as use the same data path etc. 916 5.7 Security 918 This section discusses security-related requirements. For a 919 discussion of security threats see [SEC-THR]. The NSIS protocol MUST 920 provide means for security, but it MUST be allowed that nodes 921 implementing NSIS signaling do not need use the security means. 923 5.7.1 Authentication of signaling requests 925 A signaling protocol MUST make provision for enabling various 926 entities to be authenticated against each other using strong 927 authentication mechanisms. The term strong authentication points to 928 the fact that weak plain-text password mechanisms must not be used 929 for authentication. 931 5.7.2 Resource Authorization 933 The signaling protocol MUST provide means to authorize resource 934 requests. This requirement demands a hook to interact with a policy 935 entity to request authorization data. This allows an authenticated 936 entity to be associated with authorization data and to verify the 937 resource request. Authorization prevents reservations by unauthorized 938 entities, reservations violating policies, and theft of service. 939 Additionally it limits denial of service attacks against parts of the 940 network or the entire network caused by unrestricted reservations. 941 Additionally it might be helpful to provide some means to inform 942 other protocols of participating nodes within the same administrative 943 domain about a previous successful authorization event. 945 5.7.3 Integrity protection 947 The signaling protocol MUST provide means to protect the message 948 payloads against modifications. Integrity protection prevents an 949 adversary from modifying parts of the signaling message and from 950 mounting denial of service or theft of service type of attacks 951 against network elements participating in the protocol execution. 953 5.7.4 Replay protection 955 To prevent replay of previous signaling messages the signaling 956 protocol MUST provide means to detect old i.e. already transmitted 957 signaling messages. A solution must cover issues of synchronization 958 problems in the case of a restart or a crash of a participating 959 network element. 961 5.7.5 Hop-by-hop security 963 Hop-by-Hop security SHOULD be supported. It is a well known and 964 proven concept in Quality-of-Service and other signaling protocols 965 that allows intermediate nodes that actively participate in the 966 protocol to modify the messages as it is required by processing rule. 967 Note that this requirement does not exclude end-to-end or network-to- 968 network security of a signaling message. End-to-end security between 969 the initiator and the responder may be used to provide protection of 970 non-mutable data fields. Network-to-network security refers to the 971 protection of messages over various hops but not in an end-to-end 972 manner i.e. protected over a particular network. 974 5.7.6 Identity confidentiality and location privacy 976 Identity confidentiality SHOULD be supported. It enables privacy and 977 avoids profiling of entities by adversary eavesdropping the signaling 978 traffic along the path. The identity used in the process of 979 authentication may also be hidden to a limited extent from a network 980 to which the initiator is attached. However the identity MUST provide 981 enough information for the nodes in the access network to collect 982 accounting data. 984 Location privacy MAY be supported. It is an issue for the initiator 985 who triggers the signaling protocol. In some scenarios the initiator 986 may not be willing to reveal location information to the responder as 987 part the signaling procedure. 989 5.7.7 Denial-of-service attacks 991 A signaling protocol SHOULD provide prevention of Denial-of-service 992 attacks. To effectively prevent denial-of-service attacks it is 993 necessary that the used security and protocol mechanisms MUST have 994 low computation complexity to verify a resource request prior 995 authenticating the requesting entity. Additionally the signaling 996 protocol and the used security mechanisms SHOULD NOT require large 997 resource consumption (for example main memory or other additional 998 message exchanges) before a successful authentication was done. 1000 5.7.8 Confidentiality of signaling messages 1002 Based on the signaling information exchanged between nodes 1003 participating in the signaling protocol an adversary may learn both 1004 the identities and the content of the signaling messages. To prevent 1005 this from happening, confidentiality of the signaling message in a 1006 hop-by-hop manner MAY be provided. Note that the protection can be 1007 provided on a hop-by-hop basis for most message payloads since it is 1008 required that entities which actively participating in the signaling 1009 protocol must be able to read and eventually modify the content of 1010 the signaling messages. 1012 5.7.9 Ownership of a reservation 1013 When existing reservations have to be modified then there is a need 1014 to use a reservation identifier to uniquely identify the established 1015 state. A signaling protocol MUST provide the appropriate security 1016 protection to prevent other entities to modify state without having 1017 the proper ownership. 1019 5.7.10 Hooks with Authentication and Key Agreement protocols 1021 This requirement covers two subsequent steps before a signaling 1022 protocol is executed and the required hooks. First there is a need to 1023 agree on a specific authentication protocol. Later this protocol is 1024 executed and provides authentication and establishes the desired 1025 security associations. Using these security associations it is then 1026 possible to exchange secured signaling messages. 1028 The signaling protocol implementation SHOULD provide hooks to 1029 interact with protocols that allow the negotiation of authentication 1030 and key agreement protocols. Although the negotiation of an 1031 authentication and key management protocol within the signaling 1032 protocol may be outside the scope it is still required to trigger 1033 this exchange in case that no such security association is available. 1034 This requirement originates from the fact that more than one key 1035 management protocol may be used to provide a security association for 1036 the signaling protocol. Hence the communicating entities must be 1037 capable to agree on a specific authentication. The selected 1038 authentication and key agreement protocol must however be able to 1039 create a security association that can be used within the signaling 1040 protocol. 1042 Key management protocols typically require a larger number of 1043 messages to be transmitted to allow a session key and the 1044 corresponding security association to be derived. To avoid the 1045 complex issue of embedding individual authentication and key 1046 agreement protocols into a specific signaling protocol it is required 1047 that most of these protocols are executed independently (prior to the 1048 signaling protocol) and although the key management protocol may be 1049 independent there must be a way for the signaling protocol to access 1050 and use available (i.e. already established) security associations to 1051 avoid executing a separate key management protocol (or instance of 1052 the same protocol) for protocols that closely operate together. If no 1053 such security association exists then there SHOULD be means for the 1054 signaling protocol to dynamically trigger such a protocol. 1056 5.8 Mobility 1058 5.8.1 Allow efficient service re-establishment after handover 1060 Handover is an essential function in wireless networks. After 1061 handover, the reservation may need to be completely or partially re- 1062 established due to route changes. The re-establishment may be 1063 requested by the mobile node itself or triggered by the access point 1064 that the mobile node is attached to. In the first case, the 1065 signaling MUST allow efficient re-establishment after handover. Re- 1066 establishment after handover MUST be as quick as possible so that 1067 the mobile node does not experience service interruption or service 1068 degradation. The re-establishment SHOULD be localized, and not 1069 require end-to-end signaling. 1071 5.9 Interworking with other protocols and techniques 1073 Hooks SHOULD be provided to enable efficient interworking between 1074 various protocols and techniques including: 1076 5.9.1 MUST interwork with IP tunneling 1078 IP tunneling for various applications MUST be supported. More 1079 specifically tunneling for IPSec tunnels are of importance as 1080 discussed in Section 4.2. This mainly impacts the identification of 1081 flows. Using IPSec parts of information used for flow identification 1082 (e.g. transport protocol information and ports) may not be accessible 1083 due to encryption. 1085 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 1087 5.9.3 MUST be independent from charging model 1089 Signaling MUST NOT be constrained by charging models or the charging 1090 infrastructure used. 1092 5.9.4 SHOULD provide hooks for AAA protocols 1094 The NSIS SHOULD be developed with respect to be able to collect 1095 usage records from one or more network elements. 1097 5.9.5 SHOULD interwork with seamless handoff protocols 1099 An NSIS protocol SHOULD interwork with seamless handoff protocols 1100 such as context transfer and candidate access router (CAR) 1101 discovery. 1103 5.9.6 MAY interwork with non-traditional routing 1105 NSIS assumes traditional routing, but networks, which do non- 1106 traditional L3 routing, should not break it. 1108 5.10 Operational 1110 5.10.1 Ability to assign transport quality to signaling messages. 1112 The NSIS architecture SHOULD allow the network operator to assign 1113 the NSIS protocol messages a certain transport quality. As signaling 1114 opens up for possible denial-of-service attacks, this requirement 1115 gives the network operator a mean, but also the obligation, to 1116 trade-off between signaling latency and the impact (from the 1117 signaling messages) on devices within his/her network. From protocol 1118 design this requirement states that the protocol messages SHOULD be 1119 detectable, at least where the control and assignment of the 1120 messages priority is done. 1122 Furthermore, the protocol design must take into account reliability 1123 concerns. Communication reliability is seen as part of the quality 1124 assigned to signaling messages. So procedures MUST be defined how an 1125 NSIS signaling system behaves if some kind of request it sent stays 1126 without answer. The basic transport protocol to be used between 1127 adjacent NSIS units MAY ensure message integrity and reliable 1128 transport. 1130 5.10.2 Graceful fail over 1132 Any unit participating in NSIS signaling MUST NOT cause further 1133 damage to other systems involved in NSIS signaling when it has to go 1134 out of service. 1136 5.10.3 Graceful handling of NSIS entity problems 1138 NSIS peers SHOULD be able to detect the malfunctioning peer. It may 1139 notify the NSIS Initiator or another NSIS entity involved in the 1140 signaling process. The NSIS peer may handle the problem itself e.g. 1141 switching to a backup NSIS entity. In the latter case note that 1142 synchronization of state between the primary and the backup entity 1143 is needed. 1145 6 Security Considerations 1147 Section 5.7 of this document provides security related requirements 1148 of a signaling protocol. A separate document describes security 1149 threats for NSIS signaling [SEC-THR]. 1151 7 References 1153 [SEC-THR] Tschofenig, H., "NSIS Threats", Internet Draft , October 2002. 1156 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1157 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1158 Specification", RFC 2205, September 1997. 1160 [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 1161 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 1162 December 2001. 1164 8 Acknowledgments 1166 Quite a number of people have been involved in the discussion of the 1167 document, adding some ideas, requirements, etc. We list them without 1168 a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul 1169 (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas 1170 Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), 1171 Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 1172 University Berlin), Xiaoming Fu (Technical University Berlin), Hans- 1173 Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph 1174 Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya 1175 Freytsis. 1177 Some text and/or ideas for text, requirements, scenarios have been 1178 taken from an Internet Draft written by the following authors: David 1179 Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis 1180 (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University 1181 of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 1182 Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have 1183 actively contributed new text to this document as well. 1185 Another Internet Draft impacting this document has been written by 1186 Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel). 1187 These people contributed also new text. 1189 9 Author's Addresses 1191 Marcus Brunner (Editor) 1192 NEC Europe Ltd. 1193 Network Laboratories 1194 Kurfuersten-Anlage 34 1195 D-69115 Heidelberg 1196 Germany 1197 E-Mail: brunner@ccrle.nec.de 1199 Robert Hancock 1200 Roke Manor Research Ltd 1201 Romsey, Hants, SO51 0ZN 1202 United Kingdom 1203 E-Mail: robert.hancock@roke.co.uk 1205 Eleanor Hepworth 1206 Roke Manor Research Ltd 1207 Romsey, Hants, SO51 0ZN 1208 United Kingdom 1209 E-Mail: eleanor.hepworth@roke.co.uk 1211 Cornelia Kappler 1212 Siemens AG 1213 Berlin 13623 1214 Germany 1215 E-Mail: cornelia.kappler@icn.siemens.de 1217 Hannes Tschofenig 1218 Siemens AG 1219 Otto-Hahn-Ring 6 1220 81739 Munchen 1221 Germany 1222 Email: Hannes.Tschofenig@mchp.siemens.de 1224 10 Appendix: Scenarios/Use cases 1225 In the following we describe scenarios, which are important to 1226 cover, and which allow us to discuss various requirements. Some 1227 regard this as use cases to be covered defining the use of a 1228 signaling protocol. 1230 10.1 Terminal Mobility 1232 The scenario we are looking at is the case where a mobile terminal 1233 (MT) changes from one access point to another access point. The 1234 access points are located in separate QoS domains. We assume Mobile 1235 IP to handle mobility on the network layer in this scenario and 1236 consider the various extensions (i.e., IETF proposals) to Mobile IP, 1237 in order to provide 'fast handover' for roaming Mobile Terminals. 1238 The goal to be achieved lies in providing, keeping, and adapting the 1239 requested QoS for the ongoing IP sessions in case of handover. 1240 Furthermore, the negotiation of QoS parameters with the new domain 1241 via the old connection might be needed, in order to support the 1242 different 'fast handover' proposals within the IETF. 1244 The entities involved in this scenario include a mobile terminal, 1245 access points, an access network manager, and communication partners 1246 of the MT (the other end(s) of the communication association). 1247 From a technical point of view, terminal mobility means changing the 1248 access point of a mobile terminal (MT). However, technologies might 1249 change in various directions (access technology, QoS technology, 1250 administrative domain). If the access points are within one specific 1251 QoS technology (independent of access technology) we call this 1252 intra-QoS technology handoff. In the case of an inter-QoS technology 1253 handoff, one change from e.g. a DiffServ to an IntServ domain, 1254 however still using the same access technology. Finally, if the 1255 access points are using different access technologies we call it 1256 inter-technology hand-off. 1258 The following issues are of special importance in this scenario: 1260 1) Handoff decision 1262 - The QoS management requests handoff. The QoS management can decide 1263 to change the access point, since the traffic conditions of the new 1264 access point are better supporting the QoS requirements. The metric 1265 may be different (optimized towards a single or a group/class of 1266 users). Note that the MT or the network (see below) might trigger 1267 the handoff. 1269 - The mobility management forces handoff. This can have several 1270 reasons. The operator optimizes his network, admission is no longer 1271 granted (e.g. emptied prepaid condition). Or another example is when 1272 the MT is reaching the focus of another base station. However, this 1273 might be detected via measurements of QoS on the physical layer and 1274 is therefore out of scope of QoS signaling in IP. Note again that 1275 the MT or the network (see below) might trigger the handoff. 1277 - This scenario shows that local decisions might not be enough. The 1278 rest of the path to the other end of the communication needs to be 1279 considered as well. Hand-off decisions in a QoS domain do not only 1280 depend on the local resource availability, e.g., the wireless part, 1281 but involve the rest of the path as well. Additionally, 1282 decomposition of an end-to-end reservation might be needed, in order 1283 to change only parts of it. 1285 2) Trigger sources 1287 - Mobile terminal: If the end-system QoS management identifies 1288 another (better-suited) access point, it will request the handoff 1289 from the terminal itself. This will be especially likely in the case 1290 that two different provider networks are involved. Another important 1291 example is when the current access point bearer disappears (e.g. 1292 removing the Ethernet cable). In this case, the NSIS Initiator is 1293 basically located on the mobile terminal. 1295 - Network (access network manager): Sometimes, the handoff trigger 1296 will be issued from the network management to optimize the overall 1297 load situation. Most likely this will result in changing the base- 1298 station of a single providers network. Most likely the NSIS 1299 Initiator is located on a system within the network. 1301 3) Integration with other protocols 1303 - Interworking with other protocol must be considered in one or the 1304 other form. E.g., it might be worth combining QoS signaling between 1305 different QoS domains with mobility signaling at hand-over. 1307 4) Handover rates 1309 In mobile networks, the admission control process has to cope with 1310 far more admission requests than call setups alone would generate. 1311 For example, in the GSM (Global System for Mobile communications) 1312 case, mobility usually generates an average of one to two handovers 1313 per call. For third generation networks (such as UMTS), where it is 1314 necessary to keep radio links to several cells simultaneously 1315 (macro-diversity), the handover rate is significantly higher. 1317 5) Fast reservations 1319 Handover can also cause packet losses. This happens when the 1320 processing of an admission request causes a delayed handover to the 1321 new base station. In this situation, some packets might be 1322 discarded, and the overall speech quality might be degraded 1323 significantly. Moreover, a delay in handover may cause degradation 1324 for other users. In the worst-case scenario, a delay in handover may 1325 cause the connection to be dropped if the handover occurred due to 1326 bad air link quality. Therefore, it is critical that QoS signaling 1327 in connection with handover be carried out very quickly. 1329 6) Call blocking in case of overload 1331 Furthermore, when the network is overloaded, it is preferable to 1332 keep reservations for previously established flows while blocking 1333 new requests. Therefore, the resource reservation requests in 1334 connection with handover should be given higher priority than new 1335 requests for resource reservation. 1337 10.2 Cellular Networks 1339 In this scenario, the user is using the packet service of a 3rd 1340 generation cellular system, e.g. UMTS. The region between the End 1341 Host and the edge node connecting the cellular network to another 1342 QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is 1343 considered to be a single QoS domain. 1345 The issues in such an environment regarding QoS include: 1347 1) Cellular systems provide their own QoS technology with 1348 specialized parameters to co-ordinate the QoS provided by both the 1349 radio access and wired access network. For example, in a UMTS 1350 network, one aspect of GPRS is that it can be considered as a QoS 1351 technology; provisioning of QoS within GPRS is described mainly in 1352 terms of calling UMTS bearer classes. This QoS technology needs to 1353 be invoked with suitable parameters when higher layers trigger a 1354 request for QoS, and this therefore involves mapping the requested 1355 IP QoS onto these UMTS bearer classes. This request for resources 1356 might be triggered by IP signaling messages that pass across the 1357 cellular system, and possibly other QoS domains, to negotiate for 1358 network resources. Typically, cellular system specific messages 1359 invoke the underlying cellular system QoS technology in parallel 1360 with the IP QoS negotiation, to allocate the resources within the 1361 cellular system. 1363 2) The placement of NSIS Initiators and NSIS Forwarders (terminology 1364 in the framework given here). The NSIS Initiator could be located at 1365 the End Host (triggered by applications), the GGSN/PDSN, or at a 1366 node not directly on the data path, such as a bandwidth broker. In 1367 the second case, the GGSN/PDSN could either be acting as a proxy on 1368 behalf of an End Host with little capabilities, and/or managing 1369 aggregate resources within its QoS domain (the UMTS core network). 1370 The IP signaling messages are interpreted by the NSIS Forwarders, 1371 which may be located at the GGSN/PDSN, and in any QoS sub-domains 1372 within the cellular system. 1374 3) Initiation of IP-level QoS negotiation. IP-level QoS re- 1375 negotiation may be initiated by either the End Host, or by the 1376 network, based on current network loads, which might change 1377 depending on the location of the end host. 1379 4) The networks are designed and mainly used for speech 1380 communication (at least so far). 1382 Note that in comparison to the previous scenario emphasis is much 1383 less on the mobility aspects, because mobility is mainly handled on 1384 the lower layer. 1386 10.3 UMTS access 1388 The UMTS access scenario is shown in figure 3. The Proxy-Call State 1389 Control Function/Policy Control Function (P-CSCF/PCF) is the 1390 outbound SIP proxy of the visited domain, i.e. the domain where the 1391 mobile user wants to set-up a call. The Gateway GPRS Support Node 1392 (GGSN) is the egress router of the UMTS domain and connects the UMTS 1393 access network to the Edge Router (ER) of the core IP network. The 1394 P-CSCF/PCF communicates with the GGSN via the COPS protocol. The 1395 User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal 1396 Equipment (TE), e.g. a laptop. 1398 +--------+ 1399 +----------| P-CSCF |-------> SIP signaling 1400 / +--------+ 1401 / SIP : 1402 : +--------+ NSIS +----------------+ 1403 : | PCF |---------| NSIS Forwarder | 1404 : +--------+ +----------------+ 1405 : : 1406 : : COPS 1407 : : 1408 +----+ +--------+ +----+ 1409 | UE |----------| GGSN |------| ER | 1410 +----+ +--------+ +----+ 1412 Figure 1: UMTS access scenario 1414 In this scenario the GGSN has the role of Access Gate. According to 1415 3GPP standardization, the PCF is responsible for the policy-based 1416 control of the end-user service in the UMTS access network (i.e. 1417 from UE to GGSN). In the current UMTS release R.5, the PCF is part 1418 of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF 1419 may evolve to an open standardized interface. In any case the PCF 1420 has all required QoS information for per-flow admission control in 1421 the UMTS access network (which it gets from the P-CSCF and/or GGSN). 1422 Thus the PCF would be the appropriate entity to host the 1423 functionality of NSIS Initiator, initiating the "NSIS" QoS signaling 1424 towards the core IP network. The PCF/P-CSCF has to do the mapping 1425 from codec type (derived from SIP/SDP signaling) to IP traffic 1426 descriptor. SDP extensions to explicitly signal QoS information are 1427 useful to avoid the need to store codec information in the PCF and 1428 to allow for more flexibility and accurate description of the QoS 1429 traffic parameters. The PCF also controls the GGSN to open and close 1430 the gates and to configure per-flow policers, i.e. to authorize or 1431 forbid user traffic. 1433 The NSIS Forwarder is (of course) not part of the standard UMTS 1434 architecture. However, to achieve end-to-end QoS a NSIS Forwarder is 1435 needed such that the PCF can request a QoS connection to the IP 1436 network. As in the previous example, the NSIS Forwarder could manage 1437 a set of pre-provisioned resources in the IP network, i.e. bandwidth 1438 pipes, and the NSIS Forwarder performs per-flow admission control 1439 into these pipes. In this way, a connection can be made between two 1440 UMTS access networks, and hence, end-to-end QoS can be achieved. In 1441 this case the NSIS Initiator and NSIS Forwarder are clearly two 1442 separate entities. 1443 This use case clearly illustrates the need for an "NSIS" QoS 1444 signaling protocol between NSIS Initiator and NSIS Forwarder. An 1445 important application of such a protocol may be its use in the 1446 inter-connection of UMTS networks over an IP backbone. 1448 10.4 Wired part of wireless network 1450 A wireless network, seen from a QoS domain perspective, usually 1451 consists of three parts: a wireless interface part (the "radio 1452 interface"), a wired part of the wireless network (i.e., Radio 1453 Access Network) and the backbone of the wireless network, as shown 1454 in Figure 2. Note that this figure should not be seen as an 1455 architectural overview of wireless networks but rather as showing 1456 the conceptual QoS domains in a wireless network. 1458 In this scenario, a mobile host can roam and perform a handover 1459 procedure between base stations/access routers. In this scenario the 1460 NSIS QoS protocol can be applied between a base station and the 1461 gateway (GW). In this case a GW can also be considered as a local 1462 handover anchor point. Furthermore, in this scenario the NSIS QoS 1463 protocol can also be applied either between two GWs, or between two 1464 edge routers (ER). 1466 |--| 1467 |GW| 1468 |--| |--| 1469 |MH|--- . 1470 |--| / |-------| . 1471 /--|base | |--| . 1472 |station|-|ER|... 1473 |-------| |--| . |--| back- |--| |---| |----| 1474 ..|ER|.......|ER|..|BGW|.."Internet"..|host| 1475 -- |-------| |--| . |--| bone |--| |---| |----| 1476 |--| \ |base |-|ER|... . 1477 |MH| \ |station| |--| . 1478 |--|--- |-------| . MH = mobile host 1479 |--| ER = edge router 1480 <----> |GW| GW = gateway 1481 Wireless link |--| BGW = border gateway 1482 ... = interior nodes 1483 <-------------------> 1484 Wired part of wireless network 1486 <----------------------------------------> 1487 Wireless Network 1489 Figure 2. QoS architecture of wired part of wireless network 1491 Each of these parts of the wireless network impose different issues 1492 to be solved on the QoS signaling solution being used: 1494 - Wireless interface: The solution for the air interface link 1495 has to ensure flexibility and spectrum efficient transmission 1496 of IP packets. However, this link layer QoS can be solved in 1497 the same way as any other last hop problem by allowing a 1498 host to request the proper QoS profile. 1500 - Wired part of the wireless network: This is the part of 1501 the network that is closest to the base stations/access 1502 routers. It is an IP network although some parts logically 1503 perform tunneling of the end user data. In cellular networks, 1504 the wired part of the wireless network is denoted as a 1505 radio access network. 1507 This part of the wireless network has different 1508 characteristics when compared to traditional IP networks: 1510 1. The network supports a high proportion of real-time 1511 traffic. The majority of the traffic transported in the 1512 wired part of the wireless network is speech, which is 1513 very sensitive to delays and delay variation (jitter). 1515 2. The network must support mobility. Many wireless 1516 networks are able to provide a combination of soft 1517 and hard handover procedures. When handover occurs, 1518 reservations need to be established on new paths. 1519 The establishment time has to be as short as possible 1520 since long establishment times for reservations degrade 1521 the performance of the wireless network. Moreover, 1522 for maximal utilization of the radio spectrum, frequent 1523 handover operations are required. 1525 3. These links are typically rather bandwidth-limited. 1527 4. The wired transmission in such a network contains a 1528 relatively high volume of expensive leased lines. 1529 Overprovisioning might therefore be prohibitively 1530 expensive. 1532 5. The radio base stations are spread over a wide 1533 geographical area and are in general situated a large 1534 distance from the backbone. 1536 - Backbone of the wireless network: the requirements imposed 1537 by this network are similar to the requirements imposed by 1538 other types of backbone networks. 1540 Due to these very different characteristics and requirements, often 1541 contradictory, different QoS signaling solutions might be needed in 1542 each of the three network parts. 1544 10.5 Session Mobility 1545 In this scenario, a session is moved from one end-system to another. 1546 Ongoing sessions are kept and QoS parameters need to be adapted, 1547 since it is very likely that the new device provides different 1548 capabilities. Note that it is open which entity initiates the move, 1549 which implies that the NSIS Initiator might be triggered by 1550 different entities. 1552 User mobility (i.e., a user changing the device and therefore moving 1553 the sessions to the new device) is considered to be a special case 1554 within the session mobility scenario. 1556 Note that this scenario is different from terminal mobility. Not the 1557 terminal (end-system) has moved to a different access point. Both 1558 terminals are still connected to an IP network at their original 1559 points. 1561 The issues include: 1563 1) Keeping the QoS guarantees negotiated implies that the end- 1564 point(s) of communication are changed without changing the 1565 reservations. 1567 2) The trigger of the session move might be the user or any other 1568 party involved in the session. 1570 10.6 QoS reservations/negotiation from access to core network 1572 The scenario includes the signaling between access networks and core 1573 networks in order to setup and change reservations together with 1574 potential negotiation. 1576 The issues to be solved in this scenario are different from previous 1577 ones. 1579 1) The entity of reservation is most likely an aggregate. 1581 2) The time scales of reservations might be different (long living 1582 reservations of aggregates, less often re-negotiation). 1584 3) The specification of the traffic (amount of traffic), a 1585 particular QoS is guaranteed for, needs to be changed. E.g., in case 1586 additional flows are added to the aggregate, the traffic 1587 specification of the flow needs to be added if it is not already 1588 included in the aggregates specification. 1590 4) The flow specification is more complex including network 1591 addresses and sets of different address for the source as well as 1592 for the destination of the flow. 1594 10.7 QoS reservation/negotiation over administrative boundaries 1596 Signaling between two or more core networks to provide QoS is 1597 handled in this scenario. This might also include access to core 1598 signaling over administrative boundaries. Compared to the previous 1599 one it adds the case, where the two networks are not in the same 1600 administrative domain. Basically, it is the inter-domain/inter 1601 provider signaling which is handled in here. 1603 The domain boundary is the critical issue to be resolved. Which as 1604 various flavors of issues a QoS signaling protocol has to be 1605 concerned with. 1607 1) Competing administrations: Normally, only basic information 1608 should be exchanged, if the signaling is between competing 1609 administrations. Specifically information about core network 1610 internals (e.g., topology, technology, etc.) should not be 1611 exchanged. Some information exchange about the "access points" of 1612 the core networks (which is topology information as well) may need 1613 to be exchanged, because it is needed for proper signaling. 1615 2) Additionally, as in scenario 4, signaling most likely is based on 1616 aggregates, with all the issues raise there. 1618 3) Authorization: It is critical that the NSIS Initiator is 1619 authorized to perform a QoS path setup. 1621 4) Accountability: It is important to notice that signaling might be 1622 used as an entity to charge money for, therefore the interoperation 1623 with accounting needs to be available. 1625 10.8 QoS signaling between PSTN gateways and backbone routers 1627 A PSTN gateway (i.e., host) requires information from the network 1628 regarding its ability to transport voice traffic across the network. 1629 The voice quality will suffer due to packet loss, latency and 1630 jitter. Signaling is used to identify and admit a flow for which 1631 these impairments are minimized. In addition, the disposition of 1632 the signaling request is used to allow the PSTN GW to make a call 1633 routing decision before the call is actually accepted and delivered 1634 to the final destination. 1636 PSTN gateways may handle thousands of calls simultaneously and there 1637 may be hundreds of PSTN gateways in a single provider network. These 1638 numbers are likely to increase as the size of the network increases. 1639 The point being that scalability is a major issue. 1641 There are several ways that a PSTN gateway can acquire assurances 1642 that a network can carry its traffic across the network. These 1643 include: 1645 1. Over-provisioning a high availability network. 1646 2. Handling admission control through some policy server 1647 that has a global view of the network and its resources. 1648 3. Per PSTN GW pair admission control. 1649 4. Per call admission control (where a call is defined as 1650 the 5-tuple used to carry a single RTP flow). 1652 Item 1 requires no signaling at all and is therefore outside the 1653 scope of this working group. 1655 Item 2 is really a better informed version of 1, but it is also 1656 outside the scope of this working group as it relies on a particular 1657 telephony signaling protocol rather than a packet admission control 1658 protocol. 1660 Item 3 is initially attractive, as it appears to have reasonable 1661 scaling properties, however, its scaling properties only are 1662 effective in cases where there are relatively few PSTN GWs. In the 1663 more general case were a PSTN GW reduces to a single IP phone 1664 sitting behind some access network, the opportunities for 1665 aggregation are reduced and the problem reduces to item 4. 1667 Item 4 is the most general case. However, it has the most difficult 1668 scaling problems. The objective here is to place the requirements on 1669 Item 4 such that a scalable per-flow admission control protocol or 1670 protocol suite may be developed. 1672 The case where per-flow signaling extends to individual IP end- 1673 points allows the inclusion of IP phones on cable, DSL, wireless or 1674 other access networks in this scenario. 1676 Call Scenario 1678 A PSTN GW signals end-to-end for some 5-tuple defined flow a 1679 bandwidth and QoS requirement. Note that the 5-tuple might include 1680 masking/wildcarding. The access network admits this flow according 1681 to its local policy and the specific details of the access 1682 technology. 1684 At the edge router (i.e., border node), the flow is admitted, again 1685 with an optional authentication process, possibly involving an 1686 external policy server. Note that the relationship between the PSTN 1687 GW and the policy server and the routers and the policy server is 1688 outside the scope of NSIS. The edge router then admits the flow into 1689 the core of the network, possibly using some aggregation technique. 1691 At the interior nodes, the NSIS host-to-host signaling should either 1692 be ignored or invisible as the Edge router performed the admission 1693 control decision to some aggregate. 1695 At the inter-provider router (i.e., border node), again the NSIS 1696 host-to-host signaling should either be ignored or invisible, as the 1697 Edge router has performed an admission control decision about an 1698 aggregate across a carrier network. 1700 10.9 PSTN trunking gateway 1702 One of the use cases for the NSIS signaling protocol is the scenario 1703 of interconnecting PSTN gateways with an IP network that supports 1704 QoS. 1705 Four different scenarios are considered here. 1707 1. In-band QoS signaling is used. In this case the Media Gateway 1708 (MG) will be acting as the NSIS Initiator and the Edge Router 1709 (ER) will be the NSIS Forwarder. Hence, the ER should do 1710 admission control (into pre-provisioned traffic trunks) for the 1711 individual traffic flows. This scenario is not further 1712 considered here. 1713 2. Out-of-band signaling in a single domain, the NSIS forwarder is 1714 integrated in the MGC. In this case no NSIS protocol is 1715 required. 1716 3. Out-of-band signaling in a single domain, the NSIS forwarder is 1717 a separate box. In this case NSIS signaling is used between the 1718 MGC and the NSIS Forwarder. 1719 4. Out-of-band signaling between multiple domains, the NSIS 1720 Forwarder (which may be integrated in the MGC) triggers the 1721 NSIS Forwarder of the next domain. 1723 When the out-of-band QoS signaling is used the Media Gateway 1724 Controller (MGC) will be acting as the NSIS Initiator. 1726 In the second scenario the voice provider manages a set of traffic 1727 trunks that are leased from a network provider. The MGC does the 1728 admission control in this case. Since the NSIS Forwarder acts both 1729 as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is 1730 required. This scenario is shown in figure 1. 1732 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1733 | SS7 network |---------------------| MGC |--------------| SS7 | 1734 +-------------+ +-------+-----+---------+ +-----+ 1735 : / : \ 1736 : / : \ 1737 : / +--------:----------+ \ 1738 : MEGACO / / : \ \ 1739 : / / +-----+ \ \ 1740 : / / | NMS | \ \ 1741 : / | +-----+ | \ 1742 : : | | : 1743 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1744 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1745 +--------------+ +----+ \ / +----+ 1746 \ QoS network / 1747 +-------------------+ 1749 Figure 1: PSTN trunking gateway scenario 1751 In the third scenario, the voice provider does not lease traffic 1752 trunks in the network. Another entity may lease traffic trunks and 1753 may use a NSIS Forwarder to do per-flow admission control. In this 1754 case the NSIS signaling is used between the MGC and the NSIS 1755 Forwarder, which is a separate box here. Hence, the MGC acts only as 1756 a NSIS Initiator. This scenario is depicted in figure 2. 1758 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1759 | SS7 network |---------------------| MGC |--------------| SS7 | 1760 +-------------+ +-------+-----+---------+ +-----+ 1761 : / : \ 1762 : / +-----+ \ 1763 : / | NF | \ 1764 : / +-----+ \ 1765 : / : \ 1766 : / +--------:----------+ \ 1767 : MEGACO : / : \ : 1768 : : / +-----+ \ : 1769 : : / | NMS | \ : 1770 : : | +-----+ | : 1771 : : | | : 1772 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1773 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1774 +--------------+ +----+ \ / +----+ 1775 \ QoS network / 1776 +-------------------+ 1778 Figure 2: PSTN trunking gateway scenario 1780 In the fourth scenario multiple transport domains are involved. In 1781 the originating network either the MGC may have an overview on the 1782 resources of the overlay network or a separate NSIS Forwarder will 1783 have the overview. Hence, depending on this either the MGC or the 1784 NSIS Forwarder of the originating domain will contact the NSIS 1785 Forwarder of the next domain. The MGC always acts as a NSIS 1786 Initiator and may also be acting as a NSIS Forwarder in the first 1787 domain. 1789 10.10 Application request end-to-end QoS path from the network 1791 This is actually the easiest case, nevertheless might be most often 1792 used in terms of number of users. So multimedia application requests 1793 a guaranteed service from an IP network. We assume here that the 1794 application is somehow able to specify the network service. The 1795 characteristics here are that many hosts might do it, but that the 1796 requested service is low capacity (bounded by the access line). 1797 Additionally, we assume no mobility and standard devices. 1799 QOS for Virtual Private Networks 1801 In a Virtual Private Network (VPN) a variety of tunnels might be 1802 used between its edges. These tunnels could be for example, IP-Sec, 1803 GRE, and IP-IP. One of the most significant issues in VPNs is 1804 related to how a flow is identified and what quality a flow gets. A 1805 flow identification might consist among others of the transport 1806 protocol port numbers. In an IP-Sec tunnel this will be problematic 1807 since the transport protocol information is encrypted. 1809 There are two types of L3 VPNs, distinguished by where the endpoints 1810 of the tunnels exist. The endpoints of the tunnels may either be on 1811 the customer (CPE) or the provider equipment or provider edge (PE). 1813 Virtual Private networks are also likely to request bandwidth or 1814 other type of service in addition to the premium services the PSTN 1815 GW are likely to use. 1817 Tunnel end points at the Customer premises 1819 When the endpoints are the CPE, the CPE may want to signal across 1820 the public IP network for a particular amount of bandwidth and QoS 1821 for the tunnel aggregate. Such signaling may be useful when a 1822 customer wants to vary their network cost with demand, rather than 1823 paying a flat rate. Such signaling exists between the two CPE 1824 routers. Intermediate access and edge routers perform the same exact 1825 call admission control, authentication and aggregation functions 1826 performed by the corresponding routers in the PSTN GW scenario with 1827 the exception that the endpoints are the CPE tunnel endpoints rather 1828 than PSTN GWs and the 5-tuple used to describe the RTP flow is 1829 replaced with the corresponding flow spec to uniquely identify the 1830 tunnels. Tunnels may be of any variety (e.g. IP-Sec, GRE, IP-IP). 1832 In such a scenario, NSIS would actually allow partly for customer 1833 managed VPNs, which means a customer can setup VPNs by subsequent 1834 NSIS signaling to various end-point. Plus the tunnel end-points are 1835 not necessarily bound to an application. The customer administrator 1836 might be the one triggering NSIS signaling. 1838 Tunnel end points at the provider premises 1840 In the case were the tunnel end-points exist on the provider edge, 1841 requests for bandwidth may be signaled either per flow, where a flow 1842 is defined from a customers address space, or between customer 1843 sites. 1845 In the case of per flow signaling, the PE router must map the 1846 bandwidth request to the tunnel carrying traffic to the destination 1847 specified in the flow spec. Such a tunnel is a member of an 1848 aggregate to which the flow must be admitted. In this case, the 1849 operation of admission control is very similar to the case of the 1850 PSTN GW with the additional level of indirection imposed by the VPN 1851 tunnel. Therefore, authentication, accounting and policing may be 1852 required on the PE router. 1854 In the case of per site signaling, a site would need to be 1855 identified. This may be accomplished by specifying the network 1856 serviced at that site through an IP prefix. In this case, the 1857 admission control function is performed on the aggregate to the PE 1858 router connected to the site in question. 1860 Full Copyright Statement 1862 Copyright (C) The Internet Society (2002). All Rights Reserved. 1864 This document and translations of it may be copied and furnished to 1865 others, and derivative works that comment on or otherwise explain it 1866 or assist in its implementation may be prepared, copied, published 1867 and distributed, in whole or in part, without restriction of any 1868 kind, provided that the above copyright notice and this paragraph are 1869 included on all such copies and derivative works. However, this 1870 document itself may not be modified in any way, such as by removing 1871 the copyright notice or references to the Internet Society or other 1872 Internet organizations, except as needed for the purpose of 1873 developing Internet standards in which case the procedures for 1874 copyrights defined in the Internet Standards process must be 1875 followed, or as required to translate it into languages other than 1876 English. 1878 The limited permissions granted above are perpetual and will not be 1879 revoked by the Internet Society or its successors or assigns. 1881 This document and the information contained herein is provided on an 1882 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1883 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 1884 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1885 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1886 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.