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