idnits 2.17.1 draft-hancock-nsis-fw-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1329 has weird spacing: '...special packe...' == Line 1331 has weird spacing: '...gnaling messa...' == Line 1332 has weird spacing: '...ions of mobil...' == Line 1337 has weird spacing: '... Care of Ad...' == Line 1338 has weird spacing: '...s least deman...' == (11 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 2002) is 7979 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 21 looks like a reference -- Missing reference section? '2' on line 368 looks like a reference -- Missing reference section? '3' on line 55 looks like a reference -- Missing reference section? '4' on line 1695 looks like a reference -- Missing reference section? '5' on line 690 looks like a reference -- Missing reference section? '6' on line 690 looks like a reference -- Missing reference section? '7' on line 853 looks like a reference -- Missing reference section? '8' on line 818 looks like a reference -- Missing reference section? '9' on line 818 looks like a reference -- Missing reference section? '10' on line 855 looks like a reference -- Missing reference section? '11' on line 1071 looks like a reference -- Missing reference section? '12' on line 1085 looks like a reference -- Missing reference section? '13' on line 1171 looks like a reference -- Missing reference section? '14' on line 1180 looks like a reference -- Missing reference section? '15' on line 1180 looks like a reference -- Missing reference section? '16' on line 1187 looks like a reference -- Missing reference section? '17' on line 1213 looks like a reference -- Missing reference section? '18' on line 1218 looks like a reference -- Missing reference section? '19' on line 1281 looks like a reference -- Missing reference section? '20' on line 1302 looks like a reference -- Missing reference section? '21' on line 1533 looks like a reference -- Missing reference section? '22' on line 1311 looks like a reference -- Missing reference section? '23' on line 1452 looks like a reference -- Missing reference section? '24' on line 1389 looks like a reference -- Missing reference section? '25' on line 1455 looks like a reference -- Missing reference section? '26' on line 1512 looks like a reference -- Missing reference section? '27' on line 1456 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Ilya Freytsis 3 Cetacean Networks 4 Robert Hancock 5 Siemens/Roke Manor Research 6 Georgios Karagiannis 7 Ericsson 8 John Loughney 9 Nokia 10 Sven Van den Bosch 11 Alcatel 12 Document: draft-hancock-nsis-fw-00.txt 13 Expires: December 2002 June 2002 15 Next Steps in Signaling: A Framework Proposal 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026 [1]. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The NSIS working group is considering protocol developments in 40 signaling for resources for a traffic flow along its path in the 41 network. The requirements for such signaling are being developed in a 42 separate document [2]; This Internet Draft proposes a framework for 43 such signaling. This initial version provides a model for describing 44 the entities that take part in the signaling and the ways in which 45 they can be used in different modes of operation. It also discusses 46 the overall structure of such a signaling protocol. Finally, it 47 considers the possible interactions of NSIS signaling with other 48 protocols and functions, including security issues. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [3]. 56 Table of Contents 58 1. Introduction...................................................3 59 1.1 Scope of this Document .....................................3 60 2. Terminology....................................................4 61 3. Overall Framework Structure....................................5 62 3.1 Basic Signaling Entities and Interfaces ....................5 63 3.1.1 NSIS Entities ..........................................5 64 3.1.2 Placement of NSIS entities .............................7 65 3.2 Modes of Operation .........................................7 66 3.2.1 In-Band and Out-of-Band Signaling ......................8 67 3.2.2 Inter-domain and Intra-domain Signaling ................8 68 3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge ..............9 69 3.2.4 Global and Local Operation .............................9 70 3.2.5 Multicast versus Unicast ..............................10 71 3.2.6 Sender versus Receiver Initiated Signaling ............10 72 3.2.7 Uni-Directional and Bi-Directional Reservations .......11 73 3.3 Basic Assumptions and Critical Issues .....................11 74 3.3.1 Overview of Open Items and Critical Issues ............11 75 3.3.2 NI, NF, NR functionality ..............................13 76 3.3.3 NI, NF, NR relationship ...............................13 77 3.3.4 NSIS Addressing .......................................13 78 3.3.5 Service description ...................................14 79 3.3.6 NSIS Acknowledgement and Notification Semantics .......14 80 4. Protocol Components...........................................15 81 4.1 Lower Layer Interfaces ....................................15 82 4.2 Upper Layer Services ......................................16 83 4.3 Protocol Structure ........................................17 84 4.3.1 Internal Layering .....................................17 85 4.3.2 Protocol Messages .....................................18 86 4.4 State Management ..........................................19 87 4.5 Identity Elements .........................................21 88 4.5.1 Flow Identification ...................................21 89 4.5.2 Reservation Identification ............................21 90 4.5.3 Resource Type Identification ..........................22 91 5. NSIS and other Functions and Protocols........................22 92 5.1 Resource Management and Network Provisioning ..............22 93 5.2 IP Routing ................................................25 94 5.2.1 Load Sharing ..........................................25 95 5.2.2 QoS Routing ...........................................26 96 5.2.3 Route pinning .........................................26 97 5.2.4 Route changes .........................................27 98 5.3 Mobility Support ..........................................28 99 5.3.1 Addressing and Encapsulation ..........................28 100 5.3.2 Localized Path Repair .................................29 101 5.3.3 Reservation Update on the Unchanged Path ..............30 102 5.3.4 Interaction with Mobility Signaling ...................30 103 5.3.5 Interaction with Fast Handoff Support Protocols .......32 104 5.4 Existing Resource Signaling Protocols .....................33 105 5.5 Multi-Level NSIS Signaling ................................34 106 6. Security and AAA Considerations...............................36 107 6.1 Authentication ............................................36 108 6.2 Authorization .............................................37 109 6.3 Accounting ................................................39 110 6.4 End-to-End vs. Peer-Session Protection ....................39 111 Acknowledgments..................................................43 112 Author's Addresses...............................................43 113 Full Copyright Statement.........................................44 115 1. Introduction 117 NSIS will work on signaling from an end point that follows a path 118 through the net that is determined by layer 3 routing and is used to 119 convey information to the devices the signals pass through - the 120 signaling can, for example, install soft state in the devices it 121 passes through. A signaling end point could be a device along the 122 path, which signals for a data flow that passes through it. 124 The intention is to allow for the NSIS protocol to be deployed in 125 different parts of the Internet, for different needs, without 126 requiring a complete end-to-end deployment. 128 There is no requirement that the per-flow information be QoS related. 129 NSIS should only worry about how to do the signaling - what the 130 signaling conveys should be opaque to NSIS. This document discusses 131 'where' the signaling takes place, with some discussion on 'how' the 132 signaling can be done. 134 1.1 Scope of this Document 136 The scope of this document is to provide a framework for where a NSIS 137 protocol can be used and deployed. It is not intended that NSIS will 138 provide an over-arching architecture for carrying out resource 139 management in the Internet. It is not intended to be used as a 140 protocol design document. 142 The framework is not about what NSIS should do but how it should do 143 it. It is not intended that this places requirements on a future NSIS 144 protocol. The document discusses important protocol considerations, 145 such as mobility, security, interworking with resource management (in 146 a broad sense). Discussions about existing signaling and resource 147 protocols are assumed to be contained in a separate analysis 148 document. 150 The initial draft of this document is more about discussing the 151 important issues and gaining some scoping on the problem space. 152 Future revisions will have more concrete proposals. 154 The purpose of this document is to develop the realms, domains and 155 modes of operation where an NSIS protocol can be used; identify the 156 relationship of an NSIS protocol to other protocols; and identify 157 areas for future work. 159 2. Terminology 161 Classifier - an entity which selects packets based on the content of 162 packet headers according to defined rules. 164 Interdomain traffic - Traffic that passes from one NSIS domain to 165 another. 167 NSIS Domain (ND) - Administrative domain where an NSIS protocol 168 signals for a resource or set of resources. 170 NSIS Entity (NE) - the function within a node which implements an 171 NSIS protocol. 173 NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR 174 which may interact with local resource management function (RMF) for 175 this purpose. NSIS Forwarder also propagates NSIS signaling further 176 through the network. 178 NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a 179 network resource. 181 NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and 182 can optionally interact with applications as well. 184 Peer session - signaling relationship between two adjacent NSIS 185 entities (i.e. NEs with no other NEs between them). 187 Resource - something of value in a network infrastructure to which 188 rules or policy criteria are first applied before access is granted. 189 Examples of resources include the buffers in a router and bandwidth 190 on an interface. 192 Resource Management Function (RMF) - an abstract concept, 193 representing the management of resources in a domain or a node. 195 Service Level Agreement (SLA) - a service contract between a customer 196 and a service provider that specifies the forwarding service a 197 customer should receive. 199 Traffic characteristic - a description of the temporal behavior or a 200 description of the attributes of a given traffic flow or traffic 201 aggregate. 203 Traffic flow - a stream of packets between two end-points that can be 204 characterized in a certain way. 206 3. Overall Framework Structure 208 3.1 Basic Signaling Entities and Interfaces 210 3.1.1 NSIS Entities 212 The NSIS protocol is intended to be used as a signaling control plane 213 for the variety of network resources required for data traffic across 214 the Internet. The most common examples are QoS resources, firewalls 215 and NATs resources, etc. The NSIS signaling itself does not depend on 216 the type of the network resources it is used for but the information 217 it carries does. This section discusses the basic signaling entities 218 of the protocol as well as interfaces between them. 220 We can identify three different roles in the NSIS signaling for 221 resources: initiator, forwarder and responder. 223 The NSIS Initiator (NI) is an entity that initiates NSIS signaling 224 (request) for the network resource. The NSIS initiator can be 225 triggered by the different "sources" - applications, an instance of 226 NSIS Forwarder, other protocols, network management etc. - that need 227 network resources for a data flow. For the purpose of the NSIS 228 discussion all these sources can be called applications. The NSIS 229 initiator can provide feedback information to the triggering 230 application in respect to the requested network resources. The NSIS 231 initiator uses NSIS signaling to interact with other NSIS entities 232 (NFs and NRs). 234 The NSIS Forwarder (NF) is an entity that services NSIS resource 235 requests from NSIS initiators and other NSIS forwarders. It may 236 interact with local resource management function (RMF). How and if 237 this interaction takes place depends on the deployed resource 238 management mechanism and the specific role of the NF. The NSIS 239 forwarder propagates NSIS signaling further through the network. 241 The NSIS Responder (NR) is an entity that terminates NSIS signaling 242 and can optionally interact with applications as well e.g. for the 243 purpose of notification when network resources get allocated etc. 245 The signaling relationship between two NSIS entities (with no other 246 NSIS entities between them) is called a 'Peer-session'. This concept 247 might loosely be described as an 'NSIS hop'; however, there is no 248 implication that it corresponds to a single IP hop. 250 Figure 1 depicts simplified interactions/interfaces between NI, NFs 251 and NR as well as applications and RMFs. Note that the NI and NR 252 could also interact with an RMF; additionally, this could be modeled 253 as co-location of NI&NF and NR&NF. This distinction should have no 254 impact on the operation of the protocol. Also, there is no bar on 255 placing an NI or NR in the interior of the network, to initiate and 256 terminate NSIS signaling independently of the ultimate endpoints of 257 the end to end flow, and NI and NR do not have to talk via 258 intervening NFs. An example of NSIS being used in this way is given 259 in section 5.5. 261 +-----------+ +-----------+ 262 |Application| |Application| 263 +-----------+ +-----------+ 264 ^ ^ 265 | | 266 | | 267 V V 268 +----+ NSIS +----+ NSIS +----+ NSIS +----+ 269 | NI |<========>| NF |<===...===>| NF |<========>| NR | 270 +----+ +----+ +----+ +----+ 271 ^ ^ 272 | | 273 | | 274 V V 275 +-----+ +-----+ 276 | RMF | | RMF | 277 +-----+ +-----+ 279 <========> = NSIS Peer-session 281 Figure 1: Basic NI/NF/NR Relationships 283 3.1.2 Placement of NSIS entities 285 The NI, NF and NR definitions do not make any assumptions about 286 placements of NSIS signaling entities in respect to the particular 287 part of the network or data-forwarding path. 289 They can be located along the data path (hosts generating and 290 receiving data flows, edge routers, intermediate routers etc.) but it 291 may not be the only one desirable location. 293 In some cases it is desired to be able to initiate and/or terminate 294 NSIS signaling not from the end host that generates/receives the data 295 flow but from the some other entities on the network that can be 296 called application or service NSIS proxies. There could be various 297 reasons for this: signaling in behalf of the end hosts that are not 298 enabled with NSIS, consolidation of the customer accounting 299 (authentication, authorization) in respect to consumed application 300 and transport resources, security considerations, limitation of the 301 physical connection between host and network etc. The proxy can 302 communicate the relevant information to the host in the 303 application/service specific, maybe compressed, form. 305 Support for NSIS proxies affects the protocol in the following way: 306 * The protocol should accommodate signaling with the scope of a 307 single NSIS peer-session; the signaling could be propagated over 308 multiple peer-sessions all the way toward the destination (end-to- 309 end). 310 * In the particular case where the proxy is not on the data path, 311 NSIS might have to be extended to allow separated data and signaling 312 paths, although this analysis is not initially in scope. 314 The further discussion of these issues is given in sections 3.2.1 and 315 3.3.3. 317 As it can be seen from the usage cases presented in the NSIS 318 requirements draft [2] the NSIS signaling procedures may depend on 319 the part/type of the network where NSIS is used. In fact to satisfy 320 sometimes-conflicting requirements in [2], different procedures and 321 possibly different kinds of the NSIS protocol can be used on 322 different parts/types of the network. Sections 3.2 and 5.5 provide 323 more details on this topic. 325 3.2 Modes of Operation 327 This section discusses several modes of NSIS protocol operation. Each 328 mode of NSIS operation is briefly introduced and where needed 329 analyzed and compared with other modes of NSIS operation. 331 3.2.1 In-Band and Out-of-Band Signaling 333 In-band signaling means that the path followed by the user data 334 packets is the same as the path followed by signaling messages. In 335 other words, the signaling and data paths are identical. Out-of-band 336 signaling means that the path followed by signaling messages might be 337 different from the path used by the user data packets. 339 There are potentially significant differences in the way that the in 340 and out of band signaling paradigms should be analyzed, for example 341 in terms of scaling behavior, failure recovery, security properties, 342 mechanism for NSIS peer discovery, and so on. These differences might 343 or might not cause changes in the way that the NSIS protocol 344 operates. The initial goal of NSIS and this framework is to 345 concentrate mainly on the in-band case. 347 3.2.2 Inter-domain and Intra-domain Signaling 349 Inter-domain NSIS signaling is where the NSIS signaling messages are 350 originated in one NSIS domain and are terminated in another NSIS 351 domain. 353 In the case of in-band signaling, inter-domain NSIS signaling can be 354 used to signal NSIS information to the edge nodes of one or more NSIS 355 domains. 357 In the case of out-of-band signaling, inter-domain NSIS signaling can 358 be used to signal NSIS information to entities that are not on the 359 data path (i.e., "out-of-band" NFs), and additionally to signal from 360 off-path entities to on-path edge nodes . 362 NSIS inter-domain signaling has to fulfill several requirements, such 363 as: 364 * Basic functionality, such as scalable, simple and fast signaling. 365 Because different networks have different resource management 366 characteristics, such as cost of bandwidth and performance, this 367 basic functionality may differ from one NSIS domain to another. 368 * All other requirements specified in [2]. 370 Intra-domain NSIS signaling is where the NSIS signaling messages are 371 originated, processed and terminated within the same NSIS domain. 372 Note that these messages could be handled within a local instance of 373 NSIS signaling; another possibility could be to piggyback them on 374 inter-domain NSIS messages. 376 Intra-domain signaling can be used to signal NSIS information to the 377 edge nodes (i.e., routers located at the border of the NSIS domain) 378 and to the interior nodes (i.e., routers located within the NSIS 379 domain that are not edge nodes). 381 The NSIS intra-domain signaling approach has to fulfill fewer 382 requirements than inter-domain signaling. These are: 383 * Basic functionality, such as scalable, simple and fast signaling. 384 Due to the fact that different networks have different resource 385 management characteristics, this basic functionality may differ from 386 one NSIS domain to another. 387 * Provides the necessary functionality to interact between inter- 388 domain signaling and intra-domain signaling. 390 3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge 392 End-to-end: When used end-to-end, the NSIS protocol is initiated by 393 an end host and is terminated by another end host. In this context, 394 NSIS can be applied as needed within all of the NSIS domains between 395 the end hosts. In the end-to-end path, NSIS may be used both for 396 intra-domain NSIS signaling, as well as for inter-domain signaling. 398 Edge-to-edge: In this scenario the NSIS protocol is initiated by an 399 edge node of a NSIS domain and is terminated by another edge node of 400 the same (or possibly different) NSIS domain. NSIS can be applied 401 either within one single NSIS domain, which is denoted as edge-to- 402 edge in a single domain, or within a concatenated number of NSIS 403 domains, which is denoted as edge-to-edge in a multi-domain. When an 404 appropriate security trust relation exists between two or more 405 concatenated NSIS domains, these concatenated NSIS domains are 406 considered, in terms of NSIS, to be a single, larger NSIS domain. 408 End-to-edge: In this scenario the NSIS protocol is either initiated 409 by an end host and is terminated by an edge node or is initiated by 410 an edge node and is terminated by an end host. When using in-band 411 signaling, the edge node may be a proxy that is located on a boundary 412 node of a NSIS domain. If using out-of-band signaling, the edge node 413 may be a proxy that is located on an out-of-band node that controls, 414 or is associated with, a NSIS domain. 416 3.2.4 Global and Local Operation 418 It is likely that the appropriate way to describe the resources NSIS 419 is signaling for will vary from one part of the network to another. 420 In particular, resource descriptions that are valid for inter-domain 421 links will probably be different from those useful for intra-domain 422 operation (and the latter will differ from one NSIS domain to 423 another). 425 One way to describe this issue is to consider the resource 426 description objects carried by NSIS as divided in globally-understood 427 objects ("global objects") and locally-understood objects ("local 428 objects"). The local objects are only applicable for intra-domain 429 signaling, while the global objects are mainly used in inter-domain 430 signaling. 432 The purpose of this division is to provide additional flexibility in 433 defining the objects carried by the NSIS protocol such that only 434 those objects that are applicable in a particular setting are used. 435 An example approach for reflecting the distinction in the signaling 436 is that local objects could be put into separate local messages that 437 are initiated and terminated within one single QoS (NSIS) domain 438 and/or they could be "stacked" within the NSIS messages that are used 439 for inter-domain signaling. These possibilities will be considered 440 further during the protocol design activity. 442 3.2.5 Multicast versus Unicast 444 Multicast support, compared to unicast support, would introduce a 445 level of complexity into the NSIS protocol mainly related to: 446 * complex state maintenance to support dynamic membership changes in 447 the multicast groups, such as reservation state merging and 448 maintenance. 449 * a state per flow has to be maintained that is used during backward 450 routing. 452 3.2.6 Sender versus Receiver Initiated Signaling 454 A sender-initiated approach is when the sender of the data flow 455 initiates and maintains the resource reservation used for that flow. 456 In a receiver-initiated approach the receiver of the data flow 457 initiates and maintains the resource reservation used for the data 458 flow. 460 In the case of in-band signaling, in the sender initiated case, the 461 sender of the data is the NSIS Initiator, while the receiver of the 462 data is the NSIS Responder. In the receiver initiated case, receiver 463 of the data is the NSIS Initiator, while the sender of the data is 464 the NSIS Responder. In the case of out-band signaling, the mapping is 465 not necessarily clear cut (for example, if the NI and NR are not 466 located at the end systems themselves). 468 The main differences between the sender-initiated and receiver- 469 initiated approaches are the following: 470 * Compared with the receiver-initiated approach, a sender using a 471 sender-initiated approach can be informed faster when the reservation 472 request is rejected. In other words, when using a sender-initiated 473 approach, the reservation request response time can be shorter in the 474 case of an unsuccessful reservation than with a receiver-initiated 475 approach. 476 * In a receiver-initiated approach, the signaling messages traveling 477 from the receiver to the sender must be backward routed such that 478 they follow exactly the same path as was followed by the signaling 479 messages belonging to the same flow traveling from the sender to the 480 receiver. This implies that a backward routing state per flow must be 481 maintained. When using a sender-initiated approach, provided 482 acknowledgements and notifications can be securely delivered to the 483 sending node, backward routing is not necessary, and nodes do not 484 have to maintain backward routing states. 485 * In a sender-initiated approach, a mobile node can initiate a 486 reservation as soon as it has moved to another roaming subnetwork. In 487 a receiver-initiated approach, a mobile node has to inform the 488 receiver about its handover procedure, thus allowing the receiver to 489 initiate a reservation. 491 3.2.7 Uni-Directional and Bi-Directional Reservations 493 It is possible that a resource will only be required for one 494 direction of traffic, for example for a media stream with no feedback 495 channel. Reservations for both directions of traffic may be required 496 for other applications, for example a voice call. Therefore, the NSIS 497 signaling protocol must allow for these uni-directional resource 498 reservations and for bi-directional resource reservations is 499 required. 501 The most basic method for bi-directional reservations is based on 502 combining two uni-directional reservations. This means that the 503 signaling messages from the sender of the bi-directional reservation 504 towards a receiver are able to follow a different path from messages 505 traveling in the opposite direction, which is necessary for on-path 506 signaling in the presence of asymmetric routing. (Other more 507 integrated approaches may be possible in constrained network 508 topologies.) The bi-directional reservations can, for example, be 509 used to make the NSIS signaling procedure required after a handover 510 procedure more efficient. 512 3.3 Basic Assumptions and Critical Issues 514 3.3.1 Overview of Open Items and Critical Issues 516 Some of these issues are specific to another section of this 517 document; for clarity and to provide an overview, these are 518 summarized here. The subsequent subsections describe more generic 519 assumptions and issues. 521 Hancock et al. Expires 522 - the solution developed by NSIS must be sufficiently flexible and 523 modular that it can be efficiently deployed and used with 524 functionality appropriate to the part/type of the network. (Sections 525 3.2.2 and 3.2.3.) 527 - the protocol developed by the NSIS working group will operate in- 528 band (the signaling and data paths are identical). Considerations 529 related to a potential out-of-band solution are part of this 530 framework, because they are also needed in order to co-exist with 531 existing solutions. The NSIS working group currently has no plans to 532 develop an out-of-band signaling protocol. (Section 3.2.1.) 534 - multicast support introduces a level of complexity into the NSIS 535 protocol that is not needed in support of unicast applications. 536 Therefore, a working assumption is be that the NSIS protocol should 537 be optimized for unicast. (Section 3.2.5.) 539 - the NSIS protocol can be used for setup of both uni-directional and 540 bi-directional reservations. (Section 3.2.7.) 542 - to function as part of a complete system, the NSIS protocol may 543 need to be supported by extensions to other protocols. These 544 extensions are still to be identified. (Section 4.2.) 546 - the NSIS protocol could be constructed on the services offered by 547 lower layer protocols, but the dividing line between NSIS and these 548 lower layers is not fixed. Use of standard lower layer protocols may 549 be difficult if 'end-to-end addressing' (see section 3.3.4) is used. 550 (Section 4.3.1.) 552 - it is commonly expected that a future resource signaling protocol 553 would need to use abstract reservation identifiers. However, the 554 precise properties needed of these identifiers are unclear, and 555 enabling their secure use may be hard. (Sections 4.5.2 and 5.3.2.) 557 - use of some routing techniques (e.g. load sharing or QoS routing), 558 even in remote parts of the network, could be incompatible with naive 559 use of end-to-end addressing. (Sections 5.2.1 and 5.2.2.) 561 - the correct flow identification semantics need to be defined in the 562 case where mobility encapsulations might make it ambiguous which 563 addresses to use. (Section 5.3.1.) 565 - the interactions between mobility and resource signaling during 566 path updating need to be further analyzed, especially from the point 567 of view of combined overall latency. (Section 5.3.2 and 5.3.3.) 569 3.3.2 NI, NF, NR functionality 571 The basic functions that can be fulfilled by an NSIS entity are 572 request, accept, notify, modify and release of a reservation. At this 573 point, it is not clear which responsibilities can be assumed by each 574 of the NSIS entities. More in particular, it is not clear whether: 575 - an NF can request, modify or release a reservation. If it cannot, 576 it needs to notify the NI in order to perform these functions. 577 - an NR can modify and release a reservation. Even if the NR can 578 reject or accept the reservation with modification, it might still be 579 required to notify the NI to signal the release or modification. 581 3.3.3 NI, NF, NR relationship 583 An important open issue is related to the way in which NSIS entities 584 maintain relations between each other. These relations could be 585 purely local, where an NSIS entity only maintains relations with its 586 direct neighbors. In that case, messages will be sent to and accepted 587 from these neighbors only. Alternatively, the relations between NSIS 588 entities could have a more global scope. 590 The type of NSIS peering relations may have an impact on the 591 complexity involved with protocol security. In case of inter-domain 592 signaling, the security relations are likely to be built between 593 neighboring NSIS entities only for scalability reasons. In that case, 594 each NSIS entity will establish and maintain a security relation with 595 each of its peers and accept only messages from these peers. 596 Conversely, there may exist larger domains of NSIS entities that have 597 a trust relationship (trusted domains). This may be the case for 598 intra-domain signaling. In this case, an NE may accept messages from 599 all other NSIS entities in the domain. Both alternatives need not be 600 mutually exclusive. It is conceivable that different instances of the 601 NSIS protocol (or different NSIS protocols) use the NSIS security 602 model to a larger or lesser extent, provided that overall security is 603 not impacted. A detailed analysis of NSIS threats is available from 604 [4]. 606 The NSIS peering relations may also have an impact on the required 607 amount of state at each NSIS entity. When direct interaction with 608 remote NSIS peers is not allowed, it may be required to keep track of 609 the path that an NSIS message has followed through the network. This 610 can be achieved by keeping per-flow state at the NSIS entities or by 611 maintaining a record route object in the NSIS messages. 613 3.3.4 NSIS Addressing 615 The are potentially two ways to establish a signaling connection by 616 means of the NSIS protocol. On the one hand, the NSIS message could 617 be addressed to a neighboring NSIS entity (NE) that is known to be 618 closer to the destination NE. On the other hand, the NSIS message 619 could be addressed to the destination NE directly. We denote the 620 latter approach as end-to-end addressing and the former as peer- 621 session addressing. 623 With peer-session addressing, an NE will determine the address of the 624 next NE based on the payload of the NSIS message (and potentially 625 also on the previous NE). This requires the address of the 626 destination NE to be derivable from information present in the 627 payload. This can be achieved through the availability of a local 628 routing table or through participation in the routing protocol. Peer- 629 session addressing inherently supports tunneling of NSIS signaling 630 messages between NEs, and is equally applicable to on or off path 631 signaling. 633 In case of end-to-end addressing, the NSIS message will be sent with 634 the address of the NR, which then necessarily needs to be on the data 635 path. This requires (some of) the data-path entities to be upgraded 636 (NSIS-aware) in order to be able to intercept the NSIS messages. The 637 routing of the NSIS signaling follows exactly the same path as the 638 data flow for which the reservation is requested. 640 3.3.5 Service description 642 Although the service specific part of the NSIS message is outside of 643 the scope of the NSIS working group, it may be necessary to make some 644 assumptions about its content in order to determine whether similar 645 functionality needs to be foreseen in the NSIS-specific part of the 646 message: 647 - It is assumed that the service description will handle pre-emption 648 and survivability issues. These are seen as a part of the offered 649 service and need not be present in the NSIS control layer. 650 - It is assumed that some flow description information is part of the 651 NSIS control layer (see section 4.3.1 and 4.5.1). This might be 652 needed by service-unaware entities located at address boundaries. It 653 is not clear to which level of complexity, the flow description needs 654 to be available at this level. 655 - It is not assumed that the content of the service description is 656 independent of the NSIS control layer. It seems appropriate to allow 657 the content of the service description to be dependent on the type of 658 message that is sent (request/response/refresh). 660 3.3.6 NSIS Acknowledgement and Notification Semantics 662 The semantics of the acknowledgement and notification messages are of 663 particular importance. An NE sending a message can assume 664 responsibility for the entire downstream chain of NEs, indicating for 665 instance the availability of reserved resources for the entire 666 downstream path. Alternatively, the message could have a more local 667 meaning, indicating for instance that a certain failure or 668 degradation occurred at a particular NSIS entity. 670 4. Protocol Components 672 4.1 Lower Layer Interfaces 674 Within a signaling entity, NSIS interacts with the 'lower layers' of 675 the protocol stack for two nearly independent purposes: sending and 676 receiving signaling messages; and configuring the operation of the 677 lower layers themselves. 679 For sending and receiving messages, this framework places the lower 680 boundary of the NSIS protocol at the IP layer. (It is possible that 681 NSIS could use a standard transport protocol above the IP layer to 682 provide some of its functionality; this is discussed in section 683 4.3.1.) The interface with the lower layers is therefore very simple: 684 *) NSIS sends raw IP packets 685 *) NSIS receives raw IP packets. In the case of peer-session 686 addressing, they have been addressed directly to it. In the case of 687 end-to-end addressing, this will be by intercepting packets that have 688 been marked in some special way (by special protocol number or by 689 some option interpreted within the IP layer, such as the Router Alert 690 option [5] and [6].) 692 NSIS needs to have some information about the link and IP layer 693 configuration of the local networking stack. For example, NSIS needs 694 to know about: 695 *) [in general] how to select the outgoing interface for a signaling 696 message, in case this needs to match the interface that will be used 697 by the corresponding flow. This might be as simple as just allowing 698 the IP layer to handle the message using its own routing table. 699 *) [in the case of IPv6] what address scopes are associated with the 700 interfaces that messages are sent and received on (to interpret 701 scoped addresses in flow identification, if these are to be allowed). 703 The way in which NSIS actually configures the lower layers to handle 704 the flow depends on the particular NSIS application; for example, if 705 NSIS is being used for QoS signaling, this might involve 706 configuration of traffic classification and conditioning parameters, 707 for example local packet queues, type of filters, type of scheduling, 708 and so on. However, none of this is directly related to the NSIS 709 protocol itself; therefore, this interaction is handled indirectly 710 via a resource management function, as described in section 5.1. 712 4.2 Upper Layer Services 714 NSIS provides a signaling service, which can be used by multiple 715 upper layers for several types of application. We describe this 716 service here as an abstract set of capabilities. A later version of 717 this framework could illustrate the use of these capabilities within 718 a broader context (e.g. how NSIS signaling could be used within a 719 complete set of message flows that signal a voice over IP call). 721 We can loosely define the boundary between NSIS and these upper 722 layers from three views: 723 *) What basic control primitives are available at the interface; 724 *) What information is exchanged within these primitives; 725 *) What assumptions NSIS makes about operations carried out above the 726 interface. 728 The set of control primitives required is quite small. 729 At the initiating (NI) end: 730 *) UL requests signaling for a new resource; 731 *) UL requests modification or removal of an existing resource. 732 *) UL receives progress indications (minimally, success or failure). 733 At the responding (NR) end: 734 *) Notification to UL that a resource has been set up. 735 At either end: 736 *) Notification to UL that something has changed about the available 737 resource and other error conditions. 738 This description is in terms of a 'hard state' interface, without 739 explicit refresh messages between upper layers and NSIS, although 740 this is an implementation issue. In any case, NSIS implementations 741 will need to be able to detect conditions when ULs fail without 742 issuing explicit resource removal requests. 744 The information in the control primitives consists essentially of two 745 parts. The first is the definition of the data flow for which the 746 resource is being signaled. The format (e.g. socket id or packet 747 fields or whatever) is an implementation issue; it has to be 748 interpreted into a 'wire format' (as in section 4.5). Since NSIS 749 could support both sender and receiver initiation, the flow 750 definition must also state whether it is incoming or outgoing over a 751 particular interface (this can be inferred when the initiator is 752 colocated with the flow endpoint). The second part of the information 753 exchanged is the service definition (e.g. QoS description in the case 754 of a QoS request). This is opaque to NSIS, with the possible 755 exception of identifying the resource type being signaled. 757 We have a basic design goal not to duplicate functionality that is 758 already present in (or most naturally part of) existing signaling 759 protocols which could be used by the upper layers. Therefore NSIS 760 (implicitly) assumes that certain procedures are carried out 761 'externally'. The main aspects of this are: 762 *) Negotiation of service configuration (e.g. discovering what 763 services are available to be requested); 764 *) Agreement to use NSIS for signaling, and coordination of which end 765 will be the initiator; 766 *) (Potentially) discovery of the NSIS peer to be signaled with, 767 especially if this is not directly on the data path. See also the 768 security discussion in section 6. 769 Actually providing these functions might require enhancements to 770 these other protocols. These are still to be identified. 772 4.3 Protocol Structure 774 4.3.1 Internal Layering 776 We can model the NSIS protocol as consisting of three layers, as 777 shown in Figure 2. This is initially just a way of grouping 778 associated functionality, and does not mean that all these layers 779 could necessarily operate or even be implemented independently. 781 +--------------------------------+ 782 |////////////////////////////////| 783 |///// Service Description //////| 784 |///// (Opaque to NSIS) //////| 785 |///// (Section 4.2) //////| 786 |////////////////////////////////| 787 +--------------------------------+ 788 | | 789 | NSIS Control Layer | 790 | | 791 +--------------------------------+ 792 | | 793 | Generic Signaling Transport | 794 | Protocol | 795 | | 796 +--------------------------------+ 797 . Interface to IP Layer . 798 . (Section 4.1) . 799 .................................. 801 Figure 2: NSIS Layer Structure 803 The lower layer interface (to IP) has been described in section 4.1. 804 The service description information is essentially the same as 805 provided by the upper layers, as described in section 4.2. It isn't 806 clear if the service description can be independent of the lower 807 parts of the protocol or whether different descriptions would be 808 valid at different stages of protocol operation. This depends on the 809 particular service, and therefore to make NSIS service independent we 810 must allow that the service description part may be explicitly 811 dependent on the 'NSIS' fields which lie below. This is similar to 812 the ALSP/CSTP coupling described in [7]. 814 The distinction between the 'NSIS layer' and the 'Generic Signaling' 815 layer is not functionally clear cut, but one of convenience. In 816 outline: 817 *) The 'generic' layer provides (at most) functionality which might 818 be available from existing protocols, such as SCTP [8] or IPSec [9]. 819 An extreme case could be the binding update messages of mobility 820 signaling (section 5.3.4). 821 *) The 'NSIS' layer provides (at least) functionality which is 822 somehow specific to path-directed signaling. 824 Functionality reasonable to re-use from existing signaling protocols 825 might include reliability and re-ordering protection, dead peer 826 detection (keepalive), multihoming support, payload multiplexing 827 (piggybacking), and security services, such as establish a security 828 context and carrying out key exchange. 830 Functionality which would probably have to be in the NSIS layer would 831 include flow and reservation identification, some error handling, 832 demultiplexing between different resource types, as well as the basic 833 NSIS messages. More details on the messages are in section 4.3.2 and 834 the identifier aspects in section 4.5. 836 The choice of using functionality from an existing protocol or re- 837 specifying it as part of NSIS is for further analysis. It probably 838 depends on the function in question, and in the end might be left 839 flexible to allow optimization to local circumstances. (For example, 840 Diameter allows the use of IPSec for security services, but also 841 includes its own CMS application as an alternative.) Whichever 842 approach is taken, the combination of NSIS and supporting transport 843 protocol must provide a uniform protocol capability to the service 844 layer. 846 4.3.2 Protocol Messages 848 The NSIS specific part protocol will include a set of messages to 849 carry out particular operations along the signaling path. Initial 850 work for RSVP concentrated on the particular case of QoS reservation 851 signaling, although in principle, the necessary basic messages could 852 depend on the resource type NSIS is being used for. However, the 853 implication of the analysis in [7] is that this message set 854 generalizes to a wide variety of signaling scenarios, and so we use 855 it as a starting point. A very similar set was generated in [10]. 857 Hancock et al. Expires December 858 +-------+---------+---------------------------------------------+ 859 | Name |Direction| Semantics | 860 | | | | 861 +-------+---------+---------------------------------------------+ 862 |Request| I-->R | Create a new reservation for a flow | 863 +-------+---------+---------------------------------------------+ 864 |Modify | I-->R | Modify an existing reservation | 865 | |(&R-->I?)| | 866 +-------+---------+---------------------------------------------+ 867 |Release| I-->R & | Delete (tear down) an existing reservation | 868 | | R-->I | | 869 +-------+---------+---------------------------------------------+ 870 |Accept/| R-->I | Confirm (possibly modified?) or reject a | 871 | Reject| | reservation request | 872 +-------+---------+---------------------------------------------+ 873 |Notify | I-->R & | Report an event detected within the | 874 | | R-->I | network (e.g. congestion condition or end | 875 | | | of condition) | 876 +-------+---------+---------------------------------------------+ 877 |Refresh| I-->R | State management (see section 4.4) | 878 +-------+---------+---------------------------------------------+ 880 Note that the 'direction' column in this table only indicates the 881 'orientation' of the message. The messages can be originated and 882 absorbed at NF nodes as well as the NI or NR; an example might be NFs 883 at the edge of a domain exchanging NSIS messages to set up resources 884 for a flow across a it. 886 Note the working assumption that responder as well as the initiator 887 can release a reservation (comparable to rejecting it in the first 888 place). It is left open if the responder can modify a reservation, 889 during or after setup. This seems mainly a matter of assumptions 890 about authorization, and the possibilities might depend on resource 891 type specifics. 893 The table also explicitly includes a refresh message. This does 894 nothing to a reservation except extend its lifetime, and is one 895 possible state management mechanism for NSIS. This is considered in 896 more detail in section 4.4. 898 4.4 State Management 900 The prime purpose of NSIS is to manage state information along the 901 path taken by a data flow. There two critical issues to be considered 902 in building a robust protocol to handle this problem: 903 *) The protocol must be scalable. It should minimize the state 904 storage demands that it makes on intermediate nodes; in particular, 905 storage of state per 'micro' flow is likely to be impossible except 906 at the very edge of the network. 907 *) The protocol must be robust against failure and other conditions, 908 which imply that the stored state has to be moved or removed. 910 The total amount of state that has to be stored depends both on NSIS 911 and on the resource type it is being used to signal for. The resource 912 type might require per flow or lower granularity state; examples of 913 each for the case of QoS would be IntServ or RMD (per 'class' state) 914 respectively. The NSIS protocol should not overburden an application 915 that was otherwise lightweight in state requirement. However, 916 depending on design details, it might require storage of per-flow 917 state including reverse path peer addressing, simply for sending NSIS 918 messages themselves. 920 There are several robustness problems, which roughly align with the 921 'layers' of the NSIS protocols of Figure 2, that can be handled by 922 the soft state principle. (Independence of these layers therefore 923 implies the danger of duplication of functionality.) This relies on 924 periodic refresh of the state information with the current context, 925 relying on invalid state being timed out. Soft state can be used 926 either as the primary mechanism to handle the problem, or sometimes 927 as a backup to some other approach. 929 *) At the lowest level, soft state can be used to detect dead NSIS 930 peers - loss of several periodic messages implies termination of the 931 signaling. (The same inference can be made e.g. if failure is 932 detected at the link layer.) The assumption is then that the 933 corresponding reservation should be automatically deleted, and the 934 deletion propagated along the remainder of the path. 936 *) At the next level, in the event of a routing change (for example 937 caused by network changes or end host mobility), reservation state 938 should be removed from the old path and added to the new one. This 939 will be handled automatically by periodic messaging, provided that 940 the entities on the new path accept a Refresh message to install a 941 new reservation. (A partial alternative is to have a routing-aware 942 NSIS implementation, if the route change takes place at an NSIS-aware 943 node.) 945 *) At the highest level, a particular resource type might have timing 946 limits associated with a particular reservation (e.g. credit limited 947 network access). Periodic re-authorized requests can be used as part 948 of the time control. 950 All of these can be handled with a single soft state mechanism, 951 although it may be hard to choose a single refresh interval and 952 message loss threshold appropriate for all of them. Even where 953 alternative approaches are possible, for example using knowledge of 954 the fact that a routing change has occurred to trigger an explicit 955 NSIS release message, it seems that a soft state mechanism is always 956 necessary as a backup. 958 4.5 Identity Elements 960 NSIS will carry certain identifiers within the NSIS layer. The most 961 significant identifier needs seem to be the following. 963 4.5.1 Flow Identification 965 The flow identification is a method of identifying a flow in a unique 966 way. All packets and/or messages that are associated with the same 967 flow will be identified by the same flow identifier. In principle, it 968 could be a combination of the following information (note that this 969 is not an exclusive list of information that could be used for flow 970 identification): 971 *) source IP address; 972 *) destination IP address; 973 *) protocol identifier and higher layer (port) addressing; 974 *) flow label (typical for IPv6); 975 *) SPI field for IPSec encapsulated traffic; 976 *) DSCP/TOS field 978 We've assumed here that the flow identification is not hidden within 979 the service definition, but is explicit as part of the basic NSIS 980 protocol. The justification for this is that it might be valuable to 981 be able to do NSIS processing even at a node which was unaware of the 982 specific resource type and service definitions in question; this 983 would be a case of an NSIS forwarder with no interface to any 984 resource management function. An example scenario would be NSIS 985 messages passing through an addressing boundary where the flow 986 identification had to be re-written. 988 The very flexibility possible in flow classification is a possible 989 source of difficulties: when wildcards or ranges are included, it is 990 probably unreasonable to assume a standard classification capability 991 in routers; on the other hand, negotiating this capability would be a 992 significant protocol complexity. 994 4.5.2 Reservation Identification 996 There are several circumstances where it is important to be able to 997 refer to a reservation independently of whatever other information is 998 associated with it. The prime example is a mobility-induced address 999 change (handover) which required the flow identifier associated with 1000 a reservation to be rewritten without installing a totally new 1001 reservation (see section 5.3.1 for some security and scoping 1002 implications of this use). The same capability could also be used to 1003 simplify refresh or release messages in some circumstances, and might 1004 be useful within the protocol to resolve reservation collisions 1005 (where both sender and receiver initiate for the same flow). 1007 A reservation identifier performs these roles. It is open how the 1008 reservation identifier space should be defined and managed, and what 1009 the scope of the identifier should be (only peer-peer, or end-end, 1010 when interpreted in conjunction with some of the addressing 1011 information). Some of the necessary identifier functions, especially 1012 to do with local operation of NSIS, may also be provided by lower 1013 layer signaling transport protocols. 1015 4.5.3 Resource Type Identification 1017 Since NSIS can be used to support several uses, there is a need to 1018 identify which resource type a particular NSIS invocation is being 1019 used to signal for, and this needs to be done outside the (opaque) 1020 service description: 1021 *) processing incoming request messages at a responder - the NSIS 1022 layer should be able to demultiplex these towards the appropriate 1023 upper layer; 1024 *) processing general NSIS messages at an NSIS aware intermediate 1025 node - if the node does not handle the specific resource type, it 1026 should be able to make a forwarding decision without having to parse 1027 the service description. 1029 Resource type identifiers would probably require an IANA registry. 1031 5. NSIS and other Functions and Protocols 1033 5.1 Resource Management and Network Provisioning 1035 It is a requirement for the NSIS protocol to be independent of 1036 resource allocation and management techniques that may be used in the 1037 network. As such, we need to define the interaction between NSIS and 1038 what we will call the Resource Management Function (RMF). The RMF is 1039 responsible for all network provisioning and resource allocation 1040 functions. 1042 In its resource provisioning role, the RMF can act as a client 1043 towards the NSIS protocol, as a particular "application" triggering 1044 an NI for resources in the network. This situation is depicted in 1045 Figure 3 and Figure 4. 1047 +-----+ 1048 +----------| RMF |-----------+ 1049 / +-----+ \ 1050 / COPS \ 1051 / \ 1052 / \ 1053 +----+ NSIS +-----+ NSIS +----+ 1054 | NI |------------| NF |-------------| NR | 1055 +----+ +-----+ +----+ 1057 Figure 3: Centralized RMF as a client to NSIS 1059 +----+ +----+ +----+ 1060 |RMF | |RMF | |RMF | 1061 +----+ +----+ +----+ 1062 +----+ NSIS +----+ NSIS +----+ 1063 | NI |------------| NF |-------------| NR | 1064 +----+ +----+ +----+ 1066 Figure 4: Distributed RMF as a client to NSIS 1068 When the RMF is distributed in the network, a protocol for 1069 communication with the NI, NF, NR may not be required. In this case 1070 the RMF is providing traffic classification and conditioning 1071 functions; an example of such functionality is described in [11]. 1073 Conversely, the RMF can be a server to an NI, NF or NR controlling a 1074 complete domain. In the centralized case, it would be natural to 1075 formalize the relation between the nodes containing NEs and the 1076 central RMF as a Service Level Agreement (SLA). In order to shield 1077 the NE from (resource specific) SLA aspects, we would model the 1078 interaction as being via some kind of local 'proxy' the RMF. This 1079 situation is depicted schematically in Figure 5. Figure 6 shows the 1080 corresponding distributed case. Note that the functional split 1081 between the NE and RMF is the same in each case; in other words the 1082 same NSIS functionality supports both scenarios. 1084 In case of centralized RMF, the SLA or its technical part, the 1085 Service Level Specification (SLS) [12] specifies the resource 1086 guarantees that the RMF needs to provide. These guarantees apply 1087 between one or more ingress and egress points of the network. The SLS 1088 also specifies the availability and reliability of the service. In 1089 the case of QoS signaling, it may refer to a bandwidth service with 1090 certain performance guarantees regarding delay, jitter or packet 1091 loss. 1093 +----+ NSIS +------+ NSIS +----+ 1094 | NI |------------| NF |-------------| NR | 1095 +----+ +------+ +----+ 1096 +------+ 1097 | pRMF | 1098 +------+ 1099 | 1100 | SLA 1101 | 1102 +------+ 1103 | RMF | 1104 +------+ 1106 Figure 5: Centralized RMF as a server to NSIS 1108 +----+ NSIS +-----+ NSIS +----+ 1109 | NI |------------| NF |-------------| NR | 1110 +----+ +-----+ +----+ 1111 +----+ +-----+ +----+ 1112 |RMF | | RMF | |RMF | 1113 +----+ +-----+ +----+ 1115 Figure 6: Distributed RMF as a server to NSIS 1117 The decoupling of NSIS signaling and network management by means of 1118 an SLS has some attractive properties: 1119 - It allows a Network Provider to easily share the use of its 1120 infrastructure between several Service Providers using NSIS signaling 1121 to provide their service. 1122 - It allows a clear separation between resource provisioning and 1123 management and reservation signaling and admission control. 1124 - It relieves the NF from several tasks, making it potentially more 1125 scalable in the core of the network. 1127 The resource management system can perform either per-flow or per- 1128 class admission control decisions based on the requested QoS 1129 information and on the reservation state it keeps regarding active 1130 flows (or classes). Keeping per-flow state may be required for 1131 policing, accounting/billing and explicit reservation teardown. Per- 1132 flow based functions can be mandatory in some parts of the network, 1133 e.g., end host to first hop router, or at the edge of the network or 1134 at the boundary of a network domain. Conveniently, this is also where 1135 the processing needed to maintain per-flow state will remain 1136 manageable. In the core, this approach may not scale very well and 1137 per-class state may be used as an alternative that is very scalable 1138 and allows for a lightweight processing of signaling messages. With 1139 per-class state, however, we lose the ability to directly notify the 1140 NE in case of unsolicited network events because the affected flows 1141 cannot be identified. Instead, the situation needs to be detected 1142 from the response to a refresh message which in turn mandates the use 1143 of soft-state with separate messages or message structure for 1144 requests and refreshes. 1146 The RMF can execute its network provisioning functions according to 1147 its internal policies. In the easiest case, it may run an 1148 overprovisioned network with only monitoring capabilities in order to 1149 follow up on the delivered performance. In more complex scenarios, it 1150 may use a whole array of network optimization tools in order to 1151 deliver and maintain service quality according to the SLS. 1153 5.2 IP Routing 1155 Several situations may occur when routing diverges from standard 1156 layer 3 routing. These are summarized in the sections below. 1158 5.2.1 Load Sharing 1160 Load sharing or load balancing is a network optimization technique 1161 that exploits the existence of multiple paths to the same destination 1162 in order to obtain benefits in terms of protection, resource 1163 efficiency or network stability. The significance of load sharing in 1164 the context of NSIS is that, if the load sharing mechanism in use 1165 will forward packets on any basis other than source and destination 1166 address, routing of NSIS messages using end-to-end addressing does 1167 not guarantee that the messages will follow the data path. In this 1168 section, we briefly survey what standard methods have been used for 1169 load sharing within standard routing protocols. 1171 In OSPF, load balancing can be used between equal cost paths [13] or 1172 unequal cost paths. An example of the latter approach is Optimized 1173 Multi Path (OMP). OMP discovers multiple paths, not necessarily equal 1174 cost paths, to any destinations in the network, but based on the load 1175 reported from a particular path, it determines which fraction of the 1176 traffic to direct to the given path. Incoming packets are subject to 1177 a (source, destination address) hash computation, and effective load 1178 sharing is accomplished by means of adjusting the hash thresholds. 1180 BGP [14][15] advertises the routes chosen by the BGP decision process 1181 to other BGP speakers. In the basic specification, routes with the 1182 same Network Layer reachability information (NLRI) as previously 1183 advertised routes implicitly replace the original advertisement, 1184 which means that multiple paths for the same prefix cannot exist. 1185 Recently, however, a new mechanism was defined that will allow the 1186 advertisement of multiple paths for the same prefix without the new 1187 paths implicitly replacing any previous ones [16]. The essence of the 1188 mechanism is that each path is identified by an arbitrary identifier 1189 in addition to its prefix. 1191 The distribution of traffic over the available path may be done per 1192 destination, per message in a round-robin fashion or with a 1193 predefined hashing function. The determination of the hashing image 1194 may take into account the source/destination IP address, QoS 1195 information such as the DSCP or protocol ID. When the routing 1196 decision is no longer based on the destination address only, however, 1197 there is a risk that data plane messages and control plane messages 1198 will not follow the same route. 1200 5.2.2 QoS Routing 1202 The are several proposals for the introduction of QoS awareness in 1203 the routing protocols. All of these essentially lead to the existence 1204 of multiple paths (with different QoS) towards the same destination. 1205 As such, they also contain an inherent risk for a divergence between 1206 control plane and data plane, similar to the load sharing case. 1208 For intra-domain traffic, the difference in routing may result from a 1209 QoS-aware traffic engineering scheme, that e.g. maps incoming traffic 1210 to LSPs based on multi-field classification. In BGP, several 1211 techniques for including QoS information in the routing decision are 1212 currently proposed. A first proposal is based on a newly defined BGP- 1213 4 attribute, the QoS_NLRI attribute [17]. The QoS_NLRI attribute is 1214 an optional transitive attribute that can be used to advertise a QoS 1215 route to a peer or to provide QoS information in along with the 1216 Network Layer Reachability Information (NLRI) in a single BGP update. 1217 A second proposal is based on controlled redistribution of AS routes 1218 [18]. It defines a new extended community (the redistribution 1219 extended community) that allows a router to influence how a specific 1220 route should be redistributed towards a specified set of eBGP 1221 speakers. The types of redistribution communities may result in a 1222 specific route not being announced to a specified set of eBGP 1223 speakers, that it should not be exported or that the route should be 1224 prepended n times. 1226 5.2.3 Route pinning 1228 Route pinning refers to the independence of the path taken by certain 1229 data packets from reachability changes caused by routing updates from 1230 an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway 1231 Protocol (BGP). This independence may for instance be caused by the 1232 configuration of static LSPs or by the establishment of explicitly 1233 routed LSPs by means of a signaling protocol (RSVP-TE or CR-LDP). If 1234 the NSIS signaling messages follow standard Layer 3 routing, this may 1235 cause a divergence between control plane and data plane. If 1236 reservations are made on the control plane, this may result in 1237 sending data along an unreserved path while maintaining a reservation 1238 on a path that is not used. 1240 5.2.4 Route changes 1242 In this section, we will explore the expected interworking between a 1243 signaling for resource BGP routing updates, although the same applies 1244 for any source of routing updates. The normal operation of the NSIS 1245 protocol will lead to the situation depicted in Figure 7, where the 1246 reserved resources match the data path. 1248 reserved +----+ reserved +----+ 1249 ------->| NF |----------->| NF | 1250 +----+ +----+ 1251 ===================================== 1252 data path 1254 Figure 7: Normal NSIS protocol operation 1256 A route change (triggered by a BGP routing update for instance) can 1257 occur while such a reservation is in place. In case of RSVP, the 1258 route change will be installed immediately and any data that is sent 1259 will be forwarded on the new path. This situation is depicted Figure 1260 8. 1262 BGP route update 1263 | 1264 v 1265 reserved +----+ reserved +----+ 1266 ------->| NF |----------->| NF | 1267 +----+ +----+ 1268 ========== | 1269 || | +----+ 1270 || +---------->| NF | 1271 || +----+ 1272 ============================ 1273 data path 1275 Figure 8: Route Change 1277 Resource reservation on the new path will only be started once the 1278 next control message is routed along the new path. This means that 1279 there is a certain time interval during which resources are not 1280 reserved on (part of) the data path. To minimize this time interval 1281 several techniques could be considered. As an example, RSVP [19] has 1282 the concept of local repair, where the router may be triggered by a 1283 route change. In that case the RSVP node can start sending PATH 1284 messages directly after the route has been changed. Note that this 1285 option may not be available for NSIS if no per-flow state is kept in 1286 the NF. 1288 It is not guaranteed that the new path will be able to provide the 1289 same guarantees that were available on the old path. Therefore, in a 1290 more desirable scenario, the NF should wait until resources have been 1291 reserved on the new path before installing the route change. The 1292 route change procedure then consists of the following steps: 1293 1. NF receives a route announcement, 1294 2. Refresh messages are forwarded along the current path, 1295 3. A copy of the refresh message is remarked as request and send 1296 along the new path that was announced, 1297 4. When the NF has been acknowledged about the reservations on the 1298 new path the route will be installed and the traffic will flow along 1299 the new path. 1301 Another example related to route changes is denoted as severe 1302 congestion and is explained in [20]. This solution adapts to a route 1303 change, when a route change creates a congestion on the new routed 1304 path. 1306 5.3 Mobility Support 1308 The interactions between mobility and resource signaling protocols 1309 have been quite extensively analyzed in recent years, primarily in 1310 the context of RSVP and Mobile IP interaction (e.g. [21]), but also 1311 in the context of other types of network (e.g. [22]). This analysis 1312 work has shown that some difficulties in the interactions are quite 1313 deep seated in the detailed design of these protocols; however, the 1314 problems and their possible solutions fall under five broad headings. 1315 The main issue is to limit the period after handovers during which 1316 the resource state has not been installed on the path, in particular 1317 the new part of the path. 1319 We can use this work as the starting point for considering the 1320 framework aspects of a new resource signaling protocol like NSIS, 1321 which will need to interwork with mobility signaling, e.g., Mobile 1322 IP, or mobility paradigms using micromobility, or application layer 1323 approaches. 1325 5.3.1 Addressing and Encapsulation 1327 A mobility solution typically involves address reallocation on 1328 handover (unless a network supports per host routing) and may 1329 involve special packet formats (e.g. the routing header and Home 1330 Address option of MIPv6). Since NSIS may depend on end system 1331 addresses for forwarding signaling messages and defining flows 1332 (section 4.5.1), the special implications of mobility for addressing 1333 need to be considered. Examples of possible approaches that could be 1334 used to solve the addressing and encapsulation problem are as 1335 follows: 1336 *) Use a filter definition based on low level IP addresses (e.g. the 1337 Care of Address) and other 'standard' fields in the IP header. This 1338 makes least demands on the packet classification engines within the 1339 network. However, it means that even on a part of the flow path 1340 which is unchanged, the reservation will need to be modified to 1341 reflect the changed flow identification (see section 5.3.3). 1342 *) Use a flow definition that does not change (e.g. based on Home 1343 Address); this is the approach assumed in [23]. This simplifies the 1344 problem of reservation update, at the likely cost of considerably 1345 complicating the flow identification requirements. 1347 In the first approach, to prevent double reservation, NSIS nodes need 1348 to be able to recognize that a reservation with the new flow 1349 identifier is to be correlated with an existing one. The reservation 1350 identifier (section 4.5.2) was introduced for exactly this purpose. 1351 Note that this would require the reservation identifier to have 1352 (secure) end to end significance. (An additional optimization here 1353 would be use a local mobility management scheme to localize the 1354 visibility of the address change.) 1356 The feasibility and performance of this approach needs to be 1357 assessed, including a detailed analysis of the signaling scenarios 1358 after a handover. However, given the high impact of requiring more 1359 sophisticated packet classifiers, initially it still seems more 1360 plausible than the second approach. This implies that the NSIS 1361 initiator should define flows in terms of real (care of) addresses 1362 rather than virtual (home) addresses. Thus, it would have detailed 1363 access to lower layer interface configuration (cf. section 4.1), 1364 rather than operating as a pure application level daemon as is 1365 commonplace with current RSVP implementations. 1367 5.3.2 Localized Path Repair 1369 In any mobility approach, a handover will cause at least some changes 1370 in the path of upstream and downstream packets. NSIS needs to 1371 install new state on the new path, and remove it on the old. 1372 Provided that some NSIS node on the joined path - the crossover 1373 router - can recognize this situation (which again depends on 1374 reservation identification), state installation and teardown can be 1375 done locally between it and the mobile node. (This may have 1376 implications for which entities are allowed to generate which 1377 message types, see section 4.3.2). It seems that the basic NSIS 1378 framework already contains the fundamental components necessary for 1379 this. 1381 A critical point here is the signaling that is used to discover the 1382 crossover router. This is a generalization of the problem of finding 1383 next-NSIS-hop nodes: it requires extending the new path over several 1384 hops until it intersects the old one. This is easy for uplink traffic 1385 (where the mobile is the sender), but much harder for downlink 1386 traffic without signaling via the correspondent. There is no reason 1387 for the crossover routers for uplink and downlink flows to be the 1388 same, even for the same correspondent. The problem is discussed 1389 further in [24]. 1391 5.3.3 Reservation Update on the Unchanged Path 1393 On the path between the crossover router(s) and the correspondent, it 1394 is necessary to avoid, if possible, double reservations, but rather 1395 to update the reservation state to reflect new flow identification 1396 (if this is needed, which is the default assumption of section 1397 5.3.1). Examples of approaches that could be used to solve this 1398 problem are the following: 1399 *) Use a reservation state definition that does not change even if 1400 the flow definition changes (see Section 4.5.2). In this case this 1401 problem is solved. 1402 *) Use signaling all the way to the correspondent node (receiver 1403 end host), accepting the additional latency that this might impose. 1404 *) Use an NSIS-capable crossover router that manages this 1405 reservation update autonomously (more efficiently than the end 1406 nodes), with similar considerations to the local path repair case. 1408 5.3.4 Interaction with Mobility Signaling 1410 In existing work on mobility protocol and resource signaling protocol 1411 interactions, several framework proposals describing the protocol 1412 interactions have been made. Usually they have taken existing 1413 protocols (Mobile IP and RSVP respectively) as the starting point; it 1414 should be noted that an NSIS protocol might operate in quite a 1415 different way. In this section, we provide an overview of how these 1416 proposals would be reflected in framework of NSIS. The mobility 1417 aspects are described using Mobile IP terminology, but are generally 1418 applicable to other network layer mobility solutions. The purpose of 1419 this overview is not to select or priorities any particular approach, 1420 but simply to point out how they would fit into our framework and 1421 point out any major issues with them. 1423 We can consider that two signaling processes are active: mobility 1424 signaling (e.g. Binding updates or local micromobility signals) and 1425 NSIS. The discussion so far considered how NSIS should operate. There 1426 is still a question of how the interactions between the NSIS and 1427 mobility signaling should be considered. 1429 The basic case of totally independent specification and 1430 implementation seems likely to lead to ambiguities and even 1431 interoperability problems (see [23]). At least, the addressing and 1432 encapsulation issues for mobility solutions that use virtual links or 1433 their equivalents need to be specified in an implementation-neutral 1434 way. 1436 A type of 'loose' integration is to have independent protocol 1437 definitions, but to define how they trigger each other - in 1438 particular, how the mobility protocol triggers NSIS to send 1439 refresh/modify/tear messages. A pair of implementations could use 1440 these triggers to improve performance, primarily reducing latency. 1441 (Existing RSVP modification consider the closer interaction of making 1442 the RSVP implementation mobility-routing aware, e.g. so it is able to 1443 localize refresh signaling; this would be a self contained aspect of 1444 NSIS.) This information could be developed for NSIS by analyzing 1445 message flows for various mobility signaling scenarios as was done in 1446 [21]. 1448 An even tighter level of integration is to consider a single protocol 1449 carrying both mobility and resource information. Logically, there are 1450 two cases: 1451 1. Carry mobility routing information (a 'mobility object') in the 1452 resource messages, as is done in [23]. (The prime purpose in this 1453 approach is to enable crossover router discovery.) 1454 2. Carry resource signaling in the mobility messages, typically as a 1455 new extension header. This was proposed in [25] and followed up in 1456 [26]; [27] also anticipates this approach. In our framework, we could 1457 consider this a special case of NSIS layering, with the mobility 1458 protocol playing the role of the signaling transport (as in 4.3.1). 1459 The usefulness of this class of approach depends on a tradeoff 1460 between specification simplicity and performance. Simulation work is 1461 under way to compare the performance of the two approaches in the 1462 case of RSVP and micromobility protocols. 1464 Other modes of interaction might also be possible. The critical point 1465 with all these models is that the general solutions developed by NSIS 1466 should not depend fundamentally on the choice of any particular 1467 mobility protocol. Especially if it has interdomain scope, tight 1468 integration would have major deployment issues; loose integration 1469 could require NSIS implementations to hook into multiple different 1470 mobility protocols. Therefore, any integrated solution should be 1471 considered out of scope of initial NSIS development, and even in the 1472 long term is probably only applicable if it can be localized within a 1473 particular part of the network. 1475 5.3.5 Interaction with Fast Handoff Support Protocols 1477 In the context of mobility between different access routers, it is 1478 common to consider performance optimizations in two areas: selection 1479 of the optimal access router to handover to, and transfer of state 1480 information between the access routers to avoid having to regenerate 1481 it in the new access router after handover. The seamoby working group 1482 is developing solutions for these protocols for pure IP based 1483 networks (CARD and CT respectively); other networks, which use NSIS 1484 for resource signaling within the network, may use different types of 1485 solution. 1487 In this section, we consider how NSIS should interact with these 1488 functions, however they are implemented. Detailed solutions are not 1489 proposed, but the way in which interaction these functions is seen 1490 within the NSIS framework is described. NSIS should be able to 1491 operate independently of these protocols. However, significant 1492 performance gains could be achieved if they could be made to 1493 cooperate. In addition, the resource signaling aspects of these 1494 protocols could profitably use a common set of resource types and 1495 definitions with NSIS to avoid a proliferation of incompatible 1496 service models (also since at any given node, these protocols will 1497 probably interface to common resource management functions). 1499 The question arises, what the mode of interaction should be: 1500 independent operation, NSIS triggering access router discovery and 1501 state transfer, or vice versa. The questions for the two cases seem 1502 to be independent. 1504 For access router discovery, a typical model of operation is that the 1505 mobile carries out an information gathering exercise about a range of 1506 capabilities. In addition, where those capabilities relate purely to 1507 the AR and mobile, there is no role for NSIS (its special 1508 functionality is not relevant). However, considering resource 1509 aspects, one aspect of the AR 'capability' is resource availability 1510 on the path between it and the correspondent, and NSIS should be able 1511 to fulfill this part. Indeed, this is effectively precisely the 1512 application considered in [26], where it is a sort of special case of 1513 resource signaling during handover. 1515 Therefore, a possible model of access router discovery/NSIS 1516 relationship is that some entity in a candidate AR triggers NSIS 1517 using resource and reservation information (including reservation id) 1518 from the current AR to find out about what would be available on the 1519 new path. Note that this should be a query rather than an actual 1520 reservation; this semantic could be included either in the service 1521 definition or NSIS itself. 1523 The case of state transfer is more complex. There are two obvious 1524 options, corresponding to whether one transfer just resource state or 1525 NSIS state as well: 1526 1. "State transfer triggering NSIS": A state transfer process passes 1527 the 'raw' resource state to the new AR. This triggers a new instance 1528 of NSIS to request that resource. 1529 2. "NSIS using state transfer": NSIS transfers its own state 1530 information from the old to the new AR. It can then carry out the 1531 same update signaling as though it was a single 'virtual AR' which 1532 had just had a topology change towards the correspondent. (This is 1533 essentially the conceptual model of [21].) 1535 The first model is simpler, and maybe more in line with the basic 1536 state transfer expectation; however, it seems hard to avoid double 1537 reservations since the two NSIS protocol instances are not 1538 coordinated. Therefore, the second model seems more appropriate. An 1539 advantage of the 'virtual AR' model is that it ensures that the 1540 impact of the interaction is limited to the NSIS instances at ARs 1541 themselves, since the rest of the network must be able to handle a 1542 topology change anyway. 1544 Note that there is an open issue of who is responsible between the 1545 mobile and AR to decide that the state transfer procedures have not 1546 happened for whatever reason - e.g. because they were not even 1547 implemented - and take recovery action to have the mobile refresh 1548 reservations promptly. It appears this has to be an NSIS 1549 responsibility in the AR, and probably requires a custom notification 1550 message for this circumstance. 1552 5.4 Existing Resource Signaling Protocols 1554 It is hoped that an NSIS protocol could eventually achieve widespread 1555 use for resource signaling. However, it is bound to have to inter- 1556 operate with existing resource signaling protocols at least during 1557 transition and possibly long term. The prime example here is RSVP, 1558 although other proprietary or domain specific protocols (e.g. 1559 bandwidth broker related) may also be considered. A related issue is 1560 that NSIS will be only one part of a resource control solution: it 1561 will always need to interwork with other resource-related protocols 1562 (e.g. COPS). 1564 Analyzing the constraints on NSIS that come from these requirements 1565 is hard before further refinement of the framework has been carried 1566 out and critical assumptions pinned down. However, we can identify 1567 various modes of interoperation, and the attributes of the framework 1568 that will make them easy. 1570 Firstly, we should allow for NSIS to be used over a 'long range', in 1571 conjunction with a different protocol locally (e.g. intra-domain); 1572 or, the two roles could be reversed. This is actually very similar to 1573 the case of use of NSIS layered over itself (section 5.5). In the 1574 case where the 'inter-layer' interaction is mediated via resource 1575 management, the same should approach should work with non-NSIS 1576 protocols. What needs to be validated here is whether NSIS layering 1577 requires the exchange of NSIS specific information between the 1578 layers. 1580 A second issue is that NSIS should be able to be deployed within an 1581 environment without radical changes to supporting resource (or AAA) 1582 related protocols. The main issue here is that NSIS should be 1583 flexible in its ability to support different service definitions (and 1584 possibly flow classifications). This is already one of the main goals 1585 of the framework presented here. 1587 The final point is that it should be possible to use NSIS over one 1588 network region, concatenated with another protocol over an adjacent 1589 region. The main issue here, apart from the flexible service and flow 1590 capabilities already mentioned, is that NSIS should be adaptable in 1591 what signaling paths (e.g. to interwork with both on- and off-path 1592 solutions), and in initiation paradigms (e.g. to interwork with 1593 sender and receiver initiated solutions). 1595 5.5 Multi-Level NSIS Signaling 1597 This section describes a way of separating the NSIS signaling 1598 protocol into more than one hierarchical level. In this section three 1599 levels of hierarchy are considered (see Figure 9); however, the 1600 approach is quite general to more (or fewer) levels: the important 1601 issue is the use of NSIS at more than one level at all. 1603 The lowest hierarchical level ("level 1") provides basic resource 1604 management functionality related to scalable, simple and fast soft 1605 state maintenance and to transport functions, such as reliable 1606 delivery of signaling messages, congestion control notification and 1607 load sharing adaptation. Soft state that is maintained by this level 1608 is usually per traffic class based. 1610 The second hierarchical level ("level 2") is more complex than level 1611 1 as regards soft state maintenance. Soft state maintained by this 1612 hierarchical level is usually per flow. Note that this level, like 1613 level 1, also supports transport functions. When an NSIS edge-to- 1614 edge multi-domain protocol is used, level 2 stretches beyond domain 1615 boundaries and is applied on all the edges of the domains that are 1616 included in the multidomain region. 1618 The third hierarchical level ("level 3") includes a set of upper- 1619 level signaling functions that are specific to particular signaling 1620 applications. Such functions could, for example, be security, policy, 1621 billing, etc. 1623 As shown in Figure 9, the three hierarchical levels might be applied 1624 on different NSIS entities. 1626 This three-level architecture for NSIS signaling can be provided by 1627 using: 1629 * a single end-to-end NSIS protocol that supports all three 1630 hierarchical levels 1632 * two independent NSIS protocols: Level 3 is supported by an end- 1633 to-end NSIS protocol, and levels 1 and 2 are supported by another 1634 edge-to-edge NSIS protocol. 1636 |-----| |-------| |-------| |-----| 1637 |level|<--| level |<--------------------------| level |<->|level| 1638 | 3 |<--| 3 | | 3 |<->| 3 | 1639 |-----| |-------| |-------| |-----| 1640 | | | | | | | | 1641 | | |-------| |-------| | | 1642 | | | level |<------------------------->| level | | | 1643 | | | 2 | | 2 | | | 1644 | | |-------| |-------| | | 1645 | | | | | | | | 1646 |-----| |-------| |-------| |-------| |-------| |-----| 1647 |level|<->| level |<->| level |<->| level |<->| level |<->|level| 1648 | 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 | 1649 |-----| | | | 1650 ------- -------| |-------| |-------| |-----| 1651 NI NF NF NF NF NR 1652 (edge) (interior) (interior) (edge) 1654 Figure 9: Three level architecture for NSIS signaling 1656 * NI (NSIS Initiator): can be an end-host or a proxy and 1657 can process and use the "level 1" and "level 3" protocol 1658 components 1660 * NR (NSIS Responder): can be an end-host or a proxy and 1661 can process and use the "level 1" and "level 3" protocol 1662 components 1664 * NF (NSIS Forwarder) (edge): can be a Diffserv edge, 1665 MPLS edge, etc. It can process and use the "level 3", 1666 "level 2" and "level 1" protocol components. Usually, 1667 "level 2" provides an interworking between "level 1" and 1668 "level 3" protocol components. 1670 * NF (interior): can be any router within a domain. It can 1671 process and use only the "level 1" protocol component. 1672 The "level 3" and "level 2" protocol components are not 1673 processed (used or checked); 1675 The hierarchical level separation can be provided by supporting a 1676 hierarchical object structure. In other words, the NSIS protocol 1677 objects should be structured and positioned within the NSIS messages 1678 in a hierarchical way, i.e., first the "level 1" objects, then the 1679 "level 2" objects and finally the "level 3" objects. 1681 6. Security and AAA Considerations 1683 A framework is meant to create boundaries for a later protocol and to 1684 describe the interaction between the protocol and its environment. 1685 Security issues usually turn out to have impacts in the interaction 1686 of these protocols and must therefore be appropriately addressed in 1687 such a framework. This section describes these general security 1688 issues, and in particular considers the interactions between NSIS and 1689 authentication, authorization and accounting. Together with 1690 authentication the protection of the signaling messages is addressed 1691 - namely replay and integrity protection. 1693 An initial analysis of the major security threats that apply in the 1694 typical of scenario where NSIS is expected to be used is given in 1695 [4]; these threats are described at the overall scenario level, in 1696 terms of the impact on users and networks. However, in any given 1697 scenario, NSIS will be just one protocol or component of the overall 1698 solution. Ultimately, the framework will need to what aspects of 1699 these threats need to be handled by NSIS compared to the other 1700 components. Currently, we can only make initial scoping assumptions 1701 of this sort. 1703 6.1 Authentication 1705 Authentication (and key establishment) for a signaling protocol 1706 should be seen as a two-phase process. The first-phase is usually 1707 more performance intensive because of a larger number of roundtrips, 1708 denial of service protection, cross-realm handling, interaction with 1709 other protocols and the likely larger cryptographic computation 1710 associated with it. As stated in section 4.3, this functionality 1711 could be provided externally to NSIS, e.g. by reusing a standard 1712 transport protocol which already included this functionality. At the 1713 end of this phase it should be possible to create or derive security 1714 associations that are usable for the protection of the NSIS signaling 1715 messages themselves. The functionality required here relates to 1716 (data origin) authentication (including integrity and replay 1717 protection) of individual signaling messages. Key establishment, 1718 rekeying, synchronization issues are issue that may be addressed here 1719 depending on the specific method. In any case the protection applied 1720 to each signaling message must be fast and efficient. 1722 When using cryptography to protect signaling messages, it is obvious 1723 that a node must be able to select the appropriate security 1724 association in order to be able to apply signaling message 1725 protection. This should just be a general point about endpoint 1726 identity issues. Hence the identity identifier must be available to 1727 the transmitting node. Regarding identities there is a need to 1728 support different identity types to enable the flexible usage of 1729 several signaling initiators and receivers. Supporting static 1730 configuration and dynamic learning of these identities should be 1731 provided. 1733 6.2 Authorization 1735 Authorization information can be seen in an abstract form as "Can the 1736 resource requestor be trusted to pay for the reservation?". This 1737 abstraction is supported by the fact that reservations require some 1738 form of incentive to use some 'default' resource (or vice versa - 1739 penalty for not reserving too many resources). In general, the 1740 semantics of the authorisation will depend on the type of resource 1741 (QoS, firewall configuration etc.) that NSIS is being used to signal 1742 for. The implication of this is that NSIS will not directly make 1743 authorisation decisions; instead, the authorisation information must 1744 be fed into the resource management function (section 5.1) which 1745 actually decides the allocation (or rejection) of the request. 1747 Some negotiation needs to take place to determine which node will 1748 take responsibility for authorising a resource request, the 1749 implication being that the same node will ultimately be accounted to 1750 for it. Such a negotiation needs to be flexible enough to support 1751 most currently deployed schemes (e.g. reverse charging, etc.) while 1752 keeping efficiency and simplicity in mind. This negotiation might be 1753 executed before starting resource signaling (assumed in section 4.2), 1754 although it could also be part of the NSIS signaling messages (as in 1755 some proposals dealing with charging and RSVP). Since information 1756 needs to be sent to the networks, some information needs to be 1757 included to provide the network with the necessary information to 1758 start the authorisation process. Hence fully opaque objects might not 1759 always be the proper choice. 1761 It is not clear if 'initiation' of a reservation is related to 1762 willingness to accept authorisation responsibility. (Current 1763 practices tend to assume that flow originators are responsible.) In 1764 any case, it seems unlikely that a domain will make a cost-incurring 1765 request of a peer domain without already having received a matching 1766 request from the peer in the other direction - in other words, 1767 requests must propagate between domains in the same direction as 1768 authorisation responsibility. If this argument is correct, and if 1769 NSIS initiation and authorisation responsibility are decoupled, it 1770 must be possible for the authorisation responsibility to propagate 1771 both in the direction initiator->responder and vice versa. Also, if 1772 both [flow] sender and receiver initiation are possible, service 1773 descriptions must include information about the authorisation policy 1774 to be applied, which must be imposed consistently along the whole 1775 path. These issues should be analyzed to determine if 1, 2 or 4 1776 alternative scenarios are possible and realistic. 1778 A second question is that of which entities actually authorise which. 1779 One end user must ultimately get authorisation for the request (this 1780 may or may not be assumed to be the NSIS initiator, see below). There 1781 are then two possible models for how this authorisation is done 1782 throughout the path. 1784 The first model assumes that each network along the path is able to 1785 authenticate and authorise the user directly. The implication for a 1786 signaling protocol is that the user credentials cannot be removed 1787 after the first hop and have to be further included in the message 1788 when forwarded to other networks. Every node along the path is then 1789 able to verify the user and to provide policy based admission 1790 control. 1792 The second model assumes that the user credentials are removed at the 1793 first hop. The first network knows the user identity requesting the 1794 resources but does not include this information further along the 1795 path. The first network can therefore be seen as acting on behalf of 1796 the originator to take responsibility to enable further reservations 1797 to be done along the path i.e. in particular to the next network 1798 only. This procedure is then applied in a hop-by-hop basis. 1800 Note that both models are independent on whether a traditional 1801 subscription based approach or an alternative means of payment (such 1802 as pre-pay on on-line charging by the visited network) is used. These 1803 issues only have an impact for the transmission of accounting records 1804 and for a requirement to execute an online verification whether a 1805 user still has sufficient credits/funds; therefore, these details do 1806 not affect NSIS operation. 1808 6.3 Accounting 1810 It is obvious that accounting/charging is an important part for the 1811 success and the acceptance of a resource signaling protocol. Most of 1812 the thinking in this area is derived from the specific case of 1813 signaling for QoS; however, we make an initial working assumption 1814 that the same paradigms should apply to signaling for any type of 1815 resource for which accounting is necessary. We can only refer to QoS 1816 as an example. We make the general assumption here that accounting 1817 records are generated by the resource management function based 1818 entirely on traffic measurements and processed in accordance with the 1819 authorisation information that was used in deciding to grant the 1820 request in the first place. 1822 Therefore, NSIS plays no further part in this activity; the 1823 accounting records are transmitted using the AAA infrastructure, and 1824 charging and billing for the overall service is carried out at some 1825 higher layer. This would include feedback to applications (and users) 1826 about total session cost (of which the network resource cost might be 1827 only a part). An open issue is whether a query (without actually 1828 making a reservation) to the network should also generate a 1829 chargeable event; this could be considered as an aspect of the 1830 service definition. 1832 6.4 End-to-End vs. Peer-Session Protection 1834 It is reasonable to assume that peer-session security (with chain-of- 1835 trust) is used for most signaling environments relevant to NSIS. 1836 Especially the separation of signaling into different network parts 1837 (intra-domain within the access network, end-node to access network, 1838 intra-domain, and so on) and new proposals regarding mobility and 1839 proxy support show that the traditionally end-to-end signaling nature 1840 is not applicable in every environment (or possibly only in a minor 1841 number of environments). End-to-end security in a signaling protocol 1842 is actually problematic for two reasons: 1844 a) Even if the messages use the address of the end-host (to support 1845 routing) if in path signaling is used then still the messages have to 1846 be interpreted and modified along the path. 1848 b) The only property that can be achieved by using end-to-end 1849 security is that one end-host can be assured that the other end-host 1850 included some parameters (possibly resource parameters) that have not 1851 been modified along the path. Nodes along the path usually do not 1852 have the possibility to cryptographically verify the protected 1853 message parts. If the two end-points negotiate which side has to pay 1854 for the reservation (or possibly how much and other parameters) 1855 within the signaling protocol then there is a need to protect this 1856 information. This leads to the question which protocols are executed 1857 before the signaling message exchange starts. If resource parameters 1858 and payment/charging related information are already exchanged 1859 beforehand as part of a separate protocol (possibly SIP) then there 1860 is little need to protect (and possibly retransmit) this information 1861 at the NSIS level basis. In most cases an opaque token to link the 1862 different protocols may be sufficient. 1864 References 1866 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1867 9, RFC 2026, October 1996. 1869 2 Brunner, M., "Requirements for QoS Signaling Protocols", draft- 1870 ietf-nsis-req-02.txt (work in progress), May 2002 1872 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1873 Levels", BCP 14, RFC 2119, March 1997 1875 4 Tschofenig, H., "NSIS Threats", draft-tschofenig-nsis-threats- 1876 00.txt (work in progress), May 2002 1878 5 Katz, D., "IP Router Alert Option", RFC 2113, February 1997 1880 6 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 1881 October 1999 1883 7 Braden, R., "A Two-Level Architecture for Internet Signaling", 1884 draft-braden-2level-signal-arch-00.txt (work in progress), 1885 November 2001 1887 8 Stewart, R. et al., "Stream Control Transmission Protocol", RFC 1888 2960, October 2000 1890 9 Kent, S., R. Atkinson, "Security Architecture for the Internet 1891 Protocol", RFC 2401, November 1998 1893 10 Westberg, L., et al., "Framework for Edge-to-Edge NSIS Signaling", 1894 draft-westberg-nsis-edge-edge-framework-00.txt (work in progress), 1895 May 2002 1897 11 Blake, S., et al., "An Architecture for Differentiated Services", 1898 RFC2475, December 1998 1900 12 Goderis, D., et al. "Service Level Specification Semantics and 1901 Parameters", draft-tequila-sls-02.txt (work in progress), February 1902 2002 1904 13 Apostolopoulos, G., et al., "QoS Routing Mechanisms and OSPF 1905 Extensions", RFC 2676, August 1999 1907 14 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1908 1771, March 1995 1910 15 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1911 draft-ietf-idr-bgp4-17.txt (work in progress), January 2002 1913 16 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of 1914 Multiple Paths in BGP", draft-walton-bgp-add-paths-00.txt (work in 1915 progress), May 2002 1917 17 Cristallo, G., C. Jacquenet, "Providing Quality-of-Service 1918 Indication by the BGP-4 Protocol: the QoS_NLRI Attribute", draft- 1919 jacquenet-qos-nlri-04.txt (work in progress), March 2002 1921 18 Bonaventure, O., S. De Cnodder, J. Haas, B. Quoitin and R. White, 1922 "Controlling the redistribution of BGP Routes", draft-bonaventure- 1923 bgp-redistribution-02.txt (work in progress), February 2002 1925 19 Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 1926 Version 1 Functional Specification", RFC 2205, September 1997 1928 20 Westberg, L., M. Jacobsson, G. Karagiannis, S. Oosthoek, D. 1929 Partain, V. Rexhepi, R. Szabo, P. Wallentin, "Resource Management 1930 in Diffserv (RMD) Framework", draft-westberg-rmd-framework-01.txt 1931 (work in progress), February 2002 1933 21 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 1934 thomas-seamoby-rsvp-analysis-00.txt (work in progress), February 1935 2001 1937 22 Partain, D. et al., "Resource Reservation Issues in Cellular Radio 1938 Access Networks", draft-westberg-rmd-cellular-issues-01.txt (work 1939 in progress), June 2002 1941 23 Shen, C. et al., "An Interoperation Framework for Using RSVP in 1942 Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt 1943 (work in progress), July 2001 1945 24 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt 1946 (work in progress), May 2002 1948 25 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile 1949 IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March 1950 2001 1952 26 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile 1953 IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress), 1954 January 2002 1956 27 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6 1957 Networks", draft-kan-qos-framework-00.txt (work in progress), 1958 April 2002 1960 Acknowledgments 1962 The authors would like to thank Anders Bergsten, Maarten Buchli and 1963 Hannes Tschofenig for significant contributions in particular areas 1964 of this draft. In addition, the authors would like to acknowledge 1965 Marcus Brunner, Danny Goderis, Eleanor Hepworth, Cornelia Kappler, 1966 Hans De Neve, David Partain, Vlora Rexhepi, and Lars Westberg for 1967 insights and inputs during this and previous framework activities. 1969 Author's Addresses 1971 Ilya Freytsis 1972 Cetacean Networks Inc. 1973 100 Arboretum Drive 1974 Portsmouth, NH 03801 1975 USA 1976 email: ifreytsis@cetacean.com 1978 Robert Hancock 1979 Roke Manor Research 1980 Old Salisbury Lane 1981 Romsey 1982 Hampshire 1983 SO51 0ZN 1984 United Kingdom 1985 email: robert.hancock@roke.co.uk 1987 Georgios Karagiannis 1988 Ericsson EuroLab Netherlands B.V. 1989 Institutenweg 25 1990 P.O.Box 645 1991 7500 AP Enschede 1992 The Netherlands 1993 email: Georgios.Karagiannis@eln.ericsson.se 1995 John Loughney 1996 Nokia Research Center 1997 11-13 Italahdenkatu 1998 00180 Helsinki 1999 Finland 2000 email: john.loughney@nokia.com 2001 Sven Van den Bosch 2002 Alcatel 2003 Francis Wellesplein 1 2004 B-2018 Antwerpen 2005 Belgium 2006 email: sven.van_den_bosch@alcatel.be 2008 Full Copyright Statement 2010 "Copyright (C) The Internet Society (date). All Rights Reserved. This 2011 document and translations of it may be copied and furnished to 2012 others, and derivative works that comment on or otherwise explain it 2013 or assist in its implementation may be prepared, copied, published 2014 and distributed, in whole or in part, without restriction of any 2015 kind, provided that the above copyright notice and this paragraph are 2016 included on all such copies and derivative works. However, this 2017 document itself may not be modified in any way, such as by removing 2018 the copyright notice or references to the Internet Society or other 2019 Internet organizations, except as needed for the purpose of 2020 developing Internet standards in which case the procedures for 2021 copyrights defined in the Internet Standards process must be 2022 followed, or as required to translate it into languages other than 2023 English. 2025 The limited permissions granted above are perpetual and will not be 2026 revoked by the Internet Society or its successors or assigns. This 2027 document and the information contained herein is provided on an "AS 2028 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2029 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2030 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2031 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2032 OR FITNESS FOR A PARTICULAR PURPOSE.