Current Meeting Report

2.7.11 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 05-Mar-02
John Loughney <>
Transport Area Director(s):
Scott Bradner <>
Allison Mankin <>
Transport Area Advisor:
Allison Mankin <>
Mailing Lists:
To Subscribe:
In Body: (un)subscribe
Description of Working Group:
Quite a bit of work has been done on Quality of Service and resource reservation for the Internet. For a number of reasons, however, there has not been a significant amount of end-to-end QoS deployed on the Internet other than best effort service.

It is noted that resource reservation and traffic engineering can be considered as part of network administration, and therefore beyond the scope of the IETF to mandate a particular mechanism. When considering end-to-end communication, it is likely that several administrative domains are traversed. Interworking between domains in which different QoS solutions solutions are deployed is problematic. Mobility and roaming additionally add complexity to the overall picture. This creates a need for a simplified solution of signaling QoS, one that reuses parts of existing methods. This will allow users to obtain QoS-aware services, irrespective of underlying mechanisms used.

This working group will develop the requirements, architecture and protocols for the next IETF steps on signaling QoS. The working group will use existing IETF signaling as the basis for this work, evaluating RSVP in particular as the starting point. Additionally, the working group will consider how to signal QoS (what sort of QoS parameters to use), and where to signal (end-to-end, end-to-edge, end-to-proxy, edge-to-edge, etc.).

As requirements input to the working group, the Mobile IP QoS Requirements document (draft-mobileip-qos-requirements) will be considered as one starting point for developing the overall set of requirements. The working group will not limit itself to mobile IP-only QoS signaling needs, however, but will consider general cases of signaling QoS in the Internet (both wired and wireless). Consideration will be given to the idea of a building block structure, so the group could develop elements for QoS signaling that could be modular and be combined with a different payload or different proxy (e.g.) for use by a non-QoS signaling function. The added function will be out of scope, but the openness of the design (which may be a new version of RSVP) will be in scope.

This working group will focus on providing (QoS) signaling function to a local access network and end-to-end signaling. It is not the intention of this working group to invent new signaling protocols. Additionally, mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context Transfer and Diameter.

The working group will develop signaling requirements, analysis and framework documents. The Transport area directors and chair will evaluate these against criteria including that the use of a simplified version of RSVP has been fully evaluated, and that the potential for a tool box or building block contribution has been covered by the framework. Work on the protocol document will be contingent on this evaluation.

As with nearly all work being done in the IETF, security is a very important concern for NSIS. The working group will study the security requirements for QoS Signaling, as well as create a threat analysis of QoS signaling. Compatibility with authentication and authorization mechanisms is also a concern. These topics will be addressed in the Signaling Requirements document.

This working group will provide the framework for interworking with existing resource allocation methods. It is a non-goal of the working group to develop new resource allocation protocols.

The working group will coordinate with a number of other IETF working groups, including Diffserv, Seamoby, Mobileip, AAA, Midcom and RAP. It will also welcome participation and expression of requirements from non-IETF standards organization members, for instance 3GPP and 3GPP2 and ITU-T.

Goals and Milestones:
Done   Initial ID on Signaling Requirements.
Mar 02   Initial ID on Analysis of existing signaling protocols.
Mar 02   Initial ID on Initial ID on Framework Signaling Architecture
Jun 02   Submit 'Signaling Requirements' to IESG for publication as an Informational RFC.
Jun 02   Initial ID on 'Next Step QoS Signaling
Jul 02   Submit 'Analysis of existing signaling protocols' to IESG for publication as an Informational RFC.
Sep 02   Submit 'Framework signaling architecture' to IESG for publication as an Informational RFC.
Sep 02   If the initial analysis and framework do not meet criteria stated in charter, submit a rechartering request to the IESG
Dec 02   If criteria were met, submit 'Next Step QoS Signaling' as a standards track RFC
No Request For Comments

Current Meeting Report

IETF#53 meeting in Minneapolis: 17.03.2002 - 22.03.2002

1. Draft-ietf-nsis-req-00.txt:
Requirements for QoS Signaling Protocols
Markus Brunner

Marcus Brunner went through the requirements based on the discussions in the mailing and the outcome of a 'brainstorming' with authors of some of the drafts.

The biggest problem of the draft currently is that scope is very wide. Also we should get rid of application level QoS and low level QoS in order to have more focused target for the NSIS work. Risks in the current situation are that discussion is unproductive and there is a risk of over specifying.
In general, it was proposed to select use cases and then create list of requirements and eventually relates them to "parts of the network" part. Also it was proposed that scenarios section and structure of requirements section remain in addition to adding description of "parts of the network" to section 6. Change the tables with MUST's, SHOULD's and MAY's to relate to parts of the network instead of relate them to scenarios. Parts of the network will not be 1) host to first hop (also first hop to host), 2) access network or 3) core to core. It was commented that it is important to differentiate the directions. It was criticized that dividing issue into sections might not be good idea. However there will be different requirements in different contents. It was pointed out in the presentation that some use cases like Voice over IP scenario (from the draft-partain-nsis-requirements-00.txt), the case when host request QoS from the network without mobility, wireless etc. and using signaling to set up the pipes.

Regarding Mobile IP, the hand of decision and trigger sources should be out of the scope of the NSIS. Thus the WG should rather focus only on "establishing" QoS after hand off. Marcus presented also some concerns and pros related to Framework and it was proposed remove the figures, since they are seen as bit misleading. The changes to the text are needed in such a way that we do not want to impose any architecture or constrains. Also the intention is to try to phrase the requirements without relaying too much on the framework. In the issue, who will initiate signaling, accounting was one key issue mentioned, thus it was commented that we should not link signaling protocol solution to accounting. Also it was proposed that we don't assume that requirements are being considered to be for bi-directional reservations.

The biggest discussion arose on the globally defined services and especially creating NSIS QoS classes. The question was who should define those QoS classes, since NSIS was not seen as an appropriate group to define them. NSIS could rather collect them, although something need to be done in NSIS WG as well. Massive non-interoperability problems were foreseen as well. Actually this part of the presentation raised many concerns among the DiffServ, RSVP and Intserv pioneers and it was commented that there is not technical problem at all, thus this discussion is purely political. At this point it was mentioned again that the scope and charter is definitely too wide. Also it was clarified that intention of the WG is not to define any new QoS reservation mechanism, thus we are focusing to signaling mechanism only in NSIS.

Previously IP fragmentation was proposed to be one requirement, but eventually it was proposed to remove it since it may increase complexity. Some text needs to be added to avoiding duplication, ability to signal lifetime of reservation and independence of reservation identifier sections. The security requirement for the NSIS was also discussed. It was commented that more analysis about the threads are needed and current draft needs more text for security section.

The next step of this work is that next version of the draft will be submitted by the end of the may.

2. Draft-fodor-reqts-cellular-netwks-00.txt:
NSIS QoS Signaling Requirements from a Multi-access Wireless Perspective
Gabor Fudor

The presenter emphasized the importance of multi-access wireless networks. The requirements presented in the drafts are 1) host to edge signaling must be per flow, 2) QoS information, 3) bi-directional and asymmetric reservation, 4) local reservation must be supported, 5) multicast, 6) local control, Dos, 7) support for adaptivity.

No comments were provided in the meeting.

3. Draft-buchli-nsis-req-00.txt:
QoS signaling requirements, interfaces and architecture
Sven Van Den Bosch

Main goal of the draft is to enable hard guaranteed per-flow end-to-end QoS.

Relation to NSIS WG draft was elaborated in the presentation. Basically the terminology and requirement section are inherently covered currently. QoS signaling and QC must not constrained to be in the data path and 2 level QoS granularities are emphasized. Mobility, modularity, universality of signaled parameters, communication between QI/QC and local administration are de-emphasized or not even applicable. Some requirements are new: priority, grouping of micro-flows.
The authors of the draft support proposal to split work into three areas and propose to add use cases, terminology and requirements to WG draft.

Also it was proposed to move some use cases to framework document. Some kind of document that is describing the use of NSIS would be good to have.

4. Draft-hancock-nsis-framework-00.txt:
NSIS Framework Issues
Robert Handcock

It was stated especially in the presentation that AAA/policy capability is needed. Anyway the level of Security needs more discussion. Presentation covered issues like receiver-initiated reservations, bi-directional reservations and end-to-end signaling. Correlation between application level signaling was mentioned in the discussions.

Eventually the conclusion was that the authors do not see any showstoppers, although AAA needs to be investigated more.

5. Next Steps

· Re-publish requirement document
· Start working on analyses of existing signaling protocols document
· Start work on framework signaling document
· Possible interim meeting: target date would be in May, Location open
(possibly in Helsinki, Dallas, Boston, ...)


Requirements for QoS Signaling Protocols
NSIS QoS Signaling Requirements from a Multi-access Wireless Perspective
QoS signaling requirements, interfaces and architecture
Open Issues in ‘an NSIS framework’