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