idnits 2.17.00 (12 Aug 2021) /tmp/idnits8775/draft-loughney-nsis-ext-02.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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 6, 2006) is 5919 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: 'IANA' on line 113 == Outdated reference: draft-ietf-nsis-fw has been published as RFC 4080 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '2') == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '4') == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '5') == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '3') == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qspec (ref. '6') Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Loughney 3 Internet-Draft Nokia 4 Expires: September 7, 2006 March 6, 2006 6 NSIS Extensibility Model 7 draft-loughney-nsis-ext-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 7, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document discusses the Next Steps in Signaling extensibility 41 model. This model is based upon a two-layer model, where there is a 42 transport layer and a signaling application model. This two-layer 43 provides the ability to develope new signaling applications, while 44 retaining the use of a common transport layer. This document will 45 serve as guidence on how the NSIS architecture can be extended. 47 Table of Contents 49 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. NSIS Extensibility Types . . . . . . . . . . . . . . . . . 3 52 3. GIST Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. NSLP Identifiers . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Message Routing Methods . . . . . . . . . . . . . . . . . 4 55 3.3. Protocol Indicators . . . . . . . . . . . . . . . . . . . 5 56 3.4. Router Alert Values . . . . . . . . . . . . . . . . . . . 5 57 4. NSLP Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Common Functionality Among Signaling Applications . . . . 7 59 5. QoS Model Extensibility . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [1]. 75 2. Introduction 77 The Next Steps in Signaling Framework NSIS Framework [2] details a 78 basic two-layer framework for signaling on the Internet. The 79 document decomposes signaling into a two-layer model, into a generic 80 transport layer and specific signaling layers. 82 This model allows for an extensible model for different signaling 83 needs on the the Internet. Currently, the NSIS working group is 84 working on two main signaling applications - QoS signaling [3] and 85 NAT/Firewall signaling [4]. It is expected that there will be more 86 signaling applications. 88 The NSIS Transport Layer Protocol, GIST (General Internet Signaling 89 Transport) GIST [5] defines a basic protocol for routing and 90 transport of per-flow signaling along the path taken by that flow 91 through the network; managing the underlying transport and security 92 protocols. 94 Above GIST can one or more NSIS Signaling Layer protocols, which can 95 signal for things such as QoS, firewall control and NAT signaling.QoS 96 NSLP [3], NAT/FW NSLP [4]. These signaling applications manage their 97 state by using the services that the GIST provides them for 98 signaling. 100 This two layer approach allows for signaling applications to be 101 developed indepently of the transport. As it is likely that the 102 functionality entities for different signaling applications will be 103 distinct, not all path elements support NSIS signaling will require 104 that a specific signaling application is present - only those nodes 105 that will be maintaining some signaling application state need to 106 support the signaling application. 108 2.1. NSIS Extensibility Types 110 Generally, NSIS protocols can be extended in multiple ways. This 111 secition is and overview of the mechansims used. The extensibility 112 rules are based upon the procedures by which IANA assigns values: 113 "Standards Action" (as defined in [IANA]), "IETF Action", "Expert 114 Review", and "Organization/Vendor Private", defined below. 116 Extensions subject to "IETF Action" require either a Standards Track 117 RFC, Experimental RFC or an Information RFC. 119 Extensions subject to "Expert Review" refer to values that are to be 120 reviewed by an Expert designated by the IESG. The code points from 121 these ranges are typically used for experimental extensions; such 122 assignments MUST be requested by either Experimental or Information 123 RFCs that document their use and processing, and the actual 124 assignments made during the IANA actions for the document. Values 125 from "Expert Review" ranges MUST be registered with IANA. 127 "Organization/Vendor Private" ranges refer to values that are 128 enterprise-specific. In this way, different enterprises, vendors, or 129 Standards Development Organizations (SDOs) can use the same code 130 point without fear of collision. 132 In the NSIS protocols, experimental code points are allocated for 133 experimentation, usually within closed networks, as explained in RFC 134 3692.[7]. If these experiments yield useful results, it is assumed 135 that they will be formally allocated by one of the above mechanisms. 137 3. GIST Extensibility 139 GIST is Major extensibility options for GIST are: 141 3.1. NSLP Identifiers 143 Each signaling application requires one of more NSLPIDs (different 144 NSLPIDs may be used to distinguish different classes of signaling 145 node, for example to handle different aggregation levels or different 146 processing subsets). An NSLPID must be associated with a unique RAO 147 value. IETF Action is required to allocate a new NSLP Identifier. 149 3.2. Message Routing Methods 151 GIST allows the idea of multiple Message Routing Methods (MRM). The 152 message routing method is indicated in the leading 2 bytes of the MRI 153 object. GIST allocates 2 bits for experimental Routing Methods, for 154 use in closed networks for experimentation purposes. Standards 155 Action is required to allocate new Routing Methods. 157 Experimental NSLPs are required to be able to use experimental MRMs, 158 and the experimental NSLP is not supported, then the MRM is ignored. 159 The expectation is that the experimental MRM is used within a closed 160 network, for experimental purposes, as explained in RFC 3692.[7] 162 3.3. Protocol Indicators 164 The GIMPS design allows the set of possible protocols to be used in a 165 messaging association to be extended. Every new mode of using a 166 protocol is given by a Protocol Indicator, which is used as a tag in 167 the Node Addressing and Stack Proposal objects. New protocol 168 indicators require IETF Action. Allocating a new protocol indicator 169 requires defining the higher layer addressing information in the Node 170 Addressing Object that is needed to define its configuration. 172 3.4. Router Alert Values 174 Router Alert Option (RAO) values are allocated on the basis of IETF 175 consensis. However, new RAO values SHOULD NOT be allocated for each 176 new NSLP. Careful consideration needs to be exercised when choosing 177 to allocate a new RAO value. This section discusses some 178 considerations on how to choose if an existing RAO option should be 179 chosen or a new RAO should be allocated for an NSLP 181 The use of the RAO is the primary mechanism to indicate that an GIST 182 message should be intercepted by a particular node. There are two 183 basic reasons why a GIST node might wish not to intercept a 184 particular message. The first reason would be because the message is 185 for a signaling application that the node does not process. The 186 second reason would be because the node is processes signaling 187 messages at the aggregate level, not for individual flow, even though 188 the signaling application is present on the node. However, these 189 reasons do not preclude a node processing several RAO values, 190 implying it supports several different signaling applications. 192 Some of this information can be encoded in the RAO value field, which 193 then allows messages to be filtered on the fast path. There is a 194 tradeoff between two approaches here, whose evaluation depends on 195 whether the processing node is specialised or general purpose: 197 Fine-Grained: The signaling application (including specific version) 198 and aggregation level are directly identified in the RAO value. A 199 specialised node which handles only a single NSLP can efficiently 200 ignore all other messages; a general purpose node may have to match 201 the RAO value in a message against a long list of possible values. 203 Coarse-Grained> RAO values are allocated are ased on common 204 applications or sets of applications (such as 'All QoS Signaling 205 Applications'). This speeds up the processing in a general purpose 206 node, but a specialised node may have to carry out further processing 207 on the GIST common header to identify the precise messages it needs 208 to consider. 210 These considerations imply that the RAO value should not be tied 211 directly to the NSLPID, but should be selected for the application on 212 broader considerations of likely deployment scenarios. Note that the 213 exact NSLP is given in the GIMPS common header, and some 214 implementations may still be able to process it on the fast path. 215 The semantics of the node dropping out of the signaling path are the 216 same however the filtering is done. Which is to say that the RAO 217 does not have to have a one-to-one relation to a specific NSLPID, the 218 RAO must be uniquely derivable from the NSLPID. 220 There is a special consideration in the case of the aggregation 221 level. In this case, whether a message should be processed depends 222 on the network region it is in (specifically, the link it is on). 223 There are then two basic possibilities: 225 All routers have essentially the same algorithm for which messages 226 they process, i.e. all messages at aggregation level 0. However, 227 messages have their aggregation level incremented on entry to an 228 aggregation region and decremented on exit. 230 Router interfaces are configured to process messages only above a 231 certain aggregation level and ignore all others. The aggregation 232 level of a message is never changed; signaling messages for end to 233 end flows have level 0, but signaling messages for aggregates are 234 generated with a higher level. 236 The first technique requires aggregating/deaggregating routers to be 237 configured with which of their interfaces lie at which aggregation 238 level, and also requires consistent message rewriting at these 239 boundaries. The second technique eliminates the rewriting, but 240 requires interior routers to be configured also. It is not clear 241 what the right trade-off between these options is. 243 4. NSLP Extensibility 245 An NSLP roughly should correspond to a class of signaling 246 application, which requires some state maintenance along a network 247 path. Signaling applications should be generic enough to allow for 248 state manipulation for a common set of funtions. This allows for an 249 architecture which allows for flexible network deployment, without 250 over-burdening nodes with extra signaling applications. 252 New NSLPs should be created when there is a new signaling 253 application. Creating new NSLPs which only slightly modify existing 254 NSLPs is not recommended as it will increase deployment complexity 255 (common nodes would need to support multiple NSLPs for similar 256 functionality). 258 4.1. Common Functionality Among Signaling Applications 260 While NSIS has adopted a two-layer signaling approach, in practice, 261 there is much in common between different NSLPs. Efforts should be 262 made to ensure some high-level of compatibililty among signaling 263 applications, which could be reused by some implementations in order 264 to combine multiple signaling applications into one implementation, 265 but that is an implementation decision. 267 5. QoS Model Extensibility 269 The QoS NSLP provides signaling for QoS reservations on the Internet. 270 The QoS NSLP decouples the resource reservation model or architecture 271 from the signaling. The QoS specification is defined in QSpec [6]. 272 New QoS Models require IETF action, which defines the elements within 273 the QSpec. See QSpec [6] for details. 275 A key part of the QoS model is support a common language, which can 276 be shared among several QOSMs. These QSPEC parameters ensure a 277 certain level of interoperability of QOSMs. Optional QSPEC 278 parameters support the extensibility of the QoS NSLP to other QOSMs 279 in the future. The node initiating the NSIS signaling adds an 280 Initiator QSPEC that must not be removed, thereby ensuring the 281 intention of the NSIS initiator is preserved along the signaling 282 path. 284 6. IANA Considerations 286 This document outlines the basic rules for extending NSIS protocols. 287 This instructions IANA on allocation policies for NSIS protocols. 289 7. Security Considerations 291 This document is an informational document, outlining the 292 extensibility model of the NSIS protocol suite. As such, this 293 document does not impact the security of the Internet directly. 295 8. Acknowledgements 297 This document borrows some ideas and some text from RFC3936 [8], 298 Procedures for Modifying the Resource reSerVation Protocol (RSVP). 300 Robert Hancock provided text for much of the GIST section. Claudia 301 Keppler have provided feedback on this draft. 303 Allison Mankin and Bob Braden suggest that this draft be worked on. 305 9. References 307 9.1. Normative References 309 [2] Hancock, R., "Next Steps in Signaling: Framework", 310 draft-ietf-nsis-fw-07 (work in progress), December 2004. 312 [4] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 313 (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress), 314 February 2006. 316 [5] Schulzrinne, H. and R. Hancock, "GIST: General Internet 317 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 318 progress), February 2006. 320 [3] Manner, J., "NSLP for Quality-of-Service signalling", 321 draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006. 323 [6] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-08 324 (work in progress), December 2005. 326 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 327 Levels", BCP 14, RFC 2119, March 1997. 329 9.2. Informative References 331 [7] Narten, T., "Assigning Experimental and Testing Numbers 332 Considered Useful", BCP 82, RFC 3692, January 2004. 334 [8] Kompella, K. and J. Lang, "Procedures for Modifying the Resource 335 reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004. 337 Author's Address 339 John Loughney 340 Nokia 341 Itamerenkatu 11-13 342 Helsinki 00180 343 Finland 345 Phone: +358504836242 346 Email: john.loughney@nokia.com 348 Intellectual Property Statement 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at 370 ietf-ipr@ietf.org. 372 Disclaimer of Validity 374 This document and the information contained herein are provided on an 375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 377 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 378 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 379 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 382 Copyright Statement 384 Copyright (C) The Internet Society (2006). This document is subject 385 to the rights, licenses and restrictions contained in BCP 78, and 386 except as set forth therein, the authors retain all their rights. 388 Acknowledgment 390 Funding for the RFC Editor function is currently provided by the 391 Internet Society.