idnits 2.17.1 draft-ietf-nsis-fw-02.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7706 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 21 looks like a reference -- Missing reference section? '2' on line 70 looks like a reference -- Missing reference section? '3' on line 468 looks like a reference -- Missing reference section? '4' on line 1736 looks like a reference -- Missing reference section? '5' on line 174 looks like a reference -- Missing reference section? '6' on line 1820 looks like a reference -- Missing reference section? '7' on line 177 looks like a reference -- Missing reference section? 'Data' on line 225 looks like a reference -- Missing reference section? '8' on line 468 looks like a reference -- Missing reference section? '9' on line 484 looks like a reference -- Missing reference section? '10' on line 827 looks like a reference -- Missing reference section? '11' on line 852 looks like a reference -- Missing reference section? '12' on line 1857 looks like a reference -- Missing reference section? '13' on line 1041 looks like a reference -- Missing reference section? '14' on line 1041 looks like a reference -- Missing reference section? '15' on line 1240 looks like a reference -- Missing reference section? '16' on line 1682 looks like a reference -- Missing reference section? '17' on line 1687 looks like a reference -- Missing reference section? '18' on line 1255 looks like a reference -- Missing reference section? '19' on line 1352 looks like a reference -- Missing reference section? '20' on line 1495 looks like a reference -- Missing reference section? '21' on line 1366 looks like a reference -- Missing reference section? '22' on line 1502 looks like a reference -- Missing reference section? '23' on line 1432 looks like a reference -- Missing reference section? '24' on line 1506 looks like a reference -- Missing reference section? '25' on line 1506 looks like a reference -- Missing reference section? '26' on line 1507 looks like a reference -- Missing reference section? '27' on line 1525 looks like a reference -- Missing reference section? '28' on line 1526 looks like a reference -- Missing reference section? '29' on line 1541 looks like a reference -- Missing reference section? '30' on line 1543 looks like a reference -- Missing reference section? '31' on line 1547 looks like a reference -- Missing reference section? '32' on line 1602 looks like a reference -- Missing reference section? '33' on line 1654 looks like a reference -- Missing reference section? '34' on line 1757 looks like a reference -- Missing reference section? '35' on line 1785 looks like a reference -- Missing reference section? '36' on line 1785 looks like a reference -- Missing reference section? '37' on line 1785 looks like a reference -- Missing reference section? '38' on line 1821 looks like a reference -- Missing reference section? '39' on line 1821 looks like a reference -- Missing reference section? '40' on line 1821 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 43 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group 2 Internet Draft Robert Hancock (editor) 3 Siemens/Roke Manor Research 4 Ilya Freytsis 5 Cetacean Networks 6 Georgios Karagiannis 7 Ericsson 8 John Loughney 9 Nokia 10 Sven Van den Bosch 11 Alcatel 12 Document: draft-ietf-nsis-fw-02.txt 13 Expires: September 2003 March 2003 15 Next Steps in Signaling: Framework 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026 [1]. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The Next Steps in Signaling working group is considering protocols 40 for signaling information about a data flow along its path in the 41 network. Based on existing work on signaling requirements, this 42 document proposes an architectural framework for such signaling 43 protocols. 45 This document provides a model for the network entities that take 46 part in such signaling, and the relationship between signaling and 47 the rest of network operation. We decompose the overall signaling 48 protocol suite into a generic (lower) layer, with a separate upper 49 layers for each specific signaling application. An initial proposal 50 for the split between these layers is given, describing the overall 51 functionality of the lower layer, and discussing the ways that upper 52 layer behavior can be adapted to specific signaling application 53 requirements. 55 This framework also considers the general interactions between 56 signaling and other network layer functions, specifically routing and 57 mobility. The different routing and mobility events that impact 58 signaling operation are described, along with how their handling 59 should be divided between the generic and application-specific 60 layers. Finally, an example signaling application (for Quality of 61 Service) is described in more detail. 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC-2119 [2]. 68 [Editor's note: if - as is likely - we don't end up using these words 69 in the framework, this paragraph will disappear.] 71 Table of Contents 73 1. Introduction...................................................3 74 1.1 Definition of the NSIS Signaling Problem ...................3 75 1.2 Scope and Structure of the NSIS Framework ..................4 76 2. Terminology....................................................5 77 3. Overview of Signaling Scenarios and Protocol Structure.........6 78 3.1 Fundamental Signaling Concepts .............................6 79 3.1.1 Simple Network and Signaling Topology ..................6 80 3.1.2 Signaling to Hosts, Networks and Proxies ...............7 81 3.1.3 Signaling Messages and Network Control State ...........9 82 3.1.4 Data Flows and Sessions ...............................10 83 3.2 Layer Model for the Protocol Suite ........................11 84 3.2.1 Layer Model Overview ..................................11 85 3.2.2 Layer Split Concept ...................................12 86 3.2.3 Core NTLP Functionality ...............................13 87 3.2.4 Path De-Coupled Operation .............................14 88 3.3 Signaling Application Properties ..........................14 89 3.3.1 Sender/Receiver Orientation ...........................15 90 3.3.2 Uni- and Bi-Directional Operation .....................16 91 3.3.3 Heterogeneous Operation ...............................16 92 3.3.4 Peer-Peer and End-End Relationships ...................17 93 3.3.5 Acknowledgements and Notifications ....................17 94 3.3.6 Security and other AAA Issues .........................18 95 3.4 Open Layer Model Issues ...................................19 96 3.4.1 Classical Transport Functionality .....................19 97 3.4.2 State Management ......................................20 98 4. The NSIS Transport Layer Protocol.............................21 99 4.1 Internal Protocol Components ..............................21 100 4.2 Addressing ................................................22 101 4.3 Lower Layer Interfaces ....................................22 102 4.4 Upper Layer Services ......................................23 103 4.5 Identity Elements .........................................24 104 4.5.1 Flow Identification ...................................24 105 4.5.2 Session Identification ................................24 106 4.5.3 Signaling Application Identification ..................25 107 4.6 Security Properties .......................................25 108 5. Interactions with Other Protocols.............................26 109 5.1 IP Routing Interactions ...................................26 110 5.1.1 Load Sharing and Policy-Based Forwarding ..............26 111 5.1.2 Route Changes .........................................28 112 5.1.3 Router Redundancy .....................................29 113 5.2 Mobility Interactions .....................................29 114 5.2.1 Addressing and Encapsulation ..........................30 115 5.2.2 Localized Path Repair .................................30 116 5.2.3 Update on the Unchanged Path ..........................31 117 5.2.4 Interaction with Mobility Signaling ...................31 118 5.2.5 Interaction with Context Transfer .....................33 119 5.3 Interactions with NATs ....................................33 120 6. Signaling Applications........................................34 121 6.1 Signaling for Quality of Service ..........................34 122 6.1.1 Protocol Messages .....................................34 123 6.1.2 State Management ......................................35 124 6.1.3 QoS Forwarding ........................................36 125 6.1.4 Route Changes and QoS Reservations ....................36 126 6.1.5 Resource Management Interactions ......................38 127 6.2 Other Signaling Applications ..............................39 128 7. Security Considerations.......................................39 129 8. Change History................................................40 130 8.1 Changes from draft-ietf-nsis-fw-01.txt ....................40 131 References.......................................................41 132 Acknowledgments..................................................44 133 Authors' Addresses...............................................44 134 Intellectual Property Considerations.............................45 135 Full Copyright Statement.........................................46 137 1. Introduction 139 1.1 Definition of the NSIS Signaling Problem 141 The NSIS working group is considering protocols for signaling 142 information about a data flow along its path in the network. 144 It is assumed that the path taken by the data flow is already 145 determined by network configuration and routing protocols, 146 independent of the signaling itself; that is, signaling to set up the 147 routes themselves is not considered. Instead, the signaling simply 148 interacts with nodes along the data flow path. Additional 149 simplifications are that the actual signaling messages pass directly 150 through these nodes themselves; this is 'path-coupled' signaling in 151 the sense described in [3], and that only unicast data flows are 152 considered. 154 The signaling problem in this sense is very similar to that addressed 155 by RSVP [4]. However, there are two generalizations. Firstly, the 156 intention is that NSIS designs protocols that can be used in 157 different parts of the Internet, for different needs, without 158 requiring a complete end-to-end deployment (in particular, the 159 signaling protocol messages may not need to run all the way between 160 the data flow endpoints). 162 Secondly, the signaling is intended for more purposes than just QoS 163 (resource reservation). The basic mechanism to achieve this 164 flexibility is to divide the signaling protocol stack into two 165 layers: a generic (lower) layer, and an upper layer specific to each 166 signaling application. The scope of NSIS is to define both the 167 generic protocol, and initially an upper layer suitable for QoS 168 signaling similar to the corresponding functionality in RSVP. Further 169 signaling applications may be considered later. 171 1.2 Scope and Structure of the NSIS Framework 173 The underlying requirements for signaling in the context of NSIS are 174 defined in [3]; other related requirements can be found in [5] and 175 [6]. This framework does not replace or update these requirements. 176 Discussions about lessons to be learned from existing signaling and 177 resource protocols are contained in a separate analysis document [7]. 179 The role of this framework is to explain how NSIS signaling should 180 work within the broader networking context, and how the signaling 181 protocols should be structured at the overall level. Therefore, it 182 discusses important protocol considerations, such as routing, 183 mobility, security, and interactions with network 'resource' 184 management (in the broadest sense). 186 The basic framework for NSIS is given in section 3. Section 3.1 187 describes the fundamental elements of NSIS operation in comparison to 188 RSVP; in particular, section 3.1.2 describes more general signaling 189 scenarios, and 3.1.3 defines a broader class of signaling 190 applications for which the NSIS protocols should be useful. The two- 191 layer protocol architecture that supports this generality is 192 described in section 3.2, and section 3.3 gives examples of the ways 193 in which particular signaling application properties can be 194 accommodated within signaling layer protocol behavior. 196 The overall functionality required from the lower (generic) protocol 197 layer is described in section 4. This is not intended to define the 198 protocol detailed design or even design options, although some are 199 described as examples. The emphasis is on defining the interfaces 200 between this lower layer protocol and the IP layer and signaling 201 application protocols, including the identity elements that appear on 202 these interfaces. Following this, section 5 describes how signaling 203 applications that use the NSIS protocols can interact sensibly with 204 network layer operations, specifically routing (and re-routing), IP 205 mobility, and network address translation. 207 Section 6 describes particular signaling applications. The example of 208 signaling for QoS (comparable to core RSVP QoS signaling 209 functionality) is described in detail in section 6.1, which describes 210 both the signaling application specific protocol and example modes of 211 interaction with network resource management and other deployment 212 aspects. However, note that these examples are included only as 213 background and for explanation; it is not intended to define an over- 214 arching architecture for carrying out resource management in the 215 Internet. Further possible signaling applications are outlined in 216 section 6.2. 218 2. Terminology 220 [Editor's note: it is a matter of taste where we put this.] 222 Classifier - an entity which selects packets based on their contents 223 according to defined rules. 225 [Data] flow - a stream of packets from sender to receiver which is a 226 distinguishable subset of a packet stream. Each flow is distinguished 227 by some flow identifier (see section 4.5.1). 229 Edge node - a (NSIS-capable) node on the boundary of some 230 administrative domain. 232 Interior nodes - the set of (NSIS-capable) nodes which form an 233 administrative domain, excluding the edge nodes. 235 NSIS Entity (NE) - the function within a node which implements an 236 NSIS protocol. In the case of path-coupled signaling, the NE will 237 always be on the data path. 239 NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS 240 protocol component that supports a specific signaling application. 241 See also section 3.2.1. 243 NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS 244 protocol component that will support lower layer (signaling 245 application independent) functions. See also section 3.2.1. 247 Path-coupled signaling - a mode of signaling where the signaling 248 messages follow a path that is tied to the data messages. 250 Path-decoupled signaling - signaling - signaling for state 251 manipulation related to data flows, but only loosely coupled to the 252 data path, e.g. at the AS level. 254 Peer discovery - the act of locating and/or selecting which NSIS peer 255 to carry out signaling exchanges with for a specific data flow. 257 Peer relationship - signaling relationship between two adjacent NSIS 258 entities (i.e. NEs with no other NEs between them). 260 Receiver - the node in the network which is receiving the data 261 packets in a flow. 263 Sender - the node in the network which is sending the data packets in 264 a flow. 266 Session - application layer flow of information for which some 267 network control state information is to be manipulated or monitored 268 (see section 4.5.2). 270 Signaling application - the purpose of the NSIS signaling: a service 271 could be QoS management, firewall control, and so on. Totally 272 distinct from any specific user application. 274 3. Overview of Signaling Scenarios and Protocol Structure 276 3.1 Fundamental Signaling Concepts 278 3.1.1 Simple Network and Signaling Topology 280 The NSIS suite of protocols is envisioned to support various 281 signaling applications that need to install and/or manipulate state 282 in the network. This state is related to a data flow and is installed 283 and maintained on the NSIS Entities (NEs) along the data flow path 284 through the network; not every node has to contain an NE. The basic 285 protocol concepts do not depend on the signaling application, but the 286 details of operation and the information carried do. This section 287 discusses the basic entities involved with signaling as well as 288 interfaces between them. 290 Two NSIS entities that communicate directly are said to be in a 'peer 291 relationship'. This concept might loosely be described as an 'NSIS 292 hop'; however, there is no implication that it corresponds to a 293 single IP hop. Either or both NEs might store some state information 294 about the other, but there is no assumption that they necessarily 295 establish a long-term signaling connection between themselves. 297 It is common to consider a network as composed of various domains, 298 e.g. for administrative or routing purposes, and the operation of 299 signaling protocols may be influenced by these domain boundaries. 300 However, it seems there is no reason to expect that an 'NSIS domain' 301 should exactly overlap with an IP domain (AS, area) but it is likely 302 that its boundaries would consist of boundaries (segments) of one or 303 several IP domains. 305 Figure 1 shows a diagram of nearly the simplest possible signaling 306 configuration. A single data flow is running from an application in 307 the sender to the receiver via routers R1, R2 and R3. Each host and 308 two of the routers contain NEs which exchange signaling messages - 309 possibly in both directions - about the flow. This scenario is 310 essentially the same as that considered by RSVP for QoS signaling; 311 the main difference is that we make no assumptions here about the 312 particular sequence of signaling messages that will be invoked. 314 Sender Receiver 315 +-----------+ +----+ +----+ +----+ +-----------+ 316 |Application|----->| R1 |----->| R2 |----->| R3 | ---->|Application| 317 | +--+ | |+--+| |+--+| +----+ | +--+ | 318 | |NE|====|======||NE||======||NE||==================|===|NE| | 319 | +--+ | |+--+| |+--+| | +--+ | 320 +-----------+ +----+ +----+ +-----------+ 322 +--+ 323 |NE| = NSIS ==== = Signaling ---> = Data flow messages 324 +--+ Entity Messages (unidirectional) 326 Figure 1: Simple Signaling and Data Flows 328 3.1.2 Signaling to Hosts, Networks and Proxies 330 There are different possible triggers for the NSIS signaling. Amongst 331 them are signaling applications (that are using NSIS signaling 332 services), other instances of the signaling, network management 333 actions, some network events, and so on. The variety of possible 334 triggers requires that the signaling can be initiated and terminated 335 in the different parts of the network - hosts, domain boundary nodes 336 (edge nodes) or interior domain nodes. 338 NSIS extends the RSVP model to consider this wider variety of 339 possible signaling exchanges. As well as the basic end-to-end model 340 already described, examples such as end-to-edge and edge-to-edge can 341 be considered. The edge-to-edge case might involve the edge nodes 342 communicating directly, as well as via the interior nodes. 344 While end-to-edge (host-to-network) scenario requires only intra- 345 domain signaling, the other cases might need inter-domain NSIS 346 signaling as well if the signaling endpoints (hosts or network edges) 347 are connected to different domains. Depending on the trust relation 348 between concatenated NSIS domains the edge-to-edge scenario might 349 cover single domain or multiple concatenated NSIS domains. The latter 350 case assumes the existence of the trust relation between domains. 352 In some cases it is desired to be able to initiate and/or terminate 353 NSIS signaling not from the end host that sends/receives the data 354 flow, but from the some other entities on the network that can be 355 called signaling proxies. There could be various reasons for this: 356 signaling on behalf of the end hosts that are not NSIS-aware, 357 consolidation of the customer accounting (authentication, 358 authorization) in respect to consumed application and transport 359 resources, security considerations, limitation of the physical 360 connection between host and network and so on. This configuration can 361 be considered as a kind of "on the data path", see Figure 2. 363 Proxy1 Proxy2 364 +------+ +----+ +----+ +----+ +----+ +--------+ 365 |Sender|-...->|Appl|---->| R |-.->| R |--->|Appl|-...->|Receiver| 366 | | |+--+| |+--+| |+--+| +----+ | | 367 +------+ ||NE||=====||NE||=.==||NE||====||NE|| +--------+ 368 |+--+| |+--+| |+--+| |+--+| 369 +----+ +----+ +----+ +----+ 371 +--+ 372 |NE| = NSIS ==== = Signaling ---> = Data flow messages 373 +--+ Entity Messages (unidirectional) 375 Appl = signaling application 377 Figure 2: "On path" NSIS proxy 379 This configuration presents a set of specific challenges to the NSIS 380 signaling: 382 *) The proxy that terminates signaling on behalf of the NSIS-unaware 383 host (or part of the network) should be able to make determination 384 that it is a last NSIS aware node along the path. 385 *) Where a proxy initiates NSIS signaling on behalf of the NSIS 386 unaware host, interworking with some other "local" technology might 387 be required, for example to provide QoS reservation from proxy to the 388 end host in the case of QoS signaling application. 390 Another possible configuration, shown in Figure 3 is where an NE can 391 send and receive signaling information off path for and from remote 392 processing. The NSIS protocols may or may not be suitable for this 393 remote processing but in any case it is not currently part of the 394 NSIS problem. This configuration is supported by considering the NE 395 as a proxy at the signaling application level. This is a natural 396 implementation approach for some policy control and centralized 397 control architectures, see also section 6.1.5. 399 Receiver 400 +------+ +----+ +----+ +----+ +-----------+ 401 |Sender|----->| PA |----->| R2 |----->| R3 | ---->|Application| 402 | | |+--+| |+--+| +----+ | +--+ | 403 +------+ ||NE||======||NE||==================|===|NE| | 404 |+--+| |+--+| | +--+ | 405 +-..-+ +----+ +-----------+ 406 .. 407 .. 408 .. 409 .. 410 +-..-+ 411 |Appl| 412 +----+ 414 Appl = signaling PA = Proxy for signaling 415 application application 417 Figure 3: "Off path" NSIS proxy 419 3.1.3 Signaling Messages and Network Control State 421 The distinguishing features of the signaling supported by the NSIS 422 protocols are that it is related to specific flows (rather than to 423 network operation in general), and that it involves nodes in the 424 network (rather than running transparently between the end hosts). 426 Therefore, each signaling application (upper layer) protocol must 427 carry per-flow information for the aspects of network-internal 428 operation corresponding to that signaling application. An example for 429 the case of an RSVP-like QoS signaling application would be state 430 data representing resource reservations. However, more generally, the 431 per-flow information might be related to some other control function 432 in routers and middleboxes along the path. Indeed, the signaling 433 might simply be used to gather per-flow information, without 434 modifying network operation at all. 436 We call this information generically 'network control state'. 437 Signaling messages may install, modify, refresh, or simply read this 438 state from network elements for particular data flows. Usually a 439 network element will also manage this information at the per-flow 440 level, although coarser-grained state management is also possible. 442 3.1.4 Data Flows and Sessions 444 Formally, a data flow is a (unidirectional) sequence of packets 445 between the same endpoints which follow a unique path through the 446 network (determined by IP routing and other network layer 447 configuration). A flow is defined by a packet classifier (in the 448 simple cases, just the destination address and topological origin are 449 needed). In general we assume that when discussing only the data flow 450 path, we only need to consider 'simple' fixed classifiers (e.g. IPv4 451 5-tuple or equivalent). 453 A session is an application layer concept for a (unidirectional) flow 454 of information between two endpoints, for which some network state is 455 to be allocated or monitored. (Note that this use of the term 456 'session' is distinct from the usage in RSVP. It is closer to the 457 session concept of, for example, the Session Initiation Protocol.) 459 The simplest service provided by NSIS signaling is network control 460 state management at the flow level, as described in the previous 461 subsection. In particular, it is possible to monitor routing updates 462 as they change the path taken by a flow and, for example, update 463 network state appropriately. This is no different from the case for 464 RSVP (local path repair). Where there is a 1:1 flow:session 465 relationship, this is all that is required. 467 However, for some more complex scenarios (especially mobility-related 468 ones, see [3] and [8]) it is desirable to update the flow:session 469 relationship during the session lifetime. For example, a new flow can 470 be added, and the old one deleted (and maybe in that order, for a 471 'make-before-break' handover), effectively transferring the network 472 control state between data flows to keep it associated with the same 473 session. Such updates can only be managed by the end systems (because 474 of the packet classifier change). To enable this, it must be possible 475 for end systems to relate signaling messages to sessions as well as 476 data flows. 478 3.2 Layer Model for the Protocol Suite 480 3.2.1 Layer Model Overview 482 In order to achieve a modular solution for the NSIS requirements, it 483 is proposed to structure the NSIS protocol suite into 2 layers, 484 similar to the original proposal in [9]: 485 *) a 'signaling transport' layer, responsible for moving signaling 486 messages around, which should be independent of any particular 487 signaling application; and 488 *) a 'signaling application' layer, which contains functionality 489 such as message formats and sequences, specific to a particular 490 signaling application. 492 For the purpose of this document, we use the term 'NSIS Transport 493 Layer Protocol' (NTLP) to refer to the component that will be used in 494 the transport layer. We also use the term 'NSIS Signaling Layer 495 Protocol' (NSLP) to refer generically to any protocol component 496 within the signaling application layer; in the end, there will be 497 several NSLPs. These relationships are illustrated in Figure 4. Note 498 that the NTLP may or may not have an interesting internal structure 499 (e.g. based on the use of existing transport protocols) but that is 500 not relevant at this level. 502 ^ +-----------------+ 503 | | NSIS Signaling | 504 | | Layer Protocol | 505 NSIS | +----------------| for middleboxes | 506 Signaling | | NSIS Signaling | +-----------------+ 507 Layer | | Layer Protocol +--------| NSIS Signaling | 508 | | for QoS | | Layer Protocol | 509 | | | | for something | 510 | +-----------------+ | else | 511 V +-----------------+ 512 ============================================= 513 ^ +--------------------------------+ 514 NSIS | | | 515 Transport | | NSIS Transport Layer Protocol | 516 Layer | | | 517 V +--------------------------------+ 518 ============================================= 519 +--------------------------------+ 520 | | 521 . IP and lower layers . 522 . . 524 Figure 4: NSIS Protocol Components 526 Note that not every generic function has to be located in the NTLP. 527 Another option would be to have re-usable components within the 528 signaling application layer. Functionality within the NTLP should be 529 restricted to that which interacts strongly with other transport and 530 lower layer operations. 532 Because NSIS problem includes multiple signaling applications, it is 533 very likely that a particular NSLP will only be implemented on a 534 subset of the NSIS-aware nodes on a path, as shown in Figure 5. 535 Messages for unrecognized NSLPs are forwarded at the NTLP level. 537 +------+ +------+ +------+ +------+ 538 | NE | | NE | | NE | | NE | 539 |+----+| | | |+----+| |+----+| 540 ||NSLP|| | | ||NSLP|| ||NSLP|| 541 || || | | || || || || 542 || 1 || | | || 2 || || 1 || 543 |+----+| | | |+----+| |+----+| 544 | || | | | | | | || | 545 |+----+| |+----+| |+----+| |+----+| 546 ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== 547 |+----+| |+----+| |+----+| |+----+| 548 +------+ +------+ +------+ +------+ 550 Figure 5: Signaling with Heterogeneous NSLPs 552 3.2.2 Layer Split Concept 554 This section describes the basic concepts which underlie how the 555 necessary functionality within the NTLP can be determined. Firstly, 556 we make a working assumption that the protocol mechanisms of the NTLP 557 operate only between adjacent NEs (informally, the NTLP is a 'hop-by- 558 hop' protocol), whereas any larger scope issues (including e2e 559 aspects) are left to the upper layers. 561 The way in which the NTLP works can be described as follows: When a 562 signaling message is ready to be sent from one NE, it is given to the 563 NTLP along with information about what flow it is for; it is then up 564 to the NTLP to get it to the next NE along the path (up- or down- 565 stream), where it is received and the responsibility of the NTLP 566 ends. Note that there is no assumption here about how the messages 567 are actually addressed (this is a protocol design issue, and the 568 options are outlined in section 4.2). The key point is that the NTLP 569 for a given NE does not use any knowledge about addresses, 570 capabilities, or status of any NEs other than its direct peers. 572 The NTLP in the receiving NE either forwards the message directly, 573 or, if there is an appropriate signaling application locally, passes 574 it upwards for further processing; the signaling application can then 575 generate another message to be sent via the NTLP. In this way, larger 576 scope (including end-to-end) message delivery can be automatically 577 achieved. 579 This definition relates to NTLP operation. It is not intended to 580 restrict the ability of an NSLP to send messages by other means. For 581 example, an NE in the middle or end of the signaling path could send 582 a message directly to the other end as a notification of or 583 acknowledgement for some signaling application event. However, it 584 appears that the issues in sending such messages (endpoint discovery, 585 security, NAT traversal and so on) are so different from the direct 586 peer-peer case that there is no benefit in extending the scope of the 587 NTLP to include such non-local functionality; instead, an NSLP which 588 requires such messages and wants to avoid traversing the path of NEs 589 should use some other existing transport protocol - for example, UDP 590 would be a good match for many of the scenarios that have been 591 proposed. Acknowledgements and notifications of this type are 592 considered further in section 3.3.5. 594 One motivation for restricting the NTLP to only peer-relationship 595 scope is that if there are any options or variants in design approach 596 - or, worse, in basic functionality - it is easier to manage the 597 resulting complexity if it only impacts direct peers rather than 598 potentially the whole network. 600 3.2.3 Core NTLP Functionality 602 This section describes the basic functionality to be supported by the 603 NTLP. Note that the analysis has to be based on considering NSLP and 604 NTLP operation jointly; for example, we can always assume that an 605 NSLP is operating above the NTLP and taking care of end-to-end issues 606 (e.g. recovery of messages after restarts and so on). 608 Therefore, NTLP functionality is essentially just efficient upstream 609 and downstream peer-peer message delivery in a wide variety of 610 network scenarios. Message delivery includes the act of locating 611 and/or selecting which NTLP peer to carry out signaling exchanges 612 with for a specific data flow. This discovery might be an active 613 process (using specific signaling packets) or a passive process (a 614 side effect of using a particular addressing mode). In addition, it 615 appears that the NTLP can sensibly carry out most of the functions of 616 enabling signaling messages to pass through middleboxes, since this 617 is closely related to the problem of routing the signaling messages 618 in the first place. 620 Two major open issues remain about NTLP functionality, namely what 621 classical transport capabilities (congestion avoidance, 622 retransmission and so on) it should have, or whether these functions 623 can be left entirely to the upper layers; and to what extent the NTLP 624 should provide a common state management service to the signaling 625 applications. These questions are discussed in section 3.4. 627 3.2.4 Path De-Coupled Operation 629 Path-decoupled signaling is defined as signaling for state 630 installation along the data path, without the restriction of passing 631 only through nodes (NEs) that are located on the data path. Signaling 632 messages can be routed to NEs off the data path, but which are 633 (presumably) aware of it. This allows a looser coupling between NEs 634 and data plane nodes, e.g. at the AS level. 636 The main advantages of path-decoupled signaling are ease of 637 deployment and support of additional functionality. The ease of 638 deployment comes from a restriction of the number of impacted nodes 639 in case of deployment and/or upgrade of an NSLP. It would allow, for 640 instance, deploying a solution without upgrading any of the routers 641 in the data plane. Additional functionality that can be supported 642 includes the use of off-path proxies to support authorization or 643 accounting architectures. 645 There are potentially significant differences in the way that the two 646 signaling paradigms should be analyzed. Using a single centralized 647 off-path NE may increase the requirements in terms of message 648 handling. This effect, however, is orthogonal to the NSIS charter, 649 since path-decoupled signaling is equally applicable to distributed 650 off-path entities. Failure recovery scenarios need to be analyzed 651 differently because fate-sharing between data and control plane can 652 no longer be assumed. Furthermore, the interpretation of 653 sender/receiver orientation becomes less obvious. With the local 654 operation of NTLP, the impact of path-decoupled signaling on the 655 routing of signaling messages is presumably restricted to the problem 656 of peer determination. The assumption that the off-path NEs are 657 loosely tied to the data path suggests, however, that peer 658 determination can still be based on L3 routing information. 660 3.3 Signaling Application Properties 662 It is clear that many signaling applications will require specific 663 protocol behavior in their NSLP. This section outlines some of the 664 options for NSLP behavior; further work on selecting from these 665 options would depend on detailed analysis of the application in 666 question. 668 3.3.1 Sender/Receiver Orientation 670 In some signaling applications, one end of the data flow takes 671 responsibility for requesting special treatment - such as a resource 672 reservation - from the network. The appropriate end may depend on the 673 signaling application, or characteristics of the network deployment. 675 A sender-initiated approach is when the sender of the data flow 676 requests and maintains the resource reservation used for that flow. 677 In a receiver-initiated approach the receiver of the data flow 678 requests and maintains the resource reservation used for that flow. 679 The NTLP has no freedom in this area: next peers have to be 680 discovered in the sender to receiver direction, but after that time 681 the default assumption is that signaling is possible both upstream 682 and downstream (unless possibly an application specifically indicates 683 this is not required). This implies that backward routing state must 684 be maintained or that backward routing information must be available 685 in the signaling packet. 687 The sender and receiver initiated approaches have several differences 688 in operational characteristics. The main ones are as follows: 690 *) In a receiver-initiated approach, the signaling messages traveling 691 from the receiver to the sender must be backward routed such that 692 they follow exactly the same path as was followed by the signaling 693 messages belonging to the same flow traveling from the sender to the 694 receiver. This implies that a backward routing state per flow must be 695 maintained. When using a sender-initiated approach, provided 696 acknowledgements and notifications can be securely delivered to the 697 sending node, backward routing is not necessary, and nodes do not 698 have to maintain backward routing states. 699 *) In a sender-initiated approach, a mobile node can initiate a 700 reservation for its outgoing flows as soon as it has moved to another 701 roaming subnetwork. In a receiver-initiated approach, a mobile node 702 has to inform the receiver about its handover procedure, thus 703 allowing the receiver to initiate a reservation for these flows. For 704 incoming flows, the reverse argument applies. 705 *) A sender- (receiver-) initiated approach will allow faster setup 706 and modification if the sender (receiver) is also authorized to carry 707 out the operation. A mismatch between authorizing and initiating NEs 708 will cause additional message exchanges either in the NSLP or in a 709 protocol executed prior to NSIS invocation. Note that this may 710 complicate modifications of network control state for existing flows. 711 *) Where the signaling is looking for the last (nearest to receiver) 712 NE on the data path, receiver oriented signaling is most efficient; 713 sender orientation would be possible, but take more messages. 714 *) In either case, the initiator can generally be informed faster 715 about reservation failures than the remote end. 717 3.3.2 Uni- and Bi-Directional Operation 719 For some signaling applications and scenarios, signaling may only be 720 considered for one direction of the data flow. However, in other 721 cases, there may be interesting relationships between the signaling 722 for the two directions; an example is QoS for a voice call. In the 723 basic case, bi-directional signaling can simply use a separate 724 instance of the same signaling mechanism in each direction. Note that 725 the path in the two directions may differ due to asymmetric routing. 727 In constrained topologies where parts of the route are symmetric, it 728 may be possible to use a more unified approach to bi-directional 729 signaling, e.g. carrying the two signaling directions in common 730 messages. This optimization might be used for example to make mobile 731 QoS signaling more efficient. 733 In either case, the correlation of the signaling for the two flow 734 directions is carried out in the NSLP. The NTLP would simply be 735 enabled to bundle the messages together. 737 3.3.3 Heterogeneous Operation 739 It is likely that the appropriate way to describe the state NSIS is 740 signaling for will vary from one part of the network to another 741 (depending on signaling application). For example in the QoS case, 742 resource descriptions that are valid for inter-domain links will 743 probably be different from those useful for intra-domain operation 744 (and the latter will differ from one NSIS domain to another). 746 One way to address this issue is to consider the state description 747 carried within the NSLP as divided in globally-understood objects 748 ("global objects") and locally-understood objects ("local objects"). 749 The local objects are only applicable for intra-domain signaling, 750 while the global objects are mainly used in inter-domain signaling. 751 Note that such local objects are still part of the NSIS protocol and 752 can be inserted, used and removed by one single domain. 754 The purpose of this division is to provide additional flexibility in 755 defining the objects carried by the NSLP such that only those objects 756 that are applicable in a particular setting are used. An example 757 approach for reflecting the distinction in the signaling is that 758 local objects could be put into separate local messages that are 759 initiated and terminated within one single NSIS domain and/or they 760 could be "stacked" within the NSLP messages that are used for inter- 761 domain signaling. 763 3.3.4 Peer-Peer and End-End Relationships 765 The assumption taken in this framework is that the NTLP will operate 766 'locally', that is, just over the scope of a single peer 767 relationship. End-to-end operation is built up by simply 768 concatenating these relationships. Any non-local operation (if any) 769 will take place only in particular NSLPs. 771 The peering relations may also have an impact on the required amount 772 of state at each NSIS entity. When direct interaction with remote 773 peers is not allowed, it may be required to keep track of the path 774 that a message has followed through the network. This can be achieved 775 by keeping per-flow state at the NSIS entities or by maintaining a 776 record route object in the messages. 778 Note that, for the reasons discussed in section 3.2.1, NSLP peers are 779 not inevitably NTLP peers. This has a number of implications for the 780 relationship between the signaling layers, in that NSLP peers may 781 depend on the service provided by a concatenation of NTLP peer 782 relationships rather than a single one, which makes it harder to 783 exploit fully some NTLP properties (e.g. channel security, 784 reliability). 786 3.3.5 Acknowledgements and Notifications 788 We are assuming that the NTLP provides a simple message transfer 789 service, and any acknowledgements or notifications it generates are 790 handled purely internally (and apply within the scope of a single 791 peer relationship). 793 However, we expect that some signaling applications will requires 794 acknowledgements regarding the failure/success of state installation 795 along the data path, and this will be an NSLP function. 797 Acknowledgements can be sent along the sequence of NTLP peer 798 relationships towards the signaling initiator, which relieves the 799 requirements on the security associations that need to be maintained 800 by NEs and can ensure NAT traversal in both directions. (If this 801 direction is towards the flow sender, it implies maintaining reverse 802 routing state in the NTLP). In certain circumstances (e.g. trusted 803 domains), an optimization can be made by sending acknowledgements 804 directly to the signaling initiator (see section 3.2.2). 806 The semantics of the acknowledgement messages are of particular 807 importance. An NE sending a message could assume responsibility for 808 the entire downstream chain of NEs, indicating for instance the 809 availability of reserved resources for the entire downstream path. 810 Alternatively, the message could have a more local meaning, 811 indicating for instance that a certain failure or degradation 812 occurred at a particular point in the network. 814 Notifications differ from acknowledgements because they are not 815 (necessarily) generated in response to other signaling messages. This 816 means that it may not be obvious to determine where the notification 817 should be sent. Other than that, the same considerations apply as for 818 acknowledgements. One useful distinction to make would be to 819 differentiate between notifications that trigger a signaling action 820 and others that don't. The security requirements for the latter are 821 less stringent, which means they could be sent directly to the NE 822 they are destined for (provided this NE can be determined). 824 3.3.6 Security and other AAA Issues 826 In some cases it will be possible to achieve the necessary level of 827 signaling security by using basic 'channel security' mechanisms [10] 828 at the level of the NTLP, and the possibilities are described in 829 section 4.6. In other cases, signaling applications may have specific 830 security requirements, in which case they are free to invoke their 831 own authentication and key exchange mechanisms and apply 'object 832 security' to specific fields within the NSLP messages. 834 In addition to authentication, authorisation (to manipulate network 835 control state) has to be considered as functionality above the NTLP 836 level, since it will be entirely application specific. Indeed, 837 authorisation decisions may be handed off to a third party in the 838 protocol (e.g. for QoS, the resource management function as described 839 in section 6.1.5). Many different authorisation models are possible, 840 and the variations impact 841 *) what message flows take place - for example, whether authorisation 842 information is carried along with a control state modification 843 request, or is sent in the reverse direction in response to it; 844 *) what administrative relationships are required - for example, 845 whether authorisation takes place only between peer signaling 846 applications, or over longer distances. 848 Because the NTLP operates only between adjacent peers, and places no 849 constraints on the direction or order in which signaling applications 850 can send messages, these authorisation aspects are left open to be 851 defined by each NSLP. Further background discussion of this issue is 852 contained in [11]. 854 3.4 Open Layer Model Issues 856 3.4.1 Classical Transport Functionality 858 The first major issue is the extent to which the NTLP should include 859 'traditional' transport like functions, or whether these should be 860 seen as either fundamentally unnecessary or automatically handled by 861 the upper layers. The following functions have been identified as 862 candidates: 864 1. Local retransmission to improve reliability. The argument in favor 865 is that the NTLP can recover from congestive loss or corruption much 866 more rapidly than end-to-end (NSLP) mechanisms; the argument against 867 is that the additional complexity in the NTLP is not needed for all 868 signaling applications. (It's assumed that the NTLP is not actually 869 providing perfect message delivery guarantees or notifications, for 870 example because NSLP peers may be separated by more than one NTLP 871 peer relationship. A signaling application that needs peer-peer 872 acknowledgements of this nature should define them within the NSLP.) 873 In-order message delivery and duplicate detection are related 874 functions. 876 2. Congestion control. Here, the question is whether the NTLP should 877 include a common mechanism which protects the local portion of the 878 network from overload, or whether this can be derived from the 879 behavior of each signaling application. 881 3. Message fragmentation. For NSLPs that generate large messages, it 882 will be necessary to fragment and re-assemble them efficiently within 883 the network, where the use IP fragmentation may lead to reduced 884 reliability and be incompatible with some addressing schemes. (It's 885 assumed that the counterpart functionality, of bundling small 886 messages together, can be provided locally by the NTLP as an option 887 if desired; it doesn't affect the operation of the network 888 elsewhere.) 890 4. Flow control. Here, the question is how a receiving NSLP should be 891 protected from overload - whether the NTLP should provide a flow 892 controlled channel, or whether this should be managed using 893 application layer acknowledgements, for example. 895 It appears that all these issues don't affect the basic way in which 896 the NSLP/NTLP layers relate to each other (e.g. in terms of the 897 semantics of the inter-layer interaction); it is much more a question 898 of the overall performance/complexity tradeoff implied by placing 899 certain functions within each layer. 901 3.4.2 State Management 903 It is clear that the NTLP may have to manage some per-flow state to 904 carry out its message delivery functions (for example, state about 905 the reverse route for signaling messages, or state needed for route 906 change detection). How this state is stored and managed is an 907 internal matter for the NTLP (see section 4), and the details (in 908 particular, any connection model it might use) is in any case 909 entirely invisible to the signaling applications. 911 However, signaling applications are frequently managing network 912 control state for their own purposes, and it is an open issue how 913 much the NTLP should provide a common service to do this for them. 915 The simplest case is that the NTLP simply delivers messages, and any 916 state-related aspects (lifetimes, message semantics and so on) are 917 entirely invisible to it, being part of the signaling application 918 data. This provides the simplest interface between NTLP and NSLP. 920 The other extreme is where the NTLP provides a complete state 921 management service, including explicit commands for creation, 922 modification and deletion of state with known lifetimes in remote 923 nodes. This service could make it easy to write new signaling 924 applications, at the cost of increasing the complexity of the 925 NTLP/NSLP interface; in particular, there would be many more events 926 and error conditions to generate within the NTLP, and there may be 927 several different types of state management semantics required by 928 different signaling applications. The commonality with other parts of 929 NTLP functionality is not clear. 931 An intermediate case is where there is particular support for the 932 refresh messages used for soft-state maintenance. The characteristics 933 of these messages are that they can be sent and processed without 934 invoking signaling application specific logic, and that their timing 935 can be manipulated to fit in with other NTLP requirements (e.g. 936 jittering to avoid network synchronization, or to allow bundling with 937 other messages). Therefore, provided this functionality can be 938 defined simply and universally, there may be benefits in supporting 939 it within the NTLP itself. The implication would be that some NTLP 940 messages contain timing and other control information (to allow the 941 refresh to be handled correctly at intermediate NSLP-unaware nodes). 942 In addition, the automatic generation and reception of refreshes 943 could be handled above or below the NSLP/NTLP boundary (this seems to 944 be mainly an API issue). 946 4. The NSIS Transport Layer Protocol 948 This section describes the overall functionality required from the 949 NTLP. It mentions possible protocol components within the NTLP layer 950 and the different possible addressing modes that can be utilized. 951 The interfaces between NTLP and the layers above and below it are 952 identified, with a description of the identity elements that appear 953 on these interfaces. 955 It is not the intention of this discussion to design the NTLP or even 956 to discuss design options, although some are described as examples. 957 The goal is to provide a general discussion of required functionality 958 and to highlight some of the issues associated with this. 960 4.1 Internal Protocol Components 962 The NTLP includes all functionality below the signaling application 963 layer and above the IP layer. The functionality that is required 964 within the NTLP is described in section 3.2. 966 Some NTLP functionality could be provided via components existing as 967 sublayers within the NTLP design. For example, if specific transport 968 capabilities are required, such as congestion avoidance, 969 retransmission, security and so on, then existing protocols, such as 970 TCP or TLS, could be incorporated into the NTLP. This possibility is 971 not required or excluded by this framework. 973 ==================== =========================== 974 ^ +------------------+ +-------------------------+ 975 | | | | NSIS Specific Functions | 976 | | | | .............| 977 NSIS | | Monolithic | |+----------+. Peer .| 978 Transport | | Protocol | || Existing |. Discovery .| 979 Layer | | | || Protocol |. Aspects .| 980 | | | |+----------+.............| 981 V +------------------+ +-------------------------+ 982 ==================== =========================== 984 Figure 6: Options for NTLP Structure 986 If peer-peer addressing (section 4.2) is used for some messages, then 987 active next-peer discovery functionality will be required within the 988 NTLP to support the explicit addressing of these messages. (This 989 could use message exchanges for dynamic peer discovery as a sublayer 990 within the NTLP; there could also be an interface to external 991 mechanisms to carry out this function.) 993 4.2 Addressing 995 There are two ways to address a signaling message being transmitted 996 between NSIS peers: 997 *) peer-peer, where the message is addressed to a neighboring NSIS 998 entity that is known to be closer to the destination NE. 999 *) end-to-end, where the message is addressed to the destination 1000 directly, and intercepted by an intervening NE. 1002 With peer-peer addressing, an NE will determine that address of the 1003 next NE based on the payload of the message (and potentially on the 1004 previous NE). This requires the address of the destination NE to be 1005 derivable from the information present in the payload. This can be 1006 achieved through the availability of a local routing table or through 1007 participation in active peer discovery message exchanges. Peer-peer 1008 addressing inherently supports tunneling of messages between NEs, and 1009 is equally applicable to the path-coupled and path-decoupled cases. 1011 In the case of end-to-end addressing, the message is addressed to the 1012 data flow receiver, and (some of) the NEs along the data path 1013 intercept the messages. The routing of the messages should follow 1014 exactly the same path as the associated data flow (but see section 1015 5.1.1 on this point). Note that securing messages sent this way 1016 raises some interesting security issues (these are discussed in 1017 [12]). 1019 It is not possible at this stage to mandate one addressing mode or 1020 the other. Indeed, each is necessary for some aspects of NTLP 1021 operation: in particular, initial discovery of the next downstream 1022 peer will usually require end-to-end addressing, whereas reverse 1023 routing will always require peer-peer addressing. For other message 1024 types, the choice is a matter of protocol design. The mode used is 1025 not visible to the NSLP, and the information needed in each case is 1026 available from the flow identifier (section 4.5.1) or locally stored 1027 NTLP state. 1029 4.3 Lower Layer Interfaces 1031 The NTLP interacts with 'lower layers' of the protocol stack for the 1032 purposes of sending and receiving signaling messages. This framework 1033 places the lower boundary of the NTLP at the IP layer. The interface 1034 to the lower layer is therefore very simple: 1035 *) The NTLP sends raw IP packets 1036 *) The NTLP receives raw IP packets. In the case of peer-peer 1037 addressing, they have been addressed directly to it. In the case of 1038 end-to-end addressing, this will be achieved by intercepting packets 1039 that have been marked in some special way (by special protocol number 1040 or by some option interpreted within the IP layer, such as the Router 1041 Alert option [13] and [14]). 1042 *) The NTLP receives indications from the IP layer regarding route 1043 changes and similar events (see section 5.1). 1045 For correct message routing, the NTLP needs to have some information 1046 about link and IP layer configuration of the local networking stack. 1047 For example, it needs to know: 1048 *) [in general] how to select the outgoing interface for a signaling 1049 message, in case this needs to match the interface that will be used 1050 by the corresponding flow. This might be as simple as just allowing 1051 the IP layer to handle the message using its own routing table. There 1052 is no intention to do something different from IP routing (for end- 1053 to-end addressed messages); however, some hosts allow applications to 1054 bypass routing for their data flows, and the NTLP processing must 1055 account for this. 1056 *) [in the case of IPv6] what address scopes are associated with the 1057 interface that messages are sent and received on (to interpret scoped 1058 addresses in flow identification, if these are to be allowed). 1060 Configuration of lower layer operation to handle flows in particular 1061 ways is handled by the signaling application. 1063 4.4 Upper Layer Services 1065 The NTLP offers transport layer services to higher layer signaling 1066 applications for two purposes: sending and receiving signaling 1067 messages, and exchanging control and feedback information. 1069 For sending and receiving messages, two basic control primitives are 1070 required: 1071 *) Send Message, to allow the signaling application to pass data to 1072 the NTLP for transport. 1073 *) Receive Message, to allow the NTLP to pass received data to the 1074 signaling application. 1076 The NTLP and signaling application may also want to exchange other 1077 control information, such as: 1078 *) Signaling application registration/de-registration, so that 1079 particular signaling application instances can register their 1080 presence with the transport layer. This may also require some 1081 identifier to be agreed between the NTLP and signaling application to 1082 allow support the exchange of further control information and to 1083 allow the de-multiplexing of incoming data. 1084 *) NTLP configuration, allowing signaling applications to indicate 1085 what optional NTLP features they want to use, and to configure NTLP 1086 operation, such as controlling what transport layer state should be 1087 maintained. 1089 *) Error messages, to allow the NTLP to indicate error conditions to 1090 the signaling application and vice versa. 1091 *) Feedback information, such as route change indications so that 1092 the signaling application can decide what action to take. 1094 The exact form of the primitives used across this interface and the 1095 information exchanged by them depends on a decision about what the 1096 responsibility of the layers is either side of the interface, and 1097 where state is managed (see section 3.4.2). 1099 4.5 Identity Elements 1101 4.5.1 Flow Identification 1103 The flow identification is a method of identifying a flow in a unique 1104 way. All packets associated with the same flow will be identified by 1105 the same flow identifier. The key aspect of the flow identifier is 1106 to provide enough information such that the signaling flow receives 1107 the same treatment along the data path as that actual data itself, 1108 i.e. consistent behavior is applied to the signaling and data flows 1109 by a NAT or policy-based forwarding engine. 1111 Information that could be used in flow identification may include: 1112 *) source IP address; 1113 *) destination IP address; 1114 *) protocol identifier and higher layer (port) addressing; 1115 *) flow label (typical for IPv6); 1116 *) SPI field for IPSec encapsulated data; 1117 *) DSCP/TOS field 1118 It is assumed that wildcarding on these identifiers is not needed 1119 (further analysis may be required). 1121 We've assumed here that the flow identification is not hidden within 1122 the NSLP, but is explicitly part of the NTLP. The justification for 1123 this is that it might be valuable to be able to do NSIS processing 1124 even at a node which was unaware of the specific signaling 1125 application (see section 3.2.1): an example scenario would be 1126 messages passing through an addressing boundary where the flow 1127 identification had to be re-written. 1129 4.5.2 Session Identification 1131 There are circumstances where it is important to be able to refer to 1132 signaling application state independently of the underlying flow. 1133 For example, if the address of one of the flow endpoints changes due 1134 to a mobility event, it is desirable to be able to change the flow 1135 identifier without having to install a completely new reservation. 1137 The session identifier provides a method to correlate the signaling 1138 about the different flows with the same network control state. 1140 The session identifier is essentially a signaling application 1141 concept, since it is only used in non-trivial state management 1142 actions that are application specific. However, we assume here that 1143 it should be visible within the NTLP. This enables it to be used to 1144 control NTLP behavior, for example, by controlling how the transport 1145 layer should forward packets belonging to this session (as opposed to 1146 this signaling application). In addition, the session identifier can 1147 be used by the NTLP to demultiplex received signaling messages 1148 between multiple instances of the same signaling application, if such 1149 an operational scenario is supported (see section 4.5.3 for more 1150 information on signaling application identification). 1152 To be useful for mobility support, the session identifier should be 1153 globally unique, and it should not be modified end-to-end. It is well 1154 known that it is practically impossible to generate identifiers in a 1155 way which guarantees this property; however, using a large random 1156 number makes it highly likely. In any case, the NTLP ascribes no 1157 valuable semantics to the identifier (such as 'session ownership'); 1158 this problem is left to the signaling application, which may be able 1159 to secure it to use for this purpose. 1161 4.5.3 Signaling Application Identification 1163 Since the NTLP can be used to support several NSLP types, there is a 1164 need to identify which type a particular signaling message exchange 1165 is being used for. This is to support: 1166 *) processing of incoming messages - the NTLP should be able to 1167 demultiplex these towards the appropriate signaling applications; 1168 *) processing of general messages at an NSIS aware intermediate node 1169 - if the node does not handle the specific signaling application, it 1170 should be able to make a forwarding decision without having to parse 1171 upper layer information. 1173 No position is taken on the form of the signaling application 1174 identifier, or even the structure of the signaling application 1175 'space' - free-standing applications, potentially overlapping groups 1176 of capabilities, etc. These details should not influence the rest of 1177 NTLP design. 1179 4.6 Security Properties 1181 It is assumed that the only security service required within NTLP is 1182 channel security. Channel security requires a security association to 1183 be established between the signaling endpoints, which is carried out 1184 via some authentication and key management exchange. This 1185 functionality could be provided by reusing a standard protocol. 1187 In order to protect a particular signaling exchange, the NSIS entity 1188 needs to select the security association that it has in place with 1189 the next NSIS entity that will be receiving the signaling message. 1190 The ease of doing this depends on the addressing model in use by the 1191 NTLP (see section 4.2). 1193 Channel security can provide many different types of protection to 1194 signaling exchanges, including integrity and replay protection and 1195 encryption. It is not clear which of these is required at the NTLP 1196 layer, although most channel security mechanisms support them all. 1198 Channel security can also be applied to the signaling messages with 1199 differing granularity, i.e. all or parts of the signaling message may 1200 be protected. For example, if the flow is traversing a NAT, only the 1201 parts of the message that do not need to be processed by the NAT 1202 should be protected. It is an open question as to which parts of the 1203 NTLP messages need protecting, and what type of protection should be 1204 applied to each. 1206 5. Interactions with Other Protocols 1208 5.1 IP Routing Interactions 1210 The NSIS Transport Layer (NTLP) is responsible for discovering the 1211 next node to be visited by the signaling protocol. For path-coupled 1212 signaling, this next node should be the one that will be visited by 1213 the data flow. In practice, this peer discovery will be approximate, 1214 as any node could use any feature of the peer discovery packet to 1215 route it differently than the corresponding data flow packets. 1216 Divergence between data and signaling path can occur due to load 1217 sharing or load balancing (section 5.1.1). An example specific to the 1218 case of QoS is given in section 6.1.1. Route changes cause a 1219 temporary divergence between the data path and the path on which 1220 signaling state has been installed. The occurrence, detection and 1221 impact of route changes is described in section 5.1.2. A description 1222 of this issue in the context of QoS is given in section 6.1.2. 1224 5.1.1 Load Sharing and Policy-Based Forwarding 1226 Load sharing or load balancing is a network optimization technique 1227 that exploits the existence of multiple paths to the same destination 1228 in order to obtain benefits in terms of protection, resource 1229 efficiency or network stability. The significance of load sharing in 1230 the context of NSIS is that, if the load sharing mechanism in use 1231 will forward packets on any basis other than the destination address, 1232 routing of messages using end-to-end addressing does not guarantee 1233 that the messages will follow the data path. Policy-based forwarding 1234 for data packets - where the outgoing link is selected based on 1235 policy information about fields additional to the packet destination 1236 address - has the same impact. 1238 Signaling and data flow packets may diverge because of these 1239 techniques. In OSPF, load balancing can be used between equal cost 1240 paths [15] or unequal cost paths. An example of the latter approach 1241 is Optimized Multi Path (OMP). OMP discovers multiple paths, not 1242 necessarily equal cost paths, to any destinations in the network, but 1243 based on the load reported from a particular path, it determines 1244 which fraction of the data to direct to the given path. Incoming 1245 packets are subject to a (source, destination address) hash 1246 computation, and effective load sharing is accomplished by means of 1247 adjusting the hash thresholds. BGP [16][17] advertises the routes 1248 chosen by the BGP decision process to other BGP speakers. In the 1249 basic specification, routes with the same Network Layer reachability 1250 information (NLRI) as previously advertised routes implicitly replace 1251 the original advertisement, which means that multiple paths for the 1252 same prefix cannot exist. Recently, however, a new mechanism was 1253 defined that will allow the advertisement of multiple paths for the 1254 same prefix without the new paths implicitly replacing any previous 1255 ones [18]. The essence of the mechanism is that each path is 1256 identified by an arbitrary identifier in addition to its prefix. 1258 If the routing decision is based on both source and destination 1259 address, signaling and data flow packets may still diverge because of 1260 layer 4 load-balancing (based on TCP/UDP or port-based). Such 1261 techniques would, however, constrain the use of proxies. Proxies 1262 would cause ICMP errors to be misdirected to the source of the data 1263 because of source address spoofing. 1265 If the routing decision is based on the complete five-tuple, 1266 divergence may still occur because of the presence of router alert 1267 options. In this case, the same constraint on proxy use applies as 1268 above. Additionally, it becomes difficult for the end systems to 1269 distinguish between data and signaling packets. Finally, QoS routing 1270 techniques (section 6.1.3) may base the routing decision on any field 1271 in the packet header (e.g. DSCP, ...). 1273 Most load-balancing techniques use the first n bytes of the packet 1274 header (including SA, DA and protocol field) in the hashing function. 1275 In this case, the above considerations regarding source/destination 1276 address or five-tuple based forwarding apply. 1278 5.1.2 Route Changes 1280 In a routed network, each packet is independently routed based on its 1281 header information. Whenever a better route towards the destination 1282 becomes available, this route is installed in the forwarding table 1283 and will be used for all subsequent (data and signaling) packets. 1284 This can cause a divergence between the path along which state has 1285 been installed and the path along which forwarding will actually take 1286 place. 1288 The possibility of route changes requires the presence of three 1289 processes in the signaling protocol 1290 1. route change detection 1291 2. installation of state on the new path 1292 3. teardown of state on the old path 1294 Many route change detections methods can be used, some of which need 1295 explicit protocol support and some of which are implementation- 1296 internal. They differ in their speed of reaction and the types of 1297 change they can detect. In rough order of increasing applicability, 1298 they can be summarized as: 1299 a) monitoring changes in local interface state 1300 b) monitoring network-wide topology changes in a link-state routing 1301 protocol 1302 c) inference from changes in data packet TTL 1303 d) inference from loss of packet stream in a downstream flow-aware 1304 router 1305 e) inference from changes in signalling packet TTL 1306 f) changed route of a PATH-like (end-to-end addressed) signaling 1307 packet 1308 g) changed route of a specific end-to-end addressed probe packet 1310 There are essentially three ways in which detection can happen: based 1311 on network monitoring (method a-b), based on data packet monitoring 1312 (method c-d) and based on monitoring signaling protocol messages 1313 (method e-g). Methods contingent on monitoring signaling messages 1314 become less effective as refresh reduction techniques are used. 1316 When a route change has been detected, it is important that state is 1317 installed as quickly as possible along the new path. It is not 1318 guaranteed that the new path will be able to provide the same 1319 characteristics that were available on the old path. In order to be 1320 able to avoid duplicate state installation or, worse, rejection of 1321 the signaling message because of previously installed state, it is 1322 important to be able to recognize the new signaling message as 1323 belonging to an existing session. In this respect, we distinguish 1324 between route changes with associated change of the flow 1325 specification (e.g. in case of a mobility event when the IP source 1326 might change) and route changes without change of the flow 1327 specification (e.g. in case of a link failure along the path). The 1328 former case requires an identifier independent from the flow 1329 specification. 1331 When state has been installed along the new path, the existing state 1332 on the old path needs to be removed. With the soft-state principle, 1333 this will happen automatically because of the lack of refresh 1334 messages. Depending on the refresh timer, however, it may be required 1335 to tear down this state much faster (e.g. because it is tied to an 1336 accounting record). In that case, the teardown message needs to be 1337 able to distinguish between the new path and the old path. 1339 The problem of route changes would not occur if there was a way to do 1340 route pinning. Route pinning refers to the independence of the path 1341 taken by certain data packets from reachability changes caused by 1342 routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an 1343 Exterior Gateway Protocol (BGP). 1345 5.1.3 Router Redundancy 1347 In some environments, it is desired to provide connectivity and per 1348 flow or per class flow management with high-availability 1349 characteristics, i.e. with rapid transparent recovery even in the 1350 presence of route changes. This may involve interactions with the 1351 basic protocols which are used to manage the routing in this case, 1352 such as VRRP [19]. A future version of this document may consider 1353 interactions between NSIS and such protocols in support of high 1354 availability functionality. 1356 5.2 Mobility Interactions 1358 Mobility, in most cases, causes changes to the data path that packets 1359 take. Assuming that signaling has taken place prior to any mobility 1360 to establish some state along the data path, new signaling may be 1361 needed in order to (re)establish state along the changed data path. 1363 The interactions between mobility and signaling protocols have been 1364 extensively analyzed in recent years, primarily in the context of 1365 RSVP and Mobile IP interaction (e.g. [20]), but also in the context 1366 of other types of network (e.g. [21]). This analysis work has shown 1367 that some difficulties in the interactions are quite deeply rooted in 1368 the detailed design of these protocols; however, the problems and 1369 their possible solutions fall under five broad headings. The main 1370 issues for a resource signaling application are limiting the period 1371 after handovers during for which the resource states are not 1372 available along the path; and avoiding double reservations - 1373 reservations on both the old path and new path. Similar issues may 1374 apply to other types of signaling application. 1376 5.2.1 Addressing and Encapsulation 1378 A mobility solution typically involves address reallocation on 1379 handover (unless a network supports per host routing) and may involve 1380 special packet formats (e.g. the routing header and Home Address 1381 option of MIPv6). Since NSIS may depend on end system addresses for 1382 forwarding signaling messages and defining flows (section 4.5.1), the 1383 special implications of mobility for addressing need to be 1384 considered. Examples of possible approaches that could be used to 1385 solve the addressing and encapsulation problem are as follows: 1387 * Use a flow identification based on low level IP addresses (e.g. the 1388 Care of Address) and other 'standard' fields in the IP header. This 1389 makes least demands on the packet classification engines within the 1390 network. However, it means that even on a part of the flow path that 1391 is unchanged, the session will need to be modified to reflect the 1392 changed flow identification (see section 5.2.3). 1394 * Use a flow identification that does not change (e.g. based on Home 1395 Address); this is the approach assumed in [22]. This simplifies the 1396 problem of session update, at the likely cost of considerably 1397 complicating the flow identification requirements. 1399 In the first approach, to prevent double reservation, NSIS entities 1400 need to be able to recognize that a session with the new flow 1401 identifier is to be correlated with an existing one. A session 1402 identifier could be used for this purpose. This is why the session 1403 identifier as described in section 4.5.2 has to have end-to-end 1404 semantics. 1406 While the feasibility and performance of this first approach needs to 1407 be assessed, given the high impact of requiring more sophisticated 1408 packet classifiers, it still seems more plausible than the second 1409 approach. This implies that signaling applications should define 1410 flows in terms of real, routable (care of) addresses rather than 1411 virtual (home) addresses. 1413 5.2.2 Localized Path Repair 1415 In any mobility approach, a handover will cause at least some changes 1416 in the path of upstream and downstream packets. At some point along 1417 the joined path, an NSIS entity should be able to recognize this 1418 situation, based upon session identification. New state needs to be 1419 installed on the new path, and removed from the old. Who triggers the 1420 new state may be constrained by which entities are allowed to carry 1421 out which state manipulations, which is then a signaling application 1422 question. 1424 A critical point here is the signaling that is used to discover the 1425 crossover node. This is a generalization of the problem of finding 1426 next-NSIS peer: it requires extending the new path over several hops 1427 until it intersects the old one. This is easy for the uplink 1428 direction (where the mobile is the sender), but much harder for 1429 downlink without signaling via the correspondent. There is no reason 1430 for the crossover node for uplink and downlink flows to be the same, 1431 even for the same correspondent. The problem is discussed further in 1432 [23]. 1434 5.2.3 Update on the Unchanged Path 1436 On the path between the crossover node(s) and the correspondent, it 1437 is necessary to avoid, if possible, double reservations, but rather 1438 to update the network control state to reflect new flow 1439 identification (this is needed, by the default assumption of section 1440 5.2.1). Examples of approaches that could be used to solve this 1441 problem are the following: 1443 *) Use a session state identification that does not change even if 1444 the flow definition changes (see Section 4.5.2). Signaling is still 1445 needed to update a changed flow identification, but it should be 1446 possible to avoid AAA and admission control processing. 1448 *) Use an NSIS-capable crossover router that manages this update 1449 autonomously (more efficiently than the end nodes could), with 1450 similar considerations to the local path repair case. 1452 Note that in the case of an address change, end to end message 1453 exchanges will be required at the application layer anyway, so 1454 signaling to update the flow identifier does not necessarily add to 1455 the handover latency. 1457 5.2.4 Interaction with Mobility Signaling 1459 In existing work on mobility protocol and signaling protocol 1460 interactions, several framework proposals describing the protocol 1461 interactions have been made. Usually they have taken existing 1462 protocols (Mobile IP and RSVP respectively) as the starting point; it 1463 should be noted that an NSIS protocol might operate in quite a 1464 different way. In this section, we provide an overview of how these 1465 proposals would be reflected in framework of NSIS. The mobility 1466 aspects are described using Mobile IP terminology, but are generally 1467 applicable to other network layer mobility solutions. The purpose of 1468 this overview is not to select or prioritise any particular approach, 1469 but simply to point out how they would fit into our framework and any 1470 major issues with them. 1472 We can consider that two signaling processes are active: mobility 1473 signaling and NSIS signaling. The discussion so far considered how 1474 NSIS signaling should operate. There is still a question of how the 1475 interactions between the NSIS and mobility signaling should be 1476 considered. 1478 The basic case of totally independent specification and 1479 implementation seems likely to lead to ambiguities and even 1480 interoperability problems (see [22]). At least, the addressing and 1481 encapsulation issues for mobility solutions that use virtual links or 1482 their equivalents need to be specified in an implementation-neutral 1483 way. 1485 A type of 'loose' integration is to have independent protocol 1486 definitions, but to define how they trigger each other - in 1487 particular, how the mobility protocol triggers sending of 1488 refresh/modify/tear messages. A pair of implementations could use 1489 these triggers to improve performance, primarily reducing latency. 1490 (Existing RSVP modifications consider the closer interaction of 1491 making the RSVP implementation mobility routing aware, e.g. so it is 1492 able to localize refresh signaling; this would be a self contained 1493 aspect of NSIS.) This information could be developed by analyzing 1494 message flows for various mobility signaling scenarios as was done in 1495 [20]. 1497 An even tighter level of integration is to consider a single protocol 1498 carrying both mobility and network control state information. 1499 Logically, there are two cases: 1501 1. Carry mobility routing information (a 'mobility object') in the 1502 signaling messages, as is done in [22]. (The prime purpose in this 1503 approach is to enable crossover router discovery.) 1505 2. Carry signaling in the mobility messages, typically as a new 1506 extension header. This was proposed in [24] and followed up in [25]; 1507 [26] also anticipates this approach. In our framework, we could 1508 consider this a special case of NSIS layering, with the mobility 1509 protocol playing the role of the signaling transport. 1511 Other modes of interaction might also be possible. The critical point 1512 with all these models is that the general solutions developed by NSIS 1513 should be independent of mobility protocols. Tight integration would 1514 have major deployment issues especially in interdomain cases. 1515 Therefore, any tightly integrated solution is considered out of scope 1516 of initial NSIS development. 1518 5.2.5 Interaction with Context Transfer 1520 In the context of mobility between different access routers, it is 1521 common to consider performance optimizations in two areas: selection 1522 of the optimal access router to handover to, and transfer of state 1523 information between the access routers to avoid having to regenerate 1524 it in the new access router after handover. The Seamoby Working Group 1525 is developing solutions for these protocols (CARD [27] and Context 1526 Transfer [28] respectively); alternative approaches with similar 1527 characteristics are also possible. 1529 As these solutions are still underdevelopment, it is premature to 1530 specify details on the interaction. It is thought that Context 1531 Transfer transfers state between access routers based upon changes 1532 caused by mobility. NSIS protocol state may be a candidate for 1533 context transfer. Such work, should it be undertaken, will be done 1534 in the Seamoby working group. 1536 5.3 Interactions with NATs 1538 Because at least some messages will almost inevitably contain address 1539 and possibly higher layer information as payload, we must consider 1540 the interaction with address translation devices (NATs). As well as 1541 'traditional' NATs of various types (as defined in [29]) very similar 1542 considerations would apply to some IPv4/v6 transition mechanisms such 1543 as SIIT [30]. 1545 In the simplest case of an NSIS unaware NAT in the signaling path, 1546 payloads will be uncorrected and the signaling will be for the 1547 incorrect flow. Applications could attempt to use STUN [31] or 1548 similar techniques to detect and recover from the presence of the 1549 NAT. Even then, NSIS protocols would have to use a well known 1550 encapsulation (TCP/UDP/ICMP) to avoid being dropped by the more 1551 cautious low-end NAT devices. 1553 A simple 'NSIS-aware' NAT would require flow identification 1554 information to be in the clear and not integrity protected. An 1555 alternative conceptual approach is to consider the NAT functionality 1556 being part of message processing itself, in which case the 1557 translating node can take part natively in any NSIS protocol security 1558 mechanisms. Depending on NSIS protocol layering, it would be possible 1559 for this processing to be done in an NSIS entity which was otherwise 1560 ignorant of any particular signaling applications. This is the 1561 motivation for including basic flow identification information in the 1562 NTLP (section 4.5.1). 1564 Note that all of this discussion is independent of the use of a 1565 specific NSLP for general control of NATs (and firewalls). This is 1566 considered in section 6.2. 1568 6. Signaling Applications 1570 This section describes NSLPs for particular signaling applications. 1571 The assumption is that the NSLP uses the generic functionality of the 1572 NTLP given earlier; this section describes specific aspects of NSLP 1573 operation. 1575 6.1 Signaling for Quality of Service 1577 In the case of signaling for QoS, all the basic NSIS concepts of 1578 section 3.1 apply. In addition, there is an assumed directionality of 1579 the signaling process, in that one end of the signaling flow takes 1580 responsibility for actually requesting the resource. This leads to 1581 the following definitions: 1582 *) NSIS Initiator (NI): the signaling entity which makes the resource 1583 request, usually as a result of user application request. 1584 *) NSIS Responder (NR): the signaling entity that acts as the 1585 endpoint for the signaling and can optionally interact with 1586 applications as well. 1587 *) NSIS Forwarder (NF): the signaling entity an NI and NR which 1588 propagates NSIS signaling further through the network. 1589 Each of these entities will interact with a resource management 1590 function (RMF) which actually allocates network resources (router 1591 buffers, interface bandwidth and so on). 1593 Note that there is no constraint on which end of the signaling flow 1594 should take the NSIS Initiator role: with respect to the data flow 1595 direction it could be at the sending or receiving end. 1597 6.1.1 Protocol Messages 1599 The QoS NSLP will include a set of messages to carry out resource 1600 reservations along the signaling path. A message set for the QoS NSLP 1601 is shown below (a very similar set of messages was generated in 1602 [32]). Note that the 'direction' column in the table below only 1603 indicates the 'orientation' of the message. The messages can be 1604 originated and absorbed at NF nodes as well as the NI or NR; an 1605 example might be NFs at the edge of a domain exchanging messages to 1606 set up resources for a flow across a it. 1608 Note the working assumption that responder as well as the initiator 1609 can release a reservation (comparable to rejecting it in the first 1610 place). It is left open if the responder can modify a reservation, 1611 during or after setup. This seems mainly a matter of assumptions 1612 about authorization, and the possibilities might depend on resource 1613 type specifics. 1615 +-------+---------+---------------------------------------------+ 1616 | Name |Direction| Semantics | 1617 +-------+---------+---------------------------------------------+ 1618 |Request| I-->R | Create a new reservation for a flow | 1619 +-------+---------+---------------------------------------------+ 1620 |Modify | I-->R | Modify an existing reservation | 1621 | |(&R-->I?)| | 1622 +-------+---------+---------------------------------------------+ 1623 |Release| I-->R & | Delete (tear down) an existing reservation | 1624 | | R-->I | | 1625 +-------+---------+---------------------------------------------+ 1626 |Accept/| R-->I | Confirm (possibly modified?) or reject a | 1627 | Reject| | reservation request | 1628 +-------+---------+---------------------------------------------+ 1629 |Notify | I-->R & | Report an event detected within the | 1630 | | R-->I | network | 1631 +-------+---------+---------------------------------------------+ 1632 |Refresh| I-->R | State management (see section 4.4) | 1633 +-------+---------+---------------------------------------------+ 1635 The table also explicitly includes a refresh message. This does 1636 nothing to a reservation except extend its lifetime, and is one 1637 possible state management mechanism (see next section). 1639 6.1.2 State Management 1641 The prime purpose of NSIS is to manage state information along the 1642 path taken by a data flow. The issues regarding state management 1643 within the NTLP (state related to message transport) are described in 1644 section 4. The QoS NSLP will typically have to handle additional 1645 state related to the desired resource reservation to be made. 1647 There two critical issues to be considered in building a robust NSLP 1648 to handle this problem: 1649 *) The protocol must be scalable. It should allow minimization of the 1650 resource reservation state storage demands that it implies for 1651 intermediate nodes; in particular, storage of state per 'micro' flow 1652 is likely to be impossible except at the very edge of the network. A 1653 QoS signaling application might require per flow or lower granularity 1654 state; examples of each for the case of QoS would be IntServ [33] or 1655 RMD [34] (per 'class' state) respectively. 1656 *) The protocol must be robust against failure and other conditions, 1657 which imply that the stored resource reservation state has to be 1658 moved or removed. 1660 For resource reservations, typically soft state management is 1661 considered for robustness reasons. It is currently open whether the 1662 soft state protocol aspects should be built into the NSLP for 1663 specific signaling applications, or provided as a generic service by 1664 the NTLP; this issue is discussed in section 3.4.2. 1666 6.1.3 QoS Forwarding 1668 The assumption is that the NTLP works with standard (i.e. best- 1669 effort) layer 3 routing. There are, however, several proposals for 1670 the introduction of QoS awareness in the routing protocols. All of 1671 these essentially lead to the existence of multiple paths (with 1672 different QoS) towards the same destination. As such, they also 1673 contain an inherent risk for a divergence between control plane and 1674 data plane, similar to the load sharing case. Clearly, any QoS NSLP 1675 needs to be able to handle this type of routing. 1677 For intra-domain data flows, the difference in routing may result 1678 from a QoS-aware traffic engineering scheme, that e.g. maps incoming 1679 flows to LSPs based on multi-field classification. In BGP, several 1680 techniques for including QoS information in the routing decision are 1681 currently proposed. A first proposal is based on a newly defined BGP- 1682 4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute is 1683 an optional transitive attribute that can be used to advertise a QoS 1684 route to a peer or to provide QoS information along with the Network 1685 Layer Reachability Information (NLRI) in a single BGP update. A 1686 second proposal is based on controlled redistribution of AS routes 1687 [17]. It defines a new extended community (the redistribution 1688 extended community) that allows a router to influence how a specific 1689 route should be redistributed towards a specified set of eBGP 1690 speakers. The types of redistribution communities may result in a 1691 specific route not being announced to a specified set of eBGP 1692 speakers, that it should not be exported or that the route should be 1693 prepended n times. 1695 6.1.4 Route Changes and QoS Reservations 1697 In this section, we will explore the expected interworking between a 1698 signaling for resource BGP routing updates, although the same applies 1699 for any source of routing updates. The normal operation of the NSIS 1700 protocol will lead to the situation depicted in Figure 7, where the 1701 reserved resources match the data path. 1703 reserved +----+ reserved +----+ 1704 ------->| NF |----------->| NF | 1705 +----+ +----+ 1706 ===================================== 1707 data path 1709 Figure 7: Normal NSIS protocol operation 1711 A route change (triggered by a BGP routing update for instance) can 1712 occur while such a reservation is in place. In case of RSVP, the 1713 route change will be installed immediately and any data that is sent 1714 will be forwarded on the new path. This situation is depicted Figure 1715 8. 1717 Route update 1718 | 1719 v 1720 reserved +----+ reserved +----+ 1721 ------->| NF |----------->| NF | 1722 +----+ +----+ 1723 ========== | 1724 || | +----+ 1725 || +---------->| NF | 1726 || +----+ 1727 ============================ 1728 data path 1730 Figure 8: Route Change 1732 Resource reservation on the new path will only be started once the 1733 next control message is routed along the new path. This means that 1734 there is a certain time interval during which resources are not 1735 reserved on (part of) the data path. To minimize this time interval 1736 several techniques could be considered. As an example, RSVP [4] has 1737 the concept of local repair, where the router may be triggered by a 1738 route change. In that case the RSVP node can start sending PATH 1739 messages directly after the route has been changed. Note that this 1740 option may not be available if no per-flow state is kept in the NF. 1742 It is not guaranteed that the new path will be able to provide the 1743 same guarantees that were available on the old path. Therefore, in a 1744 more desirable scenario, the NF should wait until resources have been 1745 reserved on the new path before installing the route change (unless 1746 of course the old path no longer exists). The route change procedure 1747 then consists of the following steps: 1748 1. NF receives a route announcement, 1749 2. Refresh messages are forwarded along the current path, 1750 3. A copy of the refresh message is re-marked as a request and send 1751 along the new path that was announced, 1752 4. When the NF has been acknowledged about the reservations on the 1753 new path the route will be installed and the data will flow along the 1754 new path. 1756 Another example related to route changes is denoted as severe 1757 congestion and is explained in [34]. This solution adapts to a route 1758 change, when a route change creates a congestion on the new routed 1759 path. 1761 6.1.5 Resource Management Interactions 1763 The QoS NSLP itself is not involved in any specific resource 1764 allocation or management techniques. The definition of an NSLP for 1765 resource reservation with Quality-of-Service, however, implies the 1766 notion of admission control. For a QoS NSLP, the measure of signaling 1767 success will be the ability to reserve resources from the total 1768 resource pool that is provisioned in the network. We define the 1769 function responsible for allocating this resource pool as the 1770 Resource Management Function (RMF). The RMF is responsible for all 1771 resource provisioning, monitoring and assurance functions in the 1772 network. 1774 A QoS NSLP will rely on the RMF to do resource management and to 1775 provide inputs for admission control. In this model, the RMF acts as 1776 a server towards client NSLP(s). It is noted, however, that the RMF 1777 may in turn use another NSLP instance to do the actual resource 1778 provisioning in the network. In this case, the RMF acts as the 1779 initiator (client) of an NSLP. 1781 This essentially corresponds to a multi-level signaling paradigm, 1782 with an 'upper' level handling internetworking QoS signaling, 1783 possibly running end-to-end, and a 'lower' level handling the more 1784 specialised intradomain QoS signaling, running between just the edges 1785 of the network (see [35], [36], and [37] for a discussion of similar 1786 architectures). Given that NSIS signaling is already supposed to be 1787 able to support multiple instances of NSLPs for a given flow, and 1788 limited scope (e.g. edge-to-edge) operation, it is not currently 1789 clear that supporting the multi-level model leads to any new protocol 1790 requirements for the QoS NSLP. 1792 The RMF may or may not be co-located with an NF (note that co- 1793 location with an NI/NR can be handled logically as a combination 1794 between NF and NI/NR). To cater for both cases, we define a (possibly 1795 logical) NF-RMF interface. Over this interface, information may be 1796 provided from the RMF about monitoring, resource availability, 1797 topology, and configuration. In the other direction, the interface 1798 may be used to trigger requests for resource provisioning. One way to 1799 formalize the interface between the NF and the RMF is via a Service 1800 Level Agreement (SLA). The SLA may be static or it may be dynamically 1801 updated by means of a negotiation protocol. Such a protocol is 1802 outside the scope of NSIS. 1804 There is no assumed restriction on the placement of the RMF. It may 1805 be a centralized RMF per domain, several off-path distributed RMFs, 1806 or an on-path RMF per router. The advantages and disadvantages of 1807 both approaches are well-known. Centralization typically allows 1808 decisions to be taken on more global information with more efficient 1809 resource utilization as a result. It also facilitates deployment or 1810 upgrade of policies. Distribution allows local decision processes and 1811 rapid response to data path changes. 1813 6.2 Other Signaling Applications 1815 As well as the use for 'traditional' QoS signaling, it should be 1816 possible to use develop NSLPs for other signaling applications which 1817 operate on different types of network control state. One specific 1818 case is setting up flow-related state in middleboxes (firewalls, 1819 NATs, and so on). Requirements for such communication are given in 1820 [6], and initial discussions of NSIS-like solutions are contained in 1821 [38], [39] and [40]. Other examples include network monitoring and 1822 testing, and tunnel endpoint discovery. 1824 A future version of this document may contain more details on how to 1825 build NSLPs for these types of signaling application. 1827 7. Security Considerations 1829 This document describes a framework for signaling protocols which 1830 assumes a two-layer decomposition, with a common lower layer (NTLP) 1831 supporting a family of signaling application specific upper layer 1832 protocols (NSLPs). The overall security considerations for the 1833 signaling therefore depend on the joint security properties assumed 1834 or demanded for each layer. 1836 Security for the NTLP is discussed in section 4.6. We have assumed 1837 that the role of the NTLP will be to provide message protection over 1838 the scope of a single peer relationship (between adjacent signaling 1839 entities), and that this can most likely be provided by some kind of 1840 channel security mechanism using an external key management mechanism 1841 based on mutual authentication. In addition, the NTLP should be 1842 resilient against denial of service attacks on the protocol itself. 1844 Security for the NSLPs is entirely dependent on signaling application 1845 requirements. In some cases, no additional protection may be required 1846 compared to what is provided by the NTLP. In other cases, more 1847 sophisticated object-level protection and the use of public key based 1848 solutions may be required. In addition, the NSLP needs to consider 1849 the authorisation requirements of the signaling application. 1851 Another factor is that NTLP security mechanisms operate only locally, 1852 whereas NSLP mechanisms may also need to operate over larger regions 1853 (not just between adjacent peers) especially for authorisation 1854 aspects; this complicates the analysis of basing signaling 1855 application security on NTLP protection. Further work on this and 1856 other security design will depend on a refinement of the NSIS threats 1857 work begun in [12]. 1859 8. Change History 1861 8.1 Changes from draft-ietf-nsis-fw-01.txt 1863 This -02 version has been very significantly restructured compared to 1864 the previous version, and a section by section change history is 1865 probably neither possible or useful. Instead, this section lists the 1866 major technical and structural changes. 1868 1. The concept of splitting the protocol suite into two layers is 1869 now introduced much earlier, and the rest of the framework 1870 restructured around it. In general, the content is supposed to be 1871 signaling application independent: possibilities for application 1872 dependent behavior are described in section 3.3, and the specific 1873 case of QoS/resource management is restricted to section 6.1. 1874 2. Sender and receiver orientation is now assumed to be a signaling 1875 application protocol property (section 3.3.1), with the NTLP by 1876 default operating bidirectionally (section 3.2.3). As a 1877 consequence, the initiator, forwarder, and responder concepts 1878 only appear in the later sections. 1879 3. In general, the NTLP is now a 'thinner' layer than previously 1880 envisaged (e.g. without specific reserve/tear messages), and so 1881 the possible inter-layer coupling with the NSLP is much reduced. 1882 However, the option of the NTLP providing some kind of generic 1883 state management service is still an open issue (section 3.4.2). 1884 4. In general, authorisation issues are still handled by the NSLP, 1885 including the question of which network entities are allowed to 1886 modify network state. In particular, the issue of 'session' 1887 (previously 'reservation') ownership (section 3.1.4) is assumed 1888 to be handled by the NSLP level, although session identification 1889 is still visible to the NTLP (section 4.5.2). The implication is 1890 that most key aspects of mobility support (section 5.2) are now 1891 NSLP responsibilities. 1893 5. Both peer-peer and end-to-end addressing modes are assumed to be 1894 needed for the NTLP, and any choice between them is a protocol 1895 design issue (not visible externally). 1897 References 1899 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1900 9, RFC 2026, October 1996. 1902 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1903 Levels", BCP 14, RFC 2119, March 1997 1905 3 Brunner, M., "Requirements for QoS Signaling Protocols", draft- 1906 ietf-nsis-req-05.txt (work in progress), November 2002 1908 4 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource 1909 ReSerVation Protocol (RSVP) -- Version 1 Functional 1910 Specification", RFC 2205, September 1997 1912 5 Chaskar, H. (editor), "Requirements of a QoS Solution for Mobile 1913 IP", draft-ietf-mobileip-qos-requirements-03.txt (work in 1914 progress), July 2002 1916 6 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 1917 Communications (midcom) Protocol Requirements", RFC 3304, August 1918 2002 1920 7 Manner, J. and X. Fu, "Analysis of Existing Quality of Service 1921 Signaling Protocols", draft-ietf-nsis-signalling-analysis-01.txt 1922 (work in progress), February 2003 1924 8 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 1925 thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002 1927 9 Braden, R., and B. Lindell, "A Two-Level Architecture for Internet 1928 Signaling", draft-braden-2level-signaling-01.txt (work in 1929 progress), November 2002 1931 10 Rescorla, E. et al., "Guidelines for Writing RFC Text on Security 1932 Considerations", draft-iab-sec-cons-03.txt (work in progress), 1933 January 2003 1935 11 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne, 1936 "NSIS Authentication, Authorization and Accounting Issues", draft- 1937 tschofenig-nsis-aaa-issues-00.txt (work in progress), February 1938 2003 1940 12 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 1941 draft-ietf-nsis-threats-01.txt (work in progress), January 2003 1943 13 Katz, D., "IP Router Alert Option", RFC 2113, February 1997 1945 14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 1946 October 1999 1948 15 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, 1949 T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 1950 2676, August 1999 1952 16 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1953 1771, March 1995 1955 17 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1956 draft-ietf-idr-bgp4-17.txt (work in progress), January 2002 1957 (expired) 1959 18 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of 1960 Multiple Paths in BGP", draft-walton-bgp-add-paths-01.txt (work in 1961 progress), November 2002 1963 19 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, 1964 P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy 1965 Protocol", RFC2338, April 1998 1967 20 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft- 1968 thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002 1970 21 Partain, D., G. Karagiannis, P. Wallentin, L. Westberg, "Resource 1971 Reservation Issues in Cellular Radio Access Networks", draft- 1972 westberg-rmd-cellular-issues-01.txt (work in progress), June 2002 1974 22 Shen, C. et al., "An Interoperation Framework for Using RSVP in 1975 Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt 1976 (work in progress), July 2001 (expired) 1978 23 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt 1979 (work in progress), January 2003 1981 24 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile 1982 IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March 1983 2001 (expired) 1985 25 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile 1986 IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress), 1987 January 2002 (expired) 1989 26 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6 1990 Networks", draft-kan-qos-framework-01.txt (work in progress), July 1991 2002 1993 27 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 1994 candidate access router discovery for seamless IP-level handoffs", 1995 draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress), 1996 October 2002 1998 28 Kempf, J., "Problem Description: Reasons For Performing Context 1999 Transfers Between Nodes in an IP Access Network", RFC3374, 2000 September 2002 2002 29 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 2003 (NAT) Terminology and Considerations", RFC2663, August 1999 2005 30 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 2006 RFC2765, February 2000 2008 31 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple 2009 Traversal of UDP Through Network Address Translators", draft-ietf- 2010 midcom-stun-05.txt (work in progress), December 2002 2012 32 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework 2013 for Edge-to-Edge NSIS Signaling", draft-westberg-nsis-edge-edge- 2014 framework-00.txt (work in progress), May 2002 2016 33 Braden, R., D. Clark, S. Shenker, "Integrated Services in the 2017 Internet Architecture: an Overview", RFC 1633, June 1994 2019 34 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 2020 Partain, D., Pop, O., Rexhepi, V., Szab�, R., Tak�cs, A., 2021 "Resource Management in Diffserv (RMD): A Functionality and 2022 Performance Behavior Overview", Seventh International Workshop on 2023 Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 2025 35 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for 2026 Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92- 2027 072, November 1992 2029 36 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated 2030 Services Architecture for the Internet", RFC 2638, July 1999 2032 37 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 2033 RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 2035 38 Shore, M., "Towards a Network-friendlier Midcom", draft-shore- 2036 friendly-midcom-01.txt (work in progress), June 2002 2038 39 Shore, M., "The TIST (Topology-Insensitive Service Traversal) 2039 Protocol", draft-shore-tist-prot-00.txt (work in progress), May 2040 2002 2042 40 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS 2043 Framework", draft-brunner-nsis-mbox-fmwk-00.txt (work in 2044 progress), June 2002 2046 Acknowledgments 2048 The authors would like to thank Anders Bergsten, Bob Braden, Maarten 2049 Buchli, Eleanor Hepworth, Melinda Shore and Hannes Tschofenig for 2050 significant contributions in particular areas of this draft. In 2051 addition, the authors would like to acknowledge Cedric Aoun, Marcus 2052 Brunner, Danny Goderis, Cornelia Kappler, Mac McTiffin, Hans De Neve, 2053 David Partain, Vlora Rexhepi, Henning Schulzrinne and Lars Westberg 2054 for insights and inputs during this and previous framework 2055 activities. 2057 Authors' Addresses 2059 Ilya Freytsis 2060 Cetacean Networks Inc. 2061 100 Arboretum Drive 2062 Portsmouth, NH 03801 2063 USA 2064 email: ifreytsis@cetacean.com 2066 Robert Hancock 2067 Roke Manor Research 2068 Old Salisbury Lane 2069 Romsey 2070 Hampshire 2071 SO51 0ZN 2072 United Kingdom 2073 email: robert.hancock@roke.co.uk 2074 Georgios Karagiannis 2075 Ericsson EuroLab Netherlands B.V. 2076 Institutenweg 25 2077 P.O.Box 645 2078 7500 AP Enschede 2079 The Netherlands 2080 email: georgios.karagiannis@eln.ericsson.se 2082 John Loughney 2083 Nokia Research Center 2084 11-13 Italahdenkatu 2085 00180 Helsinki 2086 Finland 2087 email: john.loughney@nokia.com 2089 Sven Van den Bosch 2090 Alcatel 2091 Francis Wellesplein 1 2092 B-2018 Antwerpen 2093 Belgium 2094 email: sven.van_den_bosch@alcatel.be 2096 Intellectual Property Considerations 2098 The IETF takes no position regarding the validity or scope of any 2099 intellectual property or other rights that might be claimed to 2100 pertain to the implementation or use of the technology described in 2101 this document or the extent to which any license under such rights 2102 might or might not be available; neither does it represent that it 2103 has made any effort to identify any such rights. Information on the 2104 IETF's procedures with respect to rights in standards-track and 2105 standards-related documentation can be found in BCP-11. Copies of 2106 claims of rights made available for publication and any assurances of 2107 licenses to be made available, or the result of an attempt made to 2108 obtain a general license or permission for the use of such 2109 proprietary rights by implementers or users of this specification can 2110 be obtained from the IETF Secretariat. 2112 The IETF invites any interested party to bring to its attention any 2113 copyrights, patents or patent applications, or other proprietary 2114 rights which may cover technology that may be required to practice 2115 this standard. Please address the information to the IETF Executive 2116 Director. 2118 Full Copyright Statement 2120 "Copyright (C) The Internet Society (2003). All Rights Reserved. This 2121 document and translations of it may be copied and furnished to 2122 others, and derivative works that comment on or otherwise explain it 2123 or assist in its implementation may be prepared, copied, published 2124 and distributed, in whole or in part, without restriction of any 2125 kind, provided that the above copyright notice and this paragraph are 2126 included on all such copies and derivative works. However, this 2127 document itself may not be modified in any way, such as by removing 2128 the copyright notice or references to the Internet Society or other 2129 Internet organizations, except as needed for the purpose of 2130 developing Internet standards in which case the procedures for 2131 copyrights defined in the Internet Standards process must be 2132 followed, or as required to translate it into languages other than 2133 English. 2135 The limited permissions granted above are perpetual and will not be 2136 revoked by the Internet Society or its successors or assigns. This 2137 document and the information contained herein is provided on an "AS 2138 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2139 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2140 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2141 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2142 OR FITNESS FOR A PARTICULAR PURPOSE. 2144 Hancock et al. Expires - Septemb