Using and Extending the NSIS Protocol Family
draft-ietf-nsis-ext-05.txt

Abstract

This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS working group during the period 2001-2009 together with suggestions on how the industry can make use of the new protocols, and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 20, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  The NSIS Architecture
3.  The General Internet Signaling Transport
4.  Quality of Service NSLP
5.  NAT/Firewall Traversal NSLP
6.  Deploying the Protocols
    6.1.  Deployment Issues Due to Use of RAO
    6.2.  Deployment Issues with NATs and Firewalls
    6.3.  Incremental Deployment and Workarounds
7.  Security Features
8.  Extending the Protocols
    8.1.  Overview of Administrative Actions Needed When Extending NSIS
    8.2.  GIST
        8.2.1.  Use of Different Message Routing Methods
        8.2.2.  Use of Different Transport Protocols or Security Capabilities
        8.2.3.  Use of Alternative Security Services
        8.2.4.  Query Mode Packet Interception Schemes
        8.2.5.  Use of Alternative NAT Traversal Mechanisms
        8.2.6.  Additional Error Identifiers
        8.2.7.  Defining New Objects to be Carried in GIST
        8.2.8.  Adding New Message Types
    8.3.  QoS NSLP
    8.4.  QoS Specifications
    8.5.  NAT/Firewall NSLP
    8.6.  New NSLP Protocols
9.  Security Considerations
10.  IANA Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Next Steps in Signaling (NSIS) Working Group was formed in November 2001 to develop an Internet signaling protocol suite that would attempt to remedy some of the perceived shortcomings of solutions based on the Resource ReSerVation Protocol (RSVP), e.g., with respect to mobility and Quality of Service (QoS) interoperability. The initial charter was focused on QoS signaling as the first use case, taking as the background for the work RSVP. In May 2003, middlebox traversal was added as an explicit second use case. The requirements for the new generation of signaling protocols are documented in [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.) and an analysis of existing signaling protocols can be found in [RFC4094] (Manner, J. and X. Fu, “Analysis of Existing Quality-of-Service Signaling Protocols,” May 2005.).

The design of NSIS is based on a two-layer model, where a general signaling transport layer provides services to an upper signaling application layer. The design was influenced by Bob Braden's Internet Draft entitled "A Two-Level Architecture for Internet Signaling" [I‑D.braden‑2level‑signal‑arch] (Braden, R. and B. Lindell, “A Two-Level Architecture for Internet Signaling,” November 2002.).

This document gives an overview of the NSIS framework and protocol suite is at the time of writing (2009), providing an introduction to the use cases for which the current version of NSIS was designed, notes on how to deploy NSIS in existing networks and summarizing how the protocol suite can be enhanced to satisfy new use cases.

2.  The NSIS Architecture

The design of the NSIS protocol suite reuses ideas and concepts from RSVP but essentially divides the functionality into two layers. The lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge of transporting the higher layer protocol messages to the next signaling node on the path. This includes discovery of the next hop NSIS node, which may not be the next routing hop, and different transport and security services depending on the signaling application requirements. The General Internet Signaling Transport (GIST) [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.) has been developed as the protocol that fulfills the role of the NTLP. The NSIS protocol suite supports both IP protocol versions, IPv4 and IPv6.

The actual signaling application logic is implemented in the higher layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). While GIST is only concerned with transporting NSLP messages hop-by-hop between pairs of signalling nodes, the end-to-end signaling functionality is provided by the NSLP protocols if needed. Not all NSLP protocols need to perform end-to-end signaling. The current protocols have features to confine the signaling to a limited part of the path (such as the interior of a domain). Messages transmitted by GIST on behalf of an NSLP are identified by a unique NSLP identifier (NSLPID) associated with the NSLP. Two NSLP protocols are currently standardized: one concerning Quality of Service signaling and one to enable NAT/Firewall traversal.

NSIS is primarily designed to provide the signaling needed to install state on nodes that lie on the path that will be taken by some end-to-end flow of data packets; the state installed should facilitate or enhance some characteristic of the data flow. This is typically achieved by routing signaling messages along the same path (known as "path-coupled signaling") and intercepting the signaling message at NSIS capable nodes. However, the NSIS architecture is designed to be flexible, and the routing of signaling messages is controlled by the Message Routing Method (MRM) that is applied to the signaling messages. The initial specifications define two MRMs:

• the basic Path-Coupled MRM designed to drive signaling along the path that will be followed by the data flow, and
• an alternative Loose End MRM which is applicable for preconditioning the state in firewalls and Network Address Translation (NAT) middleboxes when data flow destinations lie behind this sort of middlebox. Without preconditioning these middleboxes will generally reject signalling messages originating outside the region 'protected' by the middlebox and where the destination is located.

Parameters carried by each signaling message drive the operation of the relevant transport or signaling application. In particular, the messages will carry Message Routing Information (MRI) that will allow the NSIS nodes to identify the data flow to which the signaling applies. Generally, the intercepted messages will be reinjected into the network after processing by the NSIS entities and routed further towards the destination, possibly being intercepted by additional NSIS capable nodes before arriving at the flow endpoint.

As with RSVP, it is expected that the signaling message will make a complete round trip either along the whole end-to-end path or a part of it if the scope of the signaling is limited. This implements a two-phase strategy in which capabilities are assessed and provisional reservations are made on the outbound leg; these provisional reservations are then confirmed and operational state installed on the return leg. Unlike RSVP, signaling is normally initiated at the source of the data flow making it easier to ensure that the signaling follows the expected path of the data flow, but can also be receiver initiated as in RSVP.

A central concept of NSIS is the Session Identifier (SID). Signaling application states are indexed and referred to through the SID in all the NSLPs. This decouples the state information from IP addresses, allowing dynamic IP address changes for signaling flows, e.g., due to mobility: changes in IP addresses do not force complete tear down and re-initiation of a signaling application state, merely an update of the state parameters in the NSLP(s), especially the MRI.

At the NTLP (GIST) layer the SID is not meaningful by itself, but is rather used together with the NSLP identifier (NSLPID) and the Message Routing Information (MRI). This 3-tuple is used by GIST to index and manage the signaling flows. Changes of routing or dynamic IP address changes, e.g., due to mobility, will require GIST to modify the Messaging Associations (MAs) that are used to channel NSLP messages between adjacent GIST peers in order to satisfy the NSLP MRI for each SID.

The following design restrictions were imposed for the first phase of the protocol suite. They may be lifted in future and new functionality may be added into the protocols at some later stage.

• Initial focus on MRMs for path-coupled signaling: GIST transports messages towards an identified unicast data flow destination based on the signaling application request, and does not directly support path-decoupled signaling, e.g., QoS signaling to a bandwidth broker or other off-path resource manager. The framework also supports a "Loose-End" message routing method used to discover GIST nodes with particular properties in the direction of a given address, for example the NAT/FW NSLP uses this method to discover a NAT along the upstream data path.
• No multicast support: Introducing support for multicast was deemed too much overhead, considering the currently limited support for global IP multicast. Thus, the current GIST and the NSLP specifications consider unicast flows only.

The key documents specifying the NSIS framework are:

• Requirements for Signaling Protocols [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.)
• Next Steps in Signaling: Framework [RFC4080] (Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, “Next Steps in Signaling (NSIS): Framework,” June 2005.)
• Security Threats for NSIS [RFC4081] (Tschofenig, H. and D. Kroeselberg, “Security Threats for Next Steps in Signaling (NSIS),” June 2005.)

The protocols making up the suite specified by the NSIS working group are documented in:

• The General Internet Signaling Transport protocol [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.)
• Quality of Service NSLP (QoS NSLP) [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.)
• The QoS specification template [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.)
• NAT/Firewall traversal NSLP [I‑D.ietf‑nsis‑nslp‑natfw] (Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” April 2010.)

The next three sections provide a brief survey of GIST, the QoS NSLP, and the NAT/Firewall NSLP.

3.  The General Internet Signaling Transport

The General Internet Signaling Transport (GIST) [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.) provides a signaling transport and security services to NSIS Signaling Layer Protocols (NSLP) and the associated signaling applications. GIST does not define new IP transport protocols or security mechanisms but rather makes use of existing protocols, such as TCP, UDP, TLS and IPsec. Applications can indicate the desired transport attributes for the signaling flow, e.g., unreliable or reliable, and GIST then chooses the most appropriate transport protocol(s) to achieve the goals of the flow. GIST will normally use UDP if unreliable signaling is adequate, TCP if reliability is required and TLS over TCP for secure (and reliable) signaling flows. The GIST layered protocol stack is shown in Figure 1 (The NSIS protocol stack).

             +-----+ +--------+ +-------+
             |     | |        | |       |
             | QoS | | NAT/FW | |  ...  |       NSLP
             |     | |        | |       |
             +-----+ +--------+ +-------+

----------------------------------------------------------------------
             +--------------------------+
             |                          |
             |          GIST            |       NTLP
             |                          |
             +--------------------------+

----------------------------------------------------------------------
             +--------------------------+
             |           TLS            |
             +--------------------------+
             +--------------------------+
             | TCP | UDP | SCTP | DCCP  |
             +--------------------------+
             +--------------------------+
             |         IPsec            |
             +--------------------------+
             +--------------------------+
             |    IPv4     |    IPv6    |
             +--------------------------+

GIST divides up the end-to-end path to be taken by the data flow into a number of segments between pairs of NSIS aware peer nodes located along the path. Not every router or other middlebox on the path needs to be NSIS aware: each segment of the signaling path may incorporate several routing hops. Also not every NSIS aware node necessarily implements every possible signaling application. If the signaling for a flow requests services from a subset of the applications, then only nodes that implement those services are expected to participate as peers, and even some of these nodes can decline to operate on a particular flow if, for example, the additional load might overload the processing capability of the node. These characteristics mean that incremental deployment of NSIS capabilities is possible both with the initial protocol suite, and for any future NSLP applications that might be developed. The following paragraphs describe how a signaling segment is setup offering the transport and security characteristics needed by a single NSLP.

When an NSLP application wants to send a message towards a flow endpoint, GIST starts the process of discovering the next signaling node by sending a Query message towards the destination of the related data flow. This Query carries the NSLP identifier (NSLPID) and Message Routing Information (MRI) among others. The MRI contains enough information to control the routing of the signaling message and identify the associated data flow. The next GIST node on the path receives the message and if it is running the same NSLP, it provides the MRI to the NSLP application and requests it to make a decision on whether to peer with the querying node. If the NSLP application chooses to peer, GIST sets up a Message Routing State (MRS) between the two nodes for the future exchange of NSLP data. State setup is performed by a three-way handshake that allows for negotiation of signaling flow parameters and provides counter-measures against several attacks like denial-of-service by using cookie mechanisms and a late state installation option.

If a transport connection is required and needs to provide for reliable or secure signaling, like TCP or TLS/TCP, a Messaging Association (MA) is established between the two peers. An MA can be re-used for signaling messages concerning several different data flows, i.e., signaling messages between two nodes are multiplexed over the same transport connection. This can be done when the transport requirements (reliability, security) of a new flow can be met with an existing MA, i.e., the security and transport properties of an existing MA are equivalent or better than what is requested for a potential new MA.

For path-coupled signaling, we need to find the nodes on the data path that should take part in the signaling of an NSLP and invoke them to act on the arrival of such NSLP signaling messages. The basic concept is that such nodes along a flow's data path intercept the corresponding signaling packets and are thus discovered automatically. GIST places a Router Alert Option (RAO) in Query message packets to ensure that they are intercepted by relevant NSIS aware nodes as in RSVP.

Late in the development of GIST serious concerns were raised in the IETF about the security risks and performance implications of extensive usage of the RAO [I‑D.rahman‑rtg‑router‑alert‑dangerous] (Rahman, R. and D. Ward, “Use of IP Router Alert Considered Dangerous,” October 2008.). Additionally evidence was discovered indicating that several existing implementations of RAO were inconsistent with the (intention of the) standards and would not support the NSIS usage. There were also concerns that extending the need for RAO recognition in the fast path of routers that are frequently implemented in hardware would delay or deter implementation and deployment of NSIS. Eventually it was decided that NSIS would continue to specify RAO as its primary means for triggering interception of signaling messages in intermediate nodes on the data path, but the protocol suite would be published with Experimental status rather than on the Standards Track while deployment experience was gathered. More information about the use of RAO in GIST can be found in [I‑D.hancock‑nsis‑gist‑rao] (Hancock, R., “Using the Router Alert Option for Packet Interception in GIST,” November 2008.). Also the deployment issues that arise from the use of RAO are discussed in Section 6.1 (Deployment Issues Due to Use of RAO).

Alternative mechanisms have been considered to allow nodes to recognise NSIS signaling packets that should be intercepted. For example NSIS nodes could recognise UDP packets directed to a specific destination port as Query messages that need to be intercepted even though they are not addressed to the intercepting node. GIST provides for the use of such alternatives as a part of its extensibility design. NSIS recognises that the workload imposed by intercepting signaling packets could be considerable relative to the work needed just to forward such packets. To keep the necessary load to a minimum NSIS provides mechanisms to limit the number of interceptions needed by constraining the rate of generation and allowing for intentional bypassing of signaling nodes that are not affected by particular signaling requests. This can be accomplished either in GIST or in the NSLP.

Since GIST carries information about the data flow inside its messages (in the MRI), NAT gateways must be aware of GIST in order to let it work correctly. GIST provides a special object for NAT traversal so that the actual translation is disclosed if a GIST-aware NAT gateway provides this object.

As with RSVP, all the state installed by NSIS protocols is "soft-state" that will expire and be automatically removed unless it is periodically refreshed. NSIS state is held both at the signaling application layer and in the signaling transport layer, and is maintained separately. NSLPs control the lifetime of the state in the signaling application layer by setting a timeout and sending periodic "keep alive" messages along the signaling path if no other messages are required. The MAs and the routing state are maintained semi-independently by the transport layer, because MAs may be used by multiple NSLP sessions, and can also be recreated "on demand" if the node needs to reclaim resources. The transport layer can send its own "keep alive" messages across a MA if no NSLP messages have been sent, for example if the transport layer decides to maintain a heavily used MA even though there is no current NSLP session using it. State can also be deleted explicitly when no longer needed.

If there is a change in the route used by a flow for which NSIS has created state, NSIS needs to detect the change in order to determine if the new path contains additional NSIS nodes that should have state installed. GIST may use a range of triggers in order to detect a route change. It probes periodically for the next peer by sending a GIST Query, thereby detecting a changed route and GIST peer. GIST monitors routing tables, the GIST peer states, and notifies NSLPs of any routing changes. It is then up to the NSLPs to act appropriately, if needed, e.g., by issuing a refresh message. The periodic queries also serve to maintain the soft-state in nodes as long as the route is unchanged.

In summary, GIST provides several services in one package to the upper layer signaling protocols:

• Signaling peer discovery: GIST is able to find the next hop node that runs the NSLP being signaled for.
• Multiplexing: GIST reuses already established signaling relationships and messaging associations to next hop peers if the signaling flows require the same transport attributes.
• Transport: GIST provides transport with different attributes, namely reliable/unreliable and secure/unsecure.
• Confidentiality: If security is requested, GIST uses TLS to provide an encrypted and integrity protected message transport to the next signaling peer.
• Routing changes: GIST detects routing changes, but instead of acting on its own, it merely sends a notification to the local NSLP. It is then up to the NSLP to act.
• Fragmentation: GIST uses either a known Path MTU for the next hop or limits its message size to 576 bytes when using UDP, and especially for Query mode messages. If fragmentation is required it automatically establishes an MA and sends the signaling traffic over a reliable protocol, e.g., TCP.
• State maintenance: GIST establishes and then maintains the soft-state that controls communications through MAs between GIST peers along the signaling path, according to usage parameters supplied by NSLPs and local policies.

4.  Quality of Service NSLP

The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP) establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of RFC 3726 [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.). No support for QoS architectures based on bandwidth brokers or other off-path resource managers is currently included.

The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.), and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path). The QoS NSLP extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.), in particular support of sender or receiver-initiated reservations, as well as, a type of bi-directional reservation and support of reservations between arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other hand, there is currently no support for IP multicast.

A distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). RMF-related information is carried in the QSpec (QoS Specification) object in QoS NSLP messages. This is similar to the decoupling between RSVP and the IntServ architecture, RFC 1633 [RFC1633] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.). The QSpec carries information on resources available, resources required, traffic descriptions and other information required by the RMF. A template for Qspec objects is defined in [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.). This provides a number of basic parameter objects that can be used as a common language to specify components of concrete QoS models. The objects defined in [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.) provide the building blocks for many existing QoS models such as those associated with RSVP and Differentiated Services. The extensibility of the template allows new QoS model specifications to extend the template language as necessary to support these specifications.

The QoS NSLP supports different QoS models, because it does not define the QoS mechanisms and RMF that have to be used in a domain. As long as a domain knows how to perform admission control for a given QSpec, QoS NSLP actually does not care how the specified constraints are enforced and met, e.g., by putting the related data flow in the topmost of four DiffServ classes, or by putting it into the third highest of twelve DiffServ classes. The particular QoS configuration used is up to the network provider of the domain. The QSpec can be seen as a common language to express QoS requirements between different domains and QoS models.

In short, the functionality of the QoS NSLP includes:

• Conveying resource requests for unicast flows
• Resource requests (QSpec) that are decoupled from the signaling protocol (QoS NSLP)
• Sender- and receiver-initiated reservations, as well as, bi-directional
• Soft-state and reduced refresh (keep-alive) signaling
• Session binding, session X can be valid only if session Y is too
• Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy mode)
• Protection against message re-ordering and duplication
• Group tear, tearing down several session with a single message
• Support for re-routing, e.g., due to mobility
• Support for request priorities and preemption
• Stateful and stateless nodes: stateless operation is particularly relevant in core networks where large amounts of QoS state could easily overwhelm a node
• Reservation aggregation

The protocol also provides for a proxy mode to allow the QoS signaling to be implemented without needing all end hosts to be capable of handling NSIS signaling.

The QSpec Template supports situations where the QoS parameters need to be fine-grained, specifically targeted to an individual flow in one part of the network (typically the edge or access part) but might need to be more coarse-grained, where the flow is part of an aggregate (typically in the core of the network).

5.  NAT/Firewall Traversal NSLP

The NAT/Firewall Traversal NSLP [I‑D.ietf‑nsis‑nslp‑natfw] (Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” April 2010.) lets end-hosts interact with NAT and firewall devices in the data path. Basically it allows for a dynamic configuration of NATs and/or firewalls along the data path in order to enable data flows to traverse these devices without being obstructed. For instance, firewall pinholes could be opened on demand by authorized hosts. Furthermore, it is possible to block unwanted incoming traffic on demand, e.g., if an end-host is under attack.

Configurations to be implemented in NAT and firewall devices signaled by the NAT/Firewall NSLP take the form of a (Pattern, Action) pair, where the pattern specifies a template for packet header fields to be matched. The device is then expected to apply the specified action to any passing packet that matches the template. Actions are currently limited to ALLOW (forward the packet) and DENY (drop the packet). The template specification allows for a greater range of packet fields to be matched than those allowed for in the GIST MRI.

Basically NAT/Firewall signaling starts at the data sender (NSIS Initiator) before any actual application data packets are sent. Signaling messages may pass several NAT/Firewall NSLP-aware middleboxes (NSIS Forwarder) on their way downstream and usually hit the receiver (being the NSIS Responder). A proxy mode is also available for cases where the NAT/Firewall NSLP is not fully supported along the complete data path. NAT/Firewall NSLP is based on a soft-state concept, i.e., the sender must periodically repeat its request in order to keep it active.

Additionally, the protocol also provides functions for receivers behind NATs. The receiver may request an external address that is reachable from outside. The reserved external address must, however, be communicated to the sender out-of-band by other means, e.g., by application level signaling. After this step the data sender may initiate a normal NAT/Firewall signaling in order to create firewall pinholes.

The protocol also provides for a proxy mode to allow the NAT/Firewall signaling to be implemented without needing all end hosts to be capable of handling NSIS signaling.

6.  Deploying the Protocols

The initial version of the NSIS protocol suite is being published with the status of Experimental Protocols in order to gain deployment experience. Concerns over the security, implementation and administrative issues surrounding the use of RAO are likely to mean that initial deployments occur in 'walled gardens' where the characteristics of hardware in use are well known and there is a high level of trust and control over the end nodes that use the protocols. This section addresses issues that need to be considered in a deployment of the NSIS protocol suite.

First of all, NSIS implementations must be available in at least some of the corresponding network nodes (i.e., routers, firewalls, or NAT gateways) and end-hosts. That means not only GIST support, but also the NSLPs and their respective control functions (such as a resource management function for QoS admission control etc.) must be implemented. NSIS is capable of incremental deployment and an initial deployment does not need to involve every node in a network domain. This is discussed further in Section 6.3 (Incremental Deployment and Workarounds). There are a number of obstacles that may be encountered due to broken implementations of RAO (see Section 6.1 (Deployment Issues Due to Use of RAO)) and firewalls or NATs dropping NSIS signaling packets (see Section 6.2 (Deployment Issues with NATs and Firewalls)).

Another important issue is that applications may need to be made NSIS-aware, thereby requiring some effort on the applications programmer's behalf. Alternatively, it may be possible to implement separate applications to control, e.g., the network QoS requests or firewall pinholes, without needing to update the actual applications that will take advantage of NSIS capabilities.

6.1.  Deployment Issues Due to Use of RAO

The standardized version of GIST depends on routers and other middleboxes correctly recognizing and acting on packets containing RAO. There are a number of problems related to RAO that can obstruct a deployment of NSIS:

• Some implementations do not respond to RAO at all.
• Some implementations respond but do not distinguish between the RAO parameter values in IP version 4 (IPv4) packets or reject anything except 0 (in which case only the value 0 can be used)
• The response to RAO in a GIST Query mode packet, which is sent using the UDP transport, is to dispatch the packet to the UDP stack in the intercepting node rather than a function associated with the RAO parameter. Since the node will not normally have a normal UDP receiver for these packets they are dropped
• The major security concern with RAO in NSIS is that it provides a new vector for hosts to mount a (Distributed) Denial of Service (DDOS) attack on the control plane of routers on the data path. Such attacks have occurred and it is therefore normal for service providers to prohibit "host-to-router" signaling packets such as RSVP or NSIS from entering their networks from customer networks. This will tend to limit the deployment of NSIS to "walled gardens" unless a suitable mitigation of the DDOS threat can be found and deployed.

In order to deploy NSIS effectively routers and other hardware needs to be selected and correctly configured to respond to RAO and dispatch intercepted packets to the NSIS function.

A further obstacle results from likelihood that IPv4 packets with IP options of any kind will be filtered and dropped by firewalls and NATs. In many cases this is the default behavior so that explicit configuration is needed to allow packets carrying the RAO to pass through. The general inclination of domain administrators is to deny access to packets carrying IP options because of the security risks and the additional load on the routers in the domain. The situation with IPv6 may be easier as the RAO option in IPv6 is better defined but the security concerns remain.

Deployment issues are discussed at more length in Appendix C of the GIST specification [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

6.2.  Deployment Issues with NATs and Firewalls

NAT gateways and firewalls may also hinder initial deployment of NSIS protocols for several reasons:

• They may filter and drop signaling traffic as described in Section 6.1 (Deployment Issues Due to Use of RAO) to deny access to packets containing IP options.
• They may not permit "unsolicited" incoming GIST Query mode packets. This behavior has been anticipated in the design of the protocols but requires additional support to ensure that the middleboxes are primed to accept the incoming queries (see [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.) and [I‑D.ietf‑nsis‑nslp‑natfw] (Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” April 2010.)).
• NATs that are not aware of the NSIS protocols will generally perform address translations that are not coordinated with the NSIS protocols. Since NSIS signaling messages may be carrying embedded IP addresses affected by these translations, it may not be possible to operate NSIS through such legacy NATs. The situation and workarounds are discussed in Section 7.2.1 of [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

6.3.  Incremental Deployment and Workarounds

NSIS is specifically designed to be incrementally deployable. It is not required that all nodes on the signaling and data path are NSIS aware. To make any use of NSIS at least two nodes on the path need to be NSIS aware. However, it is not essential that the initiator and receiver of the data flow are NSIS aware. Both the QoS and NAT/Firewall NSLPs provide "proxy modes" in which nodes adjacent to the initiator and/or receiver can act as proxy signaling initiator or receiver. An initiator proxy can monitor traffic and, hopefully, detect when a data flow of a type needing NSIS support is being initiated. The proxies can act more or less transparently on behalf of the data flow initiator and/or receiver to set up the required NSIS state and maintain it while the data flow continues. This capability reduces the immediate need to modify all the data flow end points before NSIS is viable.

7.  Security Features

Basic security functions are provided at the GIST layer, e.g., protection against some blind or denial-of-service attacks, but note that introduction of alternative MRMs may provide attack avenues that are not present with the current emphasis on the path-coupled MRM. Conceptually it is difficult to protect against on-path attacker and man-in-the-middle attacks when using path-coupled MRMs, because a basic functionality of GIST is to discover yet unknown signaling peers. Transport security can be requested by signaling applications and is realized by using TLS between signaling peers, i.e., authenticity and confidentiality of signaling messages can be assured between peers. GIST allows for mutual authentication of the signaling peers (using TLS means like certificates) and can verify the authenticated identity against a database of nodes authorized to take part in GIST signaling. It is, however, a matter of policy that the identity of peers is verified and accepted upon establishment of the secure TLS connection.

While GIST is handling authentication of peer nodes, more fine grained authorization may be required in the NSLP protocols. There is currently an ongoing work to specify common authorization mechanisms to be used in NSLP protocols [I‑D.manner‑nsis‑nslp‑auth] (Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, “Authorization for NSIS Signaling Layer Protocols,” July 2008.), thus allowing, e.g., per-user and per-service authorization.

8.  Extending the Protocols

This section discusses the ways that are available to extend the NSIS protocol suite. The Next Steps in Signaling (NSIS) Framework [RFC4080] (Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, “Next Steps in Signaling (NSIS): Framework,” June 2005.) describes a two-layer framework for signaling on the Internet, comprising a generic transport layer with specific signaling layer protocols to address particular applications running over this transport layer. The model is designed to be highly extensible so that it can be adapted for different signaling needs.

It is expected that additional signaling requirements will be identified in future. The two layer approach allows for NSLP signaling applications to be developed independently of the transport protocol. Further NSLPs can therefore be developed and deployed to meet these new needs using the same GIST infrastructure thereby providing a level of macro-extensibility. However, the GIST protocol and the two signaling applications have been designed so that additional capabilities can be incorporated into the design should additional requirements within the general scope of these protocols need to be accommodated.

The NSIS framework is also highly supportive of incremental deployment. A new NSLP need not be available on every NSIS aware node in a network or along a signaling path in order to start using it. Nodes that do not (yet) support the application will forward its signaling messages without complaint until it reaches a node where the new NSLP application is deployed.

One key functionality of parameter objects carried in NSIS protocols is the so-called "Extensibility flags (AB)". All the existing protocols (and any future ones conforming to the standards) can carry new experimental objects, where the AB-flags can indicate whether a receiving node must interpret the object, or whether it can just drop them or pass them along in subsequent messages sent out further on the path. This functionality allows defining new objects without forcing all network entities to understand them.

8.1.  Overview of Administrative Actions Needed When Extending NSIS

Generally, NSIS protocols can be extended in multiple ways, many of which require the allocation of unique code point values in registries maintained by IANA on behalf of the IETF. This section is an overview of the administrative mechanisms that might apply. The extensibility rules are based upon the procedures by which IANA assigns values: "Standards Action" (as defined in [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.)), "IETF Action", "Expert Review", and "Organization/Vendor Private", defined below. The appropriate procedure for a particular type of code point is defined in one or other of the NSIS protocol documents, mostly [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

In addition to registered code points, all NSIS protocols provide code points that can be used for experimentation, usually within closed networks, as explained in [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.). There is no guarantee that independent experiments will not be using the same code point!

8.2.  GIST

GIST is extensible in several aspects covered in the subsections below. In these subsections, references to document sections refer to the GIST specification [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.). The bullet points at the end of each subsection specify the formal administrative actions that would need to carried out when a new extension was standardised.

More generally, as asserted in Section 1 of the GIST specification, the GIST design could be extended to cater for multicast flows and for situations where the signaling is not tied to an end-to-end data flow. However it is not clear whether this could be done in a totally backwards compatible way, and is not considered within the extensibility model of NSIS.

8.2.1.  Use of Different Message Routing Methods

Currently only two message routing methods are supported (Path-coupled MRM and Loose-End MRM), but further MRMs may be defined in the future. See Section 3.8. One possible additional MRM under development is documented in [I‑D.bless‑nsis‑est‑mrm] (Bless, R., “An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol,” July 2008.). This MRM would direct signaling towards an explicit target address other than the (current) data flow destination and is intended to assist setting up of state on a new path during "make-before-break" handover sequences in mobile operations. Note that alternative routing methods may require modifications to the firewall traversal techniques used by GIST and NSLPs.

• New MRMs require allocation of a new MRM-ID either by standards action or expert review [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

8.2.2.  Use of Different Transport Protocols or Security Capabilities

The initial handshake between GIST peers allows a negotiation of the transport protocols to be used. Currently, proposals exist to add the Datagram Congestion Control Protocol (DCCP) [I‑D.manner‑nsis‑gist‑dccp] (Manner, J., “Generic Internet Signaling Transport over DCCP and DTLS,” June 2007.) and the Sream Control Transport Protocol (SCTP) [I‑D.ietf‑nsis‑ntlp‑sctp] (Fu, X., Dickmann, C., and J. Crowcroft, “General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS),” April 2010.) transports to GIST, in each case using Datagram TLS (DTLS) to provide security. See Sections 3.2 and 5.7. GIST expects alternative capabilities to be treated as selection of an alternative protocol stack. Within the protocol stack, the individual protocols used are specified by MA Protocol IDs which are allocated from an IANA registry if new protocols are to be used. See Sections 5.7 and 9.

• Use of an alternative transport protocol or security capability requires allocation of a new MA-Protocol-ID either by standards action or expert review [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

8.2.3.  Use of Alternative Security Services

Currently only TLS is specified for providing secure channels with MAs. Section 3.9 suggests that alternative protocols could be used, but the interactions with GIST functions would need to be carefully specified. See also Section 4.4.2.

• Use of an alternative security service requires allocation of a new MA-Protocol-ID either by standards action or expert review [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

8.2.4.  Query Mode Packet Interception Schemes

GIST has standardized a scheme using RAO mechanisms[I‑D.hancock‑nsis‑gist‑rao] (Hancock, R., “Using the Router Alert Option for Packet Interception in GIST,” November 2008.) with UDP packets. If the difficulties of deploying the RAO scheme prove insuperable in particular circumstances, alternative interception schemes can be specified. One proposal that was explored for GIST used UDP port recognition in routers rather than RAO mechanisms to drive the interception of packets. See Sections 5.3.2 and 5.3.2.5. Each NSLP needs to specify membership of an "interception class" whenever it sends a message through GIST. A packet interception scheme can support one or more interception classes. In principle, a GIST instance can support multiple packet interception schemes, but each interception class needs to be associated with exactly one interception scheme in a GIST instance and GIST instances that use different packet interception schemes for the same interception class will not be interoperable.

Defining an alternative interception class mechanism for incorporation into GIST should be considered as a very radical step and all alternatives should be considered before taking this path. The main reason for this is that the mechanism will necessarily require additional operations on every packet passing through the affected router interfaces. A number of considerations should be taken into account:

• Although the interception mechanism need only be deployed on routers that actually need it (probably for a new NSLP), deployment may be constrained if the mechanism requires modification to the hardware of relevant routers and/or needs to await modification of the software by the router vendor.
• Any packet fields to be examined should be normally close to the start of the packet so that additional memory accesses are not needed to retrieve the values needed for examination.
• The logic required to determine if a packet should be intercepted needs to be kept simple to minimise the extra per-packet processing.
• The mechanism should be applicable to both IPv4 and IPv6 packets.
• Packet interception mechanisms potentially provide an attack path for Denial of Service attacks on routers, in that packets are diverted into the "slow path" and hence can significantly increase the load on the general processing capability of the router. Any new interception mechanism needs to be carefully designed to minimize the attack surface.

Packet interception mechanisms are identified by an "interception class" which is supplied to GIST through the Application Programming Interface for each message sent.

• New packet interception mechanisms will generally require allocation of one or more new Interception-class-IDs. This does not necessarily need to be placed in an IANA registry as it is primarily used as a parameter in the API between the NSLPs and GIST and may never appear on the wire, depending on the mechanism employed; all that is required is consistent interpretation between the NSLPs and GIST in each applicable node. However, if, as is the case with the current RAO mechanism [I‑D.hancock‑nsis‑gist‑rao] (Hancock, R., “Using the Router Alert Option for Packet Interception in GIST,” November 2008.), the scheme distinguishes between multiple packet interception classes by a value carried on the wire (different values of RAO parameter for the RAO mechanism in GIST), an IANA registry may be required to provide a mapping between interception classes and on-the-wire values as discussed in Section 6 of [I‑D.hancock‑nsis‑gist‑rao] (Hancock, R., “Using the Router Alert Option for Packet Interception in GIST,” November 2008.).

8.2.5.  Use of Alternative NAT Traversal Mechanisms

The mechanisms proposed for both legacy NAT traversal (Section 7.2.1) and GIST-aware NAT traversal (Section 7.2.2) can be extended or replaced. As discussed above, extension of NAT traversal may be needed if a new MRM is deployed. Note that there is extensive discussion of NAT traversal in the NAT/Firewall NSLP specification [I‑D.ietf‑nsis‑nslp‑natfw] (Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” April 2010.).

8.2.6.  Additional Error Identifiers

Making extensions to any of the above items may result in new error modes having to be catered for. See Section 9 and Appendix A Sections A.4.1 - A.4.3.

• Additional error identifiers require allocation of new error code(s) and/or subcode(s), and may also require allocation of Additional Information types. These are all allocated on a first-come, first-served basis by IANA [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

8.2.7.  Defining New Objects to be Carried in GIST

The AB-flags in each signaling object carried in NSIS protocols enable the community to specify new objects applicable to GIST, that can be carried inside a signaling session without breaking existing implementations. The AB-flags can also be used to indicate in a controlled fashion that a certain object must be understood by all GIST nodes, which makes it possible to probe for the support of an extension. One such object already designed is the "Peering Information Object (PIO)" [I‑D.manner‑nsis‑peering‑data] (Manner, J., Liuhto, L., Varis, N., and T. Huovila, “Peering Data for NSIS Signaling Layer Protocols,” February 2008.) that allows a QUERY message to carry additional peering data for the recipient for making the peering decision.

• New objects require allocation of a new Object Type ID either by standards action or provision of another type of specification [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

8.2.8.  Adding New Message Types

Major modifications could be made by adding additional GIST message types and defining appropriate processing. It might be necessary to define this as a new version of the protocol. A field is provided in the GIST Common Header containing the version number. GIST currently has no provision for version or capability negotiation that might be needed if a new version was defined.

• New GIST Message Types require allocation of a new GIST Message Type ID either by standards action or expert review [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

8.3.  QoS NSLP

The QoS NSLP provides signaling for QoS reservations on the Internet. The QoS NSLP decouples the resource reservation model or architecture (QoS model) from the signaling. The signaling protocol is defined in Quality of Service NSLP (QoS NSLP) [I‑D.ietf‑nsis‑qos‑nslp] (Manner, J., Karagiannis, G., and A. McDonald, “NSLP for Quality-of-Service Signaling,” January 2010.). The QoS models are defined in separate specifications and the QoS NSLP can operate with one or more of these models as required by the environment where it is used. It is anticipated that additional QoS models will be developed to address various Internet scenarios in the future. Extensibility of QoS models is considered in Section 8.4 (QoS Specifications).

The QoS NSLP specifically mentions the possibility of using alternative Message Routing Methods (MRMs), apart from the general ability to extend NSLPs using new objects with the standard "AB" extensibility flags to allow them to be used in new and old implementations.

There is already work to extend the base QoS NSLP and GIST to enable new QoS signaling scenarios. One such proposal is the Inter-Domain Reservation Aggregation aiming to support large-scale deployment of the QoS NSLP [I‑D.bless‑nsis‑resv‑aggr] (Doll, M. and R. Bless, “Inter-Domain Reservation Aggregation for QoS NSLP,” July 2007.). Another current proposal seeks to extend the whole NSIS framework towards path-decoupled signaling and QoS reservations [I‑D.cordeiro‑nsis‑hypath] (Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., Palma, D., Racaru, F., Diaz, M., and C. Chassot, “GIST Extension for Hybrid On-path Off-path Signaling (HyPath),” February 2008.).

8.4.  QoS Specifications

The QoS Specification template (QSpec) is defined in [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.). This provides the language in which the requirements of specific QoS models are described. Introduction of new QoS models requires IETF action, with the published document defining the specific elements within the QSpec used in the new model. See [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.) for details.

The introduction of new QoS models is designed to enable deployment of NSIS-based QoS control in specific scenarios. One such example is the Integrated Services Controlled Load Service for NSIS [I‑D.kappler‑nsis‑qosmodel‑controlledload] (Kappler, C., Fu, X., and B. Schloer, “A QoS Model for Signaling IntServ Controlled-Load Service with NSIS,” April 2010.).

A key feature provided by defining the QSpec template is support of a common language for describing QoS requirements and capabilities, which can be reused by any QoS models intending to use the QoS NSLP to signal their requirements for traffic flows. The commonality of the QSpec parameters ensures a certain level of interoperability of QoS models and reduces the demands on hardware that has to implement the QoS control. Optional QSpec parameters support the extensibility of the QoS NSLP to other QoS models in the future; new QSpec parameters can be defined in the document that defines a new QoS model. See Sections 4.4 and 7 of [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.).

The QSPEC consists of a QSPEC version number, QSPEC objects plus specification of processing and procedures that can be used to build many QoS models. If changes are made to the QSPEC that are not backwards compatible, a new QSPEC version number has to be assigned. Note that a new QSPEC version number is not needed just because new additional QSPEC parameters are specified; new versions will be needed only if the existing functionality is modified. It is required that later QSPEC versions be backward compatible with earlier QSPEC versions. The template includes version negotiation procedures that allow the originator of an NSLP message to retry with a lower QSPEC version if the receiver rejects a message because it does not support the QSPEC version signaled in the message.

• Creation of a new, incompatible version of an existing Qspec requires allocation of a new QSPEC version number by standards action. See [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.).
  
  
• Completely new QSpecs can also be created. Such new QSpecs require allocation of a QSPEC type by standards action. Values are also available for local or experimental use during development. See [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.).
  
  
• Additional QSPEC procedures can be defined requiring allocation of a new QSPEC procedure number by standards action or through a another specification document. Values are also available for local or experimental use during development. See [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.).
  
  
• Additional QSPEC parameters and associated error codes can be defined requiring a specification document. Values are also available for local or experimental use during development. See [I‑D.ietf‑nsis‑qspec] (Ash, G., Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” November 2008.).

8.5.  NAT/Firewall NSLP

The NAT/Firewall signaling can be extended broadly in the same way as the QoS NSLP by defining new parameters to be carried in NAT/Firewall NSLP messages. See Section 7 of [I‑D.ietf‑nsis‑nslp‑natfw] (Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” April 2010.). No proposals currently exist to fulfill new use cases for the protocol.

8.6.  New NSLP Protocols

Designing a new NSLP is both challenging and easy.

New signaling applications with associated NSLPs can be defined to work in parallel or replace the applications already defined by the NSIS working group. Applications that fit into the NSIS framework will be expected to use GIST to provide transport of signaling messages and appropriate security facilities which relieves the application designer of many "lower level" problems. GIST provides many important functions through the API that it exposes to the signaling application layer code, and allows the signaling application programmer to offload, e.g., the channel security, transport characteristics and signaling node discovery to GIST.

Yet, on the other hand, the signaling application designer must take into account that the network environment can be dynamic, both in terms of routing and node availability. The new NSLP designer must take into account at least the following issues:

• Routing changes, e.g., due to mobility: GIST sends Network Notifications when something happens in the network, e.g., peers or routing paths change. All signaling applications must be able to handle these notifications and act appropriately. GIST does not include logic to figure out what the NSLP would want to do due to a certain network event. Therefore, GIST gives the notification to the application, and lets it make the right decision.
  
  
• GIST indications: GIST will also send other notifications, e.g., if a signaling peer does not reply to refresh messages, or a certain NSLP message was not successfully delivered to the recipient. NSLP applications must also be able to handle these events. Appendix B in the GIST specification discusses the GIST-NSLP API and the various functionality required, but implementing this interface can be quite challenging; the multitude of asynchronous notifications that can arrive from GIST increases the implementation complexity of the NSLP.
  
  
• Lifetime of the signaling flow: NSLPs should inform GIST when a flow is no longer needed using the SetStateLifetime primitive. This reduces bandwidth demands in the network.
  
  
• NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new NSLP needs to use a unique NSLPID to ensure that its messages are delivered to the correct application by GIST. A single NSLP could use multiple NSLPIDs, for example to distinguish different classes of signaling nodes that might handle different levels of aggregation of requests or alternative processing paths. Note that unlike GIST, the NSLPs do not provide a protocol versioning mechanism. If the new NSLP is an upgraded version of an existing NSLP, then it should be distinguished by a different NSLPID.
  
  
  • A new generally available NSLP requires IESG approval for the allocation of a new NSLP ID [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.)
    
    
• Incremental deployment: It would generally be unrealistic to expect every node on the signaling path to have a new NSLP implemented immediately. New NSLPs need to allow for this. The QoS and NATFW NSLPs provide examples of techniques such as proxy modes that cater for cases where the data flow originator and/or receiver does not implement the NSLP.
• Signaling Message Source IP Address: It is sometimes challenging for an NSLP originating a signaling message to determine the source IP address that should be used in the signaling messages, which may be different from the data flow source address used in the MRI. This challenge occurs either when a node has multiple interfaces or is acting as a proxy for the data flow originator (typically expected to occur during the introduction of NSIS when not all nodes are NSIS enabled). A proxy signaling flow originator generally needs to know and use the correct data flow source IP address at least initially. As discussed in Section 5.8.1.2 of [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.), the signaling flow originator may choose to alter the source IP address after the initial Query message has established the flow path in order that ICMP messages are directed to the most appropriate node; in the proxy case, the data flow originator would be unaware of the signaling flow and ICMP messages relating to the signaling would be meaningless if passed on to the data flow originator. Hence it is essential that an NSLP is aware of the position and role of the node on which it is instantiated, and has means of determining the appropriate source address to be used and ensuring that this is used on signaling packets.
  
• New MRMs: GIST currently defines two Message Routing Methods, and leave the door open for new ideas. Thus, it is possible that a new NSLP also requires a new MRM, path-decoupled routing being one example.
  
  
• Cooperation with other NSLPs: Some applications might need resources from two or more different classes in order to operate successfully. The NSLPs managing these resources could operate cooperatively to ensure that such requests were coordinated to avoid wasting signaling bandwidth and prevent race conditions.

The API between GIST and NSLPs (see Appendix B in [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.)) is very important to understand. The abstract design in the GIST specification does not specify the exact messaging between GIST and the NSLPs but gives an understanding of the interactions, especially what kinds of asynchronous notifications from GIST the NSLP must be prepared to handle: the actual interface will be dependent on each implementation of GIST.

Messages transmitted by GIST on behalf of an NSLP are identified by a unique NSLP identifier (NSLPID). NSLPIDs are 16 bit unsigned numbers taken from a registry managed by IANA and defined in Section 9 of the GIST specification [I‑D.ietf‑nsis‑ntlp] (Schulzrinne, H. and M. Stiemerling, “GIST: General Internet Signalling Transport,” June 2009.).

A range of values (32704-32767) is available for Private and Experimental use during development, but any new signaling application that expects to be deployed generally on the Internet needs to be defined either in a standards track RFC or, possibly, an experimental RFC. Such an RFC would request allocation of unique NSLPID value(s) from the IANA registry. There is additional discussion of NSLPIDs in Section 3.8 of the GIST specification.

9.  Security Considerations

This document provides information to the community. It does not raise new security concerns.

10.  IANA Considerations

This memo includes no request to IANA.

11.  Acknowledgements

This document combines work previously published as two separate drafts: "What is Next Steps in Signaling anyway - A User's Guide to the NSIS Protocol Family" written by Roland Bless and Jukka Manner, and "NSIS Extensibility Model" written by John Loughney.

Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of "User's Guide" draft and valuable input. Teemu Huovila also provided valuable input on the later versions.

The "Extensibility Model" borrowed some ideas and some text from RFC3936 (Kompella, K. and J. Lang, “Procedures for Modifying the Resource reSerVation Protocol (RSVP),” October 2004.) [RFC3936], Procedures for Modifying the Resource ReSerVation Protocol (RSVP); Robert Hancock provided text for the original GIST section, since much modified and Claudia Keppler have provided feedback on this draft, while Allison Mankin and Bob Braden suggested that this draft be worked on.

12.  References

12.1. Normative References

12.2. Informative References

Authors' Addresses