Frequently Asked Questions (FAQ)

General NSIS related questions

• What is (NSIS) signaling?

  Unfortunately, the term signaling has, though widely used, not been well defined, yet. SIP defines itself as a signaling protocol, the HIP working group uses the term signaling to denote control packets and in the context of RSVP signaling is mostly concerned with QoS reservations. There are still more examples of usage, which are all connected by a common ground, though: In contrast to normal transport, signaling does not deal with data transport between two nodes, but with the management of the underlying network. Thus, in the general scope of IP networks, signaling can be defined as referring to installation, maintenance, removal and probing of state in one or more entities of the network. In the scope of NSIS, signaling is limited to the signaling along paths in the network, that are taken by data flows. In particular, end-to-end (application) signaling is not covered. Signaling can be used as a synonym for sending meta information about a data flow along the network path and this meta information being interpreted at certain signaling aware nodes.
  Generally, two types of signaling are distinguished: Path-coupled and Path-decoupled. Path-coupled signaling means that the same path is used both by the signaling messages and by the data flow, while only a subset of the involved nodes have to be aware of the signaling information. In the Path-decoupled option the signaling messages traverse nodes that do not need to be on the data flow path, but should know about the path and have to interact with the nodes on the paths in order to manipulate their behaviour.

• What is the difference between NSIS and RSVP?

  RSVP is the Resource ReSerVation Protocol (RFC 2205). It is the predecessor of the NSIS protocol suite and as thus has many similarities. However, in contrast to NSIS, RSVP is limited to Quality of Service (QoS) reservations. While signaling for Quality of Service was the first and major use case for path-coupled signaling, other applications, such as any kind of middlebox configuration, are desired. An example of such a middlebox configuration is the configuration of Network Address Translators (NATs) and firewalls. Therefore, the NSIS protocol suite was split into two layers. A common transport layer, which is able to discover the signaling nodes as well as being able to establish communication channels between them, and a signaling layer, that implements the actual signaling logic. The common transport layer of NSIS is the GIST Protocol. Examples of protocols in the signaling layer are the QoS-NSLP and the NAT/FW-NSLP.
  There are other differences between NSIS and RSVP, like improved extensibility and mobility support. In addition, NSIS was simplified to not use multicast.

• How does the NSIS signaling relate to the data traffic?

  The NSIS signaling packets have no direct connection to the data packets. In fact, NSIS signaling speaks ABOUT data packets, or better data flows. Typically a data flow is identified by the source and destination IP, the transport protocol used, the source and destination port and maybe some other information, like the DiffServ-CodePoint or a FlowIdentifier. All these parameters are summarized as the Flow-Information, which is encoded in the Message Routing Information of GIST.

• How does an NSIS usage scenario look like?

  Take a SIP phone which wants to do a Voice-over-IP call. To assure that call works well, a certain Quality of Service (QoS) on the path between the two participants is required. The QoS-NSLP is capable of reserving such QoS along the path taken by the data flow.
  Inside the SIP phone, after some session setup, it knows where to send the voice data and starts doing so. It knows all the Flow-Information that NSIS needs to know about the data flow. Therefore it invokes the NSIS (or better QoS-NSLP) daemon and tells it, that it wants a certain degree of Quality of Service (e.g. 20 kB/s bandwidth) for the particular flow (and therefore provides the Flow-Information). Then, with no direct connection to the data traffic, NSIS does all the work to reserve the QoS on the routers on the data path for that particular flow. After that, the SIP phone, or better the data traffic, will experience the improved or guaranteed QoS.

• How to integrate NSIS into a SIP phone from the implementation point of view?

  As explained above, you need to extend the SIP phone. You need to find the place in the code where the phone has all the Flow-Information and wants to start to send the audio stream. At that point, you hook yourself in and make a call to the local QoS-NSLP daemon and give it all the information that it needs to do the reservation (see above). Once the QoS-NSLP tells you, that it succeeded, the normal operation of the SIP-phone should continue (so it really starts sending the audio stream, the data).

Implementation specific questions

• On which platform does the implementation work?

  Our main development focus is Linux. Recent versions support FreeBSD and Mac OS X as well. Please see the notes in the manual/ directory of the releases about the open issues on FreeBSD and Mac OS X.

• Do you support IPv6?

  The GIST implementation has full support of IPv6, while not all NSLPs currently support it. The QoS-NSLP, as well as the "Ping tool" have IPv6 support. NAT/FW NSLP and Diagnostics NSLP currently not.

• Do you support Mobile IPv6?

  Currently not.