idnits 2.17.1 draft-ietf-nsis-req-09.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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2003) is 7560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RSVP-TE' is defined on line 1081, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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 August 2003 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 (2003). All Rights Reserved. 33 Abstract 35 This document defines requirements for signaling across different 36 network environments, such as across administrative and/or 37 technology domains. Signaling is mainly considered for Quality of 38 Service such as The Resource Reservation Protocol, however in recent 39 years several other applications of signaling have been defined such 40 as signaling for label distribution in Multiprotocol Label Switching 41 or signaling to middleboxes. To achieve wide applicability of the 42 requirements, the starting point is a diverse set of scenarios/use 43 cases concerning various types of networks and application 44 interactions. This document presents the assumptions before listing 45 the requirements. The requirements are grouped according to areas 46 such as architecture and design goals, signaling flows, layering, 47 performance, flexibility, security, and mobility. 49 Table of Contents 51 Status of this Memo................................................1 52 Abstract...........................................................1 53 Table of Contents..................................................2 54 1 Introduction.....................................................4 55 1.1. Keywords....................................................4 56 2 Terminology......................................................4 57 3 Problem Statement and Scope......................................5 58 4 Assumptions and Exclusions.......................................6 59 4.1 Assumptions and Non-Assumptions................................6 60 4.2 Exclusions.....................................................7 61 5 Requirements.....................................................9 62 5.1 Architecture and Design Goals..................................9 63 5.1.1 NSIS SHOULD provide availability information on request......9 64 5.1.2 NSIS MUST be designed modularly..............................9 65 5.1.3 NSIS MUST decouple protocol and information.................10 66 5.1.4 NSIS MUST support independence of signaling and network 67 control paradigm..................................................10 68 5.1.5 NSIS SHOULD be able to carry opaque objects.................10 69 5.2 Signaling Flows...............................................10 70 5.2.1 The placement of NSIS Initiator, Forwarder, and Responder 71 anywhere in the network MUST be allowed...........................10 72 5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled 73 signaling.........................................................11 74 5.2.3 Concealment of topology and technology information SHOULD be 75 possible..........................................................11 76 5.2.4 Transparent signaling through networks SHOULD be possible...11 77 5.3 Messaging.....................................................11 78 5.3.1 Explicit erasure of state MUST be possible..................11 79 5.3.2 Automatic release of state after failure MUST be possible...11 80 5.3.3 NSIS SHOULD allow for sending notifications upstream........12 81 5.3.4 Establishment and refusal to set up state MUST be notified..13 82 5.3.5 NSIS MUST allow for local information exchange..............13 83 5.4 Control Information...........................................13 84 5.4.1 Mutability information on parameters SHOULD be possible.....13 85 5.4.2 It SHOULD be possible to add and remove local domain 86 information.......................................................13 87 5.4.3 State MUST be addressed independent of flow identification..14 88 5.4.4 Modification of already established state SHOULD be seamless14 89 5.4.5 Grouping of signaling for several micro-flows MAY be provided 90 ..................................................................14 91 5.5 Performance...................................................14 92 5.5.1 Scalability.................................................15 93 5.5.2 NSIS SHOULD allow for low latency in setup..................15 94 5.5.3 NSIS MUST allow for low bandwidth consumption for the 95 signaling protocol................................................15 96 5.5.4 NSIS SHOULD allow to constrain load on devices..............16 97 5.5.5 NSIS SHOULD target the highest possible network utilization.16 98 5.6 Flexibility...................................................16 99 5.6.1 Flow aggregation............................................16 100 5.6.2 Flexibility in the placement of the NSIS Initiator/Responder16 101 5.6.3 Flexibility in the initiation of state change...............16 102 5.6.4 SHOULD support network-initiated state change...............17 103 5.6.5 Uni / bi-directional state setup............................17 104 5.7 Security......................................................17 105 5.7.1 Authentication of signaling requests........................17 106 5.7.2 Request Authorization.......................................17 107 5.7.3 Integrity protection........................................18 108 5.7.4 Replay protection...........................................18 109 5.7.5 Hop-by-hop security.........................................18 110 5.7.6 Identity confidentiality and network topology hiding........18 111 5.7.7 Denial-of-service attacks...................................18 112 5.7.8 Confidentiality of signaling messages.......................19 113 5.7.9 Ownership of state..........................................19 114 5.8 Mobility......................................................19 115 5.8.1 Allow efficient service re-establishment after handover.....19 116 5.9 Interworking with other protocols and techniques..............19 117 5.9.1 MUST interwork with IP tunneling............................19 118 5.9.2 MUST NOT constrain either to IPv4 or IPv6...................20 119 5.9.3 MUST be independent from charging model.....................20 120 5.9.4 SHOULD provide hooks for AAA protocols......................20 121 5.9.5 SHOULD work with seamless handoff protocols.................20 122 5.9.6 MUST work with traditional routing..........................20 123 5.10 Operational..................................................20 124 5.10.1 Ability to assign transport quality to signaling messages..20 125 5.10.2 Graceful fail over.........................................21 126 5.10.3 Graceful handling of NSIS entity problems..................21 127 6 Security Considerations.........................................21 128 7 References......................................................21 129 7.1 Normative References..........................................21 130 7.2 Non-Normative References......................................21 131 8 Acknowledgments.................................................21 132 9 Author's Addresses..............................................22 133 10 Appendix: Scenarios/Use cases..................................23 134 10.1 Terminal Mobility............................................23 135 10.2 Wireless Networks............................................25 136 10.3 An example scenario for 3G wireless networks.................26 137 10.4 Wired part of wireless network...............................27 138 10.5 Session Mobility.............................................29 139 10.6 QoS reservation/negotiation from access to core network......29 140 10.7 QoS reservation/negotiation over administrative boundaries...30 141 10.8 QoS signaling between PSTN gateways and backbone routers.....30 142 10.9 PSTN trunking gateway........................................32 143 10.10 An application requests end-to-end QoS path from the network34 144 10.11 QOS for Virtual Private Networks............................34 145 10.11.1 Tunnel end points at the Customer premises................34 146 10.11.2 Tunnel end points at the provider premises................35 148 1 Introduction 150 This document defines requirements for signaling across different 151 network environments. It does not list any problems of existing 152 signaling protocols such as [RSVP]. 154 In order to derive requirements for signaling it is necessary to 155 first have an idea of the scope within which they are applicable. 156 Therefore, we list use cases and scenarios where an NSIS protocol 157 could be applied. The scenarios are used to help derive requirements 158 and to test the requirements against use cases. 160 The requirements listed are independent of any application. However, 161 resource reservation and QoS related issues are used as example 162 within the text. However, QoS is not the only field where signaling 163 is used in the Internet. Signaling might also be used as a 164 communication protocol to setup and maintain the state in 165 middleboxes [RFC3234]. 167 This document does not cover requirements in relation to some 168 networking areas, in particular, interaction with host and site 169 multihoming. We leave these for future analysis. 171 1.1. Keywords 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 175 this document are to be interpreted as described in RFC 2119 176 [KEYWORDS]. 178 2 Terminology 180 We list the most often used terms in the document. However, they 181 cannot be made precise without a more complete architectural model, 182 and they are not meant to prescribe any solution in the document. 183 Where applicable, they will be defined in protocol documents. 185 NSIS Entity (NE): The function within a node, which implements an 186 NSIS protocol. In the case of path-coupled signaling, the NE will 187 always be on the data path. 189 NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may 190 interact with local state management functions in the network. It 191 also propagates NSIS signaling further through the network. 193 NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set 194 up or manipulate network state. 196 NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and 197 can optionally interact with applications as well. 199 Flow: A traffic stream (sequence of IP packets between two end 200 systems) for which a specific packet level treatment is provided. 201 The flow can be unicast (uni- or bi-directional) or multicast. For 202 multicast, a flow can diverge into multiple flows as it propagates 203 toward the receiver. For multi-sender multicast, a flow can also 204 diverge when viewed in the reverse direction (toward the senders). 206 Data Path: The route across the networks taken by a flow or 207 aggregate, i.e. which domains/subdomains it passes through and the 208 egress/ingress points for each. 210 Signaling Path: The route across the networks taken by a signaling 211 flow or aggregate, i.e. which domains/subdomains it passes through 212 and the egress/ingress points for each. 214 Path-coupled signaling: A mode of signaling where the signaling 215 messages follow a path that is tied to the data packets. Signaling 216 messages are routed only through nodes (NEs) that are in the data 217 path. 219 Path-decoupled signaling: Signaling with independent data and 220 signaling paths. Signaling messages are routed to nodes (NEs) which 221 are not assumed to be on the data path, but which are (presumably) 222 aware of it. Signaling messages will always be directly addressed to 223 the neighbor NE, and the NI/NR may have no relation at all with the 224 ultimate data sender or receiver. 226 Service: A generic something provided by one entity and consumed by 227 another. It can be constructed by allocating resources. The network 228 can provide it to users or a network node can provide it to packets. 230 3 Problem Statement and Scope 232 We provide in the following a preliminary architectural picture as a 233 basis for discussion. We will refer to it in the following 234 requirement sections. 236 Note that this model is intended not to constrain the technical 237 approach taken subsequently, simply to allow concrete phrasing of 238 requirements (e.g. requirements about placement of the NSIS 239 Initiator.) 241 Roughly, the scope of NSIS is assumed to be the interaction between 242 the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder 243 including a protocol to carry the information, and the 244 syntax/semantics of the information that is exchanged. Further 245 statements on assumptions/exclusions are given in the next Section. 247 The main elements are: 249 1. Something that starts the request for state to be set up in the 250 network, the NSIS Initiator. 252 This might be in the end system or within some other part of the 253 network. The distinguishing feature of the NSIS Initiator is that it 254 acts on triggers coming (directly or indirectly) from the higher 255 layers in the end systems. It needs to map the services requested by 256 them, and also provides feedback information to the higher layers, 257 which might be used by transport layer algorithms or adaptive 258 applications. 260 2. Something that assists in managing state further along the 261 signaling path, the NSIS Forwarder. 263 The NSIS Forwarder does not interact with higher layers, but 264 interacts with the NSIS Initiator, NSIS Responder, and possibly one 265 or more NSIS Forwarders on the signaling path, edge-to-edge or end- 266 to-end. 268 3. Something that terminates the signaling path, the NSIS Responder. 270 The NSIS responder might be in an end-system or within other 271 equipment. The distinguishing feature of the NSIS Responder is that 272 it responds to requests at the end of a signaling path. 274 4. The signaling path traverses an underlying network covering one 275 or more IP hops. The underlying network might use locally different 276 technology. For instance, QoS technology has to be provisioned 277 appropriately for the service requested. In the QoS example, an NSIS 278 Forwarder maps service-specific information to technology-related 279 QoS parameters and receives indications about success or failure in 280 response. 282 5. We can see the network at the level of domains/subdomains rather 283 than individual routers (except in the special case that the domain 284 contains one link). Domains are assumed to be administrative 285 entities. So security requirements might apply differently for the 286 signaling between the domains and within a domain. Both cases we 287 deal with in this document. 289 4 Assumptions and Exclusions 291 4.1 Assumptions and Non-Assumptions 293 1. The NSIS signaling could run end to end, end-to-edge, or edge-to- 294 edge, or network-to-network ((between providers), depending on what 295 point in the network acts as NSIS initiator, and how far towards the 296 other end of the network the signaling propagates. In general, we 297 could expect NSIS Forwarders to become more 'dense' towards the 298 edges of the network, but this is not a requirement. For example, in 299 the case of QoS, an over-provisioned domain might contain no NSIS 300 Forwarders at all (and be NSIS transparent); at the other extreme, 301 NSIS Forwarders might be placed at every router. In the latter case, 302 QoS provisioning can be carried out in a local implementation- 303 dependent way without further signaling, whereas in the case of 304 remote NSIS Forwarders, a protocol might be needed to control the 305 routers along the path. This protocol is then independent of the 306 end-to-end NSIS signaling. 308 2. We do not consider 'pure' end-to-end signaling that is not 309 interpreted anywhere within the network. Such signaling is a higher- 310 layer issue and IETF protocols such as SIP etc. can be used. 312 3. Where the signaling does cover several domains, we do not exclude 313 that different signaling protocols are used in each domain. We only 314 place requirements on the universality of the control information 315 that is being transported. (The goals here would be to allow the use 316 of signaling protocols, which are matched to the characteristics of 317 the portion of the network being traversed.) Note that the outcome 318 of NSIS work might result in various flavors of the same protocol. 320 4. We assume that the service definitions a NSIS Initiator can ask 321 for are known in advance of the signaling protocol running. For 322 instance in the QoS example, the service definition includes QoS 323 parameters, lifetime of QoS guarantee etc., or any other service- 324 specific parameters. 326 There are many ways service requesters get to know about available 327 services. There might be standardized services, the definition can 328 be negotiated together with a contract, the service definition is 329 published in some on-line directory (e.g., at a Web page), and so 330 on. 332 5. We assume that there are means for the discovery of NSIS entities 333 in order to know the signaling peers (solutions include static 334 configuration, automatically discovered, or implicitly runs over the 335 right nodes along the data path, etc.) The discovery of the NSIS 336 entities has security implications that need to be addressed 337 properly. For some security mechanisms (i.e. Kerberos, pre-shared 338 secret) it is required to know the identity of the other entity. 339 Hence the discovery mechanism may provide means to learn this 340 identity, which is then later used to retrieve the required keys and 341 parameters. 343 6. NSIS assumes layer 3 routing and the determination of next data 344 node selection is not done by NSIS. 346 4.2 Exclusions 348 1. Development of specific mechanisms and algorithms for application 349 and transport layer adaptation are not considered, nor are the 350 protocols that would support it. 352 2. Specific mechanisms (APIs and so on) for interaction between 353 transport/applications and the network layer are not considered, 354 except to clarify the requirements on the negotiation capabilities 355 and information semantics that would be needed of the signaling 356 protocol. 358 3. Specific mechanisms and protocols for provisioning or other 359 network control functions within a domain/subdomain are not 360 considered. The goal is to reuse existing functions and protocols 361 unchanged. However, NSIS itself can be used for signaling within a 362 domain/subdomain. 364 For instance in the QoS example, it means that the setting of QoS 365 mechanisms in a domain is out of scope, but if we have a tunnel, 366 NSIS could also be used for tunnel setup with QoS guarantees. It 367 should be possible to exploit these mechanisms optimally within the 368 end-to-end context. Consideration of how to do this might generate 369 new requirements for NSIS however. For example, the information 370 needed by a NSIS Forwarder to manage a radio subnetwork needs to be 371 provided by the NSIS solution. 373 4. Specific mechanisms (APIs and so on) for interaction between the 374 network layer and underlying provisioning mechanisms are not 375 considered. 377 5. Interaction with resource management or other internal state 378 management capabilities is not considered. Standard protocols might 379 be used for this. This may imply requirements for the sort of 380 information that should be exchanged between the NSIS entities. 382 6. Security implications related to multicasting are outside the 383 scope of the signaling protocol. 385 7. Service definitions and in particular QoS services and classes 386 are out of scope. Together with the service definition any 387 definition of service specific parameters are not considered in this 388 document. Only the base NSIS signaling protocol for transporting the 389 service information are addressed. 391 8. Similarly, specific methods, protocols, and ways to express 392 service information in the Application/Session level are not 393 considered (e.g., SDP, SIP, RTSP, etc.). 395 9. The specification of any extensions needed to signal information 396 via application level protocols (e.g. SDP), and the mapping on NSIS 397 information are considered outside of the scope of NSIS working 398 group, as this work is in the direct scope of other IETF working 399 groups (e.g. MMUSIC). 401 10. Handoff decision and trigger sources: An NSIS protocol is not 402 used to trigger handoffs in mobile IP, nor is it used to decide 403 whether to handoff or not. As soon as or in some situation even 404 before a handoff happened, an NSIS protocol might be used for 405 signaling for the particular service again. The basic underlying 406 assumption is that the route comes first (defining the path) and the 407 signaling comes after it (following the path). This doesn't prevent 408 a signaling application at some node interacting with something that 409 modifies the path, but the requirement is then just for NSIS to live 410 with that possibility. However, NSIS must interwork with several 411 protocols for mobility management. 413 11. Service monitoring is out of scope. It is heavily dependent on 414 the type of the application and or transport service, and in what 415 scenario it is used. 417 5 Requirements 419 This section defines more detailed requirements for a signaling 420 solution, respecting the framework, scoping assumptions, and 421 terminology considered earlier. The requirements are in subsections, 422 grouped roughly according to general technical aspects: architecture 423 and design goals, topology issues, parameters, performance, 424 security, information, and flexibility. 426 Two general (and potentially contradictory) goals for the solution 427 are that it should be applicable in a very wide range of scenarios, 428 and at the same time lightweight in implementation complexity and 429 resource consumption requirements in NSIS Entities. We use the terms 430 'access' and 'core' informally in the discussion of some particular 431 requirements to refer to deployment conditions where particular 432 protocol attributes, especially performance characteristics, have 433 special importance. Specifically, 'access' refers to lower capacity 434 networks and fewer users and sessions. 'Core' refers to high 435 capacity networks with a large number of users and sessions. 437 One approach to this is that the solution could deal with certain 438 requirements via modular components or capabilities, which are 439 optional to implement or use in individual nodes. 441 5.1 Architecture and Design Goals 443 This section contains requirements related to desirable overall 444 characteristics of a solution, e.g. enabling flexibility, or 445 independence of parts of the framework. 447 5.1.1 NSIS SHOULD provide availability information on request 449 NSIS SHOULD provide a mechanism to check whether state to be setup 450 is available without setting it up. For the resource reservation 451 example this translates into checking resource availability without 452 performing resource reservation. In some scenarios, e.g., the mobile 453 terminal scenario, it is required to query, whether resources are 454 available, without performing a reservation on the resource. 456 5.1.2 NSIS MUST be designed modularly 458 A modular design allows for more lightweight implementations, if 459 fewer features are needed. Mutually exclusive solutions are 460 supported. Examples for modularity: 462 - Work over any kind of network (narrowband versus broadband, error- 463 prone versus reliable, ...). This implies low bandwidth signaling, 464 and elimination of redundant information MUST be supported if 465 necessary. 467 - State setup for uni- and bi-directional flows is possible 469 - Extensible in the future with different add-ons for certain 470 environments or scenarios 472 - Protocol layering, where appropriate. This means NSIS MUST provide 473 a base protocol, which can be adapted to different environments. 475 5.1.3 NSIS MUST decouple protocol and information 477 The signaling protocol MUST be clearly separated from the control 478 information being transported. This provides for the independent 479 development of these two aspects of the solution, and allows for 480 this control information to be carried within other protocols, 481 including application layer ones, existing ones or those being 482 developed in the future. The flexibility gained in the transport of 483 information allows for the applicability of the same protocol in 484 various scenarios. 486 However, note that the information carried needs to be standardized; 487 otherwise interoperability is difficult to achieve. 489 5.1.4 NSIS MUST support independence of signaling and network control 490 paradigm 492 The signaling MUST be independent of the paradigm and mechanism of 493 network control. E.g., in the case of signaling for QoS, the 494 independence of the signaling protocol from the QoS provisioning 495 allows for using the NSIS protocol together with various QoS 496 technologies in various scenarios. 498 5.1.5 NSIS SHOULD be able to carry opaque objects 500 NSIS SHOULD be able to pass around opaque objects, which are 501 interpreted only by some NSIS-capable nodes. 503 5.2 Signaling Flows 505 This section contains requirements related to the possible signaling 506 flows that should be supported, e.g. over what parts of the flow 507 path, between what entities (end-systems, routers, middle boxes, 508 management systems), in which direction. 510 5.2.1 The placement of NSIS Initiator, Forwarder, and Responder 511 anywhere in the network MUST be allowed 513 The protocol MUST work in various scenarios such as host-to-network- 514 to-host, edge-to-edge, (e.g., just within one provider's domain), 515 user-to-network (from end system into the network, ending, e.g., at 516 the entry to the network and vice versa), and network-to-network 517 (e.g., between providers). 519 Placing the NSIS Forwarder and NSIS Initiator functions at different 520 locations allows for various scenarios to work with the same 521 protocol. 523 5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled 524 signaling. 526 The path-coupled signaling mode MUST be supported. NSIS signaling 527 messages are routed only through nodes (NEs) that are in the data 528 path. 530 However, there is a set of scenarios, where signaling is not on the 531 data path. Therefore, NSIS MAY support the path-decoupled signaling 532 mode, where signaling messages are routed to nodes (NEs), which are 533 not assumed to be on the data path, but which are aware of it. 535 5.2.3 Concealment of topology and technology information SHOULD be 536 possible 538 The NSIS protocol SHOULD allow for hiding the internal structure of 539 a NSIS domain from end-nodes and from other networks. Hence an 540 adversary should not be able to learn the internal structure of a 541 network with the help of the signaling protocol. 543 In various scenarios, topology information should be hidden for 544 various reasons. From a business point of view, some administrations 545 don't want to reveal the topology and technology used. 547 5.2.4 Transparent signaling through networks SHOULD be possible 549 It SHOULD be possible that the signaling for some flows traverses 550 path segments transparently, i.e., without interpretation at NSIS 551 Forwarders within the network. An example would be a subdomain 552 within a core network, which only interpreted signaling for 553 aggregates established at the domain edge, with the signaling for 554 individual flows passing transparently through it. 556 In other words, NSIS SHOULD work in hierarchical scenarios, where 557 big pipes/trunks are setup using NSIS signaling, but also flows 558 which run within that big pipe/trunk are setup using NSIS. 560 5.3 Messaging 562 5.3.1 Explicit erasure of state MUST be possible 564 When state along a path is no longer necessary, e.g., because the 565 application terminates, or because a mobile host experienced a hand- 566 off, it MUST be possible to erase the state explicitly. 568 5.3.2 Automatic release of state after failure MUST be possible 569 When the NSIS Initiator goes down, the state it requested in the 570 network SHOULD be released, since it will most likely no longer be 571 necessary. 573 After detection of a failure in the network, any NSIS 574 Forwarder/Initiator MUST be able to release state it is involved in. 575 For example, this may require signaling of the "Release after 576 Failure" message upstream as well as downstream, or soft state 577 timing out. 579 The goal is to prevent stale state within the network and adds 580 robustness to the operation of NSIS. So in other words, an NSIS 581 signaling protocol or mechanisms MUST provide means for an NSIS 582 entity to discover and remove local stale state. 584 Note that this might need to work together with a notification 585 mechanism. Note as well, that transient failures in NSIS processing 586 shouldn't necessarily have to cause all state to be released 587 immediately. 589 5.3.3 NSIS SHOULD allow for sending notifications upstream 591 NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS 592 Forwarder upstream, if there is a state change inside the network. 593 There are various types of network changes for instance among them: 595 Recoverable errors: the network nodes can locally repair this type 596 error. The network nodes do not have to notify the users of the 597 error immediately. This is a condition when the danger of 598 degradation (or actual short term degradation) of the provided 599 service was overcome by the network (NSIS Forwarder) itself. 601 Unrecoverable errors: the network nodes cannot handle this type of 602 error, and have to notify the users as soon as possible. 604 Service degradation: In case the service cannot be provided 605 completely but only partially. 607 Repair indication: If an error occurred and it has been fixed, this 608 triggers the sending of a notification. 610 Service upgrade available: If a previously requested better service 611 becomes available. 613 The content of the notification is very service specific, but it is 614 must at least carry type information. Additionally, it may carry the 615 location of the state change. 617 The notifications may or may not be in response to a NSIS message. 618 This means an NSIS entity has to be able to handle notifications at 619 any time. 621 Note however, that there are a number of security consideration 622 needs to be solved with notification, even more important if the 623 notification is sent without prior request (asynchronously). The 624 problem basically is, that everybody could send notifications to any 625 NSIS entity and the NSIS entity most likely reacts on the 626 notification. For example, if it gets an error notification it might 627 erase state, even if everything is ok. So the notification might 628 depend on security associations between the sender of the 629 notification and its receiver. If a hop-by-hop security mechanism is 630 chosen, this implies also that notifications need to be sent on the 631 reverse path. 633 5.3.4 Establishment and refusal to set up state MUST be notified. 635 An NR MUST acknowledge establishment of state on behalf of the NI 636 requesting establishment of that state. A refusal to set up state 637 MUST be replied with a negative acknowledgement by the NE refusing 638 to set up state. It MUST be sent to the NI. Depending on the 639 signaling application the (positive or negative) notifications may 640 have to pass through further NEs upstream. Information on the reason 641 of the refusal to set up state MAY be made available. For example, 642 in the resource reservation example, together with a negative 643 answer, the amount of resources available might also be returned. 645 5.3.5 NSIS MUST allow for local information exchange 647 The signaling protocol MUST be able to exchange local information 648 between NSIS Forwarders located within one single administrative 649 domain. The local information exchange is performed by a number of 650 separate messages not belonging to an end-to-end signaling process. 651 Local information might, for example, be IP addresses , notification 652 of successful or erroneous processing of signaling messages, or 653 other conditions. 655 In some cases, the NSIS signaling protocol MAY carry identification 656 of the NSIS Forwarders located at the boundaries of a domain. 657 However, the identification of edge should not be visible to the end 658 host (NSIS Initiator) and only applies within one administrative 659 domain. 661 5.4 Control Information 663 This section contains requirements related to the control 664 information that needs to be exchanged. 666 5.4.1 Mutability information on parameters SHOULD be possible 668 It is possible that nodes modify parameters of a signaling message. 669 However, it SHOULD be possible for the NSIS Initiator to control the 670 mutability of the signaled information. For example, the NSIS 671 Initiator should be able to control what is requested end to end, 672 without the request being gradually mutated as it passes through a 673 sequence of nodes. 675 5.4.2 It SHOULD be possible to add and remove local domain information 676 It SHOULD be possible to add and remove local scope elements. 677 Compared to Requirement 5.3.5 this requirement does use the normal 678 signaling process and message exchange for transporting local 679 information. For example, at the entrance to a domain domain- 680 specific information is added, which is used in this domain only, 681 and the information is removed again when a signaling message leaves 682 the domain. The motivation is in the economy of re-using the 683 protocol for domain internal signaling of various information 684 pieces. Where additional information is needed within a particular 685 domain, it should be possible to carry this at the same time as the 686 end-to-end information. 688 5.4.3 State MUST be addressed independent of flow identification 690 Addressing or identifying state MUST be independent of the flow 691 identifier (flow end-points, topological addresses). Various 692 scenarios in the mobility area require this independence because 693 flows resulting from handoff might have changed end-points etc. but 694 still have the same service requirement. Also several proxy-based 695 signaling methods profit from such independence, though these are 696 not chartered work items for NSIS. 698 5.4.4 Modification of already established state SHOULD be seamless 700 In many case, the established state needs to be updated (in QoS 701 example upgrade or downgrade of resource usage). This SHOULD happen 702 seamlessly without service interruption. At least the signaling 703 protocol should allow for it, even if some data path elements might 704 not be capable of doing so. 706 5.4.5 Grouping of signaling for several micro-flows MAY be provided 708 NSIS MAY group signaling information for several micro-flow into one 709 signaling message. The goal of this is the optimization in terms of 710 setup delay, which can happen in parallel. This helps applications 711 requesting several flows at once. Also potential refreshes (in case 712 of a soft state solution) might profit from grouping. 714 However, the network needs not know that a relationship between the 715 grouped flows exists. There MUST NOT be any transactional semantic 716 associated with the grouping. It is only meant for optimization 717 purposes. 719 5.5 Performance 721 This section discusses performance requirements and evaluation 722 criteria and the way in which these could and should be traded off 723 against each other in various parts of the solution. 725 Scalability is always an important requirement for signaling 726 protocols. However, the type of scalability and its importance 727 varies from one scenario to another. 729 Note that many of the performance issues are heavily dependent on 730 the scenario assumed and are normally a trade-off between speed, 731 reliability, complexity, and scalability. The trade-off varies in 732 different parts of the network. For example, in radio access 733 networks low bandwidth consumption will outweigh the low latency 734 requirement, while in core networks it may be reverse. 736 5.5.1 Scalability 738 NSIS MUST be scalable in the number of messages received by a 739 signaling communication partner (NSIS Initiator, NSIS Forwarder, and 740 NSIS Responder). The major concern lies in the core of the network, 741 where large numbers of messages arrive. 743 It MUST be scalable in number of hand-offs in mobile environments. 744 This mainly applies in access networks, because the core is 745 transparent to mobility in most cases. 747 It MUST be scalable in the number of interactions for setting up a 748 state. This applies for end-systems setting up several states. Some 749 servers might be expected to setup a large number of states. 751 Scalability in the amount of state per entity MUST be achieved for 752 NSIS Forwarders in the core of the network. 754 Scalability in CPU usage MUST be achieved on end terminals and 755 intermediate nodes in case of many state setup processes at the same 756 time. 758 Specifically, NSIS MUST work in Internet scale deployments, where 759 the use of signaling by hosts becomes universal. Note that 760 requirement 5.2.4 requires the functionality of transparently 761 signaling through networks without interpretation. Additionally, 762 requirement 5.6.1 lists the capability to aggregate. Furthermore, 763 requirement 5.5.4 states that NSIS should be able to constrain the 764 load on devices. Basically, the performance of the signaling MUST 765 degrade gracefully rather than catastrophically under overload 766 conditions. 768 5.5.2 NSIS SHOULD allow for low latency in setup 770 NSIS SHOULD allow for low latency setup of states. This is only 771 needed in scenarios, where state setups are required on a short time 772 scale (e.g. handover in mobile environments), or where human 773 interaction is immediately concerned (e.g., voice communication 774 setup delay). 776 5.5.3 NSIS MUST allow for low bandwidth consumption for the signaling 777 protocol 779 NSIS MUST allow for low bandwidth consumption in certain access 780 networks. Again only small sets of scenarios call for low bandwidth, 781 mainly those where wireless links are involved. 783 5.5.4 NSIS SHOULD allow to constrain load on devices 785 The NSIS architecture SHOULD give the ability to constrain the load 786 (CPU load, memory space, signaling bandwidth consumption and 787 signaling intensity) on devices where it is needed. One of the 788 reasons is that the protocol handling should have a minimal impact 789 on interior (core) nodes. 791 This can be achieved by many different methods. Examples include 792 message aggregation, header compression, minimizing functionality, 793 or ignoring signaling in core nodes. The framework may choose any 794 method as long as the requirement is met. 796 5.5.5 NSIS SHOULD target the highest possible network utilization 798 This requirement applies specifically to QoS signaling. 800 There are networking environments that require high network 801 utilization for various reasons, and the signaling protocol SHOULD 802 to its best ability support high resource utilization while 803 maintaining appropriate service quality. 805 In networks where resources are very expensive (as is the case for 806 many wireless networks), efficient network utilization for signaling 807 traffic is of critical financial importance. On the other hand 808 there are other parts of the network where high utilization is not 809 required. 811 5.6 Flexibility 813 This section lists the various ways the protocol can flexibly be 814 employed. 816 5.6.1 Flow aggregation 818 NSIS MUST allow for flow aggregation, including the capability to 819 select and change the level of aggregation. 821 5.6.2 Flexibility in the placement of the NSIS Initiator/Responder 823 NSIS MUST be flexible in placing an NSIS Initiator and NSIS 824 Responder. The NSIS Initiator might be located at the sending or the 825 receiving side of a data stream, and the NSIS Responder naturally on 826 the other side. 828 Also network-initiated signaling and termination MUST be allowed in 829 various scenarios such as PSTN gateways, some VPNs, and mobility. 830 This means the NSIS Initiator and NSIS Responder might not be at the 831 end points of the data stream. 833 5.6.3 Flexibility in the initiation of state change 834 The NSIS Initiator or the NSIS Responder SHOULD be able to initiate 835 a change of state. In the example of resource reservation this is 836 often referred to as resource re-negotiation. It can happen due to 837 various reasons, such as local resource shortage (CPU, memory on 838 end-system) or a user changed application preference/profiles. 840 5.6.4 SHOULD support network-initiated state change 842 NSIS SHOULD support network-initiated state change. In the QoS 843 example, this is used in cases, where the network is not able to 844 further guarantee resources and wants to e.g. downgrade a resource 845 reservation. 847 5.6.5 Uni / bi-directional state setup 849 Both unidirectional as well as bi-direction state setup SHOULD be 850 possible. With bi-directional state setup we mean that the state for 851 bi-directional data flows is setup. The bi-directional data flows 852 have the same end-points, but the path in the two directions does 853 not need to be the same. 855 The goal of a bi-directional state setup is mainly an optimization 856 in terms of setup delay. There is no requirements on constrains such 857 as use of the same data path etc. 859 5.7 Security 861 This section discusses security-related requirements. The NSIS 862 protocol MUST provide means for security, but it MUST be allowed 863 that nodes implementing NSIS signaling do not need use the security 864 means. 866 5.7.1 Authentication of signaling requests 868 A signaling protocol MUST make provision for enabling various 869 entities to be authenticated against each other using strong 870 authentication mechanisms. The term strong authentication points to 871 the fact that weak plain-text password mechanisms must not be used 872 for authentication. 874 5.7.2 Request Authorization 876 The signaling protocol MUST provide means to authorize state setup 877 requests. This requirement demands a hook to interact with a policy 878 entity to request authorization data. This allows an authenticated 879 entity to be associated with authorization data and to verify the 880 request. Authorization prevents state setup by unauthorized entities, 881 setups violating policies, and theft of service. Additionally it 882 limits denial of service attacks against parts of the network or the 883 entire network caused by unrestricted state setups. Additionally it 884 might be helpful to provide some means to inform other protocols of 885 participating nodes within the same administrative domain about a 886 previous successful authorization event. 888 5.7.3 Integrity protection 890 The signaling protocol MUST provide means to protect the message 891 payloads against modifications. Integrity protection prevents an 892 adversary from modifying parts of the signaling message and from 893 mounting denial of service or theft of service type of attacks 894 against network elements participating in the protocol execution. 896 5.7.4 Replay protection 898 To prevent replay of previous signaling messages the signaling 899 protocol MUST provide means to detect old i.e. already transmitted 900 signaling messages. A solution must cover issues of synchronization 901 problems in the case of a restart or a crash of a participating 902 network element. 904 5.7.5 Hop-by-hop security 906 Channel security between signaling entities MUST be implemented. It is 907 a well known and proven concept in Quality-of-Service and other 908 signaling protocols that allows intermediate nodes that actively 909 participate in the protocol to modify the messages as it is required 910 by processing rules. Note that this requirement does not exclude end- 911 to-end or network-to-network security of a signaling message. End-to- 912 end security between the NSIS Initiator and the NSIS Responder may be 913 used to provide protection of non-mutable data fields. Network-to- 914 network security refers to the protection of messages over various 915 hops but not in an end-to-end manner i.e. protected over a particular 916 network. 918 5.7.6 Identity confidentiality and network topology hiding 920 Identity confidentiality SHOULD be supported. It enables privacy and 921 avoids profiling of entities by adversary eavesdropping the signaling 922 traffic along the path. The identity used in the process of 923 authentication may also be hidden to a limited extent from a network 924 to which the initiator is attached. However the identity MUST provide 925 enough information for the nodes in the access network to collect 926 accounting data. 928 Network topology hiding MAY be supported to prevent entities along 929 the path to learn the topology of a network. Supporting this property 930 might conflict with a diagnostic capability. 932 5.7.7 Denial-of-service attacks 934 A signaling protocol SHOULD provide prevention of Denial-of-service 935 attacks. To effectively prevent denial-of-service attacks it is 936 necessary that the used security and protocol mechanisms MUST have 937 low computational complexity to verify a state setup request prior to 938 authenticating the requesting entity. Additionally the signaling 939 protocol and the used security mechanisms SHOULD NOT require large 940 resource consumption on NSIS Entities (for example main memory or 941 other additional message exchanges) before a successful 942 authentication is done. 944 5.7.8 Confidentiality of signaling messages 946 Based on the signaling information exchanged between nodes 947 participating in the signaling protocol an adversary may learn both 948 the identities and the content of the signaling messages. Since the 949 ability to listen to signaling channels is a major guide to what 950 data channels are interesting ones. 952 To prevent this from happening, confidentiality of the signaling 953 message in a hop-by-hop manner SHOULD be provided. Note that most 954 messages must be protected on a hop-by-hop basis, since entities, 955 which actively participate in the signaling protocol, must be able 956 to read and eventually modify the signaling messages. 958 5.7.9 Ownership of state 960 When existing states have to be modified then there is a need to use 961 a session identifier to uniquely identify the established state. A 962 signaling protocol MUST provide means of security protection to 963 prevent adversaries from modifying state. 965 5.8 Mobility 967 5.8.1 Allow efficient service re-establishment after handover 969 Handover is an essential function in wireless networks. After 970 handover, the states may need to be completely or partially re- 971 established due to route changes. The re-establishment may be 972 requested by the mobile node itself or triggered by the access point 973 that the mobile node is attached to. In the first case, the 974 signaling MUST allow efficient re-establishment after handover. Re- 975 establishment after handover MUST be as quick as possible so that 976 the mobile node does not experience service interruption or service 977 degradation. The re-establishment SHOULD be localized, and not 978 require end-to-end signaling. 980 5.9 Interworking with other protocols and techniques 982 Hooks SHOULD be provided to enable efficient interworking between 983 various protocols and techniques including the following listed. 985 5.9.1 MUST interwork with IP tunneling 987 IP tunneling for various applications MUST be supported. More 988 specifically IPSec tunnels are of importance. This mainly impacts 989 the identification of flows. When using IPSec, parts of information 990 commonly used for flow identification (e.g. transport protocol 991 information and ports) may not be accessible due to encryption. 993 5.9.2 MUST NOT constrain either to IPv4 or IPv6 995 5.9.3 MUST be independent from charging model 997 Signaling MUST NOT be constrained by charging models or the charging 998 infrastructure used. 1000 5.9.4 SHOULD provide hooks for AAA protocols 1002 The NSIS SHOULD be developed with respect to be able to collect 1003 usage records from one or more network elements. 1005 5.9.5 SHOULD work with seamless handoff protocols 1007 An NSIS protocol SHOULD work with seamless handoff protocols such as 1008 context transfer and candidate access router (CAR) discovery. 1010 5.9.6 MUST work with traditional routing 1012 NSIS assumes traditional L3 routing, which is purely based on L3 1013 destination addresses. NSIS MUST work with L3 routing, in particular 1014 it MUST work in case of route changes. This means state on the old 1015 route MUST be released and state on the new route MUST be 1016 established by an NSIS protocol. 1018 Networks, which do non-traditional routing, should not break NSIS 1019 signaling. NSIS MAY work for some of these situations. Particularly, 1020 combinations of NSIS unaware nodes and routing other then 1021 traditional one causes some problems. Non-traditional routing 1022 includes for example routing decisions based on port numbers, other 1023 IP header fields than the destination address, or splitting traffic 1024 based on header hash values. These routing environments result in 1025 the signaling path being potentially different than the data path. 1027 5.10 Operational 1029 5.10.1 Ability to assign transport quality to signaling messages. 1031 The NSIS architecture SHOULD allow the network operator to assign 1032 the NSIS protocol messages a certain transport quality. As signaling 1033 opens up for possible denial-of-service attacks, this requirement 1034 gives the network operator a means, but also the obligation, to 1035 trade-off between signaling latency and the impact (from the 1036 signaling messages) on devices within the network. From protocol 1037 design this requirement states that the protocol messages SHOULD be 1038 detectable, at least where the control and assignment of the 1039 messages priority is done. 1041 Furthermore, the protocol design must take into account reliability 1042 concerns. Communication reliability is seen as part of the quality 1043 assigned to signaling messages. So procedures MUST be defined how an 1044 NSIS signaling system behaves if some kind of request it sent stays 1045 unanswered. The basic transport protocol to be used between adjacent 1046 NSIS Entities MAY ensure message integrity and reliable transport. 1048 5.10.2 Graceful fail over 1050 Any unit participating in NSIS signaling MUST NOT cause further 1051 damage to other systems involved in NSIS signaling when it has to go 1052 out of service. 1054 5.10.3 Graceful handling of NSIS entity problems 1056 NSIS entities SHOULD be able to detect a malfunctioning peer. It may 1057 notify the NSIS Initiator or another NSIS entity involved in the 1058 signaling process. The NSIS peer may handle the problem itself e.g. 1059 switching to a backup NSIS entity. In the latter case note that 1060 synchronization of state between the primary and the backup entity 1061 is needed. 1063 6 Security Considerations 1065 Section 5.7 of this document provides security related requirements 1066 of a signaling protocol. 1068 7 References 1070 7.1 Normative References 1072 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1073 Requirement Levels", BCP 14, RFC 2119, March 1997. 1075 7.2 Non-Normative References 1077 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1078 "Resource Protocol (RSVP) -- Version 1 Functional Specification", 1079 RFC 2205, September 1997. 1081 [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. 1082 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 1083 December 2001. 1085 [RFC3234] B. Carpenter, S. Brim, "Middleboxes: Taxonomy and Issues", 1086 RFC 3234, February 2002. 1088 [PPVPN_FW] R. Callon, M. Suzuki, "A Framework for Layer 3 Provider 1089 Provisioned Virtual Private Networks", , March 2003 1092 8 Acknowledgments 1094 Quite a number of people have been involved in the discussion of the 1095 document, adding some ideas, requirements, etc. We list them without 1096 a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul 1097 (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas 1098 Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), 1099 Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 1100 University Berlin), Xiaoming Fu (Technical University Berlin), Hans- 1101 Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph 1102 Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya 1103 Freytsis. 1105 Some text and/or ideas for text, requirements, scenarios have been 1106 taken from an Internet Draft written by the following authors: David 1107 Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis 1108 (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University 1109 of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 1110 Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have 1111 actively contributed new text to this document as well. 1113 Another Internet Draft impacting this document has been written by 1114 Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel). 1115 These people contributed also new text. 1117 Thanks also to Kwok Ho Chan (Nortel) for text changes. And finally 1118 thanks Alison Mankin for the thorough AD review and thanks to Harald 1119 Tveit Alvestrand and Steve Bellovin for the IESG review comments. 1121 9 Author's Addresses 1123 Marcus Brunner (Editor) 1124 NEC Europe Ltd. 1125 Network Laboratories 1126 Kurfuersten-Anlage 36 1127 D-69115 Heidelberg 1128 Germany 1129 E-Mail: brunner@ccrle.nec.de 1131 Robert Hancock 1132 Roke Manor Research Ltd 1133 Romsey, Hants, SO51 0ZN 1134 United Kingdom 1135 E-Mail: robert.hancock@roke.co.uk 1137 Eleanor Hepworth 1138 Roke Manor Research Ltd 1139 Romsey, Hants, SO51 0ZN 1140 United Kingdom 1141 E-Mail: eleanor.hepworth@roke.co.uk 1143 Cornelia Kappler 1144 Siemens AG 1145 Berlin 13623 1146 Germany 1147 E-Mail: cornelia.kappler@icn.siemens.de 1149 Hannes Tschofenig 1150 Siemens AG 1151 Otto-Hahn-Ring 6 1152 81739 Munchen 1153 Germany 1154 Email: Hannes.Tschofenig@mchp.siemens.de 1156 10 Appendix: Scenarios/Use cases 1158 In the following we describe scenarios, which are important to 1159 cover, and which allow us to discuss various requirements. Some 1160 regard this as use cases to be covered defining the use of a 1161 signaling protocol. In general, these scenarios consider the 1162 specific case of signaling for QoS (resource reservation), although 1163 many of the issues carry over directly to other signaling types. 1165 10.1 Terminal Mobility 1167 The scenario we are looking at is the case where a mobile terminal 1168 (MT) changes from one access point to another access point. The 1169 access points are located in separate QoS domains. We assume Mobile 1170 IP to handle mobility on the network layer in this scenario and 1171 consider the various extensions (i.e., IETF proposals) to Mobile IP, 1172 in order to provide 'fast handover' for roaming Mobile Terminals. 1173 The goal to be achieved lies in providing, keeping, and adapting the 1174 requested QoS for the ongoing IP sessions in case of handover. 1175 Furthermore, the negotiation of QoS parameters with the new domain 1176 via the old connection might be needed, in order to support the 1177 different 'fast handover' proposals within the IETF. 1179 The entities involved in this scenario include a mobile terminal, 1180 access points, an access network manager, and communication partners 1181 of the MT (the other end(s) of the communication association). 1182 From a technical point of view, terminal mobility means changing the 1183 access point of a mobile terminal (MT). However, technologies might 1184 change in various directions (access technology, QoS technology, 1185 administrative domain). If the access points are within one specific 1186 QoS technology (independent of access technology) we call this 1187 intra-QoS technology handoff. In the case of an inter-QoS technology 1188 handoff, one change from e.g. a DiffServ to an IntServ domain, 1189 however still using the same access technology. Finally, if the 1190 access points are using different access technologies we call it 1191 inter-technology hand-off. 1193 The following issues are of special importance in this scenario: 1195 1) Handoff decision 1197 - The QoS management requests handoff. The QoS management can decide 1198 to change the access point, since the traffic conditions of the new 1199 access point are better supporting the QoS requirements. The metric 1200 may be different (optimized towards a single or a group/class of 1201 users). Note that the MT or the network (see below) might trigger 1202 the handoff. 1204 - The mobility management forces handoff. This can have several 1205 reasons. The operator optimizes his network, admission is no longer 1206 granted (e.g. emptied prepaid condition). Or another example is when 1207 the MT is reaching the focus of another base station. However, this 1208 might be detected via measurements of QoS on the physical layer and 1209 is therefore out of scope of QoS signaling in IP. Note again that 1210 the MT or the network (see below) might trigger the handoff. 1212 - This scenario shows that local decisions might not be enough. The 1213 rest of the path to the other end of the communication needs to be 1214 considered as well. Hand-off decisions in a QoS domain do not only 1215 depend on the local resource availability, e.g., the wireless part, 1216 but involve the rest of the path as well. Additionally, 1217 decomposition of an end-to-end signaling might be needed, in order 1218 to change only parts of it. 1220 2) Trigger sources 1222 - Mobile terminal: If the end-system QoS management identifies 1223 another (better-suited) access point, it will request the handoff 1224 from the terminal itself. This will be especially likely in the case 1225 that two different provider networks are involved. Another important 1226 example is when the current access point bearer disappears (e.g. 1227 removing the Ethernet cable). In this case, the NSIS Initiator is 1228 basically located on the mobile terminal. 1230 - Network (access network manager): Sometimes, the handoff trigger 1231 will be issued from the network management to optimize the overall 1232 load situation. Most likely this will result in changing the base- 1233 station of a single providers network. Most likely the NSIS 1234 Initiator is located on a system within the network. 1236 3) Integration with other protocols 1238 - Interworking with other protocol must be considered in one or the 1239 other form. E.g., it might be worth combining QoS signaling between 1240 different QoS domains with mobility signaling at hand-over. 1242 4) Handover rates 1244 In mobile networks, the admission control process has to cope with 1245 far more admission requests than call setups alone would generate. 1246 For example, in the GSM (Global System for Mobile communications) 1247 case, mobility usually generates an average of one to two handovers 1248 per call. For third generation networks (such as UMTS), where it is 1249 necessary to keep radio links to several cells simultaneously 1250 (macro-diversity), the handover rate is significantly higher. 1252 5) Fast state installation 1254 Handover can also cause packet losses. This happens when the 1255 processing of an admission request causes a delayed handover to the 1256 new base station. In this situation, some packets might be 1257 discarded, and the overall speech quality might be degraded 1258 significantly. Moreover, a delay in handover may cause degradation 1259 for other users. In the worst-case scenario, a delay in handover may 1260 cause the connection to be dropped if the handover occurred due to 1261 bad air link quality. Therefore, it is critical that QoS signaling 1262 in connection with handover be carried out very quickly. 1264 6) Call blocking in case of overload 1266 Furthermore, when the network is overloaded, it is preferable to 1267 keep s for previously established flows while blocking new requests. 1268 Therefore, the resource reservation requests in connection with 1269 handover should be given higher priority than new requests for 1270 resource reservation. 1272 10.2 Wireless Networks 1274 In this scenario, the user is using the packet services of a 1275 wireless system (such as the 3rd generation wireless system 1276 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the 1277 Edge Node (Edge Router) connecting the wireless network to another 1278 QoS domain is considered to be a single QoS domain. 1280 The issues in such an environment regarding QoS include: 1282 1) The wireless networks provide their own QoS technology with 1283 specialized parameters to co-ordinate the QoS provided by both the 1284 radio access and wired access networks. Provisioning of QoS 1285 technologies within a wireless network can be described mainly in 1286 terms of calling bearer classes, service options, and service 1287 instances. These QoS technologies need to be invoked with suitable 1288 parameters when higher layers trigger a request for QoS. Therefore 1289 these involve mapping of the requested higher layer QoS parameters 1290 onto specific bearer classes or service instances. The request for 1291 allocation of resources might be triggered by signaling at the IP 1292 level that passes across the wireless system, and possibly other QoS 1293 domains. Typically, wireless network specific messages are invoked 1294 to setup the underlying bearer classes or service instances in 1295 parallel with the IP layer QoS negotiation, to allocate resources 1296 within the radio access network. 1298 2) The IP signaling messages are initiated by the NSIS initiator and 1299 interpreted by the NSIS Forwarder. The most efficient placement of 1300 the NSIS Initiator and NSIS Forwarder has not been determined in 1301 wireless networks, but a few potential scenarios can be envisioned. 1302 The NSIS Initiator could be located at the End Host (e.g. 3G User 1303 equipment (UE)), the Access Gateway or at a node that is not 1304 directly on the data path, such as a Policy Decision Function. The 1305 Access Gateway could act as a proxy NSIS Initiator on behalf of the 1306 End Host. The Policy Decision Function that controls per- 1307 flow/aggregate resources with respect to the session within its QoS 1308 domain (e.g. the 3G wireless network) may act as a proxy NSIS 1309 Initiator for the end host or the Access Gateway. Depending on the 1310 placement of the NSIS Initiator, the NSIS Forwarder may be located 1311 at an appropriate point in the wireless network. 1313 3) The need for re-negotiation of resources in a new wireless domain 1314 due to host mobility. In this case the NSIS Initiator and the NSIS 1315 Forwarder should detect mobility events and autonomously trigger re- 1316 negotiation of resources. 1318 10.3 An example scenario for 3G wireless networks 1320 The following example is a pure hypothetical scenario, where an NSIS 1321 signaling protocol might be used in a 3G environment. We do not 1322 impose in any way, how a potential integration might be done. Terms 1323 from the 3GPP architecture are used (P-CSCF, IMS, expanded below) in 1324 order to give specificity, but in a hypothetical design, one that 1325 reflects neither development nor review by 3GPP. The example should 1326 help in the design of a NSIS signaling protocol such that it could 1327 be used in various environments. 1329 The 3G wireless access scenario is shown in Figure 1. The Proxy-Call 1330 State Control Function (P-CSCF) is the outbound SIP proxy (only used 1331 in integrated multimedia systems (IMS)). The Access Gateway is the 1332 egress router of the 3G wireless domain and it connects the radio 1333 access network to the Edge Router (ER) of the backbone IP network. 1334 The Policy Decision Function (PDF) is an entity responsible for 1335 controlling bearer level resource allocations/de-allocations in 1336 relation to session level services e.g. SIP. The Policy Decision 1337 Function may also control the Access Gateway to open and close the 1338 gates and to configure per-flow policies, i.e. to authorize or 1339 forbid user traffic. The P-CSCF (only used in IMS) and the Access 1340 Gateway communicate with the Policy Decision Function, for network 1341 resource allocation/de-allocation decisions. The User Equipment (UE) 1342 or the Mobile Station (MS) consists of a Mobile Terminal (MT) and 1343 Terminal Equipment (TE), e.g. a laptop. 1345 +--------+ 1346 +--------->| P-CSCF |---------> SIP signaling 1347 / +--------+ 1348 / SIP | 1349 | | 1350 | +-----+ +----------------+ 1351 | | PDF |<---------->| NSIS Forwarder |<---> 1352 | +-----+ +----------------+ 1353 | | ^ 1354 | | | 1355 | | | 1356 | |COPS | 1357 | | | 1358 +------+ +---------+ | 1359 | UE/MS|----------| Access |<-----------+ +----+ 1360 +------+ | Gateway |------------------| ER | 1361 +---------+ +----+ 1363 Figure 1: 3G wireless access scenario 1365 The PDF has all the required QoS information for per-flow or 1366 aggregate admission control in 3G wireless networks. It receives 1367 resource allocation/de-allocation requests from the P-CSCF and/or 1368 Access Gateway etc. and responds with policy decisions. Hence the 1369 PDF may be a candidate entity to host the functionality of the NSIS 1370 Initiator, initiating the "NSIS" QoS signaling towards the backbone 1371 IP network. On the other hand, the UE/MS may act as the NSIS 1372 Initiator or the Access Gateway may act as a Proxy NSIS Initiator on 1373 behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do 1374 the mapping from codec types and media descriptors (derived from 1375 SIP/SDP signaling) to IP traffic descriptor. In the latter case, the 1376 UE/MS may use any appropriate QoS signaling mechanism as the NSIS 1377 Initiator. If the Access Gateway is acting as the Proxy NSIS 1378 initiator on behalf of the UE/MS, then it may have to do the mapping 1379 of parameters from radio access specific QoS to IP QoS traffic 1380 parameters before forwarding the request to the NSIS Forwarder. 1382 The NSIS Forwarder is currently not part of the standard 3G wireless 1383 architecture. However, to achieve end-to-end QoS a NSIS Forwarder is 1384 needed such that the NSIS Initiators can request a QoS connection to 1385 the IP network. As in the previous example, the NSIS Forwarder could 1386 manage a set of pre-provisioned resources in the IP network, i.e. 1387 bandwidth pipes, and the NSIS Forwarder perform per-flow admission 1388 control into these pipes. In this way, a connection can be made 1389 between two 3G wireless access networks, and hence, end-to-end QoS 1390 can be achieved. In this case the NSIS Initiator and NSIS Forwarder 1391 are clearly two separate logical entities. The Access Gateway or/and 1392 the Edge Router in Fig.1 may contain the NSIS Forwarder 1393 functionality, depending upon the placement of the NSIS Initiator as 1394 discussed in scenario 2 in section 10.2. This use case clearly 1395 illustrates the need for an NSIS QoS signaling protocol between NSIS 1396 Initiator and NSIS Forwarder. An important application of such a 1397 protocol may be its use in the end-to-end establishment of a 1398 connection with specific QoS characteristics between a mobile host 1399 and another party (e.g. end host or content server). 1401 10.4 Wired part of wireless network 1403 A wireless network, seen from a QoS domain perspective, usually 1404 consists of three parts: a wireless interface part (the "radio 1405 interface"), a wired part of the wireless network (i.e., Radio 1406 Access Network) and the backbone of the wireless network, as shown 1407 in Figure 2. Note that this figure should not be seen as an 1408 architectural overview of wireless networks but rather as showing 1409 the conceptual QoS domains in a wireless network. 1411 In this scenario, a mobile host can roam and perform a handover 1412 procedure between base stations/access routers. In this scenario the 1413 NSIS QoS protocol can be applied between a base station and the 1414 gateway (GW). In this case a GW can also be considered as a local 1415 handover anchor point. Furthermore, in this scenario the NSIS QoS 1416 protocol can also be applied either between two GWs, or between two 1417 edge routers (ER). 1419 |--| 1420 |GW| 1421 |--| |--| 1422 |MH|--- . 1423 |--| / |-------| . 1424 /--|base | |--| . 1425 |station|-|ER|... 1426 |-------| |--| . |--| back- |--| |---| |----| 1427 ..|ER|.......|ER|..|BGW|.."Internet"..|host| 1428 -- |-------| |--| . |--| bone |--| |---| |----| 1429 |--| \ |base |-|ER|... . 1430 |MH| \ |station| |--| . 1431 |--|--- |-------| . MH = mobile host 1432 |--| ER = edge router 1433 <----> |GW| GW = gateway 1434 Wireless link |--| BGW = border gateway 1435 ... = interior nodes 1436 <-------------------> 1437 Wired part of wireless network 1439 <----------------------------------------> 1440 Wireless Network 1442 Figure 2. QoS architecture of wired part of wireless network 1444 Each of these parts of the wireless network impose different issues 1445 to be solved on the QoS signaling solution being used: 1447 - Wireless interface: The solution for the air interface link 1448 has to ensure flexibility and spectrum efficient transmission 1449 of IP packets. However, this link layer QoS can be solved in 1450 the same way as any other last hop problem by allowing a 1451 host to request the proper QoS profile. 1453 - Wired part of the wireless network: This is the part of 1454 the network that is closest to the base stations/access 1455 routers. It is an IP network although some parts logically 1456 perform tunneling of the end user data. In cellular networks, 1457 the wired part of the wireless network is denoted as a 1458 radio access network. 1460 This part of the wireless network has different 1461 characteristics when compared to traditional IP networks: 1463 1. The network must support mobility. Many wireless 1464 networks are able to provide a combination of soft 1465 and hard handover procedures. When handover occurs, 1466 reservations need to be established on new paths. 1467 The establishment time has to be as short as possible 1468 since long establishment times for s degrade 1469 the performance of the wireless network. Moreover, 1470 for maximal utilization of the radio spectrum, frequent 1471 handover operations are required. 1473 2. These links are typically rather bandwidth-limited. 1475 3. The wired transmission in such a network contains a 1476 relatively high volume of expensive leased lines. 1477 Overprovisioning might therefore be prohibitively 1478 expensive. 1480 4. The radio base stations are spread over a wide 1481 geographical area and are in general situated a large 1482 distance from the backbone. 1484 - Backbone of the wireless network: the requirements imposed 1485 by this network are similar to the requirements imposed by 1486 other types of backbone networks. 1488 Due to these very different characteristics and requirements, often 1489 contradictory, different QoS signaling solutions might be needed in 1490 each of the three network parts. 1492 10.5 Session Mobility 1494 In this scenario, a session is moved from one end-system to another. 1495 Ongoing sessions are kept and QoS parameters need to be adapted, 1496 since it is very likely that the new device provides different 1497 capabilities. Note that it is open which entity initiates the move, 1498 which implies that the NSIS Initiator might be triggered by 1499 different entities. 1501 User mobility (i.e., a user changing the device and therefore moving 1502 the sessions to the new device) is considered to be a special case 1503 within the session mobility scenario. 1505 Note that this scenario is different from terminal mobility. Not the 1506 terminal (end-system) has moved to a different access point. Both 1507 terminals are still connected to an IP network at their original 1508 points. 1510 The issues include: 1512 1) Keeping the QoS guarantees negotiated implies that the end- 1513 point(s) of communication are changed without changing the s. 1515 2) The trigger of the session move might be the user or any other 1516 party involved in the session. 1518 10.6 QoS reservation/negotiation from access to core network 1520 The scenario includes the signaling between access networks and core 1521 networks in order to setup and change reservations together with 1522 potential negotiation. 1524 The issues to be solved in this scenario are different from previous 1525 ones. 1527 1) The entity of reservation is most likely an aggregate. 1529 2) The time scales of s might be different (long living s of 1530 aggregates, less often re-negotiation). 1532 3) The specification of the traffic (amount of traffic), a 1533 particular QoS is guaranteed for, needs to be changed. E.g., in case 1534 additional flows are added to the aggregate, the traffic 1535 specification of the flow needs to be added if it is not already 1536 included in the aggregates specification. 1538 4) The flow specification is more complex including network 1539 addresses and sets of different address for the source as well as 1540 for the destination of the flow. 1542 10.7 QoS reservation/negotiation over administrative boundaries 1544 Signaling between two or more core networks to provide QoS is 1545 handled in this scenario. This might also include access to core 1546 signaling over administrative boundaries. Compared to the previous 1547 one it adds the case, where the two networks are not in the same 1548 administrative domain. Basically, it is the inter-domain/inter 1549 provider signaling which is handled in here. 1551 The domain boundary is the critical issue to be resolved. Which as 1552 various flavors of issues a QoS signaling protocol has to be 1553 concerned with. 1555 1) Competing administrations: Normally, only basic information 1556 should be exchanged, if the signaling is between competing 1557 administrations. Specifically information about core network 1558 internals (e.g., topology, technology, etc.) should not be 1559 exchanged. Some information exchange about the "access points" of 1560 the core networks (which is topology information as well) may need 1561 to be exchanged, because it is needed for proper signaling. 1563 2) Additionally, as in scenario 4, signaling most likely is based on 1564 aggregates, with all the issues raise there. 1566 3) Authorization: It is critical that the NSIS Initiator is 1567 authorized to perform a QoS path setup. 1569 4) Accountability: It is important to notice that signaling might be 1570 used as an entity to charge money for, therefore the interoperation 1571 with accounting needs to be available. 1573 10.8 QoS signaling between PSTN gateways and backbone routers 1575 A PSTN gateway (i.e., host) requires information from the network 1576 regarding its ability to transport voice traffic across the network. 1577 The voice quality will suffer due to packet loss, latency and 1578 jitter. Signaling is used to identify and admit a flow for which 1579 these impairments are minimized. In addition, the disposition of 1580 the signaling request is used to allow the PSTN GW to make a call 1581 routing decision before the call is actually accepted and delivered 1582 to the final destination. 1584 PSTN gateways may handle thousands of calls simultaneously and there 1585 may be hundreds of PSTN gateways in a single provider network. These 1586 numbers are likely to increase as the size of the network increases. 1587 The point being that scalability is a major issue. 1589 There are several ways that a PSTN gateway can acquire assurances 1590 that a network can carry its traffic across the network. These 1591 include: 1593 1. Over-provisioning a high availability network. 1594 2. Handling admission control through some policy server 1595 that has a global view of the network and its resources. 1596 3. Per PSTN GW pair admission control. 1597 4. Per call admission control (where a call is defined as 1598 the 5-tuple used to carry a single RTP flow). 1600 Item 1 requires no signaling at all and is therefore outside the 1601 scope of this working group. 1603 Item 2 is really a better informed version of 1, but it is also 1604 outside the scope of this working group as it relies on a particular 1605 telephony signaling protocol rather than a packet admission control 1606 protocol. 1608 Item 3 is initially attractive, as it appears to have reasonable 1609 scaling properties, however, its scaling properties only are 1610 effective in cases where there are relatively few PSTN GWs. In the 1611 more general case were a PSTN GW reduces to a single IP phone 1612 sitting behind some access network, the opportunities for 1613 aggregation are reduced and the problem reduces to item 4. 1615 Item 4 is the most general case. However, it has the most difficult 1616 scaling problems. The objective here is to place the requirements on 1617 Item 4 such that a scalable per-flow admission control protocol or 1618 protocol suite may be developed. 1620 The case where per-flow signaling extends to individual IP end- 1621 points allows the inclusion of IP phones on cable, DSL, wireless or 1622 other access networks in this scenario. 1624 Call Scenario 1626 A PSTN GW signals end-to-end for some 5-tuple defined flow a 1627 bandwidth and QoS requirement. Note that the 5-tuple might include 1628 masking/wildcarding. The access network admits this flow according 1629 to its local policy and the specific details of the access 1630 technology. 1632 At the edge router (i.e., border node), the flow is admitted, again 1633 with an optional authentication process, possibly involving an 1634 external policy server. Note that the relationship between the PSTN 1635 GW and the policy server and the routers and the policy server is 1636 outside the scope of NSIS. The edge router then admits the flow into 1637 the core of the network, possibly using some aggregation technique. 1639 At the interior nodes, the NSIS host-to-host signaling should either 1640 be ignored or invisible as the Edge router performed the admission 1641 control decision to some aggregate. 1643 At the inter-provider router (i.e., border node), again the NSIS 1644 host-to-host signaling should either be ignored or invisible, as the 1645 Edge router has performed an admission control decision about an 1646 aggregate across a carrier network. 1648 10.9 PSTN trunking gateway 1650 One of the use cases for the NSIS signaling protocol is the scenario 1651 of interconnecting PSTN gateways with an IP network that supports 1652 QoS. 1653 Four different scenarios are considered here. 1654 1. In-band QoS signaling is used. In this case the Media Gateway 1655 (MG) will be acting as the NSIS Initiator and the Edge Router 1656 (ER) will be the NSIS Forwarder. Hence, the ER should do 1657 admission control (into pre-provisioned traffic trunks) for the 1658 individual traffic flows. This scenario is not further 1659 considered here. 1660 2. Out-of-band signaling in a single domain, the NSIS forwarder is 1661 integrated in the MGC. In this case no NSIS protocol is 1662 required. 1663 3. Out-of-band signaling in a single domain, the NSIS forwarder is 1664 a separate box. In this case NSIS signaling is used between the 1665 MGC and the NSIS Forwarder. 1666 4. Out-of-band signaling between multiple domains, the NSIS 1667 Forwarder (which may be integrated in the MGC) triggers the 1668 NSIS Forwarder of the next domain. 1670 When the out-of-band QoS signaling is used the Media Gateway 1671 Controller (MGC) will be acting as the NSIS Initiator. 1673 In the second scenario the voice provider manages a set of traffic 1674 trunks that are leased from a network provider. The MGC does the 1675 admission control in this case. Since the NSIS Forwarder acts both 1676 as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is 1677 required. This scenario is shown in Figure 3. 1679 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1680 | SS7 network |---------------------| MGC |--------------| SS7 | 1681 +-------------+ +-------+-----+---------+ +-----+ 1682 : / : \ 1683 : / : \ 1684 : / +--------:----------+ \ 1685 : MEGACO / / : \ \ 1686 : / / +-----+ \ \ 1687 : / / | NMS | \ \ 1688 : / | +-----+ | \ 1689 : : | | : 1690 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1691 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1692 +--------------+ +----+ \ / +----+ 1693 \ QoS network / 1694 +-------------------+ 1696 Figure 3: PSTN trunking gateway scenario 1698 In the third scenario, the voice provider does not lease traffic 1699 trunks in the network. Another entity may lease traffic trunks and 1700 may use a NSIS Forwarder to do per-flow admission control. In this 1701 case the NSIS signaling is used between the MGC and the NSIS 1702 Forwarder, which is a separate box here. Hence, the MGC acts only as 1703 a NSIS Initiator. This scenario is depicted in Figure 4. 1705 +-------------+ ISUP/SIGTRAN +-----+ +-----+ 1706 | SS7 network |---------------------| MGC |--------------| SS7 | 1707 +-------------+ +-------+-----+---------+ +-----+ 1708 : / : \ 1709 : / +-----+ \ 1710 : / | NF | \ 1711 : / +-----+ \ 1712 : / : \ 1713 : / +--------:----------+ \ 1714 : MEGACO : / : \ : 1715 : : / +-----+ \ : 1716 : : / | NMS | \ : 1717 : : | +-----+ | : 1718 : : | | : 1719 +--------------+ +----+ | bandwidth pipe (SLS) | +----+ 1720 | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- 1721 +--------------+ +----+ \ / +----+ 1722 \ QoS network / 1723 +-------------------+ 1725 Figure 4: PSTN trunking gateway scenario 1727 In the fourth scenario multiple transport domains are involved. In 1728 the originating network either the MGC may have an overview on the 1729 resources of the overlay network or a separate NSIS Forwarder will 1730 have the overview. Hence, depending on this either the MGC or the 1731 NSIS Forwarder of the originating domain will contact the NSIS 1732 Forwarder of the next domain. The MGC always acts as a NSIS 1733 Initiator and may also be acting as a NSIS Forwarder in the first 1734 domain. 1736 10.10 An application requests end-to-end QoS path from the network 1738 This is actually the conceptually simplest case. So a multimedia 1739 application requests a guaranteed service from an IP network. We 1740 assume here that the application is somehow able to specify the 1741 network service. The characteristics here are that many hosts might 1742 do it, but that the requested service is low capacity (bounded by 1743 the access line). Note that there is an issue of scaling in the 1744 number of applications requesting this service in the core of the 1745 network. 1747 10.11 QOS for Virtual Private Networks 1749 In a Virtual Private Network (VPN) [PPVPN_FW] a variety of tunnels 1750 might be used between its edges. These tunnels could be for example, 1751 IPSec, GRE, and IP-IP. One of the most significant issues in VPNs is 1752 related to how a flow is identified and what quality a flow gets. A 1753 flow identification might consist among others of the transport 1754 protocol port numbers. In an IP-Sec tunnel this will be problematic 1755 since the transport protocol information is encrypted. 1757 There are two types of L3 VPNs, distinguished by where the endpoints 1758 of the tunnels exist. The endpoints of the tunnels may either be on 1759 the customer (CPE) or the provider equipment or provider edge (PE). 1761 Virtual Private networks are also likely to request bandwidth or 1762 other type of service in addition to the premium services the PSTN 1763 GW are likely to use. 1765 10.11.1 Tunnel end points at the Customer premises 1767 When the endpoints are the CPE, the CPE may want to signal across 1768 the public IP network for a particular amount of bandwidth and QoS 1769 for the tunnel aggregate. Such signaling may be useful when a 1770 customer wants to vary their network cost with demand, rather than 1771 paying a flat rate. Such signaling exists between the two CPE 1772 routers. Intermediate access and edge routers perform the same exact 1773 call admission control, authentication and aggregation functions 1774 performed by the corresponding routers in the PSTN GW scenario with 1775 the exception that the endpoints are the CPE tunnel endpoints rather 1776 than PSTN GWs and the 5-tuple used to describe the RTP flow is 1777 replaced with the corresponding flow spec to uniquely identify the 1778 tunnels. Tunnels may be of any variety (e.g. IP-Sec, GRE, IP-IP). 1780 In such a scenario, NSIS would actually allow partly for customer 1781 managed VPNs, which means a customer can setup VPNs by subsequent 1782 NSIS signaling to various end-point. Plus the tunnel end-points are 1783 not necessarily bound to an application. The customer administrator 1784 might be the one triggering NSIS signaling. 1786 10.11.2 Tunnel end points at the provider premises 1788 In the case were the tunnel end-points exist on the provider edge, 1789 requests for bandwidth may be signaled either per flow, where a flow 1790 is defined from a customers address space, or between customer 1791 sites. 1793 In the case of per flow signaling, the PE router must map the 1794 bandwidth request to the tunnel carrying traffic to the destination 1795 specified in the flow spec. Such a tunnel is a member of an 1796 aggregate to which the flow must be admitted. In this case, the 1797 operation of admission control is very similar to the case of the 1798 PSTN GW with the additional level of indirection imposed by the VPN 1799 tunnel. Therefore, authentication, accounting and policing may be 1800 required on the PE router. 1802 In the case of per site signaling, a site would need to be 1803 identified. This may be accomplished by specifying the network 1804 serviced at that site through an IP prefix. In this case, the 1805 admission control function is performed on the aggregate to the PE 1806 router connected to the site in question. 1808 Full Copyright Statement 1810 Copyright (C) The Internet Society (2003). All Rights Reserved. 1812 This document and translations of it may be copied and furnished to 1813 others, and derivative works that comment on or otherwise explain it 1814 or assist in its implementation may be prepared, copied, published 1815 and distributed, in whole or in part, without restriction of any 1816 kind, provided that the above copyright notice and this paragraph are 1817 included on all such copies and derivative works. However, this 1818 document itself may not be modified in any way, such as by removing 1819 the copyright notice or references to the Internet Society or other 1820 Internet organizations, except as needed for the purpose of 1821 developing Internet standards in which case the procedures for 1822 copyrights defined in the Internet Standards process must be 1823 followed, or as required to translate it into languages other than 1824 English. 1826 The limited permissions granted above are perpetual and will not be 1827 revoked by the Internet Society or its successors or assigns. 1829 This document and the information contained herein is provided on an 1830 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1831 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1832 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1833 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1834 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1836 Notices 1837 The IETF takes no position regarding the validity or scope of any 1838 intellectual property or other rights that might be claimed to 1839 pertain to the implementation or use of the technology described in 1840 this document or the extent to which any license under such rights 1841 might or might not be available; neither does it represent that it 1842 has made any effort to identify any such rights. Information on the 1843 IETF's procedures with respect to rights in standards-track and 1844 standards-related documentation can be found in BCP-11. Copies of 1845 claims of rights made available for publication and any assurances 1846 of licenses to be made available, or the result of an attempt made 1847 to obtain a general license or permission for the use of such 1848 proprietary rights by implementors or users of this specification 1849 can be obtained from the IETF Secretariat. 1851 The IETF invites any interested party to bring to its attention any 1852 copyrights, patents or patent applications, or other proprietary 1853 rights, which may cover technology that may be required to practice 1854 this standard. Please address the information to the IETF Executive 1855 Director.