idnits 2.17.1 draft-ietf-nsis-fw-05.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7470 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 480 looks like a reference -- Missing reference section? '2' on line 1894 looks like a reference -- Missing reference section? '3' on line 163 looks like a reference -- Missing reference section? '4' on line 1845 looks like a reference -- Missing reference section? '5' on line 1471 looks like a reference -- Missing reference section? '6' on line 166 looks like a reference -- Missing reference section? '7' on line 1747 looks like a reference -- Missing reference section? 'Data' on line 212 looks like a reference -- Missing reference section? '8' on line 329 looks like a reference -- Missing reference section? '9' on line 329 looks like a reference -- Missing reference section? '10' on line 1810 looks like a reference -- Missing reference section? '11' on line 955 looks like a reference -- Missing reference section? '12' on line 980 looks like a reference -- Missing reference section? '13' on line 1108 looks like a reference -- Missing reference section? '14' on line 1108 looks like a reference -- Missing reference section? '15' on line 1128 looks like a reference -- Missing reference section? '16' on line 1341 looks like a reference -- Missing reference section? '17' on line 1439 looks like a reference -- Missing reference section? '18' on line 1472 looks like a reference -- Missing reference section? '19' on line 1473 looks like a reference -- Missing reference section? '20' on line 1487 looks like a reference -- Missing reference section? '21' on line 1545 looks like a reference -- Missing reference section? '22' on line 1547 looks like a reference -- Missing reference section? '23' on line 1560 looks like a reference -- Missing reference section? '24' on line 1561 looks like a reference -- Missing reference section? '25' on line 1565 looks like a reference -- Missing reference section? '26' on line 1595 looks like a reference -- Missing reference section? '27' on line 1622 looks like a reference -- Missing reference section? '28' on line 1622 looks like a reference -- Missing reference section? '29' on line 1711 looks like a reference -- Missing reference section? '30' on line 1782 looks like a reference -- Missing reference section? '31' on line 1810 looks like a reference -- Missing reference section? '32' on line 1810 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft R. Hancock (editor) 4 Siemens/Roke Manor Research 5 I. Freytsis 6 Cetacean Networks 7 G. Karagiannis 8 University of Twente/Ericsson 9 J. Loughney 10 Nokia 11 S. Van den Bosch 12 Alcatel 13 Document: draft-ietf-nsis-fw-05.txt 14 Expires: April 2004 October 2003 16 Next Steps in Signaling: Framework 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Next Steps in Signaling working group is considering protocols 41 for signaling information about a data flow along its path in the 42 network. Based on existing work on signaling requirements, this 43 document proposes an architectural framework for such signaling 44 protocols. 46 This document provides a model for the network entities that take 47 part in such signaling, and the relationship between signaling and 48 the rest of network operation. We decompose the overall signaling 49 protocol suite into a generic (lower) layer, with a separate upper 50 layers for each specific signaling application. An initial proposal 51 for the split between these layers is given, describing the overall 52 functionality of the lower layer, and discussing the ways that upper 53 layer behavior can be adapted to specific signaling application 54 requirements. 56 This framework also considers the general interactions between 57 signaling and other network layer functions, specifically routing, 58 mobility, and address translators. The different events that impact 59 signaling operation are described, along with how their handling 60 should be divided between the generic and application-specific 61 layers. Finally, an example signaling application (for Quality of 62 Service) is described in more detail. 64 Table of Contents 66 1 Introduction ...................................................3 67 1.1 Definition of the Signaling Problem ......................3 68 1.2 Scope and Structure of the NSIS Framework ................4 69 2 Terminology ....................................................5 70 3 Overview of Signaling Scenarios and Protocol Structure .........6 71 3.1 Fundamental Signaling Concepts ...........................6 72 3.1.1 Simple Network and Signaling Topology ..................6 73 3.1.2 Path-Coupled and Path-Decoupled Signaling ..............7 74 3.1.3 Signaling to Hosts, Networks and Proxies ...............8 75 3.1.4 Signaling Messages and Network Control State ..........10 76 3.1.5 Data Flows and Sessions ...............................10 77 3.2 Layer Model for the Protocol Suite ......................11 78 3.2.1 Layer Model Overview ..................................11 79 3.2.2 Layer Split Concept ...................................12 80 3.2.3 Bypassing Intermediate Nodes ..........................13 81 3.2.4 Core NTLP Functionality ...............................15 82 3.2.5 State Management Functionality ........................15 83 3.2.6 Path De-Coupled Operation .............................16 84 3.3 Signaling Application Properties ........................17 85 3.3.1 Sender/Receiver Orientation ...........................17 86 3.3.2 Uni- and Bi-Directional Operation .....................18 87 3.3.3 Heterogeneous Operation ...............................19 88 3.3.4 Aggregation ...........................................19 89 3.3.5 Peer-Peer and End-End Relationships ...................20 90 3.3.6 Acknowledgements and Notifications ....................20 91 3.3.7 Security and Other AAA Issues .........................21 92 4 The NSIS Transport Layer Protocol .............................21 93 4.1 Internal Protocol Components ............................22 94 4.2 Addressing ..............................................22 95 4.3 Classical Transport Functions ...........................23 96 4.4 Lower Layer Interfaces ..................................25 97 4.5 Upper Layer Services ....................................25 98 4.6 Identity Elements .......................................26 99 4.6.1 Flow Identification ...................................26 100 4.6.2 Session Identification ................................27 101 4.6.3 Signaling Application Identification ..................27 102 4.7 Security Properties .....................................28 103 5 Interactions with Other Protocols .............................28 104 5.1 IP Routing Interactions .................................28 105 5.1.1 Load Sharing and Policy-Based Forwarding ..............29 106 5.1.2 Route Changes .........................................29 107 5.2 Mobility and Multihoming Interactions ...................31 108 5.3 Interactions with NATs ..................................33 109 5.4 Interactions with IP Tunneling ..........................34 110 6 Signaling Applications ........................................35 111 6.1 Signaling for Quality of Service ........................35 112 6.1.1 Protocol Message Semantics ............................36 113 6.1.2 State Management ......................................36 114 6.1.3 Route Changes and QoS Reservations ....................37 115 6.1.4 Resource Management Interactions ......................38 116 6.2 Other Signaling Applications ............................39 117 7 Security Considerations .......................................40 118 Normative References.............................................41 119 Informative References...........................................41 120 Acknowledgments..................................................43 121 Authors' Addresses...............................................44 122 Intellectual Property Considerations.............................44 123 Full Copyright Statement.........................................45 125 1 Introduction 127 1.1 Definition of the Signaling Problem 129 The Next Steps in Signaling (NSIS) working group is considering 130 protocols for signaling information about a data flow along its path 131 in the network. 133 It is assumed that the path taken by the data flow is already 134 determined by network configuration and routing protocols, 135 independent of the signaling itself; that is, signaling to set up the 136 routes themselves is not considered. Instead, the signaling simply 137 interacts with nodes along the data flow path. Additional 138 simplifications are that the actual signaling messages pass directly 139 through these nodes themselves (i.e. the 'path-coupled' case, see 140 section 3.1.2) and that only unicast data flows are considered. 142 The signaling problem in this sense is very similar to that addressed 143 by RSVP. However, there are two generalizations. Firstly, the 144 intention is that components of the NSIS protocol suite will be 145 usable in different parts of the Internet, for different needs, 146 without requiring a complete end-to-end deployment (in particular, 147 the signaling protocol messages may not need to run all the way 148 between the data flow endpoints). 150 Secondly, the signaling is intended for more purposes than just QoS 151 (resource reservation). The basic mechanism to achieve this 152 flexibility is to divide the signaling protocol stack into two 153 layers: a generic (lower) layer, and an upper layer specific to each 154 signaling application. The scope of NSIS work is to define both the 155 generic protocol, and initially upper layers suitable for QoS 156 signaling (similar to the corresponding functionality in RSVP) and 157 middlebox signaling. Further applications may be considered later. 159 1.2 Scope and Structure of the NSIS Framework 161 The underlying requirements for signaling in the context of NSIS are 162 defined in [1] and a separate security threats document [2]; other 163 related requirements can be found in [3] and [4]. This framework does 164 not replace or update these requirements. Discussions about lessons 165 to be learned from existing signaling and resource management 166 protocols are contained in separate analysis documents [5], [6]. 168 The role of this framework is to explain how NSIS signaling should 169 work within the broader networking context, and to describe the 170 overall structure of the protocol suite itself. Therefore, it 171 discusses important protocol considerations, such as routing, 172 mobility, security, and interactions with network 'resource' 173 management (in the broadest sense). 175 The basic context for NSIS protocols is given in section 3. Section 176 3.1 describes the fundamental elements of NSIS protocol operation in 177 comparison to RSVP [7]; in particular, section 3.1.3 describes more 178 general signaling scenarios, and 3.1.4 defines a broader class of 179 signaling applications for which the NSIS protocols should be useful. 180 The two-layer protocol architecture that supports this generality is 181 described in section 3.2, and section 3.3 gives examples of the ways 182 in which particular signaling application properties can be 183 accommodated within signaling layer protocol behavior. 185 The overall functionality required from the lower (generic) protocol 186 layer is described in section 4. This is not intended to define the 187 detailed design of the protocol or even design options, although some 188 are described as examples. It describes the interfaces between this 189 lower layer protocol and the IP layer (below) and signaling 190 application protocols (above), including the identifier elements that 191 appear on these interfaces (section 4.6). Following this, section 5 192 describes how signaling applications that use the NSIS protocols can 193 interact sensibly with network layer operations, specifically routing 194 (and re-routing), IP mobility, and network address translation. 196 Section 6 describes particular signaling applications. The example of 197 signaling for QoS (comparable to core RSVP QoS signaling 198 functionality) is given in detail in section 6.1, which describes 199 both the signaling application specific protocol and example modes of 200 interaction with network resource management and other deployment 201 aspects. However, note that these examples are included only as 202 background and for explanation; it is not intended to define an over- 203 arching architecture for carrying out resource management in the 204 Internet. Further possible signaling applications are outlined in 205 section 6.2. 207 2 Terminology 209 Classifier - an entity which selects packets based on their contents 210 according to defined rules. 212 [Data] flow - a stream of packets from sender to receiver which is a 213 distinguishable subset of a packet stream. Each flow is distinguished 214 by some flow identifier (see section 4.6.1). 216 Edge node - an (NSIS-capable) node on the boundary of some 217 administrative domain. 219 Interior nodes - the set of (NSIS-capable) nodes which form an 220 administrative domain, excluding the edge nodes. 222 NSIS Entity (NE) - the function within a node which implements an 223 NSIS protocol. In the case of path-coupled signaling, the NE will 224 always be on the data path. 226 NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS 227 protocol component that supports a specific signaling application. 228 See also section 3.2.1. 230 NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS 231 protocol component that will support lower layer (signaling 232 application independent) functions. See also section 3.2.1. 234 Path-coupled signaling - a mode of signaling where the signaling 235 messages follow a path that is tied to the data messages. 237 Path-decoupled signaling - signaling for state manipulation related 238 to data flows, but only loosely coupled to the data path, e.g. at the 239 AS level. 241 Peer discovery - the act of locating and/or selecting which NSIS peer 242 to carry out signaling exchanges with for a specific data flow. 244 Peer relationship - signaling relationship between two adjacent NSIS 245 entities (i.e. NEs with no other NEs between them). 247 Receiver - the node in the network which is receiving the data 248 packets in a flow. 250 Sender - the node in the network which is sending the data packets in 251 a flow. 253 Session - application layer flow of information for which some 254 network control state information is to be manipulated or monitored 255 (see section 4.6.2). 257 Signaling application - the purpose of the NSIS signaling: a service 258 could be QoS management, firewall control, and so on. Totally 259 distinct from any specific user application. 261 3 Overview of Signaling Scenarios and Protocol Structure 263 3.1 Fundamental Signaling Concepts 265 3.1.1 Simple Network and Signaling Topology 267 The NSIS suite of protocols is envisioned to support various 268 signaling applications that need to install and/or manipulate state 269 in the network. This state is related to a data flow and is installed 270 and maintained on the NSIS Entities (NEs) along the data flow path 271 through the network; not every node has to contain an NE. The basic 272 protocol concepts do not depend on the signaling application, but the 273 details of operation and the information carried do. This section 274 discusses the basic entities involved with signaling as well as 275 interfaces between them. 277 Two NSIS entities that communicate directly are said to be in a 'peer 278 relationship'. This concept might loosely be described as an 'NSIS 279 hop'; however, there is no implication that it corresponds to a 280 single IP hop. Either or both NEs might store some state information 281 about the other, but there is no assumption that they necessarily 282 establish a long-term signaling connection between themselves. 284 It is common to consider a network as composed of various domains, 285 e.g. for administrative or routing purposes, and the operation of 286 signaling protocols may be influenced by these domain boundaries. 287 However, it seems there is no reason to expect that an 'NSIS domain' 288 should exactly overlap with an IP domain (AS, area) but it is likely 289 that its boundaries would consist of boundaries (segments) of one or 290 several IP domains. 292 Figure 1 shows a diagram of nearly the simplest possible signaling 293 configuration. A single data flow is running from an application in 294 the sender to the receiver via routers R1, R2 and R3. Each host and 295 two of the routers contain NEs which exchange signaling messages - 296 possibly in both directions - about the flow. This scenario is 297 essentially the same as that considered by RSVP for QoS signaling; 298 the main difference is that we make no assumptions here about the 299 particular sequence of signaling messages that will be invoked. 301 Sender Receiver 302 +-----------+ +----+ +----+ +----+ +-----------+ 303 |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application| 304 | +--+ | |+--+| |+--+| +----+ | +--+ | 305 | |NE|====|======||NE||======||NE||==================|===|NE| | 306 | +--+ | |+--+| |+--+| | +--+ | 307 +-----------+ +----+ +----+ +-----------+ 309 +--+ 310 |NE| = NSIS ==== = Signaling ---> = Data flow messages 311 +--+ Entity Messages (unidirectional) 313 Figure 1: Simple Signaling and Data Flows 315 3.1.2 Path-Coupled and Path-Decoupled Signaling 317 We can consider two basic paradigms for resource reservation 318 signaling, which we refer to as "path-coupled" and "path-decoupled". 320 In the path-coupled case, signaling messages are routed only through 321 nodes (NEs) that are in the data path. They do not have to reach all 322 the nodes on the data path (for example, there could be proxies 323 distinct from the sender and receiver as described in section 3.1.3, 324 or intermediate signaling-unaware nodes); and between adjacent NEs, 325 the route taken by signaling and data might diverge. The path-coupled 326 case can be supported by various addressing styles, with messages 327 either explicitly addressed to the neighbor on-path NE, or addressed 328 identically to the data packets but also with the router alert option 329 (see [8] and [9]) and intercepted. These cases are considered in 330 section 4.2. In the second case, some network configurations may 331 split the signaling and data paths (see section 5.1.1); this is 332 considered an error case for path-coupled signaling. 334 In the path-decoupled case, signaling messages are routed to nodes 335 (NEs) which are not assumed to be on the data path, but which are 336 (presumably) aware of it. Signaling messages will always be directly 337 addressed to the neighbor NE, and the signaling endpoints may have no 338 relation at all with the ultimate data sender or receiver. The 339 implications of path-decoupled operation for the NSIS protocols are 340 considered briefly in section 3.2.6; however, the initial goal of 341 NSIS and this framework is to concentrate mainly on the path-coupled 342 case. 344 3.1.3 Signaling to Hosts, Networks and Proxies 346 There are different possible triggers for the signaling protocols. 347 Amongst them are user applications (that are using NSIS signaling 348 services), other signaling applications, network management actions, 349 some network events, and so on. The variety of possible triggers 350 requires that the signaling can be initiated and terminated in the 351 different parts of the network - hosts, domain boundary nodes (edge 352 nodes) or interior domain nodes. 354 The NSIS protocol suite extends the RSVP model to consider this wider 355 variety of possible signaling exchanges. As well as the basic end-to- 356 end model already described, examples such as end-to-edge and edge- 357 to-edge can be considered. The edge-to-edge case might involve the 358 edge nodes communicating directly, as well as via the interior nodes. 360 While the end-to-edge (host-to-network) scenario requires only intra- 361 domain signaling, the other cases might need inter-domain NSIS 362 signaling as well if the signaling endpoints (hosts or network edges) 363 are connected to different domains. Depending on the trust relation 364 between concatenated NSIS domains the edge-to-edge scenario might 365 cover single domain or multiple concatenated NSIS domains. The latter 366 case assumes the existence of trust relations between domains. 368 In some cases it is desired to be able to initiate and/or terminate 369 NSIS signaling not from the end host that sends/receives the data 370 flow, but from the some other entities in the network that can be 371 called signaling proxies. There could be various reasons for this: 372 signaling on behalf of the end hosts that are not NSIS-aware, 373 consolidation of the customer accounting (authentication, 374 authorization) in respect to consumed application and transport 375 resources, security considerations, limitation of the physical 376 connection between host and network and so on. This configuration can 377 be considered as a kind of "proxy on the data path", see Figure 2. 379 Proxy1 Proxy2 380 +------+ +----+ +----+ +----+ +----+ +--------+ 381 |Sender|-...->|Appl|---->| R |-.->| R |--->|Appl|-...->|Receiver| 382 | | |+--+| |+--+| |+--+| +----+ | | 383 +------+ ||NE||=====||NE||=.==||NE||====||NE|| +--------+ 384 |+--+| |+--+| |+--+| |+--+| 385 +----+ +----+ +----+ +----+ 387 +--+ 388 |NE| = NSIS ==== = Signaling ---> = Data flow messages 389 +--+ Entity Messages (unidirectional) 391 Appl = signaling application 393 Figure 2: "On path" NSIS proxy 395 This configuration presents 2 specific challenges for the signaling: 396 *) A proxy that terminates signaling on behalf of the NSIS-unaware 397 host (or part of the network) should be able to make determination 398 that it is a last NSIS aware node along the path. 399 *) Where a proxy initiates NSIS signaling on behalf of the NSIS 400 unaware host, interworking with some other "local" technology might 401 be required, for example to provide QoS reservation from proxy to the 402 end host in the case of QoS signaling application. 404 +------+ +----+ +----+ +----+ +-----------+ 405 |Sender|----->| PA |----->| R2 |----->| R3 | ---->| Receiver | 406 | | |+--+| |+--+| +----+ | +--+ | 407 +------+ ||NE||======||NE||==================|===|NE| | 408 |+--+| |+--+| | +--+ | 409 +-..-+ +----+ +-----------+ 410 .. 411 .. 412 +-..-+ 413 |Appl| 414 +----+ 416 Appl = signaling PA = Proxy for signaling 417 application application 419 Figure 3: "Off path" NSIS proxy 421 Another possible configuration, shown in Figure 3, is where an NE can 422 send and receive signaling information to a remote processor. The 423 NSIS protocols may or may not be suitable for this remote 424 interaction, but in any case it is not currently part of the NSIS 425 problem. This configuration is supported by considering the NE as a 426 proxy at the signaling application level. This is a natural 427 implementation approach for some policy control and centralized 428 control architectures, see also section 6.1.4. 430 3.1.4 Signaling Messages and Network Control State 432 The distinguishing features of the signaling supported by the NSIS 433 protocols are that it is related to specific flows (rather than to 434 network operation in general), and that it involves nodes in the 435 network (rather than running transparently between the end hosts). 437 Therefore, each signaling application (upper layer) protocol must 438 carry per-flow information for the aspects of network-internal 439 operation interesting to that signaling application. An example for 440 the case of an RSVP-like QoS signaling application would be state 441 data representing resource reservations. However, more generally, the 442 per-flow information might be related to some other control function 443 in routers and middleboxes along the path. Indeed, the signaling 444 might simply be used to gather per-flow information, without 445 modifying network operation at all. 447 We call this information generically 'network control state'. 448 Signaling messages may install, modify, refresh, or simply read this 449 state from network elements for particular data flows. Usually a 450 network element will also manage this information at the per-flow 451 level, although coarser-grained ('per-class') state management is 452 also possible. 454 3.1.5 Data Flows and Sessions 456 Formally, a data flow is a (unidirectional) sequence of packets 457 between the same endpoints which all follow a unique path through the 458 network (determined by IP routing and other network configuration). A 459 flow is defined by a packet classifier (in the simplest cases, just 460 the destination address and topological origin are needed). In 461 general we assume that when discussing only the data flow path, we 462 only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple 463 or equivalent). 465 A session is an application layer concept for a (unidirectional) flow 466 of information between two endpoints, for which some network state is 467 to be allocated or monitored. (Note that this use of the term 468 'session' is not identical to the usage in RSVP. It is closer to the 469 session concept of, for example, the Session Initiation Protocol.) 471 The simplest service provided by NSIS signaling protocols is 472 management of network control state at the level of a specific flow, 473 as described in the previous subsection. In particular, it should be 474 possible to monitor routing updates as they change the path taken by 475 a flow and, for example, update network state appropriately. This is 476 no different from the case for RSVP (local path repair). Where there 477 is a 1:1 flow:session relationship, this is all that is required. 479 However, for some more complex scenarios (especially mobility and 480 multihoming related ones, see [1] and the mobility discussion of [5]) 481 it is desirable to update the flow:session mapping during the session 482 lifetime. For example, a new flow can be added, and the old one 483 deleted (and maybe in that order, for a 'make-before-break' 484 handover), effectively transferring the network control state between 485 data flows to keep it associated with the same session. Such updates 486 are best managed by the end systems (generally, systems which 487 understand the flow:session mapping and are aware of the packet 488 classifier change). To enable this, it must be possible to relate 489 signaling messages to sessions as well as data flows. A session 490 identifier (section 4.6.2) is one component of the solution. 492 3.2 Layer Model for the Protocol Suite 494 3.2.1 Layer Model Overview 496 In order to achieve a modular solution for the NSIS requirements, the 497 NSIS protocol suite will be structured in 2 layers: 498 *) a 'signaling transport' layer, responsible for moving signaling 499 messages around, which should be independent of any particular 500 signaling application; and 501 *) a 'signaling application' layer, which contains functionality 502 such as message formats and sequences, specific to a particular 503 signaling application. 505 For the purpose of this document, we use the term 'NSIS Transport 506 Layer Protocol' (NTLP) to refer to the component that will be used in 507 the transport layer. We also use the term 'NSIS Signaling Layer 508 Protocol' (NSLP) to refer generically to any protocol within the 509 signaling application layer; in the end, there will be several NSLPs, 510 largely independent of each other. These relationships are 511 illustrated in Figure 4. Note that the NTLP may or may not have an 512 interesting internal structure (e.g. including existing transport 513 protocols) but that is not relevant at this level of description. 515 ^ +-----------------+ 516 | | NSIS Signaling | 517 | | Layer Protocol | 518 NSIS | +----------------| for middleboxes | 519 Signaling | | NSIS Signaling | +-----------------+ 520 Layer | | Layer Protocol +--------| NSIS Signaling | 521 | | for QoS | | Layer Protocol | 522 | +-----------------+ | for ... | 523 V +-----------------+ 524 ============================================= 525 NSIS ^ +--------------------------------+ 526 Transport | | NSIS Transport Layer Protocol | 527 Layer V +--------------------------------+ 528 ============================================= 529 +--------------------------------+ 530 . IP and lower layers . 531 . . 533 Figure 4: NSIS Protocol Components 535 Note that not every generic function has to be located in the NTLP. 536 Another option would be to have re-usable components within the 537 signaling application layer. Functionality within the NTLP should be 538 restricted to that which interacts strongly with other transport and 539 lower layer operations. 541 3.2.2 Layer Split Concept 543 This section describes the basic concepts underlying the 544 functionality of the NTLP. Firstly, we make a working assumption that 545 the protocol mechanisms of the NTLP operate only between adjacent NEs 546 (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger 547 scope issues (including e2e aspects) are left to the upper layers. 549 The way in which the NTLP works can be described as follows: When a 550 signaling message is ready to be sent from one NE, it is given to the 551 NTLP along with information about what flow it is for; it is then up 552 to the NTLP to get it to the next NE along the path (up- or down- 553 stream), where it is received and the responsibility of the NTLP 554 ends. Note that there is no assumption here about how the messages 555 are actually addressed (this is a protocol design issue, and the 556 options are outlined in section 4.2). The key point is that the NTLP 557 for a given NE does not use any knowledge about addresses, 558 capabilities, or status of any NEs other than its direct peers. 560 The NTLP in the receiving NE either forwards the message directly, 561 or, if there is an appropriate signaling application locally, passes 562 it upwards for further processing; the signaling application can then 563 generate another message to be sent via the NTLP. In this way, larger 564 scope (including end-to-end) message delivery is achieved. 566 This definition relates to NTLP operation. It does not restrict the 567 ability of an NSLP to send messages by other means. For example, an 568 NE in the middle or end of the signaling path could send a message 569 directly to the other end as a notification of or acknowledgement for 570 some signaling application event. However, the issues in sending such 571 messages (endpoint discovery, security, NAT traversal and so on) are 572 so different from the direct peer-peer case that there is no benefit 573 in extending the NTLP to include such non-local functionality; 574 instead, an NSLP which requires such messages and wants to avoid 575 traversing the path of NEs should use some other existing transport 576 protocol - for example, UDP or DCCP would be a good match for many of 577 the scenarios that have been proposed. Acknowledgements and 578 notifications of this type are considered further in section 3.3.6. 580 One motivation for restricting the NTLP to only peer-relationship 581 scope is that if there are any options or variants in design approach 582 - or, worse, in basic functionality - it is easier to manage the 583 resulting complexity if it only impacts direct peers rather than 584 potentially the whole Internet. 586 3.2.3 Bypassing Intermediate Nodes 588 Because the NSIS problem includes multiple signaling applications, it 589 is very likely that a particular NSLP will only be implemented on a 590 subset of the NSIS-aware nodes on a path, as shown in Figure 5. In 591 addition, a node inside an aggregation region will still wish to 592 ignore signaling messages which are per-flow, even if they are for a 593 signaling application which the node is able to process in general. 595 +------+ +------+ +------+ +------+ 596 | NE | | NE | | NE | | NE | 597 |+----+| | | |+----+| |+----+| 598 ||NSLP|| | | ||NSLP|| ||NSLP|| 599 || 1 || | | || 2 || || 1 || 600 |+----+| | | |+----+| |+----+| 601 | || | | | | | | || | 602 |+----+| |+----+| |+----+| |+----+| 603 ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== 604 |+----+| |+----+| |+----+| |+----+| 605 +------+ +------+ +------+ +------+ 607 Figure 5: Signaling with Heterogeneous NSLPs 609 Where signaling messages traverse such NSIS-aware intermediate nodes, 610 it is desirable to process them at the lowest level possible (in 611 particular, on the fastest path). In order to offer a non-trivial 612 message transfer service (in terms of security, reliability and so 613 on) to the peer NSLP nodes, it is important that NTLP at intermediate 614 nodes is as transparent as possible, that is, it carries out minimal 615 processing. In addition, if intermediate nodes have to do slow-path 616 processing of all NSIS messages, this eliminates many of the scaling 617 benefits of aggregation, unless tunneling is used. 619 Considering first the case of messages sent with the router alert 620 option, there are two complementary methods to achieve this bypassing 621 of intermediate NEs: 623 *) At the IP layer, a set of protocol numbers can be used, or a range 624 of values in the router alert option. In this way, messages can be 625 marked with an implied granularity, and routers can choose to apply 626 further slow-path processing only to configured subsets of messages. 627 This is the method used in [10] to distinguish per-flow and per- 628 aggregate signaling. 630 *) The NTLP could process the message but determine that there was no 631 local signaling application it was relevant to. At this stage, the 632 message can be returned unchanged to the IP layer for normal 633 forwarding; the intermediate NE has effectively chosen to be 634 transparent to the message in question. 636 In both cases, the existence of the intermediate NE is totally hidden 637 from the NSLP nodes. If later stages of the signaling use directly 638 addressed messages (e.g. for reverse routing), they will not involved 639 the intermediate NE at all, except perhaps as a normal router. 641 There may be cases where the intermediate NE would like to do some 642 restricted protocol processing, for example: 643 *) Translating addresses in message payloads (compare section 4.6.1); 644 note this would have to be done to messages passing both directions 645 through a node. 646 *) Updating signaling application payloads with local status 647 information (e.g. path property measurement inside a domain). 648 If this can be done without fully terminating the NSIS protocols, 649 this would allow a more lightweight implementation of the 650 intermediate NE, and a more direct 'end-to-end' NTLP association 651 between the peer NSLPs where the signaling application is fully 652 processed. On the other hand, this is only possible with a limited 653 class of possible NTLP designs, and makes it harder for the NTLP to 654 offer a security service (since messages have to be partially 655 protected). The feasibility of this approach will be evaluated during 656 the NTLP design. 658 3.2.4 Core NTLP Functionality 660 This section describes the basic functionality to be supported by the 661 NTLP. Note that the overall signaling solution will always be the 662 result of joint NSLP and NTLP operation; for example, we can always 663 assume that an NSLP is operating above the NTLP and taking care of 664 end-to-end issues (e.g. recovery of messages after restarts). 666 Therefore, NTLP functionality is essentially just efficient upstream 667 and downstream peer-peer message delivery, in a wide variety of 668 network scenarios. Message delivery includes the act of locating 669 and/or selecting which NTLP peer to carry out signaling exchanges 670 with for a specific data flow. This discovery might be an active 671 process (using specific signaling packets) or a passive process (a 672 side effect of using a particular addressing mode). In addition, it 673 appears that the NTLP can sensibly carry out many of the functions of 674 enabling signaling messages to pass through middleboxes, since this 675 is closely related to the problem of routing the signaling messages 676 in the first place. Further details about NTLP functionality are 677 contained in sections 3.2.5 and 4.3. 679 3.2.5 State Management Functionality 681 Internet signaling requires the existence and management of state 682 within the network for several reasons. This section describes how 683 state management functionality is split across the NSIS layers. (Note 684 that how the NTLP internal state is managed is a matter for its 685 design and indeed implementation.) 687 1. Conceptually, the NTLP provides a uniform message delivery 688 service. It is unaware of the difference in state semantics between 689 different types of signaling application message (e.g. whether a 690 message changes or just refreshes signaling application state, or 691 even has nothing to with signaling application state at all). 693 2. An NTLP instance processes and if necessary forwards all signaling 694 application messages "immediately". (It might offer different service 695 classes, but these would be distinguished e.g. by reliability or 696 priority, not state aspects.) This means that the NTLP does not know 697 explicit timer or message sequence information for the signaling 698 application; and that signaling application messages pass immediately 699 through an NSLP-unaware node (their timing cannot be jittered there, 700 nor can messages be stored up to be re-sent on a new paths in case of 701 a later re-routing event). 703 3. Within any node, it is an implementation decision whether to 704 generate/jitter/filter refreshes either separately within each 705 signaling application that needs this functionality, or to integrate 706 it with the NTLP implementation as a generic "soft-state management 707 toolbox"; the choice doesn't affect the NTLP specification at all. 708 Implementations might piggy-back NTLP soft-state refresh information 709 (if the NTLP works this way) on signaling application messages, or 710 even combine soft-state management between layers. The state machines 711 of the NTLP and NSLPs remain logically independent, but an 712 implementation is free to allow them to interact to reduce the load 713 on the network to the same level as would be achieved by a monolithic 714 model. 716 4. It may be helpful for signaling applications to receive state- 717 management related 'triggers' from the NTLP, that a peer has failed 718 or become available ("down/up notifications"). These triggers would 719 be about adjacent NTLP peers, rather than signaling application 720 peers. We can consider this as another case of route change 721 detection/notification (which the NTLP is also allowed to do anyway). 722 However, apart from generating such triggers, the NTLP takes no 723 action itself on such events, other than to ensure that subsequent 724 signaling messages are correctly routed. 726 5. The existence of these triggers doesn't replace NSLP refreshes as 727 the mechanism for maintaining liveness at the signaling application 728 level. In this sense, up/down notifications are advisories which 729 allow faster reaction to events in the network, but shouldn't be 730 built into NSLP semantics. (This is essentially the same distinction 731 - with the same rationale - as SNMP makes between traps and normal 732 message exchanges.) 734 3.2.6 Path De-Coupled Operation 736 Path-decoupled signaling is defined as signaling for state 737 installation along the data path, without the restriction of passing 738 only through nodes that are located on the data path. Signaling 739 messages can be routed to nodes off the data path, but which are 740 (presumably) aware of it. This allows a looser coupling between 741 signaling and data plane nodes, e.g. at the autonomous system level. 743 The main advantages of path-decoupled signaling are ease of 744 deployment and support of additional functionality. The ease of 745 deployment comes from a restriction of the number of impacted nodes 746 in case of deployment and/or upgrade of an NSLP. It would allow, for 747 instance, deploying a solution without upgrading any of the routers 748 in the data plane. Additional functionality that can be supported 749 includes the use of off-path proxies to support authorization or 750 accounting architectures. 752 There are potentially significant differences in the way that the two 753 signaling paradigms should be analyzed. Using a single centralized 754 off-path NE may increase the requirements in terms of message 755 handling; on the other hand, path-decoupled signaling is equally 756 applicable to distributed off-path entities. Failure recovery 757 scenarios need to be analyzed differently because fate-sharing 758 between data and control plane can no longer be assumed. Furthermore, 759 the interpretation of sender/receiver orientation becomes less 760 natural. With the local operation of NTLP, the impact of path- 761 decoupled signaling on the routing of signaling messages is 762 presumably restricted to the problem of peer determination. The 763 assumption that the off-path NSIS nodes are loosely tied to the data 764 path suggests, however, that peer determination can still be based on 765 L3 routing information. This means that a path-decoupled signaling 766 solution could be implemented using a lower layer protocol presenting 767 the same service interface to NSLPs as the path-coupled NTLP. A new 768 message transport protocol (possibly derived from the path-coupled 769 NTLP) would be needed, but NSLP specifications and the inter-layer 770 interaction would be unchanged from the path-coupled case. 772 3.3 Signaling Application Properties 774 It is clear that many signaling applications will require specific 775 protocol behavior in their NSLP. This section outlines some of the 776 options for NSLP behavior; further work on selecting from these 777 options would depend on detailed analysis of the signaling 778 application in question. 780 3.3.1 Sender/Receiver Orientation 782 In some signaling applications, a node at one end of the data flow 783 takes responsibility for requesting special treatment - such as a 784 resource reservation - from the network. Which end may depend on the 785 signaling application, or characteristics of the network deployment. 787 A sender-initiated approach is when the sender of the data flow 788 requests and maintains the treatment for that flow. In a receiver- 789 initiated approach the receiver of the data flow requests and 790 maintains the treatment for that flow. The NTLP itself has no freedom 791 in this area: next NTLP peers have to be discovered in the sender to 792 receiver direction, but after that time the default assumption is 793 that signaling is possible both upstream and downstream (unless 794 possibly a signaling application specifically indicates this is not 795 required). This implies that backward routing state must be 796 maintained by the NTLP or that backward routing information must be 797 available in the signaling message. 799 The sender and receiver initiated approaches have several differences 800 in their operational characteristics. The main ones are as follows: 802 *) In a receiver-initiated approach, the signaling messages traveling 803 from the receiver to the sender must be backward routed such that 804 they follow exactly the same path as was followed by the signaling 805 messages belonging to the same flow traveling from the sender to the 806 receiver. In a sender-initiated approach, provided acknowledgements 807 and notifications can be securely delivered to the sending node, 808 backward routing is not necessary, and nodes do not have to maintain 809 backward routing state. 810 *) In a sender-initiated approach, a mobile node can initiate a 811 reservation for its outgoing flows as soon as it has moved to another 812 roaming subnetwork. In a receiver-initiated approach, a mobile node 813 has to inform the receiver about its handover, thus allowing the 814 receiver to initiate a reservation for these flows. For incoming 815 flows, the reverse argument applies. 816 *) In general, setup and modification will be fastest if the node 817 responsible for authorizing these actions can initiate them directly 818 within the NSLP. A mismatch between authorizing and initiating NEs 819 will cause additional message exchanges either in the NSLP or in a 820 protocol executed prior to NSIS invocation. Depending on how the 821 authorization for a particular signaling application is done, this 822 may favor either sender or receiver initiated signaling. Note that 823 this may complicate modifications of network control state for 824 existing flows. 825 *) Where the signaling is looking for the last (nearest to receiver) 826 NE on the data path, receiver oriented signaling is most efficient; 827 sender orientation would be possible, but take more messages. 828 *) In either case, the initiator can generally be informed faster 829 about reservation failures than the remote end. 831 3.3.2 Uni- and Bi-Directional Operation 833 For some signaling applications and scenarios, signaling may only be 834 considered for a unidirectional data flow. However, in other cases, 835 there may be interesting relationships between the signaling for the 836 two flows of a bi-directional session; an example is QoS for a voice 837 call. Note that the path in the two directions may differ due to 838 asymmetric routing. In the basic case, bi-directional signaling can 839 simply use a separate instance of the same signaling mechanism in 840 each direction. 842 In constrained topologies where parts of the route are symmetric, it 843 may be possible to use a more unified approach to bi-directional 844 signaling, e.g. carrying the two signaling directions in common 845 messages. This optimization might be used for example to make mobile 846 QoS signaling more efficient. 848 In either case, the correlation of the signaling for the two flow 849 directions is carried out in the NSLP. The NTLP would simply be 850 enabled to bundle the messages together. 852 3.3.3 Heterogeneous Operation 854 It is likely that the appropriate way to describe the state NSIS is 855 signaling for will vary from one part of the network to another 856 (depending on signaling application). For example in the QoS case, 857 resource descriptions that are valid for inter-domain links will 858 probably be different from those useful for intra-domain operation 859 (and the latter will differ from one domain to another). 861 One way to address this issue is to consider the state description 862 used within the NSLP as carried in globally-understood objects and 863 locally-understood objects. The local objects are only applicable for 864 intra-domain signaling, while the global objects are mainly used in 865 inter-domain signaling. Note that the local objects are still part of 866 the protocol but are inserted, used and removed by one single domain. 868 The purpose of this division is to provide additional flexibility in 869 defining the objects carried by the NSLP such that only the objects 870 applicable in a particular setting are used. One approach for 871 reflecting the distinction is that local objects could be put into 872 separate local messages that are initiated and terminated within one 873 single domain; an alternative is that they could be "stacked" within 874 the NSLP messages that are used anyway for inter-domain signaling. 876 3.3.4 Aggregation 878 It is a well known problem that per-flow signaling in large-scale 879 networks present scaling challenges because of the large number of 880 flows that may traverse individual nodes. 882 The possibilities for aggregation at the level of the NTLP are quite 883 limited; the primary scaling approach for path-coupled signaling is 884 for a signaling application to group flows together and perform 885 signaling for the aggregate, rather than for the flows individually. 886 The aggregate may be created in a number of ways: for example, the 887 individual flows may be sent down a tunnel, or given a common DSCP 888 marking. The aggregation and deaggregation points perform per flow 889 signaling, but nodes within the aggregation region should only be 890 forced to process signaling messages for the aggregate, somehow 891 ignoring the per-flow signaling (see section 3.2.3). 893 Individual NSLPs will need to specify what aggregation means in their 894 context, and how it should be performed. For example, in the QoS 895 context it is possible to add together the resources specified in a 896 number of separate reservations. In the case of other applications, 897 such as signaling to NATs and firewalls, the feasibility (and even 898 the meaning) of aggregation is less clear. 900 3.3.5 Peer-Peer and End-End Relationships 902 The assumption in this framework is that the NTLP will operate 903 'locally', that is, just over the scope of a single peer 904 relationship. End-to-end operation is built up by concatenating these 905 relationships. Non-local operation (if any) will take place in NSLPs. 907 The peering relations may also have an impact on the required amount 908 of state at each NSIS entity. When direct interaction with remote 909 peers is not allowed, it may be required to keep track of the path 910 that a message has followed through the network. This can be achieved 911 by keeping per-flow state at the NSIS entities or by maintaining a 912 record route object in the messages. 914 3.3.6 Acknowledgements and Notifications 916 We are assuming that the NTLP provides a simple message transfer 917 service, and any acknowledgements or notifications it generates are 918 handled purely internally (and apply within the scope of a single 919 NTLP peer relationship). 921 However, we expect that some signaling applications will require 922 acknowledgements regarding the failure/success of state installation 923 along the data path, and this will be an NSLP function. 925 Acknowledgements can be sent along the sequence of NTLP peer 926 relationships towards the signaling initiator, which relieves the 927 requirements on the security associations that need to be maintained 928 by NEs and can allow NAT traversal in both directions. (If this 929 direction is towards the sender, it implies maintaining reverse 930 routing state in the NTLP). In certain circumstances (e.g. trusted 931 domains), an optimization can be to send acknowledgements directly to 932 the signaling initiator outside the NTLP (see section 3.2.2). 934 The semantics of the acknowledgement messages are of particular 935 importance. An NE sending a message could assume responsibility for 936 the entire downstream chain of NEs, indicating for instance the 937 availability of reserved resources for the entire downstream path. 938 Alternatively, the message could have a more local meaning, 939 indicating for instance that a certain failure or degradation 940 occurred at a particular point in the network. 942 Notifications differ from acknowledgements because they are not 943 (necessarily) generated in response to other signaling messages. This 944 means that it may not be obvious to determine where the notification 945 should be sent. Other than that, the same considerations apply as for 946 acknowledgements. One useful distinction to make would be to 947 differentiate between notifications that trigger a signaling action 948 and others that don't. The security requirements for the latter are 949 less stringent, which means they could be sent directly to the NE 950 they are destined for (provided this NE can be determined). 952 3.3.7 Security and Other AAA Issues 954 In some cases it will be possible to achieve the necessary level of 955 signaling security by using basic 'channel security' mechanisms [11] 956 at the level of the NTLP, and the possibilities are described in 957 section 4.7. In other cases, signaling applications may have specific 958 security requirements, in which case they are free to invoke their 959 own authentication and key exchange mechanisms and apply 'object 960 security' to specific fields within the NSLP messages. 962 In addition to authentication, the authorisation (to manipulate 963 network control state) has to be considered as functionality above 964 the NTLP level, since it will be entirely application specific. 965 Indeed, authorisation decisions may be handed off to a third party in 966 the protocol (e.g. for QoS, the resource management function as 967 described in section 6.1.4). Many different authorisation models are 968 possible, and the variations impact: 969 *) what message flows take place - for example, whether authorisation 970 information is carried along with a control state modification 971 request, or is sent in the reverse direction in response to it; 972 *) what administrative relationships are required - for example, 973 whether authorisation takes place only between peer signaling 974 applications, or over longer distances. 976 Because the NTLP operates only between adjacent peers, and places no 977 constraints on the direction or order in which signaling applications 978 can send messages, these authorisation aspects are left open to be 979 defined by each NSLP. Further background discussion of this issue is 980 contained in [12]. 982 4 The NSIS Transport Layer Protocol 984 This section describes the overall functionality required from the 985 NTLP. It mentions possible protocol components within the NTLP layer 986 and the different possible addressing modes that can be utilized, as 987 well as the assumed transport and state management functionality. The 988 interfaces between NTLP and the layers above and below it are 989 identified, with a description of the identity elements that appear 990 on these interfaces. 992 It is not the intention of this discussion to design the NTLP or even 993 to enumerate design options, although some are included as examples. 994 The goal is to provide a general discussion of required functionality 995 and to highlight some of the issues associated with this. 997 4.1 Internal Protocol Components 999 The NTLP includes all functionality below the signaling application 1000 layer and above the IP layer. The functionality that is required 1001 within the NTLP is outlined in section 3.2.4, with some more details 1002 in sections 3.2.5 and 4.3. 1004 Some NTLP functionality could be provided via components operating as 1005 sublayers within the NTLP design. For example, if specific transport 1006 capabilities are required, such as congestion avoidance, 1007 retransmission, security and so on, then existing protocols, such as 1008 TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP. This 1009 possibility is not required or excluded by this framework. 1011 If peer-peer addressing (section 4.2) is used for some messages, then 1012 active next-peer discovery functionality will be required within the 1013 NTLP to support the explicit addressing of these messages. This could 1014 use message exchanges for dynamic peer discovery as a sublayer within 1015 the NTLP; there could also be an interface to external mechanisms to 1016 carry out this function. 1018 ==================== =========================== 1019 ^ +------------------+ +-------------------------+ 1020 | | | | NSIS Specific Functions | 1021 | | | | .............| 1022 NSIS | | Monolithic | |+----------+. Peer .| 1023 Transport | | Protocol | || Existing |. Discovery .| 1024 Layer | | | || Protocol |. Aspects .| 1025 | | | |+----------+.............| 1026 V +------------------+ +-------------------------+ 1027 ==================== =========================== 1029 Figure 6: Options for NTLP Structure 1031 4.2 Addressing 1033 There are two ways to address a signaling message being transmitted 1034 between NTLP peers: 1035 *) peer-peer, where the message is addressed to a neighboring NSIS 1036 entity that is known to be closer to the destination NE. 1037 *) end-to-end, where the message is addressed to the flow 1038 destination directly, and intercepted by an intervening NE. 1040 With peer-peer addressing, an NE will determine the address of the 1041 next NE based on the payload of the message (and potentially on the 1042 previous NE). This requires the address of the destination NE to be 1043 derivable from the information present in the payload, either by 1044 using some local routing table or through participation in active 1045 peer discovery message exchanges. Peer-peer addressing inherently 1046 supports tunneling of messages between NEs, and is equally applicable 1047 to the path-coupled and path-decoupled cases. 1049 In the case of end-to-end addressing, the message is addressed to the 1050 data flow receiver, and (some of) the NEs along the data path 1051 intercept the messages. The routing of the messages should follow 1052 exactly the same path as the associated data flow (but see section 1053 5.1.1 on this point). Note that securing messages sent this way 1054 raises some interesting security issues (these are discussed in [2]). 1056 It is not possible at this stage to mandate one addressing mode or 1057 the other. Indeed, each is necessary for some aspects of NTLP 1058 operation: in particular, initial discovery of the next downstream 1059 peer will usually require end-to-end addressing, whereas reverse 1060 routing will always require peer-peer addressing. For other message 1061 types, the choice is a matter of protocol design. The mode used is 1062 not visible to the NSLP, and the information needed in each case is 1063 available from the flow identifier (section 4.6.1) or locally stored 1064 NTLP state. 1066 4.3 Classical Transport Functions 1068 The NSIS signaling protocols are responsible for transporting 1069 (signaling) data around the network; in general, this requires 1070 functionality such as congestion management, reliability, and so on. 1071 This section discusses how much of this functionality should be 1072 provided within the NTLP. It appears that this doesn't affect the 1073 basic way in which the NSLP/NTLP layers relate to each other (e.g. in 1074 terms of the semantics of the inter-layer interaction); it is much 1075 more a question of the overall performance/complexity tradeoff 1076 implied by placing certain functions within each layer. 1078 Note that, following the discussion at the end of section 3.2.3, 1079 there may be cases where intermediate nodes wish to modify messages 1080 in transit even though they do not perform full signaling application 1081 processing. In this case, not all of the following functionality 1082 would be invoked at every intermediate node. 1084 The following functionality is assumed to lie within the NTLP: 1085 1. Bundling together of small messages (comparable to [13]) can be 1086 provided locally by the NTLP as an option if desired; it doesn't 1087 affect the operation of the network elsewhere. The NTLP should 1088 always support unbundling, to avoid the cost of negotiating the 1089 feature as an option. (The related function of refresh 1090 summarization - where objects in a refresh message are replaced 1091 with a reference to a previous message identifier - is left to 1092 NSLPs which can then do this in a way tuned to the state 1093 management requirements of the signaling application. Additional 1094 transparent compression functionality could be added to the NTLP 1095 design later as a local option.) Note that end-to-end addressed 1096 messages for different flows cannot be bundled safely unless the 1097 next node on the outgoing interface is known to be NSIS-aware. 1098 2. Message fragmentation should be provided by the NTLP when needed. 1099 For NSLPs that generate large messages, it will be necessary to 1100 fragment them efficiently within the network, where the use of IP 1101 fragmentation may lead to reduced reliability and be incompatible 1102 with some addressing schemes. To avoid imposing the cost of 1103 reassembly on intermediate nodes, the fragmentation scheme used 1104 should allow for the independent forwarding of individual 1105 fragments towards a node hosting an interested NSLP. 1106 3. There can be significant benefits for signaling applications if 1107 state-changing messages are delivered reliably (as introduced in 1108 [13] for RSVP; see also the more general analysis of [14]). This 1109 does not change any assumption about the use of soft-state by 1110 NSLPs to manage signaling application state, and leaves the 1111 responsibility for detecting and recovering from application 1112 layer error conditions in the NSLP. However, it means that such 1113 functionality does not need to be tuned to handle fast recovery 1114 from message loss due to congestion or corruption in the lower 1115 layers, and also means that the NTLP can prevent the 1116 amplification of message loss rates caused by fragmentation. 1117 Reliable delivery functionality is invoked by the NSLP on a 1118 message-by-message basis and is always optional to use. 1119 4. The NTLP should not allow signaling messages to cause congestion 1120 in the network (i.e. at the IP layer). Congestion could be caused 1121 by retransmission of lost signaling packets or by upper layer 1122 actions (e.g. a flood of signaling updates to recover from a 1123 route change). In some cases it may be possible to engineer the 1124 network to ensure that signaling cannot overload it; in other 1125 cases, the NTLP would have to detect congestion and adapt the 1126 rate at which it allows signaling messages to be transmitted. 1127 Principles of congestion control in Internet protocols are given 1128 in [15]. The NTLP may or may not be able to detect overload in 1129 the control plane itself (e.g. an NSLP-aware node several NTLP- 1130 hops away which cannot keep up with the incoming message rate) 1131 and indicate this as a flow-control condition to local signaling 1132 applications. However, for both the congestion and overload 1133 cases, it is up to the signaling applications themselves to adapt 1134 their behavior accordingly. 1136 4.4 Lower Layer Interfaces 1138 The NTLP interacts with 'lower layers' of the protocol stack for the 1139 purposes of sending and receiving signaling messages. This framework 1140 places the lower boundary of the NTLP at the IP layer. The interface 1141 to the lower layer is therefore very simple: 1142 *) The NTLP sends raw IP packets 1143 *) The NTLP receives raw IP packets. In the case of peer-peer 1144 addressing, they have been addressed directly to it. In the case of 1145 end-to-end addressing, this will be achieved by intercepting packets 1146 that have been marked in some special way (by special protocol number 1147 or by some option interpreted within the IP layer, such as the router 1148 alert option). 1149 *) The NTLP receives indications from the IP layer regarding route 1150 changes and similar events (see section 5.1). 1152 For correct message routing, the NTLP needs to have some information 1153 about link and IP layer configuration of the local networking stack. 1154 In general, it needs to know how to select the outgoing interface for 1155 a signaling message, where this must match the interface that will be 1156 used by the corresponding flow. This might be as simple as just 1157 allowing the IP layer to handle the message using its own routing 1158 table. There is no intention to do something different from IP 1159 routing (for end-to-end addressed messages); however, some hosts 1160 allow applications to bypass routing for their data flows, and the 1161 NTLP processing must account for this. Further network layer 1162 information would be needed to handled scoped addresses (if such 1163 things ever will exist). 1165 Configuration of lower layer operation to handle flows in particular 1166 ways is handled by the signaling application. 1168 4.5 Upper Layer Services 1170 The NTLP offers transport layer services to higher layer signaling 1171 applications for two purposes: sending and receiving signaling 1172 messages, and exchanging control and feedback information. 1174 For sending and receiving messages, two basic control primitives are 1175 required: 1176 *) Send Message, to allow the signaling application to pass data to 1177 the NTLP for transport. 1178 *) Receive Message, to allow the NTLP to pass received data to the 1179 signaling application. 1181 The NTLP and signaling application may also want to exchange other 1182 control information, such as: 1184 *) Signaling application registration/de-registration, so that 1185 particular signaling application instances can register their 1186 presence with the transport layer. This may also require some 1187 identifier to be agreed between the NTLP and signaling application to 1188 allow support the exchange of further control information and to 1189 allow the de-multiplexing of incoming data. 1190 *) NTLP configuration, allowing signaling applications to indicate 1191 what optional NTLP features they want to use, and to configure NTLP 1192 operation, such as controlling what transport layer state should be 1193 maintained. 1194 *) Error messages, to allow the NTLP to indicate error conditions to 1195 the signaling application and vice versa. 1196 *) Feedback information, such as route change indications so that the 1197 signaling application can decide what action to take. 1199 4.6 Identity Elements 1201 4.6.1 Flow Identification 1203 The flow identification is a method of identifying a flow in a unique 1204 way. All packets associated with the same flow will be identified by 1205 the same flow identifier. The key aspect of the flow identifier is 1206 to provide enough information such that the signaling flow receives 1207 the same treatment along the data path as that actual data itself, 1208 i.e. consistent behavior is applied to the signaling and data flows 1209 by a NAT or policy-based forwarding engine. 1211 Information that could be used in flow identification may include: 1212 *) source IP address; 1213 *) destination IP address; 1214 *) protocol identifier and higher layer (port) addressing; 1215 *) flow label (typical for IPv6); 1216 *) SPI field for IPsec encapsulated data; 1217 *) DSCP/TOS field 1218 It is assumed that wildcarding on these identifiers is not needed 1219 (further analysis may be required). 1221 We've assumed here that the flow identification is not hidden within 1222 the NSLP, but is explicitly part of the NTLP. The justification for 1223 this is that it might be valuable to be able to do NSIS processing 1224 even at a node which was unaware of the specific signaling 1225 application (see section 3.2.3): an example scenario would be 1226 messages passing through an addressing boundary where the flow 1227 identification had to be re-written. 1229 4.6.2 Session Identification 1231 There are circumstances where it is important to be able to refer to 1232 signaling application state independently of the underlying flow. 1233 For example, if the address of one of the flow endpoints changes due 1234 to a mobility event, it is desirable to be able to change the flow 1235 identifier without having to install a completely new reservation. 1236 The session identifier provides a method to correlate the signaling 1237 about the different flows with the same network control state. 1239 The session identifier is essentially a signaling application 1240 concept, since it is only used in non-trivial state management 1241 actions that are application specific. However, we assume here that 1242 it should be visible within the NTLP. This enables it to be used to 1243 control NTLP behavior, for example, by controlling how the transport 1244 layer should forward packets belonging to this session (as opposed to 1245 this signaling application). In addition, the session identifier can 1246 be used by the NTLP to demultiplex received signaling messages 1247 between multiple instances of the same signaling application, if such 1248 an operational scenario is supported (see section 4.6.3 for more 1249 information on signaling application identification). 1251 To be useful for mobility support, the session identifier should be 1252 globally unique, and it should not be modified end-to-end. It is well 1253 known that it is practically impossible to generate identifiers in a 1254 way which guarantees this property; however, using a large random 1255 number makes it highly likely. In any case, the NTLP ascribes no 1256 valuable semantics to the identifier (such as 'session ownership'); 1257 this problem is left to the signaling application, which may be able 1258 to secure it to use for this purpose. 1260 4.6.3 Signaling Application Identification 1262 Since the NTLP can be used to support several NSLP types, there is a 1263 need to identify which type a particular signaling message exchange 1264 is being used for. This is to support: 1265 *) processing of incoming messages - the NTLP should be able to 1266 demultiplex these towards the appropriate signaling applications; 1267 *) processing of general messages at an NSIS aware intermediate node 1268 - if the node does not handle the specific signaling application, it 1269 should be able to make a forwarding decision without having to parse 1270 upper layer information. 1272 No position is taken on the form of the signaling application 1273 identifier, or even the structure of the signaling application 1274 'space' - free-standing applications, potentially overlapping groups 1275 of capabilities, etc. These details should not influence the rest of 1276 NTLP design. 1278 4.7 Security Properties 1280 It is assumed that the only security service required within NTLP is 1281 channel security. Channel security requires a security association to 1282 be established between the signaling endpoints, which is carried out 1283 via some authentication and key management exchange. This 1284 functionality could be provided by reusing a standard protocol. 1286 In order to protect a particular signaling exchange, the NSIS entity 1287 needs to select the security association that it has in place with 1288 the next NSIS entity that will be receiving the signaling message. 1289 The ease of doing this depends on the addressing model in use by the 1290 NTLP (see section 4.2). 1292 Channel security can provide many different types of protection to 1293 signaling exchanges, including integrity and replay protection and 1294 encryption. It is not clear which of these is required at the NTLP 1295 layer, although most channel security mechanisms support them all. 1297 Channel security can also be applied to the signaling messages with 1298 differing granularity, i.e. all or parts of the signaling message may 1299 be protected. For example, if the flow is traversing a NAT, only the 1300 parts of the message that do not need to be processed by the NAT 1301 should be protected (alternatively, if the NAT takes part in NTLP 1302 security procedures, it only needs to be given access to the message 1303 fields containing addresses, often just the flow id). It is an open 1304 question as to which parts of the NTLP messages need protecting, and 1305 what type of protection should be applied to each. 1307 5 Interactions with Other Protocols 1309 5.1 IP Routing Interactions 1311 The NTLP is responsible for determining the next node to be visited 1312 by the signaling protocol. For path-coupled signaling, this next node 1313 should be one that will be visited by the data flow. In practice, 1314 this peer discovery will be approximate, as any node could use any 1315 feature of the peer discovery packet to route it differently from the 1316 corresponding data flow packets. Divergence between data and 1317 signaling path can occur due to load sharing or load balancing 1318 (section 5.1.1). An example specific to the case of QoS is given in 1319 section 6.1.1. Route changes cause a temporary divergence between the 1320 data path and the path on which signaling state has been installed. 1321 The occurrence, detection and impact of route changes is described in 1322 section 5.1.2. A description of this issue in the context of QoS is 1323 given in section 6.1.2. 1325 5.1.1 Load Sharing and Policy-Based Forwarding 1327 Load sharing or load balancing is a network optimization technique 1328 that exploits the existence of multiple paths to the same destination 1329 in order to obtain benefits in terms of protection, resource 1330 efficiency or network stability. The significance of load sharing in 1331 the context of NSIS is that, if the load sharing mechanism in use 1332 will forward packets on any basis other than the destination address, 1333 routing of signaling messages using end-to-end addressing does not 1334 guarantee that the messages will follow the data path. Policy-based 1335 forwarding for data packets - where the outgoing link is selected 1336 based on policy information about fields additional to the packet 1337 destination address - has the same impact. Signaling and data packets 1338 may diverge because of both of these techniques. 1340 Load balancing techniques have been proposed for a number of routing 1341 protocols, such as OSPF equal cost paths [16] and others. Typically, 1342 based on the load reported from a particular path, load balancing 1343 determines which fraction of the data to direct to that path. 1344 Incoming packets are subject to a (source, destination address) hash 1345 computation, and effective load sharing is accomplished by means of 1346 adjusting the hash thresholds. 1348 If signaling packets are given source and destination addresses 1349 identical to data packets, signaling and data packets may still 1350 diverge because of layer 4 load-balancing (based on protocol or port 1351 number). Such techniques would also cause ICMP errors to be 1352 misdirected to the source of the data because of the source address 1353 spoofing. If signaling packets are made identical in the complete 1354 five-tuple, divergence may still occur because of the presence of 1355 router alert options. In this case, the same ICMP misdirection 1356 applies. Additionally, it becomes difficult for the end systems to 1357 distinguish between data and signaling packets. Finally, QoS routing 1358 techniques may base the routing decision on any field in the packet 1359 header (e.g. DSCP, ...). 1361 Many load-balancing implementations use the first n bytes of the 1362 packet header (including SA, DA and protocol) in the hash function. 1363 In this case, the general considerations above regarding SA/DA or 1364 five-tuple based forwarding continue to apply. 1366 5.1.2 Route Changes 1368 In a connectionless network, each packet is independently routed 1369 based on its header information. Whenever a better route towards the 1370 destination becomes available, this route is installed in the 1371 forwarding table and will be used for all subsequent (data and 1372 signaling) packets. This can cause a divergence between the path 1373 along which state has been installed and the path along which 1374 forwarding will actually take place. (The problem of route changes is 1375 reduced if route pinning is performed. Route pinning refers to the 1376 independence of the path taken by certain data packets from 1377 reachability changes caused by routing updates from an Interior 1378 Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP). 1379 Nothing about NSIS signaling prevents route pinning being used as a 1380 network engineering technique, provided it is done in a way which 1381 preserves the common routing of signaling and data. However, even if 1382 route pinning is used, it cannot be depended on to prevent all route 1383 changes (for example in the case of link failures). 1385 Handling route changes requires the presence of three processes in 1386 the signaling protocol: 1387 1. route change detection 1388 2. installation of state on the new path 1389 3. removal of state on the old path 1391 Many route change detection methods can be used, some needing 1392 explicit protocol support and some of which are implementation- 1393 internal. They differ in their speed of reaction and the types of 1394 change they can detect. In rough order of increasing applicability, 1395 they can be summarized as: 1396 a) monitoring changes in local interface state 1397 b) monitoring topology changes in a link-state routing protocol 1398 c) inference from changes in data packet TTL 1399 d) inference from loss of packet stream in a flow-aware router 1400 e) inference from changes in signaling packet TTL 1401 f) changed route of an end-to-end addressed signaling packet 1402 g) changed route of a specific end-to-end addressed probe packet 1404 These methods can be categorized as being based on network monitoring 1405 (method a-b), based on data packet monitoring (method c-d) and based 1406 on monitoring signaling protocol messages (method e-g); method f is 1407 the baseline method of RSVP. Methods contingent on monitoring 1408 signaling messages become less effective as soft state refresh rates 1409 are reduced. 1411 When a route change has been detected, it is important that state is 1412 installed as quickly as possible along the new path. It is not 1413 guaranteed that the new path will be able to provide the same 1414 characteristics that were available on the old path. In order to be 1415 able to avoid duplicate state installation or, worse, rejection of 1416 the signaling message because of previously installed state, it is 1417 important to be able to recognize the new signaling message as 1418 belonging to an existing session. In this respect, we distinguish 1419 between route changes with associated change of the flow 1420 identification (e.g. in case of a mobility event when the IP source 1421 might change) and route changes without change of the flow 1422 identification (e.g. in case of a link failure along the path). The 1423 former case requires an identifier independent from the flow 1424 identification, i.e. the session identifier (section 4.6.2). Mobility 1425 issues are discussed in more detail in section 5.2. 1427 When state has been installed along the new path, the existing state 1428 on the old path needs to be removed. With the soft-state principle, 1429 this will happen automatically because of the lack of refresh 1430 messages. Depending on the refresh timer, however, it may be required 1431 to tear down this state much faster (e.g. because it is tied to an 1432 accounting record). In that case, the teardown message needs to be 1433 able to distinguish between the new path and the old path. 1435 In some environments, it is desired to provide connectivity and per 1436 flow or per class state management with high-availability 1437 characteristics, i.e. with rapid transparent recovery even in the 1438 presence of route changes. This may need interactions with protocols 1439 which are used to manage the routing in this case, such as VRRP [17]. 1441 Our basic assumption about such interactions is that the NTLP would 1442 be responsible for detecting the route change and ensuring that 1443 signaling messages were re-routed appropriately along with data 1444 traffic; but that the further state re-synchronization (including 1445 failover between 'main' and 'standby' nodes in the high availability 1446 case) would be the responsibility of the signaling application and 1447 its NSLP, possibly triggered by the NTLP. 1449 5.2 Mobility and Multihoming Interactions 1451 The issues associated with mobility and multihoming are a 1452 generalization of the basic route change case of the previous 1453 section. As well as the fact that packets for a given session are no 1454 longer traveling over a single topological path, the following extra 1455 considerations arise: 1456 1) The use of IP-layer mobility and multihoming means that more than 1457 one IP source or destination address will be associated with a single 1458 session. The same applies if application layer solutions (e.g. SIP- 1459 based approaches) are used. 1460 2) Mobile IP and associated protocols use some special encapsulations 1461 for some segments of the data path. 1462 3) The double route may persist for some time in the network (e.g. in 1463 the case of a 'make-before-break' handover being done by a multihomed 1464 host). 1465 4) Conversely, the re-routing may be rapid and routine (unlike 1466 network internal route changes), increasing the importance of rapid 1467 state release on old paths. 1469 The interactions between mobility and signaling have been extensively 1470 analyzed in recent years, primarily in the context of RSVP and Mobile 1471 IP interaction (e.g. the mobility discussion of [5]), but also in the 1472 context of other types of network (e.g. [18]); a general review of 1473 the fundamental interactions is given in [19], which provides further 1474 details on many of the subjects considered in this section. 1476 We are assuming that the signaling will refer to 'outer' IP headers 1477 when defining the flows it is controlling. There two main reasons for 1478 this. The first is that the data plane will usually be unable to work 1479 in terms of anything else when implementing per-flow treatment (e.g. 1480 we cannot expect a router will analyse inner headers to decide how to 1481 schedule packets). The second reason is that we are implicitly 1482 relying on the security provided by the network infrastructure to 1483 ensure that the correct packets are given the special treatment being 1484 signaled for, and this is built on the relationship between packet 1485 source and destination addresses and network topology (this is 1486 essentially the same approach that is used as the basis of route 1487 optimization security in Mobile IPv6 [20]). The consequence of this 1488 assumption is that we see the packet streams to (or from) different 1489 addresses as different flows, and where a flow is carried inside a 1490 tunnel this is seen as a different flow again. The encapsulation 1491 issues (point (2) above) are therefore to be handled the same way as 1492 other tunneling cases (section 5.4). 1494 The most critical aspect is therefore the fact that multiple flows 1495 are being used, and the signaling for them needs to be correlated 1496 together. This is the intended role of the session identifier (see 1497 section 4.6.2, which also describes some of the security requirements 1498 for such an identifier). Although the session identifier is visible 1499 at the NTLP, it is the signaling application which is responsible for 1500 performing the correlation (and doing so securely). The NTLP 1501 responsibility is limited to delivering the signaling messages for 1502 each flow between the correct signaling application peers. The 1503 locations at which the correlation takes place are the end system and 1504 the signaling application aware node in the network where the flows 1505 meet (this node is generally referred to as the "crossover router"; 1506 it can be anywhere in the network). 1508 Although much work has been done in the past on finding the crossover 1509 router directly from information held in particular mobility 1510 signaling protocols, the initial focus of NSIS work should be to have 1511 a solution which is not tightly bound to any single mobility 1512 approach. In other words, it should be possible to determine the 1513 crossover router based on NSIS signaling. (This doesn't rule out the 1514 possibility that some implementations may be able to do this 1515 discovery faster, e.g. by being tightly integrated with local 1516 mobility management protocols; this is directly comparable to 1517 spotting route changes in fixed networks by being routing aware.) 1519 Note that the crossover router discovery may involve end-to-end 1520 signaling exchanges (especially for flows towards the mobile or 1521 multihomed node) which raises a latency concern; on the other hand, 1522 end to end signaling will have been necessary in any case, both at 1523 the application level (to communicate changed addresses) and also to 1524 update packet classifiers along the path. It is a matter for further 1525 analysis to decide how these exchanges could be combined or carried 1526 out in parallel. 1528 On the shared part of the path, signaling is needed at least to 1529 update the packet classifiers to include the new flow, although if 1530 correlation with the existing flow is possible it should be possible 1531 to bypass any policy or admission control processing. State 1532 installation on the new path (and possibly release on the old one) 1533 are also required. Which entity (one of the end hosts or the 1534 crossover router) controls all these procedures depends on which 1535 entities are authorised to carry out network state manipulations, so 1536 this is therefore a matter of signaling application and NSLP design. 1537 The approach may depend on the sender/receiver orientation of the 1538 original signaling (see section 3.3.1). In addition, in the mobility 1539 case, the old path may no longer be directly accessible to the mobile 1540 node; inter-access-router communication may be required to release 1541 state in these circumstances. 1543 The frequency of handovers in some network types encourages the 1544 consideration of fast handover support protocols, for selection of 1545 the optimal access router to hand over to (for example, [21]), and 1546 transfer of state information to avoid having to regenerate it in the 1547 new access router after handover (for example, [22]). Both these 1548 procedures could have strong interactions with signaling protocols, 1549 the former because a selection criterion might be what network 1550 control state could be supported on the path through the new access 1551 router, the latter because signaling application state or NTLP/NSLP 1552 protocol state may be a candidate for context transfer. 1554 5.3 Interactions with NATs 1556 Because at least some messages will almost inevitably contain 1557 addresses and possibly higher layer information as payload, we must 1558 consider the interaction with address translation devices (NATs). 1559 These considerations apply both to 'traditional' NATs of various 1560 types (as defined in [23]) as well as some IPv4/v6 transition 1561 mechanisms such as SIIT [24]. 1563 In the simplest case of an NSIS unaware NAT in the path, payloads 1564 will be uncorrected and signaling will refer to the flow incorrectly. 1565 Applications could attempt to use STUN [25] or similar techniques to 1566 detect and recover from the presence of the NAT. Even then, NSIS 1567 protocols would have to use a well known encapsulation (TCP/UDP/ICMP) 1568 to avoid being dropped by more cautious low-end NAT devices. 1570 A simple 'NSIS-aware' NAT would require flow identification 1571 information to be in the clear and not integrity protected. An 1572 alternative conceptual approach is to consider the NAT functionality 1573 being part of message processing itself, in which case the 1574 translating node can take part natively in any NSIS protocol security 1575 mechanisms. Depending on NSIS protocol layering, it would be possible 1576 for this processing to be done in an NSIS entity which was otherwise 1577 ignorant of any particular signaling applications. This is the 1578 motivation for including basic flow identification information in the 1579 NTLP (section 4.6.1). 1581 Note that all of this discussion is independent of the use of a 1582 specific NSLP for general control of NATs (and firewalls). This is 1583 considered in section 6.2. 1585 5.4 Interactions with IP Tunneling 1587 Tunneling is used in the Internet for a number of reasons such as 1588 flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual 1589 private networking, and so on. An NSIS solution must continue to work 1590 in the presence of these techniques, i.e. the presence of the tunnel 1591 should not cause problems for end-to-end signaling, and it should 1592 also be possible to use NSIS signaling to control the treatment of 1593 the packets carrying the tunneled data. 1595 It is assumed that the NSIS approach will be similar to that of [26], 1596 where the signaling for the end-to-end data flow is tunneled along 1597 with that data flow, and is invisible to nodes along the path of the 1598 tunnel (other than the endpoints). This provides backwards 1599 compatibility with networks where the tunnel endpoints do not support 1600 the NSIS protocols. We assume that NEs will not unwrap tunnel 1601 encapsulations to find and process tunneled signaling messages. 1603 To signal for the packets carrying the tunneled data, the tunnel is 1604 considered as a new data flow in its own right, and NSIS signaling is 1605 applied recursively to it. This requires signaling support in at 1606 least one tunnel endpoint. In some cases (where the signaling 1607 initiator is at the opposite end of the data flow from the tunnel 1608 initiator - i.e. in the case of receiver initiated signaling), there 1609 needs to be the ability to provide a binding between the original 1610 flow identification and that for the tunneled flow. It is left open 1611 here whether this should be an NTLP or an NSLP function. 1613 6 Signaling Applications 1615 This section gives an overview of NSLPs for particular signaling 1616 applications. The assumption is that the NSLP uses the generic 1617 functionality of the NTLP given earlier; this section describes 1618 specific aspects of NSLP operation. It is intended to clarify by 1619 simple examples how NSLPs fit into the framework. It does not replace 1620 or even form part of the formal NSLP protocol specifications; in 1621 particular, initial designs are being developed for NSLPs for 1622 resource reservation [27] and middlebox communication [28]. 1624 6.1 Signaling for Quality of Service 1626 In the case of signaling for QoS, all the basic NSIS concepts of 1627 section 3.1 apply. In addition, there is an assumed directionality of 1628 the signaling process, in that one end of the signaling flow takes 1629 responsibility for actually requesting the resource. This leads to 1630 the following definitions: 1631 *) QoS NSIS Initiator (QNI): the signaling entity which makes the 1632 resource request, usually as a result of user application request. 1633 *) QoS NSIS Responder (QNR): the signaling entity that acts as the 1634 endpoint for the signaling and can optionally interact with 1635 applications as well. 1636 *) QoS NSIS Forwarder (QNF): the signaling entity between a QNI and 1637 QNR which propagates NSIS signaling further through the network. 1638 Each of these entities will interact with a resource management 1639 function (RMF) which actually allocates network resources (router 1640 buffers, interface bandwidth and so on). 1642 Note that there is no constraint on which end of the signaling flow 1643 should take the QNI role: with respect to the data flow direction it 1644 could be at the sending or receiving end. 1646 Note the continued assumption is that the NTLP works with standard 1647 (i.e. best-effort) layer 3 routing. There are, however, several 1648 proposals for the introduction of QoS awareness in routing protocols. 1649 All of these essentially lead to the existence of multiple paths 1650 (with different QoS) towards the same destination. As such, they also 1651 contain an inherent risk for a divergence between control plane and 1652 data plane, similar to the load sharing case. Clearly, any QoS NSLP 1653 needs to be able to handle this type of routing, although, provided 1654 the NTLP continues to deliver signaling messages correctly, the 1655 impact on the QoS NSLP protocol design itself should be limited. 1657 6.1.1 Protocol Message Semantics 1659 The QoS NSLP will include a set of messages to carry out resource 1660 reservations along the signaling path. A possible set of message 1661 semantics for the QoS NSLP is shown below. Note that the 'direction' 1662 column in the table below only indicates the 'orientation' of the 1663 message. Messages can be originated and absorbed at QNF nodes as well 1664 as the QNI or QNR; an example might be QNFs at the edge of a domain 1665 exchanging messages to set up resources for a flow across a it. Note 1666 that it is left open if the responder can release or modify a 1667 reservation, during or after setup. This seems mainly a matter of 1668 assumptions about authorization, and the possibilities might depend 1669 on resource type specifics. 1671 The table also explicitly includes a refresh operation. This does 1672 nothing to a reservation except extend its lifetime, and is one 1673 possible state management mechanism (see next section). 1675 +-----------+---------+------------------------------------------+ 1676 | Operation |Direction| Semantics | 1677 +-----------+---------+------------------------------------------+ 1678 | Request | I-->R | Create a new reservation for a flow | 1679 +-----------+---------+------------------------------------------+ 1680 | Modify | I-->R | Modify an existing reservation | 1681 | |(&R-->I?)| | 1682 +-----------+---------+------------------------------------------+ 1683 | Release | I-->R | Delete (tear down) an | 1684 | |(&R-->I?)| existing reservation | 1685 +-----------+---------+------------------------------------------+ 1686 | Accept/ | R-->I | Confirm (possibly modified?) or reject a | 1687 | Reject | | reservation request | 1688 +-----------+---------+------------------------------------------+ 1689 | Notify | I-->R & | Report an event detected within the | 1690 | | R-->I | network | 1691 +-----------+---------+------------------------------------------+ 1692 | Refresh | I-->R | State management (see section 6.1.2) | 1693 +-----------+---------+------------------------------------------+ 1695 6.1.2 State Management 1697 The prime purpose of NSIS is to manage state information along the 1698 path taken by a data flow. The issues regarding state management 1699 within the NTLP (state related to message transport) are described in 1700 section 4. The QoS NSLP will typically have to handle additional 1701 state related to the desired resource reservation to be made. 1703 There two critical issues to be considered in building a robust NSLP 1704 to handle this problem: 1706 *) The protocol must be scalable. It should allow minimization of the 1707 resource reservation state storage demands that it implies for 1708 intermediate nodes; in particular, storage of state per 'micro' flow 1709 is likely to be impossible except at the very edge of the network. A 1710 QoS signaling application might require per flow or lower granularity 1711 state; examples of each for the case of QoS would be IntServ [29] or 1712 RMD [30] (per 'class' state) respectively. 1713 *) The protocol must be robust against failure and other conditions, 1714 which imply that the stored resource reservation state has to be 1715 moved or removed. 1717 For resource reservations, soft state management is typically used as 1718 a general robustness mechanism. According to the discussion of 1719 section 3.2.5, the soft state protocol mechanisms are built into the 1720 NSLP for the specific signaling application that needs them; the NTLP 1721 sees this simply as a sequence of (presumably identical) messages. 1723 6.1.3 Route Changes and QoS Reservations 1725 In this section, we will explore the expected interaction between 1726 resource signaling and routing updates (the precise source of routing 1727 updates does not matter). The normal operation of the NSIS protocol 1728 will lead to the situation depicted in Figure 7, where the reserved 1729 resources match the data path. 1731 reserved +-----+ reserved +-----+ 1732 =========>| QNF |===========>| QNF | 1733 +-----+ +-----+ 1734 ---------------------------------------> 1735 data path 1737 Figure 7: Normal NSIS protocol operation 1739 A route change can occur while such a reservation is in place. The 1740 route change will be installed immediately and any data will be 1741 forwarded on the new path. This situation is depicted Figure 8. 1743 Resource reservation on the new path will only be started once the 1744 next control message is routed along the new path. This means that 1745 there is a certain time interval during which resources are not 1746 reserved on (part of) the data path. To minimize this time interval 1747 several techniques could be considered. As an example, RSVP [7] has 1748 the concept of local repair, where the router may be triggered by a 1749 route change. In that case the RSVP node can start sending PATH 1750 messages directly after the route has been changed. Note that this 1751 option may not be available if no per-flow state is kept in the NF. 1753 Route update 1754 | 1755 v 1756 reserved +-----+ reserved +-----+ 1757 =========>| QNF |===========>| QNF | 1758 +-----+ +-----+ 1759 -------- || 1760 \ || +-----+ 1761 | ===========>| QNF | 1762 | +-----+ 1763 +---------------------------> 1764 data path 1766 Figure 8: Route Change 1768 It is not guaranteed that the new path will be able to provide the 1769 same guarantees that were available on the old path. Therefore, in a 1770 more desirable scenario, the QNF should wait until resources have 1771 been reserved on the new path before installing the route change 1772 (unless of course the old path no longer exists). The route change 1773 procedure then consists of the following steps: 1774 1. QNF receives a route announcement, 1775 2. Refresh messages are forwarded along the current path, 1776 3. A copy of the refresh message is re-marked as a request and sent 1777 along the new path that was announced, 1778 4. When the QNF has been acknowledged about the reservations on the 1779 new path, the route will be installed and data will flow along it. 1781 Another example related to route changes is denoted as severe 1782 congestion and is explained in [30]. This solution adapts to a route 1783 change, when a route change creates congestion on the new routed 1784 path. 1786 6.1.4 Resource Management Interactions 1788 The QoS NSLP itself is not involved in any specific resource 1789 allocation or management techniques. The definition of an NSLP for 1790 resource reservation with Quality of Service, however, implies the 1791 notion of admission control. For a QoS NSLP, the measure of signaling 1792 success will be the ability to reserve resources from the total 1793 resource pool that is provisioned in the network. We define the 1794 function responsible for allocating this resource pool as the 1795 Resource Management Function (RMF). The RMF is responsible for all 1796 resource provisioning, monitoring and assurance functions in the 1797 network. 1799 A QoS NSLP will rely on the RMF to do resource management and to 1800 provide inputs for admission control. In this model, the RMF acts as 1801 a server towards client NSLP(s). It is noted, however, that the RMF 1802 may in turn use another NSLP instance to do the actual resource 1803 provisioning in the network. In this case, the RMF acts as the 1804 initiator (client) of an NSLP. 1806 This essentially corresponds to a multi-level signaling paradigm, 1807 with an 'upper' level handling internetworking QoS signaling, 1808 possibly running end-to-end, and a 'lower' level handling the more 1809 specialized intradomain QoS signaling, running between just the edges 1810 of the network (see [10], [31], and [32] for a discussion of similar 1811 architectures). Given that NSIS signaling is already supposed to be 1812 able to support multiple instances of NSLPs for a given flow, and 1813 limited scope (e.g. edge-to-edge) operation, it is not currently 1814 clear that supporting the multi-level model leads to any new protocol 1815 requirements for the QoS NSLP. 1817 The RMF may or may not be co-located with a QNF (note that co- 1818 location with a QNI/QNR can be handled logically as a combination 1819 between QNF and QNI/QNR). To cater for both cases, we define a 1820 (possibly logical) NF-RMF interface. Over this interface, information 1821 may be provided from the RMF about monitoring, resource availability, 1822 topology, and configuration. In the other direction, the interface 1823 may be used to trigger requests for resource provisioning. One way to 1824 formalize the interface between the QNF and the RMF is via a Service 1825 Level Agreement (SLA). The SLA may be static or it may be dynamically 1826 updated by means of a negotiation protocol. Such a protocol is 1827 outside the scope of NSIS. 1829 There is no assumed restriction on the placement of the RMF. It may 1830 be a centralized RMF per domain, several off-path distributed RMFs, 1831 or an on-path RMF per router. The advantages and disadvantages of 1832 both approaches are well-known. Centralization typically allows 1833 decisions to be taken using more global information with more 1834 efficient resource utilization as a result. It also facilitates 1835 deployment or upgrade of policies. Distribution allows local decision 1836 processes and rapid response to data path changes. 1838 6.2 Other Signaling Applications 1840 As well as the use for 'traditional' QoS signaling, it should be 1841 possible to develop NSLPs for other signaling applications which 1842 operate on different types of network control state. One specific 1843 case is setting up flow-related state in middleboxes (firewalls, 1844 NATs, and so on). Requirements for such communication are given in 1845 [4]. Other examples include network monitoring and testing, and 1846 tunnel endpoint discovery. 1848 7 Security Considerations 1850 This document describes a framework for signaling protocols which 1851 assumes a two-layer decomposition, with a common lower layer (NTLP) 1852 supporting a family of signaling application specific upper layer 1853 protocols (NSLPs). The overall security considerations for the 1854 signaling therefore depend on the joint security properties assumed 1855 or demanded for each layer. 1857 Security for the NTLP is discussed in section 4.7. We have assumed 1858 that the role of the NTLP will be to provide message protection over 1859 the scope of a single peer relationship, between adjacent signaling 1860 application entities (see section 3.2.3 for a discussion of the case 1861 where these entities are separated by more than one NTLP hop). These 1862 functions can most likely be provided by some kind of channel 1863 security mechanism using an external key management mechanism based 1864 on mutual authentication. In addition, the NTLP should be resilient 1865 against denial of service attacks on the protocol itself. 1867 Security for the NSLPs is entirely dependent on signaling application 1868 requirements. In some cases, no additional protection may be required 1869 compared to what is provided by the NTLP. In other cases, more 1870 sophisticated object-level protection and the use of public key based 1871 solutions may be required. In addition, the NSLP needs to consider 1872 the authorisation requirements of the signaling application. 1873 Authorisation is a complex topic, for which a very brief overview is 1874 provided in section 3.3.7. 1876 Another factor is that NTLP security mechanisms operate only locally, 1877 whereas NSLP mechanisms may also need to operate over larger regions 1878 (not just between adjacent peers) especially for authorisation 1879 aspects; this complicates the analysis of basing signaling 1880 application security on NTLP protection. 1882 An additional concern for signaling applications is the session 1883 identifier security issue (sections 4.6.2 and 5.2). The purpose of 1884 this identifier is to decouple session identification (as a handle 1885 for network control state) from session "location" (i.e. the data 1886 flow endpoints). The identifier/locator distinction has been 1887 extensively discussed in the user plane for end to end data flows, 1888 and is known to lead to non-trivial security issues in binding the 1889 two together again; our problem is the analogue in the control plane, 1890 and is at least similarly complex, because of the need to involve 1891 nodes in the interior of the network as well. 1893 Further work on this and other security design will depend on a 1894 refinement of the NSIS threats work begun in [2]. 1896 Normative References 1898 1 Brunner, M., "Requirements for Signaling Protocols", draft-ietf- 1899 nsis-req-09.txt (work in progress), August 2003 1901 2 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 1902 draft-ietf-nsis-threats-02.txt (work in progress), June 2003 1904 3 Chaskar, H. (editor), " Requirements of a Quality of Service (QoS) 1905 Solution for Mobile IP", RFC 3583, September 2003 1907 4 Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M. Shore, 1908 "Middlebox Communications (midcom) Protocol Requirements", RFC 1909 3304, August 2002 1911 Informative References 1913 5 Manner, J., Fu, X. and P. Pan, "Analysis of Existing Quality of 1914 Service Signaling Protocols", draft-ietf-nsis-signalling-analysis- 1915 02.txt (work in progress), June 2003 1917 6 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp- 1918 sec-properties-02.txt (work in progress), June 2003 1920 7 Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 1921 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1922 Specification", RFC 2205, September 1997 1924 8 Katz, D., "IP Router Alert Option", RFC2113, February 1997 1926 9 Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 1927 2711, October 1999 1929 10 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 1930 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1931 September 2001 1933 11 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1934 Security Considerations", BCP 72, RFC 3552, July 2003 1936 12 Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne, 1937 "NSIS Authentication, Authorization and Accounting Issues", draft- 1938 tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003 1940 13 Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. 1941 Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC2961, 1942 April 2001 1944 14 Ji, P., Ge, Z., Kurose, J. and D. Townsley, "A Comparison of Hard- 1945 State and Soft-State Signaling Protocols", Computer Communication 1946 Review, Volume 33, Number 4, October 2003 1948 15 Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 1949 September 2000 1951 16 Apostolopoulos, G., Williams, D., Kamat, S., Guerin, R., Orda, A. 1952 and T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", 1953 RFC 2676, August 1999 1955 17 Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, 1956 P., Higginson, P., Shand, M. and A. Lindem, "Virtual Router 1957 Redundancy Protocol", RFC2338, April 1998 1959 18 Heijenk, G., Karagiannis, G., Rexhepi, V. and L. Westberg, 1960 "DiffServ Resource Management in IP-based Radio Access Networks", 1961 Proceedings of 4th International Symposium on Wireless Personal 1962 Multimedia Communications-WPMC'01, September 9 - 12, 2001 1964 19 Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, E. 1965 and Y. Khouaja, "Evaluation of Mobility and QoS Interaction", 1966 Computer Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163 1968 20 Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", 1969 draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003 1971 21 Trossen, D., Krishnamurthi, G., Chaskar, H. and J. Kempf, "Issues 1972 in candidate access router discovery for seamless IP-level 1973 handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt (work in 1974 progress), October 2002 1976 22 Kempf, J., "Problem Description: Reasons For Performing Context 1977 Transfers Between Nodes in an IP Access Network", RFC3374, 1978 September 2002 1980 23 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1981 (NAT) Terminology and Considerations", RFC2663, August 1999 1983 24 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 1984 RFC2765, February 2000 1986 25 Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1987 Simple Traversal of User Datagram Protocol (UDP) Through Network 1988 Address Translators (NATs)", RFC3489, March 2003 1990 26 Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP 1991 Operation Over IP Tunnels", RFC 2746, January 2000 1993 27 Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 1994 Quality-of- - 1995 Service Signaling", draft ietf-nsis-qos-nslp-00.txt 1996 (work in progress), September 2003 1998 28 Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "A 1999 NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf- 2000 nsis-nslp-natfw-00 (work in progress), October 2003 2002 29 Braden, R., Clark, D. and S. Shenker, "Integrated Services in the 2003 Internet Architecture: an Overview", RFC 1633, June 1994 2005 30 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 2006 Partain, D., Pop, O., Rexhepi, V., Szabo, R. and A. Takacs, 2007 "Resource Management in Diffserv (RMD): A Functionality and 2008 Performance Behavior Overview", Seventh International Workshop on 2009 Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 2011 31 Ferrari, D., Banerjea, A. and H. Zhang, "Network Support for 2012 Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92- 2013 072, November 1992 2015 32 Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated 2016 Services Architecture for the Internet", RFC 2638, July 1999 2018 Acknowledgments 2020 The authors would like to thank Bob Braden, Maarten Buchli, Eleanor 2021 Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for 2022 significant contributions in particular areas of this draft. In 2023 addition, the authors would like to acknowledge Cedric Aoun, Attila 2024 Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, 2025 Xiaoming Fu, Ruediger Geib, Danny Goderis, Cornelia Kappler, Sung 2026 Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, 2027 Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom 2028 Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg, 2029 and Lixia Zhang for insights and inputs during this and previous 2030 framework activities. 2032 Authors' Addresses 2034 Robert Hancock (editor) 2035 Roke Manor Research 2036 Old Salisbury Lane 2037 Romsey 2038 Hampshire 2039 SO51 0ZN 2040 United Kingdom 2041 email: robert.hancock@roke.co.uk 2043 Ilya Freytsis 2044 Cetacean Networks Inc. 2045 100 Arboretum Drive 2046 Portsmouth, NH 03801 2047 USA 2048 email: ifreytsis@cetacean.com 2050 Georgios Karagiannis 2051 University of Twente 2052 P.O. BOX 217 2053 7500 AE Enschede 2054 The Netherlands 2055 email: g.karagiannis@ewi.utwente.nl 2057 John Loughney 2058 Nokia Research Center 2059 11-13 Italahdenkatu 2060 00180 Helsinki 2061 Finland 2062 email: john.loughney@nokia.com 2064 Sven Van den Bosch 2065 Alcatel 2066 Francis Wellesplein 1 2067 B-2018 Antwerpen 2068 Belgium 2069 email: sven.van_den_bosch@alcatel.be 2071 Intellectual Property Considerations 2073 The IETF takes no position regarding the validity or scope of any 2074 intellectual property or other rights that might be claimed to 2075 pertain to the implementation or use of the technology described in 2076 this document or the extent to which any license under such rights 2077 might or might not be available; neither does it represent that it 2078 has made any effort to identify any such rights. Information on the 2079 IETF's procedures with respect to rights in standards-track and 2080 standards-related documentation can be found in BCP-11. Copies of 2081 claims of rights made available for publication and any assurances of 2082 licenses to be made available, or the result of an attempt made to 2083 obtain a general license or permission for the use of such 2084 proprietary rights by implementers or users of this specification can 2085 be obtained from the IETF Secretariat. 2087 The IETF invites any interested party to bring to its attention any 2088 copyrights, patents or patent applications, or other proprietary 2089 rights which may cover technology that may be required to practice 2090 this standard. Please address the information to the IETF Executive 2091 Director. 2093 Full Copyright Statement 2095 Copyright (C) The Internet Society (2003). All Rights Reserved. This 2096 document and translations of it may be copied and furnished to 2097 others, and derivative works that comment on or otherwise explain it 2098 or assist in its implementation may be prepared, copied, published 2099 and distributed, in whole or in part, without restriction of any 2100 kind, provided that the above copyright notice and this paragraph are 2101 included on all such copies and derivative works. However, this 2102 document itself may not be modified in any way, such as by removing 2103 the copyright notice or references to the Internet Society or other 2104 Internet organizations, except as needed for the purpose of 2105 developing Internet standards in which case the procedures for 2106 copyrights defined in the Internet Standards process must be 2107 followed, or as required to translate it into languages other than 2108 English. 2110 The limited permissions granted above are perpetual and will not be 2111 revoked by the Internet Society or its successors or assigns. This 2112 document and the information contained herein is provided on an "AS 2113 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2114 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2115 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2116 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2117 OR FITNESS FOR A PARTICULAR PURPOSE.