idnits 2.17.00 (12 Aug 2021) /tmp/idnits10045/draft-manner-nsis-user-guide-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust 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 (January 18, 2008) is 5236 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) == 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. 'I-D.ietf-nsis-nslp-natfw') == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') == 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. 'I-D.ietf-nsis-qos-nslp') == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qspec (ref. 'I-D.ietf-nsis-qspec') ** Downref: Normative reference to an Informational RFC: RFC 3726 ** Downref: Normative reference to an Informational RFC: RFC 4080 ** Downref: Normative reference to an Informational RFC: RFC 4081 == Outdated reference: A later version (-05) exists of draft-cordeiro-nsis-hypath-04 == Outdated reference: A later version (-14) exists of draft-kappler-nsis-qosmodel-controlledload-05 == Outdated reference: A later version (-04) exists of draft-manner-nsis-nslp-auth-03 == Outdated reference: A later version (-01) exists of draft-manner-nsis-peering-data-00 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft TKK 4 Intended status: Standards Track R. Bless 5 Expires: July 21, 2008 Univ. of Karlsruhe 6 January 18, 2008 8 What is Next Steps in Signaling anyway - A User's Guide to the NSIS 9 Protocol Family 10 draft-manner-nsis-user-guide-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Next Steps in Signaling (NSIS) Working group was officially 44 formed in November 2001 to standardize a new IP signaling protocol 45 suite. Six years have now passed and the first actual protocol 46 specifications have been finalized. The purpose of this draft is to 47 give an overview of what has been achieved, how the industry can make 48 use of the new protocols, and how the research community can further 49 extend the designs. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3 55 3. The General Internet Signaling Transport . . . . . . . . . . . 5 56 4. Quality of Service NSLP . . . . . . . . . . . . . . . . . . . 7 57 5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 8 58 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 9 59 6.1. Obstacles . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 10 61 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 10 62 8.1. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 8.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 8.3. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 11 65 8.4. New NSLP protocols . . . . . . . . . . . . . . . . . . . . 11 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . . . 16 74 1. Introduction 76 The Transport Area Directors held a Next Steps in Signaling (NSIS) 77 birds of a feather session on Wednesday 21st March 2001 at the 50th 78 IETF meeting in Minneapolis. The goal of the session was to discuss 79 and gather an initial set of requirements for a next generation 80 Internet signaling protocol suite as it was felt that the current 81 RSVP-based solutions have short-comings, e.g., with respect to 82 mobility or QoS interoperability. The NSIS Working Group was 83 officially formed later that year, in November 2001 and had its first 84 meeting at the IETF 52 in Salt Lake City in December 2001. 86 The initial charter of NSIS was focused on QoS signaling as the first 87 use case, taking RSVP as the background for the work. In May 2003, 88 middlebox traversal was added as an explicit second use case. The 89 requirements for the new generation of signaling protocols are 90 documented in [RFC3726] and an analysis of existing signaling 91 protocols can be found in [RFC4094]. 93 The design of NSIS is based on a two-layer model, where a general 94 signaling transport layer provides services to an upper signaling 95 layer. The design was influenced by Bob Braden's Internet Draft 96 entitled "A Two-Level Architecture for Internet Signaling" 97 [I-D.braden-2level-signal-arch]. 99 This document gives an overview of what the NSIS framework is today, 100 provides help and guidelines to the reader as to how NSIS can be used 101 in an IP network, and how the protocol can be enhanced to fulfill new 102 use cases. 104 2. The NSIS Architecture 106 The design of the NSIS protocol suite reuses ideas and concepts from 107 RSVP but essentially divides the functionality into two layers. The 108 lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge 109 of transporting the higher layer protocol messages to the next 110 signaling node on the path. This includes discovery of the next hop 111 NSIS node, which may not be the next routing hop, and different 112 transport services depending on the signaling application 113 requirements. The General Internet Signaling Transport (GIST) is the 114 protocol that fulfills the role of the NTLP. The NSIS suite supports 115 both IP protocol versions, IPv4 and IPv6. 117 The actual signaling application logic is implemented in the higher 118 layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). 119 While GIST is only concerned in transporting NSLP messages between 120 two end-points, the end-to-end signaling functionality is provided by 121 the NSLP protocols if needed - not all NSLP protocols need to perform 122 end-to-end signaling, even the current protocols have features to 123 confine the signaling to a limited path. Two NSLP protocols are 124 currently standardized: one concerning Quality of Service signaling 125 and one for NAT/Firewall traversal. 127 A central concept of NSIS is the Session Identifier (SID). Signaling 128 application states are indexed and referred to through the SID. This 129 decouples the state information from IP addresses, allowing dynamic 130 IP address changes for signaling flows, e.g. due to mobility: changes 131 in IP addresses do not force complete tear down and re-initiation of 132 a signaling application state, merely an update of the state 133 parameters. 135 The SID is not meaningfull by itself, but is rather used together 136 with the NSLP identifier (NSLPID) and the Message Routing Information 137 (MRI). This 3-tuple is used by GIST to index and manage the 138 signaling flows. 140 The following design restrictions were imposed for the first phase of 141 the protocol suite. They may be lifted in future and new 142 functionality may be added into the protocols at some later stage. 144 o Path-coupled signaling only: GIST transports messages towards an 145 identified unicast data flow destination based on the signaling 146 application request, and does not directly support path-decoupled 147 signaling, e.g., QoS signaling to a bandwidth broker. The 148 framework also supports a "Loose-End" message routing method used 149 to discover GIST nodes with particular properties in the direction 150 of a given address, for example the NAT/FW NSLP uses this method 151 to discover a NAT along the upstream data path. 152 o No multicast support: Introducing support for multicast was deemed 153 too much overhead, if considering the currently limited support 154 for global IP multicast. Thus, the current GIST and the NSLP 155 specifications consider unicast flows only. 157 The key documents specifying the NSIS protocol suite are: 159 o Requirements for Signaling Protocols [RFC3726] 160 o Next Steps in Signaling: Framework [RFC4080] 161 o Security Threats for NSIS [RFC4081] 162 o The General Internet Signaling Transport protocol 163 [I-D.ietf-nsis-ntlp] 164 o Quality of Service NSLP [I-D.ietf-nsis-qos-nslp] 165 o The QoS specification template [I-D.ietf-nsis-qspec] 166 o NAT/Firewall traversal NSLP [I-D.ietf-nsis-nslp-natfw] 168 The next three sections provide a brief survey of GIST, QoS NSLP, and 169 NAT/FW NSLP. 171 3. The General Internet Signaling Transport 173 The General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] 174 provides a signaling transport service to NSIS Signaling Layer 175 Protocols (NSLP). GIST does not define new IP transport protocols 176 but rather makes use of existing protocols, such TCP and UDP. 177 Applications can indicate the desired reliability, e.g., unreliable 178 or reliable, and GIST then uses the most appropriate transport 179 protocol to achieve the goal. If applications request also security, 180 GIST uses TLS. The GIST layered protocol stack is shown in Figure 1. 182 +-----+ +--------+ +-------+ 183 | | | | | | 184 | QoS | | NAT/FW | | ... | NSLP 185 | | | | | | 186 +-----+ +--------+ +-------+ 188 ---------------------------------------------------------------------- 189 +--------------------------+ 190 | | 191 | GIST | NTLP 192 | | 193 +--------------------------+ 195 ---------------------------------------------------------------------- 196 +--------------------------+ 197 | TLS | 198 +--------------------------+ 199 +--------------------------+ 200 | TCP | UDP | SCTP | DCCP | 201 +--------------------------+ 202 +--------------------------+ 203 | IPsec | 204 +--------------------------+ 205 +--------------------------+ 206 | IPv4(+RAO) | IPv6(+RAO) | 207 +--------------------------+ 209 Figure 1: The NSIS protocol stack 211 When an NSLP application wants to send a message to its next peer, 212 GIST starts discovering the next signaling node by sending a Query 213 message towards the destination of the related data flow. This Query 214 carries the NSLP identifier (NSLP ID) and Message Routing Information 215 (MRI) among others. The MRI contains enough information to route the 216 signaling message, e.g., information about the actual data flow that 217 is signaled for. The next GIST node on the path receives the message 218 and if it is running the same NSLP, it provides the MRI to the NSLP 219 application and requests it to make a decision on whether to peer 220 with the querying node. If the NSLP application chooses to peer, 221 GIST sets up a Message Routing State (MRS) between the two nodes for 222 the future exchange of NSLP data. State setup is performed by a 223 three-way handshake that allows for negotiation of signaling flow 224 parameters and provides counter-measures against several attacks like 225 denial-of-service by using cookie mechanisms and a late state 226 installation option. 228 If a transport connection is required and set up for reliable or 229 secure signaling, like TCP or TLS/TCP, a Messaging Association (MA) 230 is established between the two peers. An MA can be re-used for 231 signaling messages concerning several different data flows, i.e., 232 signaling messages between two nodes are multiplexed over the same 233 transport connection. This can be done when the transport 234 requirements (reliability, security) of a new flow can be met with an 235 existing MA, i.e., the security and transport properties of an 236 existing MA are equivalent or better than what is requested by the 237 new MA. 239 For path-coupled signaling, we need to find the nodes on the data 240 path that should take part in the signaling of an NSLP and invoke 241 them to act due to arrival of such NSLP signaling messages. The 242 basic concept is that such nodes along a flow's data path intercept 243 the corresponding signaling packets and are thus discovered 244 automatically. GIST uses by default the Router Alert Option (RAO) in 245 Query messages to tell a receiving router that the packet must be 246 inspected and possibly taken out of the fast path. This is the the 247 same mechanism as in RSVP. Different RAO values can be used to 248 indicate the actual NSLP being signaled, thus, making it possible for 249 routers to leave the packet in the fast path if the right NSLP 250 protocol is not available on the router; only a router that runs GIST 251 and the corresponding NSLP will take the packet out of the fast path, 252 and start processing it within GIST. Further intentional bypassing 253 of signaling nodes can be accomplished either in GIST or in the NSLP. 255 Since GIST carries information about the data flow inside its 256 messages (in the MRI), NAT gateways must be aware of GIST in order to 257 let it work correctly. GIST provides a special object for NAT 258 traversal so that the actual translation is disclosed if a GIST-aware 259 NAT gateway provides this object. 261 GIST may use different triggers in order to detect a route change. 262 It probes periodically for the next peer by sending a GIST Query, 263 thereby detecting a changed route and GIST peer. GIST monitors 264 routing tables, the GIST peer states, and notifies NSLPs of any 265 routing changes. It is up to the NSLPs to act appropriately then, if 266 needed, e.g., by issuing a refresh message. 268 In summary, GIST provides several services in one package to the 269 upper layer signaling protocols: 271 o Signaling peer discovery: GIST is able to find the next hop node 272 that runs the NSLP being signaled for. 273 o Multiplexing: GIST reuses already established signaling 274 relationships and messaging associations to peers if the signaling 275 flows traverse the same next signaling hop. 276 o Transport: GIST provides transport with different attributes, 277 namely reliable/unreliable and secure/unsecure. 278 o Confidentiality: If security is requested, GIST uses TLS to 279 provide an encrypted and integrity protected message transport to 280 the next signaling peer. 281 o Routing changes: GIST detects routing changes, but instead of 282 acting on its own, it merely sends a notification to the local 283 NSLP. It is then up to the NSLP to act. 284 o Fragmentation: GIST uses either a known Path MTU for the next hop 285 or limits its message size to 576 bytes. If fragmentation is 286 required it automatically establishes an MA and sends the 287 signaling traffic over a reliable protocol, e.g., TCP. 289 4. Quality of Service NSLP 291 The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP) 292 establishes and maintains state at nodes along the path of a data 293 flow for the purpose of providing some forwarding resources for that 294 flow. It is intended to satisfy the QoS-related requirements of RFC 295 3726 [RFC3726]. No support for QoS architectures based on bandwidth 296 brokers is currently included. 298 The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 299 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 300 primary state management mechanism (i.e., state installation/refresh 301 is performed between pairs of adjacent NSLP nodes, rather than in an 302 end-to-end fashion along the complete signaling path). The QoS NSLP 303 extends the set of reservation mechanisms to meet the requirements of 304 RFC 3726 [RFC3726], in particular support of sender or receiver- 305 initiated reservations, as well as, a type of bi-directional 306 reservation and support of reservations between arbitrary nodes, 307 e.g., edge-to-edge, end-to-access, etc. On the other hand, there is 308 currently no support for IP multicast. 310 A distinction is made between the operation of the signaling protocol 311 and the information required for the operation of the Resource 312 Management Function (RMF). RMF-related information is carried in the 313 QSPEC (QoS Specification) [I-D.ietf-nsis-qspec] object in QoS NSLP 314 messages. This is similar to the decoupling between RSVP and the 315 IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries 316 information on resources available, resources required, traffic 317 descriptions and other information required by the RMF. 319 QoS NSLP supports different QoS models, because it does not define 320 the QoS mechanisms and RMF that have to be used in a domain. As long 321 as a domain knows how to perform admission control for a given QSPEC, 322 QoS NSLP actually does not care how the specified constraints are 323 enforced and met, e.g., by putting the related data flow in the 324 topmost of four DiffServ classes, or by putting it into the third 325 highest of twelve DiffServ classes. The particular used QoS 326 configuration is up to the network provider of the domain. The QSPEC 327 can be seen as a common language to express QoS requirements between 328 different domains and QoS models. 330 In short, the functionality of the QoS NSLP includes: 331 o Conveying resource requests for unicast flows 332 o Resource requests (QSPEC) are decoupled from the signaling 333 protocol (QoS NSLP) 334 o Sender- and receiver-initiated reservations, as well as, bi- 335 directional 336 o Soft state and reduced refresh (keep-alive) signaling 337 o Session binding, session X can be valid only if session Y is too 338 o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy 339 mode) 340 o Protection against message re-ordering and duplication 341 o Group tear, tearing down several session with a single message 342 o Support for re-routing, e.g., due to mobility 343 o Support for request priorities and pre-emption 344 o Stateful and stateless nodes 345 o Reservation aggregation 347 5. NAT/Firewall Traversal NSLP 349 The NAT/Firewall Traversal NSLP [I-D.ietf-nsis-nslp-natfw] lets end- 350 hosts interact with NAT and firewall devices in the data path. 351 Basically it allows for a dynamic configuration of NATs and/or 352 firewalls along the data path in order to enable data flows to 353 traverse these devices without being obstructed. For instance, 354 firewall pinholes could be opened on demand by authorized hosts. 356 Furthermore, it is possible to block unwanted incoming traffic on 357 demand, e.g., if an end-host is under attack. 359 Basically NATFW signaling starts at the data sender (NSIS Initiator) 360 before any actual application data packets are sent. Signaling 361 messages may pass several NATFW NSLP-aware middleboxes (NSIS 362 Forwarder) on their way downstream and usually hit the receiver 363 (being the NSIS Responder). A proxy mode is also available for cases 364 where NATFW is not fully supported along the complete data path. 365 NATFW NSLP is based on a soft-state concept, i.e., the sender must 366 periodically repeat its request in order to keep it active. 368 Additionally, the protocol also provides functions for receivers 369 behind NATs. The receiver may request an external address that is 370 reachable from outside. The reserved external address must, however, 371 be communicated to the sender out-of-band by other means, e.g., by 372 application level signaling. After this step the data sender may 373 initiate a normal NATFW signaling in order to create firewall 374 pinholes. 376 6. Deploying the Protocols 378 First of all, NSIS implementations must be available in the 379 corresponding network nodes (i.e., routers, firewalls, or NAT 380 gateways) and end-hosts. That means not only GIST support, but also 381 the NSLPs and their respective control functions (such as a resource 382 management function for QoS admission control etc.) must be 383 implemented. In dependence on the specific NSLP, scenarios are also 384 supported where only one end-host is NSIS-capable and the end-host on 385 the other is not NSIS-capable. This is usually accomplished by 386 performing some kind of proxying functions in the domain of the 387 responding end-host. 389 Another important issue is that applications must be made NSIS-aware, 390 thereby requiring some effort on the applications programmer's side. 391 Yet, it is possible to implement separate applications to control, 392 e.g., the network QoS requests or firewall holes. 394 6.1. Obstacles 396 As there is network equipment with broken implementations of the 397 Router Alert Option deployed, there may be some obstacles for initial 398 deployment due to this legacy equipment. For controlled environments 399 an operation without RAO is also possible as GIST uses a specific UDP 400 port and a special magic number in order to detect Query signaling 401 messages reliably. 403 NAT gateways and firewalls may also hinder initial deployment of NSIS 404 protocols as they may either filter signaling traffic or perform 405 NSIS-unaware address translations. 407 7. Security Features 409 Basic security functions are provided at the GIST layer, e.g., 410 protection against some blind or denial-of-service attacks. 411 Conceptually it is difficult to protect against on-path attacker and 412 man-in-the-middle attacks, because a basic functionality of GIST is 413 to discover yet unknown signaling peers. Transport security can be 414 requested by signaling applications and is realized by using TLS 415 between signaling peers, i.e., authenticity and confidentiality of 416 signaling messages can be assured between peers. GIST allows for 417 mutual authentication of the signaling peers (using TLS means like 418 certificates) and can verify the authenticated identity against a 419 database of nodes authorized to take part in GIST signaling. It is, 420 however, a matter of policy that the identity of peers is verified 421 and accepted upon establishment of the secure TLS connection. 423 While GIST is handling authentication of peer nodes, more fine 424 grained authentication may be required in the NSLP protocols. There 425 is currently an ongoing work to specify common authorization 426 mechanisms to be used in NSLP protocols [I-D.manner-nsis-nslp-auth], 427 thus allowing, e.g., per-user and per-service authorization. 429 8. Extending the Protocols 431 This section discusses the ways to extend the NSIS protocols. One 432 key functionality of all three current protocols are the so-called 433 "Extensibility flags (AB)". The protocols can carry new experimental 434 objects, where the AB-flags can indicate whether a receiving node 435 must interpret the object, or whether it can just drop them or pass 436 them along in subsequent messages sent out further on the path. This 437 functionality allows defining new objects without forcing all network 438 entities to understand them. 440 8.1. GIST 442 GIST is extensible in several aspects. 443 o Use of different Message Routing Methods. Currently only two 444 message routing methods are supported (Path-coupled MRM and Loose- 445 End MRM), but further MRMs may be defined in the future. 446 o Use of different transport protocols. The initial handshake 447 allows a negotiation of the transport protocols to be used. 448 Currently, a proposal to add DCCP and DTLS to GIST exists 450 [I-D.manner-nsis-gist-dccp]. 451 o The AB-flags enable the community to specify new objects into 452 GIST, that can be carried inside a signaling session without 453 breaking existing implementations. The AB-flags can also be used 454 to indicate in a controlled fashion that a certain object must be 455 understood by all GIST nodes, which makes it possible to probe for 456 the support of an extension. One such object already designed is 457 the "Peering Information Object (PIO)" 458 [I-D.manner-nsis-peering-data] that allows a QUERY message to 459 carry additional peering data for the recipient for making the 460 peering decision. 462 8.2. QoS NSLP 464 A foreseen development within the QoS signaling is the introduction 465 of new QoS Models to enable deployment of NSIS in specific scenarios. 466 One such example is the Integrated Services Controlled Load Service 467 for NSIS [I-D.kappler-nsis-qosmodel-controlledload]. 469 There is already work to extend the base QoS NSLP and GIST to enable 470 new QoS signaling scenarios. One such proposal is the Inter-Domain 471 Reservation Aggregation aiming to support large-scale deployment of 472 the QoS NSLP [I-D.bless-nsis-resv-aggr]. Another current proposal 473 seeks to extend the whole NSIS framework towards path-decoupled 474 signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. 476 8.3. NAT/Firewall NSLP 478 The NATFW signaling can be extended in the same way as the QoS NSLP. 479 No proposals currently exist to fulfill new use cases for the 480 protocol. 482 8.4. New NSLP protocols 484 Designing a new NSLP is both challenging and easy. On one hand, GIST 485 provides many important functions through its service layer API, and 486 allows the signaling application programmer to offload, e.g., the 487 channel security, transport characteristics and signaling node 488 discovery to GIST. 490 Yet, on the other hand, the signaling application designer must take 491 into account that the network environment can be dynamic, both in 492 terms of routing and node availability. The new NSLP designer must 493 take into account at least the following issues: 495 o Routing changes, e.g., due to mobility: GIST sends Network 496 Notifications when something happens in the network, e.g., peers 497 or routing paths change. All signaling applications must be able 498 to handle these notifications and act appropriately. GIST does 499 not include logic to figure out what the NSLP would want to do due 500 to a certain network event. Therefore, GIST gives the 501 notification to the application, and lets it make the right 502 decision. 503 o GIST indications: GIST will also send other notifications, e.g., 504 if a signaling peer does not reply to refresh messages, or a 505 certain NSLP message was not successfully delivered to the 506 recipient. Again, NSLP applications must be able to handle these 507 events, too. Appendix B in the GIST specification discusses the 508 GIST-NSLP API and the various functionality required, but 509 implementing this interface can be quite challenging; the 510 multitude of asynchronous notifications than can from GIST 511 increases the implementation complexity of the NSLP. 512 o Lifetime of the signaling flow: NSLPs should inform GIST when a 513 flow is no longer needed using the SetStateLifetime primitive. 514 This reduces bandwidth demands in the network. 515 o NSLP IDs: there is a limited number of NSLP IDs available for 516 experimental use. In practise, a new signaling protocol will 517 eventually require its own NSLP ID number. 518 o Source IP address: It is sometimes challenging to find out at the 519 NSLP, what will the source IP address be, especially when a node 520 has multiple interfaces. Moreover, the logic in specifying the 521 source IP address may differ if the node processing an NSLP 522 message is the source of the signaling flow, or an intermediate 523 node on the signaling. Thus, the NSLP must be able to find out 524 the right source IP address from its internal interfaces, and its 525 location on the signaling. 526 o New MRMs: GIST defines currently two Message Routing Methods, and 527 leave the door open for new ideas. Thus, it is possible that a 528 new NSLP also requires a new MRM, path-decoupled routing being one 529 example. 531 The informational API between GIST and NSLPs (see Appendix B in 532 [I-D.ietf-nsis-ntlp]) is very important to understand. It does not 533 specify the exact messaging between GIST and the NSLPs but gives an 534 understanding of the interactions, especially what kinds of 535 asynchronous notifications from GIST the NSLP must be prepared to 536 handle. 538 9. Security Considerations 540 This document provides information to the community. It does not 541 raise new security concerns. 543 10. Acknowledgements 545 Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of 546 this draft and valuable input. 548 11. References 550 11.1. Normative References 552 [I-D.ietf-nsis-nslp-natfw] 553 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 554 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 555 draft-ietf-nsis-nslp-natfw-16 (work in progress), 556 November 2007. 558 [I-D.ietf-nsis-ntlp] 559 Schulzrinne, H. and R. Hancock, "GIST: General Internet 560 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 561 progress), July 2007. 563 [I-D.ietf-nsis-qos-nslp] 564 Manner, J., "NSLP for Quality-of-Service Signaling", 565 draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. 567 [I-D.ietf-nsis-qspec] 568 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 569 QSPEC Template", draft-ietf-nsis-qspec-18 (work in 570 progress), October 2007. 572 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 573 RFC 3726, April 2004. 575 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 576 Bosch, "Next Steps in Signaling (NSIS): Framework", 577 RFC 4080, June 2005. 579 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 580 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 582 11.2. Informative References 584 [I-D.bless-nsis-resv-aggr] 585 Doll, M. and R. Bless, "Inter-Domain Reservation 586 Aggregation for QoS NSLP", draft-bless-nsis-resv-aggr-01 587 (work in progress), July 2007. 589 [I-D.braden-2level-signal-arch] 590 Braden, R. and B. Lindell, "A Two-Level Architecture for 591 Internet Signaling", draft-braden-2level-signal-arch-01 592 (work in progress), November 2002. 594 [I-D.cordeiro-nsis-hypath] 595 Cordeiro, L., "GIST Extension for Hybrid On-path Off-path 596 Signaling (HyPath)", draft-cordeiro-nsis-hypath-04 (work 597 in progress), July 2007. 599 [I-D.kappler-nsis-qosmodel-controlledload] 600 Kappler, C., "A QoS Model for Signaling IntServ 601 Controlled-Load Service with NSIS", 602 draft-kappler-nsis-qosmodel-controlledload-05 (work in 603 progress), July 2007. 605 [I-D.manner-nsis-gist-dccp] 606 Manner, J., "Generic Internet Signaling Transport over 607 DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in 608 progress), June 2007. 610 [I-D.manner-nsis-nslp-auth] 611 Manner, J., "Authorization for NSIS Signaling Layer 612 Protocols", draft-manner-nsis-nslp-auth-03 (work in 613 progress), March 2007. 615 [I-D.manner-nsis-peering-data] 616 Manner, J., "Peering Data for NSIS Signaling Layer 617 Protocols", draft-manner-nsis-peering-data-00 (work in 618 progress), June 2007. 620 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 621 Services in the Internet Architecture: an Overview", 622 RFC 1633, June 1994. 624 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 625 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 626 Functional Specification", RFC 2205, September 1997. 628 [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of- 629 Service Signaling Protocols", RFC 4094, May 2005. 631 Authors' Addresses 633 Jukka Manner 634 Helsinki University of Technology (TKK) 635 P.O. Box 3000 636 Espoo FIN-02015 TKK 637 Finland 639 Phone: +358 9 451 2481 640 Email: jukka.manner@tkk.fi 641 URI: http://www.netlab.tkk.fi/~jmanner/ 643 Roland Bless 644 Institute of Telematics, Universitaet Karlsruhe (TH) 645 Zirkel 2 646 Karlsruhe 76128 647 Germany 649 Phone: +49 721 608 6413 650 Email: bless@tm.uka.de 651 URI: http://www.tm.uka.de/~bless 653 Full Copyright Statement 655 Copyright (C) The IETF Trust (2008). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 664 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 665 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 666 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 Acknowledgment 695 Funding for the RFC Editor function is provided by the IETF 696 Administrative Support Activity (IASA).