idnits 2.17.00 (12 Aug 2021) /tmp/idnits21594/draft-ietf-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 1323 has weird spacing: '...special packe...' == Line 1325 has weird spacing: '...gnaling messa...' == Line 1331 has weird spacing: '... Care of Ad...' == Line 1332 has weird spacing: '...s least deman...' == Line 1334 has weird spacing: '...ed, the reser...' == (10 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 (October 2002) is 7157 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 424 looks like a reference -- Missing reference section? '3' on line 62 looks like a reference -- Missing reference section? 'NSIS' on line 232 looks like a reference -- Missing reference section? '7' on line 892 looks like a reference -- Missing reference section? '4' on line 1590 looks like a reference -- Missing reference section? '5' on line 720 looks like a reference -- Missing reference section? '6' on line 720 looks like a reference -- Missing reference section? '8' on line 856 looks like a reference -- Missing reference section? '9' on line 856 looks like a reference -- Missing reference section? '10' on line 894 looks like a reference -- Missing reference section? '11' on line 1154 looks like a reference -- Missing reference section? '12' on line 1163 looks like a reference -- Missing reference section? '13' on line 1163 looks like a reference -- Missing reference section? '14' on line 1170 looks like a reference -- Missing reference section? '15' on line 1197 looks like a reference -- Missing reference section? '16' on line 1202 looks like a reference -- Missing reference section? '17' on line 1265 looks like a reference -- Missing reference section? '18' on line 1286 looks like a reference -- Missing reference section? '19' on line 1297 looks like a reference -- Missing reference section? '20' on line 1527 looks like a reference -- Missing reference section? '21' on line 1306 looks like a reference -- Missing reference section? '22' on line 1446 looks like a reference -- Missing reference section? '23' on line 1383 looks like a reference -- Missing reference section? '24' on line 1449 looks like a reference -- Missing reference section? '25' on line 1506 looks like a reference -- Missing reference section? '26' on line 1450 looks like a reference -- Missing reference section? '27' on line 1552 looks like a reference -- Missing reference section? '28' on line 1553 looks like a reference -- Missing reference section? '29' on line 1557 looks like a reference -- Missing reference section? '30' on line 1840 looks like a reference -- Missing reference section? '31' on line 1922 looks like a reference -- Missing reference section? '32' on line 1939 looks like a reference -- Missing reference section? '33' on line 1940 looks like a reference -- Missing reference section? '34' on line 1940 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 37 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group 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-ietf-nsis-fw-00.txt 13 Expires: April 2003 October 2002 15 Next Steps in Signaling: Framework 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 protocols for signaling for 40 resources for a traffic flow along its path in the network. The 41 requirements for such signaling are being developed in [2]; this 42 Internet Draft will propose a framework for such signaling. 44 This initial version provides a model of the entities that take part 45 in the signaling. It discusses the considerations that must be taken 46 into account in developing the framework, particularly the structural 47 options for the structure of such a protocol, and the interactions 48 between NSIS and other protocols and functions, including security 49 issues. Finally, it includes background material on how NSIS could 50 support particular signaling applications. 52 It is expected that future versions of this document will distill 53 these structural options into a concrete technical framework, and 54 material on particular signaling applications and deployment 55 scenarios will be moved into separate NSIS applicability statements. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [3]. 63 Table of Contents 65 1. Introduction...................................................3 66 1.1 Scope of this Document .....................................4 67 2. Terminology....................................................4 68 3. Overall Framework Structure....................................6 69 3.1 Basic Signaling Entities and Interfaces ....................6 70 3.1.1 NSIS Entities ..........................................6 71 3.1.2 Placement of NSIS entities .............................7 72 3.2 Modes of Operation .........................................8 73 3.2.1 Path-Coupled and Path-Decoupled Signaling ..............8 74 3.2.2 Inter-domain and Intra-domain Signaling ................9 75 3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge .............10 76 3.2.4 Global and Local Operation ............................10 77 3.2.5 Multicast versus Unicast ..............................11 78 3.2.6 Sender versus Receiver Initiated Signaling ............11 79 3.2.7 Uni-Directional and Bi-Directional Reservations .......12 80 3.3 Basic Assumptions and Conceptual Issues ...................13 81 3.3.1 Basic Assumptions .....................................13 82 3.3.2 NI, NF, NR functionality ..............................13 83 3.3.3 NI, NF, NR relationship ...............................13 84 3.3.4 NSIS Addressing .......................................14 85 3.3.5 Service description ...................................15 86 3.3.6 NSIS Acknowledgement and Notification Semantics .......15 87 4. Protocol Components...........................................15 88 4.1 Lower Layer Interfaces ....................................15 89 4.2 Upper Layer Services ......................................16 90 4.3 Protocol Structure ........................................18 91 4.3.1 Internal Layering .....................................18 92 4.3.2 Protocol Messages .....................................19 93 4.4 State Management ..........................................20 94 4.5 Identity Elements .........................................21 95 4.5.1 Flow Identification ...................................21 96 4.5.2 Reservation Identification ............................22 97 4.5.3 Signaling Application Identification ..................23 98 5. NSIS Protocol Interactions....................................23 99 5.1 Resource Management Interactions ..........................23 100 5.2 IP Routing Interactions ...................................24 101 5.2.1 Load Sharing ..........................................25 102 5.2.2 QoS Routing ...........................................25 103 5.2.3 Route pinning .........................................26 104 5.2.4 Route Changes .........................................26 105 5.2.5 Router Redundancy .....................................28 106 5.3 Mobility Interactions .....................................28 107 5.3.1 Addressing and Encapsulation ..........................28 108 5.3.2 Localized Path Repair .................................29 109 5.3.3 Reservation Update on the Unchanged Path ..............30 110 5.3.4 Interaction with Mobility Signaling ...................30 111 5.3.5 Interaction with Fast Handoff Support Protocols .......32 112 5.4 NSIS Interacting with NATs ................................33 113 6. Security and AAA Considerations...............................34 114 6.1 Authentication ............................................34 115 6.2 Authorization .............................................35 116 6.3 Accounting ................................................36 117 6.4 End-to-End vs. Peer-Session Protection ....................37 118 7. NSIS Application Scenarios....................................38 119 7.1 NSIS and Existing Resource Signaling Protocols ............38 120 7.2 NSIS Supporting Centralized QoS Resource Management .......39 121 7.3 NSIS Supporting Distributed Resource Management ...........41 122 7.4 NSIS for Middlebox Signaling ..............................41 123 7.5 Multi-Level NSIS Signaling ................................42 124 8. Open Issues...................................................43 125 9. Change History................................................45 126 9.1 Changes from draft-hancock-nsis-fw-00.txt .................45 127 Acknowledgments..................................................48 128 Author's Addresses...............................................48 129 Full Copyright Statement.........................................49 131 1. Introduction 133 NSIS will work on signaling from an end point that follows a path 134 through the net that is determined by layer 3 routing and is used to 135 convey information to the devices the signals pass through - the 136 signaling can, for example, install soft state in the devices it 137 passes through. A signaling end point could be a device along the 138 path, which signals for a data flow that passes through it. 140 The intention is to allow for the NSIS protocol to be deployed in 141 different parts of the Internet, for different needs, without 142 requiring a complete end-to-end deployment. 144 There is no requirement that the per-flow information be QoS related. 145 NSIS should only worry about how to do the signaling - what the 146 signaling conveys should be opaque to NSIS. This document discusses 147 'where' the signaling takes place, with some discussion on 'how' the 148 signaling can be done. 150 1.1 Scope of the NSIS Framework 152 The scope of this document will be to provide a framework for where a 153 NSIS protocol can be used and deployed. It is not intended that NSIS 154 will define an over-arching architecture for carrying out resource 155 management in the Internet, nor is this intended to be used as a 156 detailed protocol design document. 158 The framework is not about what NSIS should do but how it should do 159 it. It is not intended that this places requirements on a future NSIS 160 protocol, since requirements are already defined in [2]. The document 161 discusses important protocol considerations, such as mobility, 162 security, and interworking with resource management (in a broad 163 sense). Discussions about lessons to be learned from existing 164 signaling and resource protocols are assumed to be contained in a 165 separate analysis document. 167 This initial version provides a model of the entities that take part 168 in the signaling. It discusses the considerations that must be taken 169 into account in developing the framework, particularly the structural 170 options for the structure of such a protocol, and the interactions 171 between NSIS and other protocols and functions, including security 172 issues. Finally, it includes background material on how NSIS could 173 support particular signaling applications. 175 It is expected that future versions of this document will distill 176 these structural options into a concrete technical framework, and 177 material on particular signaling applications and deployment 178 scenarios will be moved into separate NSIS applicability statements. 180 The purpose of this document is to develop the realms, domains and 181 modes of operation where an NSIS protocol can be used; identify the 182 relationship of an NSIS protocol to other protocols; and identify 183 areas for future work. 185 2. Terminology 187 Classifier - an entity which selects packets based on the content of 188 packet headers according to defined rules. 190 Interdomain traffic - Traffic that passes from one NSIS domain to 191 another. 193 NSIS Domain (ND) - Administrative domain where an NSIS protocol 194 signals for a resource or set of resources. 196 NSIS Entity (NE) - the function within a node which implements an 197 NSIS protocol. 199 NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR 200 which may interact with local resource management function (RMF). 201 NSIS Forwarder also propagates NSIS signaling further through the 202 network. 204 NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a 205 network resource. 207 NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and 208 can optionally interact with applications as well. 210 Path-coupled signaling - a mode of signaling where the signaling 211 messages follow a path that is tied to the data messages. See also 212 section 3.2.1. 214 Path-decoupled signaling - signaling with independent data and 215 signaling paths. 217 Peer session - signaling relationship between two adjacent NSIS 218 entities (i.e. NEs with no other NEs between them). 220 Resource - something of value in a network infrastructure to which 221 rules or policy criteria are first applied before access is granted. 222 Examples of resources include the buffers in a router and bandwidth 223 on an interface. 225 Resource Management Function (RMF) - an abstract concept, 226 representing the management of resources in a domain or a node. 228 Service Level Agreement (SLA) - a service contract between a customer 229 and a service provider that specifies the forwarding service a 230 customer should receive. 232 [NSIS] Signaling application - the purpose of the NSIS signaling: a 233 service could be QoS management, firewall control, and so on (see 234 also [7]). Totally distinct from any specific user application. 236 Traffic characteristic - a description of the temporal behavior or a 237 description of the attributes of a given traffic flow or traffic 238 aggregate. 240 Traffic flow - a stream of packets between two end-points that can be 241 characterized in a certain way. 243 3. Overall Framework Structure 245 3.1 Basic Signaling Entities and Interfaces 247 3.1.1 NSIS Entities 249 The NSIS protocol is intended to be used as a signaling control plane 250 for the variety of network resources required for data traffic across 251 the Internet. The most common NSIS signaling applications are QoS 252 resources, firewalls and NATs resources, etc. The NSIS signaling 253 itself does not depend on the signaling application it is used for 254 but the information it carries does. This section discusses the basic 255 signaling entities of the protocol as well as interfaces between 256 them. 258 We can identify three different roles in the NSIS signaling for 259 resources: initiator, forwarder and responder. 261 The NSIS Initiator (NI) is an entity that initiates NSIS signaling 262 (request) for the network resource. The NSIS initiator can be 263 triggered by the different "sources" - user applications, an instance 264 of NSIS Forwarder, other protocols, network management etc. - that 265 need network resources for a data flow. For the purpose of the NSIS 266 discussion all these sources can be called "applications" (note that 267 this is entirely distinct from the specific term "signaling 268 application"). The NSIS initiator can provide feedback information to 269 the triggering application in respect to the requested network 270 resources. The NSIS initiator uses NSIS signaling to interact with 271 other NSIS entities (NFs and NRs). 273 The NSIS Forwarder (NF) is an entity that services NSIS resource 274 requests from NSIS initiators and other NSIS forwarders. It may 275 interact with local resource management function (RMF). How and if 276 this interaction takes place depends on the deployed resource 277 management mechanism and the specific role of the NF. The NSIS 278 forwarder propagates NSIS signaling further through the network. 280 The NSIS Responder (NR) is an entity that terminates NSIS signaling 281 and can optionally interact with local applications as well e.g. for 282 the purpose of notification when network resources get allocated etc. 284 The signaling relationship between two NSIS entities (with no other 285 NSIS entities between them) is called a 'Peer-session'. This concept 286 might loosely be described as an 'NSIS hop'; however, there is no 287 implication that it corresponds to a single IP hop. 289 Figure 1 depicts simplified interactions/interfaces between NI, NFs 290 and NR as well as local applications and RMFs. Note that the NI and 291 NR could also interact with an RMF; additionally, this could be 292 modeled as co-location of NI&NF and NR&NF. This distinction should 293 have no impact on the operation of the protocol. Also, there is no 294 bar on placing an NI or NR in the interior of the network, to 295 initiate and terminate NSIS signaling independently of the ultimate 296 endpoints of the end to end flow, and NI and NR do not have to talk 297 via intervening NFs. An example of NSIS being used in this way is 298 given in section 7.5. 300 +-----------+ +-----------+ 301 |Application| |Application| 302 +-----------+ +-----------+ 303 ^ ^ 304 | | 305 | | 306 V V 307 +----+ NSIS +----+ NSIS +----+ NSIS +----+ 308 | NI |<========>| NF |<===...===>| NF |<========>| NR | 309 +----+ +----+ +----+ +----+ 310 ^ ^ 311 | | 312 | | 313 V V 314 +-----+ +-----+ 315 | RMF | | RMF | 316 +-----+ +-----+ 318 <========> = NSIS Peer-session 320 Figure 1: Basic NI/NF/NR Relationships 322 3.1.2 Placement of NSIS entities 324 The NI, NF and NR definitions do not make any assumptions about 325 placements of NSIS signaling entities in respect to the particular 326 part of the network or data-forwarding path. 328 They can be located along the data path (hosts generating and 329 receiving data flows, edge routers, intermediate routers etc.) but it 330 may not be the only one desirable location. 332 In some cases it is desired to be able to initiate and/or terminate 333 NSIS signaling not from the end host that generates/receives the data 334 flow, but from the some other entities on the network that can be 335 called NSIS signaling application proxies. There could be various 336 reasons for this: signaling on behalf of the end hosts that are not 337 enabled with NSIS, consolidation of the customer accounting 338 (authentication, authorization) in respect to consumed application 339 and transport resources, security considerations, limitation of the 340 physical connection between host and network etc. The proxy can 341 communicate the relevant information to the host in the application 342 specific, maybe compressed, form. 344 Support for NSIS proxies affects the protocol in the following way: 345 *) The protocol should accommodate signaling with the scope of a 346 single NSIS peer-session; the signaling could be propagated over 347 multiple peer-sessions all the way toward the destination (end-to- 348 end). 349 *) In the particular case where the proxy is not on the data path, 350 NSIS might have to be extended to allow separated data and signaling 351 paths, although this analysis is not initially in scope. 353 Further discussion of these issues is given in sections 3.2.1 and 354 3.3.3. 356 As it can be seen from the usage cases presented in the NSIS 357 requirements draft [2] the NSIS signaling procedures may depend on 358 the part/type of the network where NSIS is used. In fact to satisfy 359 sometimes-conflicting requirements in [2], different procedures and 360 possibly different kinds of the NSIS protocol can be used on 361 different parts/types of the network. Sections 3.2 and 7.5 provide 362 more details on this topic. 364 3.2 Modes of Operation 366 This section discusses several modes of NSIS protocol operation. Each 367 mode of NSIS operation is briefly introduced and where needed 368 analyzed and compared with other modes of NSIS operation. 370 3.2.1 Path-Coupled and Path-Decoupled Signaling 372 We can consider two basic paradigms for resource reservation 373 signaling, which we refer to as "path-coupled" and "path-decoupled". 375 In the path-coupled case, signaling messages are routed only through 376 nodes (NEs) that are in the data path. They do not have to reach all 377 the nodes on the data path (for example, there could be proxies 378 distinct from the sender and receiver as described in section 3.1.2, 379 or intermediate signaling-unaware nodes); and between adjacent NEs, 380 the route taken by signaling and data might diverge. The path-coupled 381 case can be supported by various addressing styles, with messages 382 either explicitly addressed to the neighbor on-path NE, or routed 383 identically to the data packets and intercepted. These cases are 384 considered in section 3.3.4. In the second case, some network 385 configurations may split the signaling and data paths (see section 386 5.2); this is considered an error case for path-coupled signaling. 388 In the path-decoupled case, signaling messages are routed to nodes 389 (NEs) which are not assumed to be on the data path, but which are 390 (presumably) aware of it. Signaling messages will always be directly 391 addressed to the neighbor NE, and the NI/NR may have no relation at 392 all with the ultimate data sender or receiver. 394 There are potentially significant differences in the way that the two 395 signaling paradigms should be analyzed, for example in terms of 396 scaling behavior, failure recovery, security properties, mechanism 397 for NSIS peer discovery, and so on. These differences might or might 398 not cause changes in the way that the NSIS protocol operates. 400 The initial goal of NSIS and this framework is to concentrate mainly 401 on the path-coupled case. 403 3.2.2 Inter-domain and Intra-domain Signaling 405 Inter-domain NSIS signaling is where the NSIS signaling messages are 406 originated in one NSIS domain and are terminated in another NSIS 407 domain. 409 In the path-coupled case, inter-domain NSIS signaling can be used to 410 signal NSIS information to the edge nodes of one or more NSIS 411 domains. 413 In the path-decoupled case, inter-domain NSIS signaling can be used 414 to signal NSIS information to entities that are not on the data path 415 (i.e., "out-of-band" NFs), and additionally to signal from off-path 416 entities to on-path edge nodes . 418 NSIS inter-domain signaling has to fulfill several requirements, such 419 as: 420 *) Basic functionality, such as scalable, simple and fast signaling. 421 Because different networks have different resource management 422 characteristics, such as cost of bandwidth and performance, this 423 basic functionality may differ from one NSIS domain to another. 424 *) All other requirements specified in [2]. 426 Intra-domain NSIS signaling is where the NSIS signaling messages are 427 originated, processed and terminated within the same NSIS domain. 428 Note that these messages could be handled within a local instance of 429 NSIS signaling; another possibility could be to piggyback them on 430 inter-domain NSIS messages. 432 Intra-domain signaling can be used to signal NSIS information to the 433 edge nodes (i.e., routers located at the border of the NSIS domain) 434 and to the interior nodes (i.e., routers located within the NSIS 435 domain that are not edge nodes). 437 The NSIS intra-domain signaling approach has to fulfill fewer 438 requirements than inter-domain signaling. These are: 439 *) Basic functionality, such as scalable, simple and fast signaling. 440 Due to the fact that different networks have different resource 441 management characteristics, this basic functionality may differ from 442 one NSIS domain to another. 443 *) Provides the necessary functionality to interact between inter- 444 domain signaling and intra-domain signaling. 446 3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge 448 End-to-end: When used end-to-end, the NSIS protocol is initiated by 449 an end host and is terminated by another end host. In this context, 450 NSIS can be applied as needed within all of the NSIS domains between 451 the end hosts. In the end-to-end path, NSIS may be used both for 452 intra-domain NSIS signaling, as well as for inter-domain signaling. 454 Edge-to-edge: In this scenario the NSIS protocol is initiated by an 455 edge node of a NSIS domain and is terminated by another edge node of 456 the same (or possibly different) NSIS domain. NSIS can be applied 457 either within one single NSIS domain, which is denoted as edge-to- 458 edge in a single domain, or within a concatenated number of NSIS 459 domains, which is denoted as edge-to-edge in a multi-domain. When an 460 appropriate security trust relation exists between two or more 461 concatenated NSIS domains, these concatenated NSIS domains are 462 considered, in terms of NSIS, to be a single, larger NSIS domain. 464 End-to-edge: In this scenario the NSIS protocol is either initiated 465 by an end host and is terminated by an edge node or is initiated by 466 an edge node and is terminated by an end host. In the path-coupled 467 case, the edge node may be a proxy that is located on a boundary node 468 of a NSIS domain. In the path-decoupled case, the edge node may be a 469 proxy that is located on an off-path node that controls, or is 470 associated with, a NSIS domain. 472 3.2.4 Global and Local Operation 474 It is likely that the appropriate way to describe the resources NSIS 475 is signaling for will vary from one part of the network to another. 476 In particular, resource descriptions that are valid for inter-domain 477 links will probably be different from those useful for intra-domain 478 operation (and the latter will differ from one NSIS domain to 479 another). 481 One way to describe this issue is to consider the resource 482 description objects carried by NSIS as divided in globally-understood 483 objects ("global objects") and locally-understood objects ("local 484 objects"). The local objects are only applicable for intra-domain 485 signaling, while the global objects are mainly used in inter-domain 486 signaling. 488 The purpose of this division is to provide additional flexibility in 489 defining the objects carried by the NSIS protocol such that only 490 those objects that are applicable in a particular setting are used. 491 An example approach for reflecting the distinction in the signaling 492 is that local objects could be put into separate local messages that 493 are initiated and terminated within one single NSIS domain and/or 494 they could be "stacked" within the NSIS messages that are used for 495 inter-domain signaling. These possibilities will be considered 496 further during the protocol design activity. 498 3.2.5 Multicast versus Unicast 500 Multicast support, compared to unicast support, would introduce a 501 level of complexity into the NSIS protocol mainly related to: 502 *) complex state maintenance to support dynamic membership changes 503 in the multicast groups, such as reservation state merging and 504 maintenance. 505 *) a state per flow has to be maintained that is used during 506 backward routing. 508 3.2.6 Sender versus Receiver Initiated Signaling 510 A sender-initiated approach is when the sender of the data flow 511 initiates and maintains the resource reservation used for that flow. 512 In a receiver-initiated approach the receiver of the data flow 513 initiates and maintains the resource reservation used for the data 514 flow. 516 In the path-coupled case, and in the absence of NSIS proxies, the 517 following relationships apply: 518 *) in the sender initiated case, the sender of the data is the NSIS 519 Initiator, while the receiver of the data is the NSIS Responder; 520 *) in the receiver initiated case, the receiver of the data is the 521 NSIS Initiator, while the sender of the data is the NSIS Responder. 522 In the path-decoupled case, the mapping is not necessarily clear cut 523 (for example, if the NI and NR are not located at the end systems 524 themselves). 526 The main differences between the sender-initiated and receiver- 527 initiated approaches are the following: 528 *) Compared with the receiver-initiated approach, a sender using a 529 sender-initiated approach can be informed faster when the reservation 530 request is rejected. In other words, when using a sender-initiated 531 approach, the reservation request response time can be shorter in the 532 case of an unsuccessful reservation than with a receiver-initiated 533 approach. 534 *) In a receiver-initiated approach, the signaling messages 535 traveling from the receiver to the sender must be backward routed 536 such that they follow exactly the same path as was followed by the 537 signaling messages belonging to the same flow traveling from the 538 sender to the receiver. This implies that a backward routing state 539 per flow must be maintained. When using a sender-initiated approach, 540 provided acknowledgements and notifications can be securely delivered 541 to the sending node, backward routing is not necessary, and nodes do 542 not have to maintain backward routing states. 543 *) In a sender-initiated approach, a mobile node can initiate a 544 reservation for its incoming flows as soon as it has moved to another 545 roaming subnetwork. In a receiver-initiated approach, a mobile node 546 has to inform the receiver about its handover procedure, thus 547 allowing the receiver to initiate a reservation. 549 3.2.7 Uni-Directional and Bi-Directional Reservations 551 It is possible that a resource will only be required for one 552 direction of traffic, for example for a media stream with no feedback 553 channel. Reservations for both directions of traffic may be required 554 for other applications, for example a voice call. Therefore, the NSIS 555 signaling protocol must allow for both uni- and bi-directional 556 resource reservations. 558 The most basic method for bi-directional reservations is based on 559 combining two uni-directional reservations. This means that the 560 signaling messages from the sender of the bi-directional reservation 561 towards a receiver are able to follow a different path from messages 562 traveling in the opposite direction, which is necessary for path- 563 coupled signaling in the presence of asymmetric routing. (Other more 564 integrated approaches may be possible in constrained network 565 topologies.) The bi-directional reservations can, for example, be 566 used to make the NSIS signaling procedure required after a handover 567 procedure more efficient. 569 3.3 Basic Assumptions and Conceptual Issues 571 3.3.1 Basic Assumptions 573 The following assumptions have been made during prior NSIS 574 requirements work and initial framework discussions. They are 575 summarized here for completeness. The subsequent subsections describe 576 more generic conceptual assumptions and issues. Note that a complete 577 overview of current open issues is contained in section 8. 579 *) The solution developed by NSIS must be sufficiently flexible and 580 modular that it can be efficiently deployed and used with 581 functionality appropriate to the part/type of the network. (Sections 582 3.2.2 and 3.2.3.) 584 *) The protocol developed by the NSIS working group will be path- 585 coupled. Considerations related to a potential path-decoupled 586 solution are part of this framework, because they are also needed in 587 order to co-exist with existing solutions; however, the NSIS working 588 group currently has no plans to develop path-decoupled signaling 589 protocol. (Section 3.2.1.) 591 *) Multicast support introduces a level of complexity into the NSIS 592 protocol that is not needed in support of unicast applications. 593 Therefore, a working assumption is be that the NSIS protocol should 594 be optimized for unicast. (Section 3.2.5.) 596 *) The NSIS protocol can be used for setup of both uni-directional 597 and bi-directional reservations. (Section 3.2.7.) 599 3.3.2 NI, NF, NR functionality 601 The basic functions that can be fulfilled by an NSIS entity are 602 request, accept, notify, modify and release of a reservation. At this 603 point, it is not clear which responsibilities can be assumed by each 604 of the NSIS entities. More in particular, it is not clear whether: 605 *) an NF can request, modify or release a reservation. If it cannot, 606 it needs to notify the NI in order to perform these functions. 607 *) an NR can modify and release a reservation. Even if the NR can 608 reject or accept the reservation with modification, it might still be 609 required to notify the NI to signal the release or modification. 611 3.3.3 NI, NF, NR relationship 613 An important open issue is related to the way in which NSIS entities 614 maintain relations between each other. These relations could be 615 purely local, where an NSIS entity only maintains relations with its 616 direct neighbors (peers). In that case, messages will be sent to and 617 accepted from these neighbors only. Alternatively, the relations 618 between NSIS entities could have a more global scope. 620 The type of NSIS peering relations may have an impact on the 621 complexity involved with protocol security. In case of inter-domain 622 signaling, the security relations are likely to be built between 623 neighboring NSIS entities only for scalability reasons. In that case, 624 each NSIS entity will establish and maintain a security relation with 625 each of its peers and accept only messages from these peers. 627 Conversely, there may exist larger domains of NSIS entities that have 628 a trust relationship (trusted domains). This may be the case for 629 intra-domain signaling. In this case, an NE may accept messages from 630 all other NSIS entities in the domain. Both alternatives need not be 631 mutually exclusive. It is conceivable that different instances of the 632 NSIS protocol (or different NSIS protocols) use the NSIS security 633 model to a larger or lesser extent, provided that overall security is 634 not impacted. An analysis of NSIS threats is available from [4]. 636 The NSIS peering relations may also have an impact on the required 637 amount of state at each NSIS entity. When direct interaction with 638 remote NSIS peers is not allowed, it may be required to keep track of 639 the path that an NSIS message has followed through the network. This 640 can be achieved by keeping per-flow state at the NSIS entities or by 641 maintaining a record route object in the NSIS messages. 643 3.3.4 NSIS Addressing 645 The are potentially two ways to establish a signaling connection by 646 means of the NSIS protocol. On the one hand, the NSIS message could 647 be addressed to a neighboring NSIS entity (NE) that is known to be 648 closer to the destination NE. On the other hand, the NSIS message 649 could be addressed to the destination directly, and intercepted by an 650 intervening NE. We denote the latter approach as end-to-end 651 addressing and the former as peer-session addressing. 653 With peer-session addressing, an NE will determine the address of the 654 next NE based on the payload of the NSIS message (and potentially 655 also on the previous NE). This requires the address of the 656 destination NE to be derivable from information present in the 657 payload. This can be achieved through the availability of a local 658 routing table or through participation in the routing protocol. Peer- 659 session addressing inherently supports tunneling of NSIS signaling 660 messages between NEs, and is equally applicable to the path-coupled 661 and path-decoupled cases. 663 In case of end-to-end addressing, the NSIS message will be sent with 664 the address of the NR, which then necessarily needs to be on the data 665 path. This requires (some of) the data-path entities to be upgraded 666 (NSIS-aware) in order to be able to intercept the NSIS messages. The 667 routing of the NSIS signaling should follow exactly the same path as 668 the data flow for which the reservation is requested. 670 3.3.5 Service description 672 Although the service part of the NSIS message (the part that depends 673 on the specific signaling application) is outside of the scope of the 674 NSIS working group, it may be necessary to make some assumptions 675 about its content in order to determine whether similar functionality 676 needs to be foreseen in the NSIS-specific part of the message: 677 *) It is assumed that the service description will handle pre- 678 emption and survivability issues. These are seen as a part of the 679 offered service and need not be present in the NSIS control layer. 680 *) It is assumed that some flow description information is part of 681 the NSIS control layer (see section 4.3.1 and 4.5.1). This might be 682 needed by signaling application unaware entities located at address 683 boundaries. It is not clear to which level of complexity, the flow 684 description needs to be available at this level. 685 *) It is not assumed that the content of the service description is 686 independent of the NSIS control layer. It seems appropriate to allow 687 the content of the service description to be dependent on the type of 688 message that is sent (request/response/refresh). 690 3.3.6 NSIS Acknowledgement and Notification Semantics 692 The semantics of the acknowledgement and notification messages are of 693 particular importance. An NE sending a message can assume 694 responsibility for the entire downstream chain of NEs, indicating for 695 instance the availability of reserved resources for the entire 696 downstream path. Alternatively, the message could have a more local 697 meaning, indicating for instance that a certain failure or 698 degradation occurred at a particular NSIS entity. 700 4. Protocol Components 702 4.1 Lower Layer Interfaces 704 Within a signaling entity, NSIS interacts with the 'lower layers' of 705 the protocol stack for two nearly independent purposes: sending and 706 receiving signaling messages; and configuring the operation of the 707 lower layers themselves. 709 For sending and receiving messages, this framework places the lower 710 boundary of the NSIS protocol at the IP layer. (It is possible that 711 NSIS could use a standard transport protocol above the IP layer to 712 provide some of its functionality; this is discussed in section 713 4.3.1.) The interface with the lower layers is therefore very simple: 714 *) NSIS sends raw IP packets 715 *) NSIS receives raw IP packets. In the case of peer-session 716 addressing, they have been addressed directly to it. In the case of 717 end-to-end addressing, this will be by intercepting packets that have 718 been marked in some special way (by special protocol number or by 719 some option interpreted within the IP layer, such as the Router Alert 720 option [5] and [6].) 722 NSIS needs to have some information about the link and IP layer 723 configuration of the local networking stack. For example, NSIS needs 724 to know about: 725 *) [in general] how to select the outgoing interface for a signaling 726 message, in case this needs to match the interface that will be used 727 by the corresponding flow. This might be as simple as just allowing 728 the IP layer to handle the message using its own routing table. 729 *) [in the case of IPv6] what address scopes are associated with the 730 interfaces that messages are sent and received on (to interpret 731 scoped addresses in flow identification, if these are to be allowed). 733 The way in which NSIS actually configures the lower layers to handle 734 the flow depends on the particular NSIS signaling application; for 735 example, if NSIS is being used for QoS signaling, this might involve 736 configuration of traffic classification and conditioning parameters, 737 for example local packet queues, type of filters, type of scheduling, 738 and so on. However, none of this is directly related to the NSIS 739 protocol itself; therefore, this interaction is handled indirectly 740 via a resource management function, as described in section 5.1. 742 4.2 Upper Layer Services 744 NSIS provides a signaling service, which can be used by multiple 745 upper layers, or signaling applications. We describe this service 746 here as an abstract set of capabilities. A later version of this 747 framework could illustrate the use of these capabilities within a 748 broader context (e.g. how NSIS signaling could be used within a 749 complete set of message flows that signal a voice over IP call). 751 We can loosely define the boundary between NSIS and these signaling 752 applications from three views: 753 *) What basic control primitives are available at the interface; 754 *) What information is exchanged within these primitives; 755 *) What assumptions NSIS makes about operations carried out above 756 the interface. 758 The set of control primitives required is quite small. 759 At the initiating (NI) end: 761 *) Signaling application requests signaling for a new resource; 762 *) Signaling application requests modification or removal of an 763 existing resource. 764 *) Signaling application receives progress indications (minimally, 765 success or failure). 766 At the responding (NR) end: 767 *) Notification to signaling application that a resource has been 768 set up. 769 At either end: 770 *) Notification to signaling application that something has changed 771 about the available resource and other error conditions. 773 This description is in terms of a 'hard state' interface, without 774 explicit refresh messages between the signaling application and NSIS, 775 although this is an implementation issue. In any case, NSIS 776 implementations will need to be able to detect conditions when 777 instances of signaling applications fail without issuing explicit 778 resource removal requests. 780 The information in the control primitives consists essentially of two 781 parts. The first is the definition of the data flow for which the 782 resource is being signaled. The format (e.g. socket id or packet 783 fields or whatever) is an implementation issue; it has to be 784 interpreted into a 'wire format' (as in section 4.5). Since NSIS 785 could support both sender and receiver initiation, the flow 786 definition must also state whether it is incoming or outgoing over a 787 particular interface (this can be inferred when the initiator is 788 colocated with the flow endpoint). The second part of the information 789 exchanged is the service definition (e.g. QoS description in the case 790 of a QoS request). This is opaque to NSIS, with the possible 791 exception of identifying the signaling application in use (i.e. the 792 resource type being signaled.) 794 We have a basic design goal not to duplicate functionality that is 795 already present in (or most naturally part of) existing signaling 796 protocols which could be used by the upper layers. Therefore NSIS 797 (implicitly) assumes that certain procedures are carried out 798 'externally'. The main aspects of this are: 799 *) Negotiation of service configuration (e.g. discovering what 800 services are available to be requested); 801 *) Agreement to use NSIS for signaling, and coordination of which 802 end will be the initiator; 803 *) (Potentially) discovery of the NSIS peer to be signaled with, 804 especially if this is not directly on the data path. See also the 805 security discussion in section 6. 806 Actually providing these functions might require enhancements to 807 these other protocols. These are still to be identified. 809 4.3 Protocol Structure 811 4.3.1 Internal Layering 813 We can model NSIS in three layers, as shown in Figure 2. This is 814 initially just a way of grouping associated functionality, and does 815 not mean that all these layers could necessarily operate or even be 816 implemented independently. 818 +--------------------------------+ 819 |////////////////////////////////| 820 |///// Service Description //////| 821 |///// (Opaque to NSIS) //////| 822 |///// (Section 4.2) //////| 823 |////////////////////////////////| 824 +--------------------------------+ 825 | | 826 | NSIS Control Layer | 827 | | 828 +--------------------------------+ 829 | | 830 | Generic Signaling Transport | 831 | Protocol | 832 | | 833 +--------------------------------+ 834 . Interface to IP Layer . 835 . (Section 4.1) . 836 .................................. 838 Figure 2: NSIS Layer Structure 840 The lower layer interface (to IP) has been described in section 4.1. 841 The service description information is essentially the same as 842 provided by the signaling application, as described in section 4.2. 843 It isn't clear if the service description can be independent of the 844 lower parts of the protocol or whether different descriptions would 845 be valid at different stages of protocol operation. This depends on 846 the particular signaling application, and therefore to make NSIS 847 signaling application independent we must allow that the service 848 description part may be explicitly dependent on the 'NSIS' fields 849 which lie below. This is similar to the ALSP/CSTP coupling described 850 in [7]. 852 The distinction between the 'NSIS layer' and the 'Generic Signaling' 853 layer is not functionally clear cut, but one of convenience. In 854 outline: 855 *) The 'generic' layer provides (at most) functionality which might 856 be available from existing protocols, such as SCTP [8] or IPSec [9]. 858 An extreme case could be the binding update messages of mobility 859 signaling (section 5.3.4). 860 *) The 'NSIS' layer provides (at least) functionality which is 861 somehow specific to path-coupled signaling. 863 Functionality reasonable to re-use from existing protocols might 864 include reliability and re-ordering protection, dead peer detection 865 (keepalive), multihoming support, payload multiplexing 866 (piggybacking), and security services, such as establish a security 867 context and carrying out key exchange. 869 Functionality which would probably have to be in the NSIS layer would 870 include flow and reservation identification, some error handling, 871 demultiplexing between different signaling applications, as well as 872 the basic NSIS messages. More details on the messages are in section 873 4.3.2 and the identifier aspects in section 4.5. 875 The choice of using functionality from an existing protocol or re- 876 specifying it as part of NSIS is for further analysis. It probably 877 depends on the function in question, and in the end might be left 878 flexible to allow optimization to local circumstances. (For example, 879 Diameter allows the use of IPSec for security services, but also 880 includes its own CMS application as an alternative.) Whichever 881 approach is taken, the combination of NSIS and supporting transport 882 protocol must provide a uniform protocol capability to the upper 883 layers which contain the actual signaling application. 885 4.3.2 Protocol Messages 887 The NSIS specific part will include a set of messages to carry out 888 particular operations along the signaling path. Initial work for RSVP 889 concentrated on the particular case of QoS signaling, although in 890 principle, the necessary basic messages could depend on the signaling 891 application NSIS is being used for. However, the implication of the 892 analysis in [7] is that this message set generalizes to a wide 893 variety of scenarios, and so we use it as a starting point. A very 894 similar set was generated in [10]. 896 Note that the 'direction' column in the table below only indicates 897 the 'orientation' of the message. The messages can be originated and 898 absorbed at NF nodes as well as the NI or NR; an example might be NFs 899 at the edge of a domain exchanging NSIS messages to set up resources 900 for a flow across a it. 902 Note the working assumption that responder as well as the initiator 903 can release a reservation (comparable to rejecting it in the first 904 place). It is left open if the responder can modify a reservation, 905 during or after setup. This seems mainly a matter of assumptions 906 about authorization, and the possibilities might depend on resource 907 type specifics. 909 +-------+---------+---------------------------------------------+ 910 | Name |Direction| Semantics | 911 +-------+---------+---------------------------------------------+ 912 |Request| I-->R | Create a new reservation for a flow | 913 +-------+---------+---------------------------------------------+ 914 |Modify | I-->R | Modify an existing reservation | 915 | |(&R-->I?)| | 916 +-------+---------+---------------------------------------------+ 917 |Release| I-->R & | Delete (tear down) an existing reservation | 918 | | R-->I | | 919 +-------+---------+---------------------------------------------+ 920 |Accept/| R-->I | Confirm (possibly modified?) or reject a | 921 | Reject| | reservation request | 922 +-------+---------+---------------------------------------------+ 923 |Notify | I-->R & | Report an event detected within the | 924 | | R-->I | network (e.g. congestion condition or end | 925 | | | of condition) | 926 +-------+---------+---------------------------------------------+ 927 |Refresh| I-->R | State management (see section 4.4) | 928 +-------+---------+---------------------------------------------+ 930 The table also explicitly includes a refresh message. This does 931 nothing to a reservation except extend its lifetime, and is one 932 possible state management mechanism for NSIS. This is considered in 933 more detail in section 4.4. 935 4.4 State Management 937 The prime purpose of NSIS is to manage state information along the 938 path taken by a data flow. There two critical issues to be considered 939 in building a robust protocol to handle this problem: 940 *) The protocol must be scalable. It should minimize the state 941 storage demands that it makes on intermediate nodes; in particular, 942 storage of state per 'micro' flow is likely to be impossible except 943 at the very edge of the network. 944 *) The protocol must be robust against failure and other conditions, 945 which imply that the stored state has to be moved or removed. 947 The total amount of state that has to be stored depends both on NSIS 948 and on the specific signaling application in use. The signaling 949 application might require per flow or lower granularity state; 950 examples of each for the case of QoS would be IntServ or RMD (per 951 'class' state) respectively. The NSIS protocol should not overburden 952 an application that was otherwise lightweight in state requirement. 953 However, depending on design details, it might require storage of 954 per-flow state including reverse path peer addressing, simply for 955 sending NSIS messages themselves. 957 There are several robustness problems, which roughly align with the 958 'layers' of the NSIS protocols of Figure 2, that can be handled by 959 the soft state principle. (Independence of these layers therefore 960 implies the danger of duplication of functionality.) This relies on 961 periodic refresh of the state information with the current context, 962 relying on invalid state being timed out. Soft state can be used 963 either as the primary mechanism to handle the problem, or sometimes 964 as a backup to some other approach. 966 *) At the lowest level, soft state can be used to detect dead NSIS 967 peers - loss of several periodic messages implies termination of the 968 signaling. (The same inference can be made e.g. if failure is 969 detected at the link layer.) The assumption is then that the 970 corresponding reservation should be automatically deleted, and the 971 deletion propagated along the remainder of the path. 973 *) At the next level, in the event of a routing change (for example 974 caused by network changes or end host mobility), reservation state 975 should be removed from the old path and added to the new one. This 976 will be handled automatically by periodic messaging, provided that 977 the entities on the new path accept a Refresh message to install a 978 new reservation. (A partial alternative is to have a routing-aware 979 NSIS implementation, if the route change takes place at an NSIS-aware 980 node.) 982 *) At the highest level, a particular signaling application might 983 have timing limits associated with a particular reservation (e.g. 984 credit limited network access). Periodic re-authorized requests can 985 be used as part of the time control. 987 All of these can be handled with a single soft state mechanism, 988 although it may be hard to choose a single refresh interval and 989 message loss threshold appropriate for all of them. Even where 990 alternative approaches are possible, for example using knowledge of 991 the fact that a routing change has occurred to trigger an explicit 992 NSIS release message, it seems that a soft state mechanism is always 993 necessary as a backup. 995 4.5 Identity Elements 997 NSIS will carry certain identifiers within the NSIS layer. The most 998 significant identifier needs seem to be the following. 1000 4.5.1 Flow Identification 1001 The flow identification is a method of identifying a flow in a unique 1002 way. All packets and/or messages that are associated with the same 1003 flow will be identified by the same flow identifier. In principle, it 1004 could be a combination of the following information (note that this 1005 is not an exclusive list of information that could be used for flow 1006 identification): 1007 *) source IP address; 1008 *) destination IP address; 1009 *) protocol identifier and higher layer (port) addressing; 1010 *) flow label (typical for IPv6); 1011 *) SPI field for IPSec encapsulated traffic; 1012 *) DSCP/TOS field 1014 We've assumed here that the flow identification is not hidden within 1015 the service definition, but is explicit as part of the basic NSIS 1016 protocol. The justification for this is that it might be valuable to 1017 be able to do NSIS processing even at a node which was unaware of the 1018 specific signaling application; this would be a case of an NSIS 1019 forwarder with no interface to any resource management function. An 1020 example scenario would be NSIS messages passing through an addressing 1021 boundary where the flow identification had to be re-written. 1023 The very flexibility possible in flow classification is a possible 1024 source of difficulties: when wildcards or ranges are included, it is 1025 probably unreasonable to assume a standard classification capability 1026 in routers; on the other hand, negotiating this capability would be a 1027 significant protocol complexity. 1029 4.5.2 Reservation Identification 1031 There are several circumstances where it is important to be able to 1032 refer to a reservation independently of whatever other information is 1033 associated with it. The prime example is a mobility-induced address 1034 change (handover) which required the flow identifier associated with 1035 a reservation to be rewritten without installing a totally new 1036 reservation (see section 5.3.1 for some security and scoping 1037 implications of this use). The same capability could also be used to 1038 simplify refresh or release messages in some circumstances, and might 1039 be useful within the protocol to resolve reservation collisions 1040 (where both sender and receiver initiate for the same flow). 1042 A reservation identifier performs these roles. It is open how the 1043 reservation identifier space should be defined and managed, and what 1044 the scope of the identifier should be (only peer-peer, or end-end, 1045 when interpreted in conjunction with some of the addressing 1046 information). Some of the necessary identifier functions, especially 1047 to do with local operation of NSIS, may also be provided by lower 1048 layer signaling transport protocols. 1050 4.5.3 Signaling Application Identification 1052 Since NSIS can be used to support several signaling applications, 1053 there is a need to identify which one a particular NSIS invocation is 1054 being used for, and this needs to be done outside the (opaque) 1055 service description: 1056 *) processing incoming request messages at a responder - the NSIS 1057 layer should be able to demultiplex these towards the appropriate 1058 application; 1059 *) processing general NSIS messages at an NSIS aware intermediate 1060 node - if the node does not handle the specific signaling 1061 application, it should be able to make a forwarding decision without 1062 having to parse the service description. 1064 Signaling application identifiers would probably require an IANA 1065 registry. 1067 5. NSIS Protocol Interactions 1069 So far as possible, the NSIS protocol(s) should be usable in 1070 isolation, without explicitly depending on other protocols to 1071 operate. However, in many cases, NSIS functionality overlaps with the 1072 problem spaces of other protocols. In order to determine the 1073 boundaries which minimize any explicit interdependencies, these 1074 protocol interactions must be analyzed. 1076 This is different from considering the use of NSIS protocols to 1077 support a particular signaling application, or example configurations 1078 in which NSIS might be deployed. These subjects are discussed in 1079 section 7. 1081 5.1 Resource Management Interactions 1083 The NSIS protocol is used for signaling resource requests from an 1084 NSIS Initiator to an NSIS Responder. The NSIS protocol should be 1085 useful for many signaling applications, but should not be involved in 1086 any specific resource allocation or management techniques. As such, 1087 we need to define the interaction between an NSIS entity and what we 1088 will call the Resource Management Function (RMF). The RMF is 1089 responsible for all resource provisioning, monitoring and assurance 1090 functions in the network. 1092 The RMF may interact with NSIS entities in two different ways: as a 1093 client or as a server. 1095 First, the RMF can act as a client towards the NSIS protocol, as a 1096 particular application triggering NSIS signaling for resources in the 1097 network. This is a special case of general NSIS triggering and will 1098 not be elaborated here. This case could for instance apply with 1099 multi-level NSIS signaling (section 7.5). 1101 Second, the RMF can act as a server towards the NSIS protocol. In 1102 that case, the signaling decision taken by the NF may depend on the 1103 content or processing of the NSIS payload. 1105 The RMF may or may not be co-located with the NSIS protocol 1106 processing. To cater for both cases, we define a (possibly logical) 1107 NF-RMF interface, see Figure 3. (As mentioned in section 3.1.1, the 1108 NI and NR could also interact with an RMF. Note that this could also 1109 be modeled as co-location of the NI&NF and NR&NF. This distinction 1110 should have no impact on the operation of the protocol.) Over this 1111 interface, information may be provided from the RMF about monitoring, 1112 resource availability, topology, configuration, and so on. 1113 Additionally, resource provisioning requests may be issued towards 1114 the RMF. Note that the actual implications for NSIS as a protocol are 1115 the same, regardless of whether the RMF is centralized or 1116 distributed, since NSIS sees the same interface towards the RMF in 1117 each case. 1119 +----+ NSIS +----+ NSIS +----+ NSIS +----+ 1120 | NI |<========>| NF |<===...===>| NF |<========>| NR | 1121 +----+ +----+ +----+ +----+ 1122 ^ ^ 1123 | | 1124 V V 1125 +----+ +----+ 1126 | RMF| | RMF| 1127 +----+ +----+ 1129 Figure 3: Basic NSIS-RMF Relationship 1131 One way to formalize the interface between the NF and the RMF is via 1132 a Service Level Agreement (SLA). The SLA may be static or it may be 1133 dynamically updated by means of a negotiation protocol. Such a 1134 protocol is outside the scope of NSIS. 1136 5.2 IP Routing Interactions 1138 Several situations may occur when routing diverges from standard 1139 layer 3 routing. These are summarized in the sections below. 1141 5.2.1 Load Sharing 1143 Load sharing or load balancing is a network optimization technique 1144 that exploits the existence of multiple paths to the same destination 1145 in order to obtain benefits in terms of protection, resource 1146 efficiency or network stability. The significance of load sharing in 1147 the context of NSIS is that, if the load sharing mechanism in use 1148 will forward packets on any basis other than source and destination 1149 address, routing of NSIS messages using end-to-end addressing does 1150 not guarantee that the messages will follow the data path. In this 1151 section, we briefly survey what standard methods have been used for 1152 load sharing within standard routing protocols. 1154 In OSPF, load balancing can be used between equal cost paths [11] or 1155 unequal cost paths. An example of the latter approach is Optimized 1156 Multi Path (OMP). OMP discovers multiple paths, not necessarily equal 1157 cost paths, to any destinations in the network, but based on the load 1158 reported from a particular path, it determines which fraction of the 1159 traffic to direct to the given path. Incoming packets are subject to 1160 a (source, destination address) hash computation, and effective load 1161 sharing is accomplished by means of adjusting the hash thresholds. 1163 BGP [12][13] advertises the routes chosen by the BGP decision process 1164 to other BGP speakers. In the basic specification, routes with the 1165 same Network Layer reachability information (NLRI) as previously 1166 advertised routes implicitly replace the original advertisement, 1167 which means that multiple paths for the same prefix cannot exist. 1168 Recently, however, a new mechanism was defined that will allow the 1169 advertisement of multiple paths for the same prefix without the new 1170 paths implicitly replacing any previous ones [14]. The essence of the 1171 mechanism is that each path is identified by an arbitrary identifier 1172 in addition to its prefix. 1174 The distribution of traffic over the available path may be done per 1175 destination, per message in a round-robin fashion or with a 1176 predefined hashing function. The determination of the hashing image 1177 may take into account the source/destination IP address, QoS 1178 information such as the DSCP or protocol ID. When the routing 1179 decision is no longer based on the destination address only, however, 1180 there is a risk that data plane messages and control plane messages 1181 will not follow the same route. 1183 5.2.2 QoS Routing 1185 The are several proposals for the introduction of QoS awareness in 1186 the routing protocols. All of these essentially lead to the existence 1187 of multiple paths (with different QoS) towards the same destination. 1189 As such, they also contain an inherent risk for a divergence between 1190 control plane and data plane, similar to the load sharing case. 1192 For intra-domain traffic, the difference in routing may result from a 1193 QoS-aware traffic engineering scheme, that e.g. maps incoming traffic 1194 to LSPs based on multi-field classification. In BGP, several 1195 techniques for including QoS information in the routing decision are 1196 currently proposed. A first proposal is based on a newly defined 1197 BGP-4 attribute, the QoS_NLRI attribute [15]. The QoS_NLRI attribute 1198 is an optional transitive attribute that can be used to advertise a 1199 QoS route to a peer or to provide QoS information in along with the 1200 Network Layer Reachability Information (NLRI) in a single BGP update. 1201 A second proposal is based on controlled redistribution of AS routes 1202 [16]. It defines a new extended community (the redistribution 1203 extended community) that allows a router to influence how a specific 1204 route should be redistributed towards a specified set of eBGP 1205 speakers. The types of redistribution communities may result in a 1206 specific route not being announced to a specified set of eBGP 1207 speakers, that it should not be exported or that the route should be 1208 prepended n times. 1210 5.2.3 Route pinning 1212 Route pinning refers to the independence of the path taken by certain 1213 data packets from reachability changes caused by routing updates from 1214 an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway 1215 Protocol (BGP). This independence may for instance be caused by the 1216 configuration of static LSPs or by the establishment of explicitly 1217 routed LSPs by means of a signaling protocol (RSVP-TE or CR-LDP). If 1218 the NSIS signaling messages follow standard Layer 3 routing, this may 1219 cause a divergence between control plane and data plane. If 1220 reservations are made on the control plane, this may result in 1221 sending data along an unreserved path while maintaining a reservation 1222 on a path that is not used. 1224 5.2.4 Route Changes 1226 In this section, we will explore the expected interworking between a 1227 signaling for resource BGP routing updates, although the same applies 1228 for any source of routing updates. The normal operation of the NSIS 1229 protocol will lead to the situation depicted in Figure 4, where the 1230 reserved resources match the data path. 1232 reserved +----+ reserved +----+ 1233 ------->| NF |----------->| NF | 1234 +----+ +----+ 1235 ===================================== 1236 data path 1238 Figure 4: Normal NSIS protocol operation 1240 A route change (triggered by a BGP routing update for instance) can 1241 occur while such a reservation is in place. In case of RSVP, the 1242 route change will be installed immediately and any data that is sent 1243 will be forwarded on the new path. This situation is depicted 1244 Figure 5. 1246 Route update 1247 | 1248 v 1249 reserved +----+ reserved +----+ 1250 ------->| NF |----------->| NF | 1251 +----+ +----+ 1252 ========== | 1253 || | +----+ 1254 || +---------->| NF | 1255 || +----+ 1256 ============================ 1257 data path 1259 Figure 5: Route Change 1261 Resource reservation on the new path will only be started once the 1262 next control message is routed along the new path. This means that 1263 there is a certain time interval during which resources are not 1264 reserved on (part of) the data path. To minimize this time interval 1265 several techniques could be considered. As an example, RSVP [17] has 1266 the concept of local repair, where the router may be triggered by a 1267 route change. In that case the RSVP node can start sending PATH 1268 messages directly after the route has been changed. Note that this 1269 option may not be available for NSIS if no per-flow state is kept in 1270 the NF. 1272 It is not guaranteed that the new path will be able to provide the 1273 same guarantees that were available on the old path. Therefore, in a 1274 more desirable scenario, the NF should wait until resources have been 1275 reserved on the new path before installing the route change. The 1276 route change procedure then consists of the following steps: 1277 1. NF receives a route announcement, 1278 2. Refresh messages are forwarded along the current path, 1279 3. A copy of the refresh message is remarked as request and send 1280 along the new path that was announced, 1281 4. When the NF has been acknowledged about the reservations on the 1282 new path the route will be installed and the traffic will flow along 1283 the new path. 1285 Another example related to route changes is denoted as severe 1286 congestion and is explained in [18]. This solution adapts to a route 1287 change, when a route change creates a congestion on the new routed 1288 path. 1290 5.2.5 Router Redundancy 1292 In some environments, it is desired to provide connectivity and per 1293 flow or per class resource management with high-availability 1294 characteristics, i.e. with rapid transparent recovery even in the 1295 presence of route changes. This may involve interactions with the 1296 basic protocols which are used to manage the routing in this case, 1297 such as VRRP [19]. A future version of this document may consider 1298 interactions between NSIS and such protocols in support of high 1299 availability functionality. 1301 5.3 Mobility Interactions 1303 The interactions between mobility and resource signaling protocols 1304 have been quite extensively analyzed in recent years, primarily in 1305 the context of RSVP and Mobile IP interaction (e.g. [20]), but also 1306 in the context of other types of network (e.g. [21]). This analysis 1307 work has shown that some difficulties in the interactions are quite 1308 deep seated in the detailed design of these protocols; however, the 1309 problems and their possible solutions fall under five broad headings. 1310 The main issue is to limit the period after handovers during which 1311 the resource state has not been installed on the path, in particular 1312 the new part of the path. 1314 We can use this work as the starting point for considering the 1315 framework aspects of a new signaling protocol like NSIS, which will 1316 need to interwork with mobility signaling, from Mobile IP to mobility 1317 paradigms based on micromobility or application layer approaches. 1319 5.3.1 Addressing and Encapsulation 1321 A mobility solution typically involves address reallocation on 1322 handover (unless a network supports per host routing) and may 1323 involve special packet formats (e.g. the routing header and Home 1324 Address option of MIPv6). Since NSIS may depend on end system 1325 addresses for forwarding signaling messages and defining flows 1326 (section 4.5.1), the special implications of mobility for addressing 1327 need to be considered. Examples of possible approaches that could be 1328 used to solve the addressing and encapsulation problem are as 1329 follows: 1330 *) Use a filter definition based on low level IP addresses (e.g. the 1331 Care of Address) and other 'standard' fields in the IP header. This 1332 makes least demands on the packet classification engines within the 1333 network. However, it means that even on a part of the flow path 1334 which is unchanged, the reservation will need to be modified to 1335 reflect the changed flow identification (see section 5.3.3). 1336 *) Use a flow definition that does not change (e.g. based on Home 1337 Address); this is the approach assumed in [22]. This simplifies the 1338 problem of reservation update, at the likely cost of considerably 1339 complicating the flow identification requirements. 1341 In the first approach, to prevent double reservation, NSIS nodes need 1342 to be able to recognize that a reservation with the new flow 1343 identifier is to be correlated with an existing one. The reservation 1344 identifier (section 4.5.2) was introduced for exactly this purpose. 1345 Note that this would require the reservation identifier to have 1346 (secure) end to end significance. (An additional optimization here 1347 would be use a local mobility management scheme to localize the 1348 visibility of the address change.) 1350 The feasibility and performance of this first approach needs to be 1351 assessed, including a detailed analysis of the signaling scenarios 1352 after a handover. However, given the high impact of requiring more 1353 sophisticated packet classifiers, initially it still seems more 1354 plausible than the second approach. This implies that the NSIS 1355 initiator should define flows in terms of real (care of) addresses 1356 rather than virtual (home) addresses. Thus, it would have detailed 1357 access to lower layer interface configuration (cf. section 4.1), 1358 rather than operating as a pure application level daemon as is 1359 commonplace with current RSVP implementations. 1361 5.3.2 Localized Path Repair 1363 In any mobility approach, a handover will cause at least some changes 1364 in the path of upstream and downstream packets. NSIS needs to 1365 install new state on the new path, and remove it on the old. 1366 Provided that some NSIS node on the joined path - the crossover 1367 router - can recognize this situation (which again depends on 1368 reservation identification), state installation and teardown can be 1369 done locally between it and the mobile node. (This may have 1370 implications for which entities are allowed to generate which 1371 message types, see section 4.3.2). It seems that the basic NSIS 1372 framework already contains the fundamental components necessary for 1373 this. 1375 A critical point here is the signaling that is used to discover the 1376 crossover router. This is a generalization of the problem of finding 1377 next-NSIS-hop nodes: it requires extending the new path over several 1378 hops until it intersects the old one. This is easy for uplink traffic 1379 (where the mobile is the sender), but much harder for downlink 1380 traffic without signaling via the correspondent. There is no reason 1381 for the crossover routers for uplink and downlink flows to be the 1382 same, even for the same correspondent. The problem is discussed 1383 further in [23]. 1385 5.3.3 Reservation Update on the Unchanged Path 1387 On the path between the crossover router(s) and the correspondent, it 1388 is necessary to avoid, if possible, double reservations, but rather 1389 to update the reservation state to reflect new flow identification 1390 (if this is needed, which is the default assumption of section 1391 5.3.1). Examples of approaches that could be used to solve this 1392 problem are the following: 1393 *) Use a reservation state definition that does not change even if 1394 the flow definition changes (see Section 4.5.2). In this case this 1395 problem is solved. 1396 *) Use signaling all the way to the correspondent node (receiver end 1397 host), accepting the additional latency that this might impose. 1398 *) Use an NSIS-capable crossover router that manages this 1399 reservation update autonomously (more efficiently than the end 1400 nodes), with similar considerations to the local path repair case. 1402 5.3.4 Interaction with Mobility Signaling 1404 In existing work on mobility protocol and resource signaling protocol 1405 interactions, several framework proposals describing the protocol 1406 interactions have been made. Usually they have taken existing 1407 protocols (Mobile IP and RSVP respectively) as the starting point; it 1408 should be noted that an NSIS protocol might operate in quite a 1409 different way. In this section, we provide an overview of how these 1410 proposals would be reflected in framework of NSIS. The mobility 1411 aspects are described using Mobile IP terminology, but are generally 1412 applicable to other network layer mobility solutions. The purpose of 1413 this overview is not to select or prioritise any particular approach, 1414 but simply to point out how they would fit into our framework and any 1415 major issues with them. 1417 We can consider that two signaling processes are active: mobility 1418 signaling (e.g. binding updates or local micromobility signals) and 1419 NSIS. The discussion so far considered how NSIS should operate. There 1420 is still a question of how the interactions between the NSIS and 1421 mobility signaling should be considered. 1423 The basic case of totally independent specification and 1424 implementation seems likely to lead to ambiguities and even 1425 interoperability problems (see [22]). At least, the addressing and 1426 encapsulation issues for mobility solutions that use virtual links or 1427 their equivalents need to be specified in an implementation-neutral 1428 way. 1430 A type of 'loose' integration is to have independent protocol 1431 definitions, but to define how they trigger each other - in 1432 particular, how the mobility protocol triggers NSIS to send 1433 refresh/modify/tear messages. A pair of implementations could use 1434 these triggers to improve performance, primarily reducing latency. 1435 (Existing RSVP modification consider the closer interaction of making 1436 the RSVP implementation mobility-routing aware, e.g. so it is able to 1437 localize refresh signaling; this would be a self contained aspect of 1438 NSIS.) This information could be developed for NSIS by analyzing 1439 message flows for various mobility signaling scenarios as was done 1440 in [20]. 1442 An even tighter level of integration is to consider a single protocol 1443 carrying both mobility and resource information. Logically, there are 1444 two cases: 1445 1. Carry mobility routing information (a 'mobility object') in the 1446 resource messages, as is done in [22]. (The prime purpose in this 1447 approach is to enable crossover router discovery.) 1448 2. Carry resource signaling in the mobility messages, typically as a 1449 new extension header. This was proposed in [24] and followed up 1450 in [25]; [26] also anticipates this approach. In our framework, we 1451 could consider this a special case of NSIS layering, with the 1452 mobility protocol playing the role of the signaling transport (as 1453 in 4.3.1). 1454 The usefulness of this class of approach depends on a tradeoff 1455 between specification simplicity and performance. Simulation work is 1456 under way to compare the performance of the two approaches in the 1457 case of RSVP and micromobility protocols. 1459 Other modes of interaction might also be possible. The critical point 1460 with all these models is that the general solutions developed by NSIS 1461 should not depend fundamentally on the choice of any particular 1462 mobility protocol. Especially if it has interdomain scope, tight 1463 integration would have major deployment issues (even loose 1464 integration could require NSIS implementations to hook into multiple 1465 different mobility protocols). Therefore, any tightly integrated 1466 solution should be considered out of scope of initial NSIS 1467 development, and even in the long term is probably only applicable if 1468 it can be localized within a particular part of the network. 1470 5.3.5 Interaction with Fast Handoff Support Protocols 1472 In the context of mobility between different access routers, it is 1473 common to consider performance optimizations in two areas: selection 1474 of the optimal access router to handover to, and transfer of state 1475 information between the access routers to avoid having to regenerate 1476 it in the new access router after handover. The seamoby working group 1477 is developing solutions for these protocols for pure IP based 1478 networks (CARD and CT respectively); other networks, which use NSIS 1479 for resource signaling within the network, may use different types of 1480 solution. 1482 In this section, we consider how NSIS should interact with these 1483 functions, however they are implemented. Detailed solutions are not 1484 proposed, but the way in which interaction these functions is seen 1485 within the NSIS framework is described. NSIS should be able to 1486 operate independently of these protocols. However, significant 1487 performance gains could be achieved if they could be made to 1488 cooperate. In addition, the resource signaling aspects of these 1489 protocols could profitably use a common set of resource types and 1490 definitions, since they will probably be supporting the same overall 1491 signaling application. 1493 The question arises, what the mode of interaction should be: 1494 independent operation, NSIS triggering access router discovery and 1495 state transfer, or vice versa. The questions for the two cases seem 1496 to be independent. 1498 For access router discovery, a typical model of operation is that the 1499 mobile carries out an information gathering exercise about a range of 1500 capabilities. In addition, where those capabilities relate purely to 1501 the AR and mobile, there is no role for NSIS (its special 1502 functionality is not relevant). However, considering resource 1503 aspects, one aspect of the AR 'capability' is resource availability 1504 on the path between it and the correspondent, and NSIS should be able 1505 to fulfill this part. Indeed, this is effectively precisely the 1506 application considered in [25], where it is a sort of special case of 1507 resource signaling during handover. 1509 Therefore, a possible model of access router discovery/NSIS 1510 relationship is that some entity in a candidate AR triggers NSIS 1511 using resource and reservation information (including reservation id) 1512 from the current AR to find out about what would be available on the 1513 new path. Note that this should be a query rather than an actual 1514 reservation; this semantic could be included either in the service 1515 definition or NSIS itself. 1517 The case of state transfer is more complex. There are two obvious 1518 options, corresponding to whether one transfers just signaling 1519 application state or NSIS state as well: 1520 1. "State transfer triggering NSIS": A state transfer process passes 1521 the 'raw' resource state to the new AR. This triggers a new instance 1522 of NSIS to request that resource. 1523 2. "NSIS using state transfer": NSIS transfers its own state 1524 information from the old to the new AR. It can then carry out the 1525 same update signaling as though it was a single 'virtual AR' which 1526 had just had a topology change towards the correspondent. (This is 1527 essentially the conceptual model of [20].) 1529 The first model is simpler, and maybe more in line with the basic 1530 state transfer expectation; however, it seems hard to avoid double 1531 reservations since the two NSIS protocol instances are not 1532 coordinated. Therefore, the second model seems more appropriate. An 1533 advantage of the 'virtual AR' model is that it ensures that the 1534 impact of the interaction is limited to the NSIS instances at ARs 1535 themselves, since the rest of the network must be able to handle a 1536 topology change anyway. 1538 Note that there is an open issue of who is responsible between the 1539 mobile and AR to decide that the state transfer procedures have not 1540 happened for whatever reason - e.g. because they were not even 1541 implemented - and take recovery action to have the mobile refresh 1542 reservations promptly. It appears this has to be an NSIS 1543 responsibility in the AR, and probably requires a custom notification 1544 message for this circumstance. 1546 5.4 NSIS Interacting with NATs 1548 Because at least some NSIS messages will almost inevitably contain 1549 address and possibly higher layer information as payload (see section 1550 4.5.1), we must consider the interaction between NSIS and address 1551 translation devices (NATs). As well as 'traditional' NATs of various 1552 types (as defined in [27]) very similar considerations would apply to 1553 some IPv4/v6 transition mechanisms such as SIIT [28]. 1555 In the simplest case of an NSIS unaware NAT in the signaling path, 1556 payloads will be uncorrected and the signaling will be for the 1557 incorrect flow. Applications could attempt to use STUN [29] or 1558 similar techniques to detect and recover from the presence of the 1559 NAT. Even then, NSIS would have to use a well known encapsulation 1560 (TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end 1561 NAT devices. 1563 A simple 'NSIS-aware' NAT would require flow identification 1564 information to be in the clear and not integrity protected. An 1565 alternative conceptual approach is to consider the NAT functionality 1566 being part of NSIS message processing itself, in which case the 1567 translating node can take part natively in any NSIS security 1568 mechanisms. Depending on NSIS layering, it could be possible for this 1569 processing to be done in an NSIS node which was otherwise ignorant of 1570 any particular NSIS signaling applications. 1572 Note that all of this discussion is independent of the use of NSIS 1573 for general control of NATs (and firewalls). This is considered in 1574 section 7.4. 1576 6. Security and AAA Considerations 1578 A framework is meant to create boundaries for a later protocol and to 1579 describe the interaction between the protocol and its environment. 1580 Security issues usually turn out to have impacts in the interaction 1581 of these protocols and must therefore be appropriately addressed in 1582 such a framework. This section describes these general security 1583 issues, and in particular considers the interactions between NSIS and 1584 authentication, authorization and accounting. Together with 1585 authentication the protection of the signaling messages is addressed 1586 - namely replay and integrity protection. 1588 An initial analysis of the major security threats that apply in the 1589 typical of scenario where NSIS is expected to be used is given in 1590 [4]; these threats are described at the overall scenario level, in 1591 terms of the impact on users and networks. However, in any given 1592 scenario, NSIS will be just one protocol or component of the overall 1593 solution. Ultimately, the framework will need to define which of 1594 these threats need to be handled by NSIS and which by the other 1595 components. Currently, we can only make initial scoping assumptions 1596 of this sort. 1598 6.1 Authentication 1600 Authentication and key establishment for a signaling protocol should 1601 be seen as a two-phase process. The first-phase is usually more 1602 performance intensive because of a larger number of roundtrips, 1603 denial of service protection, cross-realm handling, interaction with 1604 other protocols and the likely larger cryptographic computation 1605 associated with it. As stated in section 4.3, this functionality 1606 could be provided externally to NSIS, e.g. by reusing a standard 1607 protocol which already included this functionality. 1609 At the end of this phase it should be possible to create or derive 1610 security associations that are usable for the protection of the NSIS 1611 signaling messages themselves. The functionality required here 1612 relates to (data origin) authentication (including integrity and 1613 replay protection) of individual signaling messages. Key 1614 establishment, rekeying, synchronization issues are issue that may be 1615 addressed here depending on the specific method. In any case the 1616 protection applied to each signaling message must be fast and 1617 efficient. 1619 When using cryptography to protect signaling messages, it is obvious 1620 that a node must be able to select the appropriate security 1621 association in order to be able to apply signaling message 1622 protection. This should just be a general point about endpoint 1623 identity issues. Hence the identifier must be available to the 1624 transmitting node. Regarding identities there is a need to support 1625 different identity types to enable the flexible usage of several 1626 signaling initiators and receivers. Supporting static configuration 1627 and dynamic learning of these identities should be provided. 1629 6.2 Authorization 1631 Authorization information can be seen in an abstract form as "Can the 1632 resource requestor be trusted to pay for the reservation?". This 1633 abstraction is supported by the fact that reservations require some 1634 form of incentive to use some 'default' resource (or vice versa - 1635 penalty for not reserving too many resources). In general, the 1636 semantics of the authorisation will depend on the signaling 1637 application in use. The implication of this is that NSIS will not 1638 directly make authorisation decisions; instead, the authorisation 1639 information must be fed into the resource management function 1640 (section 5.1) which actually decides on the request. 1642 Some negotiation needs to take place to determine which node will 1643 take responsibility for authorising a resource request, the 1644 implication being that the same node will ultimately be accounted to 1645 for it. Such a negotiation needs to be flexible enough to support 1646 most currently deployed schemes (e.g. reverse charging, etc.) while 1647 keeping efficiency and simplicity in mind. This negotiation might be 1648 executed before starting resource signaling (assumed in section 4.2), 1649 although it could also be part of the NSIS signaling messages (as in 1650 some proposals dealing with charging and RSVP). Since information 1651 needs to be sent to the networks, some information needs to be 1652 included to provide the network with the necessary information to 1653 start the authorisation process. Hence fully opaque objects might not 1654 always be the proper choice. 1656 It is not clear if 'initiation' of a reservation is related to 1657 willingness to accept authorisation responsibility. (Current 1658 practices tend to assume that flow originators are responsible.) In 1659 any case, it seems unlikely that a domain will make a cost-incurring 1660 request of a peer domain without already having received a matching 1661 request from the peer in the other direction - in other words, 1662 requests must propagate between domains in the same direction as 1663 authorisation responsibility. 1665 If this argument is correct, and if NSIS initiation and authorisation 1666 responsibility are decoupled, it must be possible for the 1667 authorisation responsibility to propagate both in the direction 1668 initiator->responder and vice versa. Also, if both [flow] sender and 1669 receiver initiation are possible, service descriptions must include 1670 information about the authorisation policy to be applied, which must 1671 be imposed consistently along the whole path. These issues should be 1672 analyzed to determine if 1, 2 or 4 alternative scenarios are possible 1673 and realistic. 1675 A second question is that of which entities actually authorise which. 1676 One end user must ultimately get authorisation for the request (this 1677 may or may not be assumed to be the NSIS initiator, see below). There 1678 are then two possible models for how this authorisation is done 1679 throughout the path. 1681 The first model assumes that each network along the path is able to 1682 authenticate and authorise the user directly. The implication for a 1683 signaling protocol is that the user credentials cannot be removed 1684 after the first hop and have to be further included in the message 1685 when forwarded to other networks. Every node along the path is then 1686 able to verify the user and to provide policy based admission 1687 control. 1689 The second model assumes that the user credentials are removed at the 1690 first hop. The first network knows the user identity requesting the 1691 resources but does not include this information further along the 1692 path. The first network can therefore be seen as acting on behalf of 1693 the originator to take responsibility to enable further reservations 1694 to be done along the path i.e. in particular to the next network 1695 only. This procedure is then applied on a hop-by-hop basis. 1697 Note that both models are independent of whether a traditional 1698 subscription based approach or an alternative means of payment (such 1699 as pre-pay on on-line charging by the visited network) is used. These 1700 issues only have an impact for the transmission of accounting records 1701 and for a requirement to execute an online verification whether a 1702 user still has sufficient credits/funds; therefore, these details do 1703 not affect NSIS operation. 1705 6.3 Accounting 1707 It is obvious that accounting/charging is an important part for the 1708 success and the acceptance of a resource signaling protocol. Most of 1709 the thinking in this area is derived from the specific case of 1710 signaling for QoS; however, we make an initial working assumption 1711 that the same paradigm should apply to any signaling application for 1712 which accounting is necessary. We make the general assumption here 1713 that accounting records are generated by the resource management 1714 function based entirely on traffic measurements and processed in 1715 accordance with the authorisation information that was used in 1716 deciding to grant the request in the first place. 1718 Therefore, NSIS plays no further part in this activity; the 1719 accounting records are transmitted using the AAA infrastructure, and 1720 charging and billing for the overall service is carried out at some 1721 higher layer. This would include feedback to applications (and users) 1722 about total session cost (of which the network resource cost might be 1723 only a part). An open issue is whether a query (without actually 1724 making a reservation) to the network should also generate a 1725 chargeable event; this could be considered as an aspect of the 1726 service definition. 1728 6.4 End-to-End vs. Peer-Session Protection 1730 It is reasonable to assume that peer-session security (with chain-of- 1731 trust) is used for most signaling environments relevant to NSIS. 1732 Especially the separation of signaling into different network parts 1733 (intra-domain within the access network, end-node to access network, 1734 intra-domain, and so on) and new proposals regarding mobility and 1735 proxy support show that traditional end-to-end signaling is not 1736 applicable in every environment (or possibly only in a minor number 1737 of environments). End-to-end security in a signaling protocol is 1738 actually problematic for two reasons: 1740 1. Even if the messages use the address of the end-host (to support 1741 routing), the messages still have to be interpreted and modified 1742 along the path. 1744 2. The only property that can be achieved by using end-to-end 1745 security is that one end-host can be assured that the other end-host 1746 included some parameters (possibly resource parameters) that have not 1747 been modified along the path. Nodes along the path usually do not 1748 have the possibility to cryptographically verify the protected 1749 message parts. If the two end-points negotiate which side has to pay 1750 for the reservation (or possibly how much and other parameters) 1751 within the signaling protocol then there is a need to protect this 1752 information. This leads to the question which protocols are executed 1753 before the signaling message exchange starts. If resource parameters 1754 and payment/charging related information are already exchanged 1755 beforehand as part of a separate protocol (possibly SIP) then there 1756 is little need to protect (and possibly retransmit) this information 1757 at the NSIS level basis. In most cases an opaque token to link the 1758 different protocols may be sufficient. 1760 7. NSIS Application Scenarios 1762 This section considers various application scenarios or deployment 1763 configurations for NSIS. Our goal is that an NSIS protocol designed 1764 according to the framework presented in the previous sections should 1765 be able to support these scenarios if implemented appropriately; 1766 therefore, this section does not form part of the framework 1767 definition, but rather provides examples of how NSIS can be used to 1768 do something interesting. In the long term, some of this material may 1769 be contained in specific NSIS applicability statements. 1771 7.1 NSIS and Existing Resource Signaling Protocols 1773 It is hoped that an NSIS protocol could eventually achieve widespread 1774 use for resource signaling. However, it is bound to have to inter- 1775 operate with existing resource signaling protocols at least during 1776 transition and possibly long term. The prime example for QoS is RSVP, 1777 although other proprietary or domain specific protocols (e.g. 1778 bandwidth broker related) may also be considered. A related issue is 1779 that NSIS will be only one part of the solution: it will always need 1780 to interwork with other resource-related protocols (e.g. COPS). 1782 Analyzing the constraints on NSIS that come from these requirements 1783 is hard before further refinement of the framework has been carried 1784 out and critical assumptions pinned down. However, we can identify 1785 various modes of interoperation, and the attributes of the framework 1786 that will make them easy. 1788 Firstly, we allow for NSIS use over a 'long range', in conjunction 1789 with a different protocol locally (e.g. intra-domain); or, the two 1790 roles could be reversed. This is actually very similar to the case of 1791 use of NSIS layered over itself (section 7.5). In the case where the 1792 'inter-layer' interaction is mediated via resource management, the 1793 same should approach should work with non-NSIS protocols. What needs 1794 to be validated here is whether NSIS layering requires the exchange 1795 of NSIS specific information between the layers. 1797 A second issue is that NSIS should be deployable within an 1798 environment without radical changes to supporting resource (or AAA) 1799 related protocols. The main issue here is that NSIS should be 1800 flexible in its ability to support different service definitions (and 1801 possibly flow classifications). This is already one of the main goals 1802 of the framework presented here. 1804 The final point is that it should be possible to use NSIS over one 1805 network region, concatenated with another protocol over an adjacent 1806 region. The main issue here, apart from the flexible service and flow 1807 capabilities already mentioned, is that NSIS should be adaptable in 1808 what it assumes about signaling paths (e.g. to interwork with both 1809 path-coupled and decoupled solutions), and in initiation paradigms 1810 (e.g. to interwork with sender and receiver initiated solutions). 1812 7.2 NSIS Supporting Centralized QoS Resource Management 1814 One area of application for the NSIS protocol is for QoS resource 1815 reservation and provisioning. The NSIS protocol may be used to 1816 provide intra-domain or inter-domain QoS bandwidth reservation setup 1817 by means of its interaction with the RMF. In what follows we assume 1818 that the NEs are colocated with an admission control entity that has 1819 a logical (abstract) view on the resources managed by the RMF, as 1820 described in section 5.1. 1822 The NEs in a domain can interface with an RMF managing the complete 1823 domain, in which case, the abstract topology view provided between 1824 NSIS and RMF can be formalized as a Service Level Agreement (SLA). 1825 This situation is depicted schematically in Figure 6. 1827 +----+ NSIS +-----+ NSIS +----+ 1828 | NI |------------| NF |-------------| NR | 1829 +----+ +-----+ +----+ 1830 | 1831 | SLA 1832 | 1833 +------+ 1834 | RMF | 1835 +------+ 1837 Figure 6: Resource Reservation using RMF as a Server to NSIS 1839 In case of centralized RMF, the SLA or its technical part, the 1840 Service Level Specification (SLS) [30] specifies the resource 1841 guarantees that the RMF needs to provide to the NF. These guarantees 1842 apply between one or more ingress and egress points of the network. 1843 The SLS also specifies the availability and reliability of the 1844 service. In the case of QoS signaling, it may refer to a bandwidth 1845 service with certain performance guarantees regarding delay, jitter 1846 or packet loss. The SLS interface can be automated by means of an SLS 1847 negotiation protocol. This allows for more dynamical SLS 1848 modifications and the exchange of notification messages with the NF. 1849 These can for instance be used to provide monitoring feedback from 1850 the RFM to the NF. 1852 The decoupling of NSIS signaling and network management by means of 1853 an SLS has some attractive properties: 1854 *) It allows a Network Provider to easily share the use of its 1855 infrastructure between several Service Providers using NSIS signaling 1856 to provide their service. 1857 *) It allows a clear separation between resource provisioning and 1858 management and reservation signaling and admission control. 1859 *) It relieves the NF from several tasks, making it potentially more 1860 scalable in the core of the network. 1862 The NF can perform either per-flow or per-class admission control 1863 decisions based on the requested QoS information and on the 1864 reservation state it keeps regarding active flows (or classes). 1865 Keeping per-flow state may be required for policing, 1866 accounting/billing and explicit reservation teardown. These functions 1867 are mandatory in the access or edge of the network. Conveniently, 1868 this is also where the processing needed to maintain per-flow state 1869 will remain manageable. In the core, this approach may not scale very 1870 well and per-class state may be used as an alternative that is very 1871 scalable and allows for a lightweight processing of signaling 1872 messages. With per-class state, however, we lose the ability to 1873 directly notify the NI in case of unsolicited network events because 1874 the affected flows cannot be identified. Instead, the NI needs to be 1875 indirectly notified in response to a refresh message which in turn 1876 mandates the use of soft-state with separate messages or message 1877 structure for requests and refreshes. 1879 The RMF can execute its network provisioning functions according to 1880 its internal policies. In the easiest case, it may run an 1881 overprovisioned network with only monitoring capabilities in order to 1882 follow up on the delivered performance. In more complex scenarios, it 1883 may use a whole array of network optimization tools in order to 1884 deliver and maintain service quality according to the SLS. This may 1885 require network monitoring, the installation and use of appropriate 1886 protection mechanisms and providing feedback regarding actual traffic 1887 performance to the NSIS entity. 1889 Alternatively, the NSIS protocol may be used for resource 1890 provisioning. In that case, the RMF acts as a client towards the NSIS 1891 protocol, as a particular "application" triggering an NI for 1892 resources in the network. This situation is depicted in Figure 7. 1894 +------+ 1895 +----------| RMF |----------+ 1896 / +------+ \ 1897 / \ 1898 / \ 1899 / \ 1900 +----+ NSIS +-----+ NSIS +----+ 1901 | NI |------------| NF |-------------| NR | 1902 +----+ +-----+ +----+ 1904 Figure 7: NSIS for Resource Provisioning 1906 In this case the RMF is providing traffic classification and 1907 conditioning functions. An example of such functionality is described 1908 in [31]. The packet "classifiers" select the packets in a traffic 1909 stream based on the content of some portion of the packet header. The 1910 traffic "conditioner" performs metering, shaping, policing, 1911 scheduling and/or re- marking of packets to ensure that the traffic 1912 entering a node conforms to a certain predefined policy. 1914 7.3 NSIS Supporting Distributed Resource Management 1916 Section 7.2 described the situation where NSIS is supporting a 1917 centralized RMF. This section introduces the situation where NSIS is 1918 supporting a distributed RMF. When the RMF is distributed in the 1919 network, a protocol for communication with the NI, NF, NR may not be 1920 required. In this case the RMF is providing traffic classification 1921 and conditioning functions; an example of such functionality is 1922 described in [31]. Figure 8 shows how a distributed RMF could 1923 interact with the NSIS protocol. 1925 +----+ NSIS +-----+ NSIS +-----+ NSIS +----+ 1926 | NI |<========>| NF |<===...===>| NF |<========>| NR | 1927 +----+ +-----+ +-----+ +----+ 1928 +----+ +-----+ +-----+ +----+ 1929 |RMF | | RMF | | RMF | |RMF | 1930 +----+ +-----+ +-----+ +----+ 1932 Figure 8: Distributed RMF as a server for NSIS 1934 7.4 NSIS for Middlebox Signaling 1936 As well as the use for 'traditional' QoS signaling, it should be 1937 possible to use NSIS to set up flow-related state in middleboxes 1938 (firewalls, NATs, and so on). Requirements for such communication are 1939 given in [32], and initial discussions of NSIS-like solutions are 1940 contained in [33] and [34]. A future version of this document may 1941 contain more details on how an NSIS should be used for this type of 1942 signaling application. 1944 7.5 Multi-Level NSIS Signaling 1946 This section describes a way of separating the NSIS signaling 1947 protocol into more than one hierarchical level. In this section three 1948 levels of hierarchy are considered (see Figure 9); however, the 1949 approach is quite general to more (or fewer) levels: the important 1950 issue is the use of NSIS at more than one level at all. 1952 The lowest hierarchical level ("level 1") provides basic resource 1953 management functionality related to scalable, simple and fast soft 1954 state maintenance and to transport functions, such as reliable 1955 delivery of signaling messages, congestion control notification and 1956 load sharing adaptation. Soft state that is maintained by this level 1957 is usually per traffic class based. 1959 The second hierarchical level ("level 2") is more complex than level 1960 1 as regards soft state maintenance. Soft state maintained by this 1961 hierarchical level is usually per flow. Note that this level, like 1962 level 1, also supports transport functions. When an NSIS edge-to-edge 1963 multi-domain protocol is used, level 2 stretches beyond domain 1964 boundaries and is applied on all the edges of the domains that are 1965 included in the multidomain region. 1967 The third hierarchical level ("level 3") includes a set of upper- 1968 level signaling functions that are specific to particular signaling 1969 applications. Such functions could, for example, be security, policy, 1970 billing, etc. 1972 As shown in Figure 9, the three hierarchical levels might be applied 1973 on different NSIS entities. 1975 This three-level architecture for NSIS signaling can be provided by 1976 using: 1977 *) a single end-to-end NSIS protocol that supports all three 1978 hierarchical levels 1979 *) two independent NSIS protocols: Level 3 is supported by an end- 1980 to-end NSIS protocol, and levels 1 and 2 are supported by another 1981 edge-to-edge NSIS protocol. 1983 |-----| |-------| |-------| |-----| 1984 |level|<--| level |<--------------------------| level |<->|level| 1985 | 3 |<--| 3 | | 3 |<->| 3 | 1986 |-----| |-------| |-------| |-----| 1987 | | | | | | | | 1988 | | |-------| |-------| | | 1989 | | | level |<------------------------->| level | | | 1990 | | | 2 | | 2 | | | 1991 | | |-------| |-------| | | 1992 | | | | | | | | 1993 |-----| |-------| |-------| |-------| |-------| |-----| 1994 |level|<->| level |<->| level |<->| level |<->| level |<->|level| 1995 | 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 | 1996 |-----| |-------| |-------| |-------| |-------| |-----| 1997 NI NF NF NF NF NR 1998 (edge) (interior) (interior) (edge) 2000 Figure 9: Three level architecture for NSIS signaling 2002 The components in the scenario are as follows: 2003 *) NI (NSIS Initiator): can be an end-host or a proxy and can 2004 process and use the "level 1" and "level 3" protocol components 2005 *) NR (NSIS Responder): can be an end-host or a proxy and can 2006 process and use the "level 1" and "level 3" protocol components 2007 *) NF (NSIS Forwarder) (edge): can be a Diffserv edge, MPLS edge, 2008 etc. It can process and use the "level 3", "level 2" and "level 1" 2009 protocol components. Usually, "level 2" provides an interworking 2010 between "level 1" and "level 3" protocol components. 2011 *) NF (interior): can be any router within a domain. It can process 2012 and use only the "level 1" protocol component. The "level 3" and 2013 "level 2" protocol components are not processed (used or checked). 2015 The hierarchical level separation can be provided by supporting a 2016 hierarchical object structure. In other words, the NSIS protocol 2017 objects should be structured and positioned within the NSIS messages 2018 in a hierarchical way, i.e., first the "level 1" objects, then the 2019 "level 2" objects and finally the "level 3" objects. 2021 8. Open Issues 2023 The following issues are currently open points within the framework. 2024 They are summarized here to provide a single overview. 2026 1. It is not clear which of the NI, NF and NR can modify or release 2027 existing reservations (this is essentially an authorisation issue). 2028 (Section 3.3.2.) 2029 2. It is not clear whether NSIS entities relate to each other only 2030 locally (peer-peer) or whether longer distance, non-local 2031 interactions and state have to be managed and stored. (Section 2032 3.3.3.) 2034 3. NSIS messages could be addressed either explicitly (to the 2035 neighboring peer) or implicitly, using the flow endpoint addresses. 2036 (Section 3.3.4.) 2038 4. It is not clear whether the service description semantics (in 2039 theory, opaque to NSIS) need to be analysed in more detail to 2040 determine requirements on the protocol. (Section 3.3.5.) 2042 5. If NSIS has explicit acknowledgement and notification messages, 2043 it is open whether they should relate to anything beyond the 2044 immediate peer-session. (Section 3.3.6.) 2046 6. To function as part of a complete system, the NSIS protocol may 2047 need to be supported by extensions to other protocols. These 2048 extensions are still to be identified. (Section 4.2.) 2050 7. The NSIS protocol could be constructed on the services offered by 2051 lower layer protocols, but the dividing line between NSIS and these 2052 lower layers is not fixed. Use of standard lower layer protocols may 2053 be difficult if 'end-to-end addressing' (see section 3.3.4) is used. 2054 (Section 4.3.1.) 2056 8. It is commonly expected that a future resource signaling protocol 2057 would need to use abstract reservation identifiers. However, the 2058 precise properties needed of these identifiers are unclear, and 2059 enabling their secure use may be hard. (Sections 4.5.2 and 5.3.2.) 2061 9. Use of some routing techniques (e.g. load sharing or QoS 2062 routing), even in remote parts of the network, could be incompatible 2063 with naive use of end-to-end addressing. (Sections 5.2.1 and 5.2.2.) 2065 10. The correct flow identification semantics need to be defined in 2066 the case where mobility encapsulations might make it ambiguous which 2067 addresses to use. (Section 5.3.1.) 2069 11. The interactions between mobility and resource signaling during 2070 path updating need to be further analyzed, especially from the point 2071 of view of combined overall latency. (Section 5.3.2 and 5.3.3.) 2073 9. Change History 2075 9.1 Changes from draft-hancock-nsis-fw-00.txt 2077 1. Changed title, document name and dates. 2078 2. Updated references. 2079 3. Editorial fix in NSIS Forwarder definition (section 2). 2080 4. Revised section 3.2.1 (path-coupled terminology), now used 2081 consistently in the rest of the document. Likewise, 'signaling 2082 application' terminology used consistently in remainder of document. 2083 5. Split old section 5 into new sections (new 5 "real interactions", 2084 new 7 "how to use NSIS to do something useful"). 2085 6. Added new resource management text for section 5.1; slight 2086 smoothing to balance centralized and distributed, and comment on 2087 NI/NF/NR distinction. 2088 7. Added VRRP placeholder in routing section of section 5 (5.2.5). 2089 8. Added section 5.4 on NSIS/NAT interactions based on Melinda's 2090 email. 2091 9. Added new text for resource management in section 7.2; slightly 2092 trimmed and made clearer that it is mainly discussing the centralized 2093 case (and isn't specific to the inter-domain case). Comment that it's 2094 OK to use the Q-word here since we aren't talking about the NSIS 2095 protocol but a use of the NSIS protocol. 2096 10. Added section 7.3 for discussion of how NSIS can be used in a 2097 distributed resource management environment. 2098 11. Added a placeholder in section 7.4 for use of NSIS for midcom 2099 (no technical content, but references to the midcom requirements and 2100 the TIST and NEC drafts). 2101 12. Moved open issues from section 3.3.1 to new section 8 (left 2102 assumptions behind). 2103 13. Added this changes section 9. 2105 References 2107 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2108 9, RFC 2026, October 1996. 2110 2 Brunner, M., "Requirements for QoS Signaling Protocols", draft- 2111 ietf-nsis-req-04.txt (work in progress), August 2002 2113 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2114 Levels", BCP 14, RFC 2119, March 1997 2116 4 Tschofenig, H., "NSIS Threats", draft-tschofenig-nsis-threats- 2117 01.txt (work in progress), July 2002 2119 5 Katz, D., "IP Router Alert Option", RFC 2113, February 1997 2121 6 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 2122 October 1999 2124 7 Braden, R., "A Two-Level Architecture for Internet Signaling", 2125 draft-braden-2level-signal-arch-00.txt (work in progress), 2126 November 2001 (expired) 2128 8 Stewart, R. et al., "Stream Control Transmission Protocol", RFC 2129 2960, October 2000 2131 9 Kent, S., R. Atkinson, "Security Architecture for the Internet 2132 Protocol", RFC 2401, November 1998 2134 10 Westberg, L., et al., "Framework for Edge-to-Edge NSIS Signaling", 2135 draft-westberg-nsis-edge-edge-framework-00.txt (work in progress), 2136 May 2002 2138 11 Apostolopoulos, G., et al., "QoS Routing Mechanisms and OSPF 2139 Extensions", RFC 2676, August 1999 2141 12 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 2142 1771, March 1995 2144 13 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 2145 draft-ietf-idr-bgp4-17.txt (work in progress), January 2002 2147 14 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of 2148 Multiple Paths in BGP", draft-walton-bgp-add-paths-00.txt (work in 2149 progress), May 2002 2151 15 Cristallo, G., C. Jacquenet, "Providing Quality-of-Service 2152 Indication by the BGP-4 Protocol: the QoS_NLRI Attribute", draft- 2153 jacquenet-qos-nlri-04.txt (work in progress), March 2002 2155 16 Bonaventure, O., S. De Cnodder, J. Haas, B. Quoitin and R. White, 2156 "Controlling the redistribution of BGP Routes", draft-bonaventure- 2157 bgp-redistribution-02.txt (work in progress), February 2002 2159 17 Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 2160 Version 1 Functional Specification", RFC 2205, September 1997 2162 18 Westberg, L., M. Jacobsson, G. Karagiannis, S. Oosthoek, D. 2163 Partain, V. Rexhepi, R. Szabo, P. Wallentin, "Resource Management 2164 in Diffserv (RMD) Framework", draft-westberg-rmd-framework-01.txt 2165 (work in progress), February 2002 2167 19 Knight, S. et al., "Virtual Router Redundancy Protocol", RFC2338, 2168 April 1998 2170 20 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 2171 thomas-seamoby-rsvp-analysis-00.txt (work in progress), February 2172 2001 (expired) 2174 21 Partain, D. et al., "Resource Reservation Issues in Cellular Radio 2175 Access Networks", draft-westberg-rmd-cellular-issues-01.txt (work 2176 in progress), June 2002 2178 22 Shen, C. et al., "An Interoperation Framework for Using RSVP in 2179 Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt 2180 (work in progress), July 2001 (expired) 2182 23 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt 2183 (work in progress), May 2002 2185 24 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile 2186 IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March 2187 2001 (expired) 2189 25 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile 2190 IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress), 2191 January 2002 2193 26 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6 2194 Networks", draft-kan-qos-framework-00.txt (work in progress), 2195 April 2002 2197 27 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 2198 (NAT) Terminology and Considerations", RFC2663, August 1999 2200 28 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 2201 RFC2765, February 2000 2203 29 Rosenberg, J. et al., "STUN - Simple Traversal of UDP Through 2204 Network Address Translators", draft-ietf-midcom-stun-02.txt (work 2205 in progress), August 2002 2207 30 Danny Goderis, et al. "Service Level Specification Semantics and 2208 Parameters", draft-tequila-sls-02.txt (work in progress), February 2209 2002 2211 31 Blake, S. et al, "An Architecture for Differentiated Services", 2212 RFC2475, December 1998 2214 32 Swale, R. P. et al., "Middlebox Communications (midcom) Protocol 2215 Requirements", RFC3304, August 2002 2217 33 Shore, M., "The TIST (Topology-Insensitive Service Traversal) 2218 Protocol", draft-shore-tist-prot-00.txt (work in progress), May 2219 2002 2221 34 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS 2222 Framework", draft-brunner-nsis-mbox-fmwk-00.txt (work in 2223 progress), June 2002 2225 Acknowledgments 2227 The authors would like to thank Anders Bergsten, Maarten Buchli, 2228 Melinda Shore and Hannes Tschofenig for significant contributions in 2229 particular areas of this draft. In addition, the authors would like 2230 to acknowledge Marcus Brunner, Danny Goderis, Eleanor Hepworth, 2231 Cornelia Kappler, Hans De Neve, David Partain, Vlora Rexhepi, and 2232 Lars Westberg for insights and inputs during this and previous 2233 framework activities. 2235 Author's Addresses 2237 Ilya Freytsis 2238 Cetacean Networks Inc. 2239 100 Arboretum Drive 2240 Portsmouth, NH 03801 2241 USA 2242 email: ifreytsis@cetacean.com 2244 Robert Hancock 2245 Roke Manor Research 2246 Old Salisbury Lane 2247 Romsey 2248 Hampshire 2249 SO51 0ZN 2250 United Kingdom 2251 email: robert.hancock@roke.co.uk 2252 Georgios Karagiannis 2253 Ericsson EuroLab Netherlands B.V. 2254 Institutenweg 25 2255 P.O.Box 645 2256 7500 AP Enschede 2257 The Netherlands 2258 email: georgios.karagiannis@eln.ericsson.se 2260 John Loughney 2261 Nokia Research Center 2262 11-13 Italahdenkatu 2263 00180 Helsinki 2264 Finland 2265 email: john.loughney@nokia.com 2267 Sven Van den Bosch 2268 Alcatel 2269 Francis Wellesplein 1 2270 B-2018 Antwerpen 2271 Belgium 2272 email: sven.van_den_bosch@alcatel.be 2274 Full Copyright Statement 2276 "Copyright (C) The Internet Society (date). All Rights Reserved. This 2277 document and translations of it may be copied and furnished to 2278 others, and derivative works that comment on or otherwise explain it 2279 or assist in its implementation may be prepared, copied, published 2280 and distributed, in whole or in part, without restriction of any 2281 kind, provided that the above copyright notice and this paragraph are 2282 included on all such copies and derivative works. However, this 2283 document itself may not be modified in any way, such as by removing 2284 the copyright notice or references to the Internet Society or other 2285 Internet organizations, except as needed for the purpose of 2286 developing Internet standards in which case the procedures for 2287 copyrights defined in the Internet Standards process must be 2288 followed, or as required to translate it into languages other than 2289 English. 2291 The limited permissions granted above are perpetual and will not be 2292 revoked by the Internet Society or its successors or assigns. This 2293 document and the information contained herein is provided on an "AS 2294 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2295 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2296 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2297 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2298 OR FITNESS FOR A PARTICULAR PURPOSE.