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