Current Meeting Report

2.7.11 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 26-Nov-01
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:
Jan 02   Initial ID on Signaling Requirements.
Feb 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 Current Internet-Drafts

No Request For Comments

Current Meeting Report


Reported by Janne Rinne, Jarno Rahalme & John Loughney

This was the first NSIS WG meeting. John Loughney/Nokia chairs this working group. In the beginning Chairman presented the charter of this WG. No comments were provided for the charter. It should be noted that all of the drafts discussed are not products of the NSIS working group, and all are individual submissions, except for the first draft - "Requirements of a QoS Solution for Mobile IP."

Requirements of a QoS Solution for Mobile IP, Hemant Chaskar

This document has gone through the last call in Mobile IP WG, but Mobile IP WG has decided not to work with QoS protocols. The QoS requirements listed in this draft were discussed in the separate mailing list and the archives are available. The draft divides requirements basically for the MUST, SHOULD and MAY categories. In the "must" part, the requirements are quick setup time in case of handovers, localization to the handover-affected segments and releasing after handovers the QoS states. In a "should" category, there are requirements for interoperability with mobility protocols, handling QoS paradigm heterogeneity, having provisions to signal QoS along the different paths. "May" part consist of the requirement to carry information relevant for lower layers. The draft is stating also that features for QoS signalling are scalability, security, and conversation of wireless bandwidth, low processing, and hooks for accounting and authorization.

Q: Georgios Karagiannis: About QOS paths, can the end host choose one?
A: Yes

Q: Bob Braden: What do you mean by scalability?
A: That is a hard question ...

Q: Bob Braden: RSVP scales linearly
A: Quantification of these requirements is hard, can take this to the mailing list.

Q: Kwok ho chan?: Roaming between wireless/wireline?
A: Distinction not visible to the IP layer, (at least all of the MUSTS).

QoS signalling Protocol Requirements for Wired Networking, Bechet Sarikaya

Inputs to this document came from the NSIS BOF, Internet 2 Qbone documents and the fact that Internet core is ready for end-to-end support. In the discussion of this document, several requirements were listed. QoS signalling should support audio and video and it needs to provide security and integrity. It was also required that security requirements should be signalled to the relevant parties. Signalling mechanism should be also simple and lightweight. Next steps are to encompass all the requirements from the wired network's world. Also there will be more specific requirements about the needed QoS parameters. Aim for this next step is to gather the requirements to the informational RFC.

Q: Ticci So: Service control signaling vs. bearer control signaling needs to be specified.
A: OK.

Q: Georgios Karagiannis: Do security, accounting and charging apply on all nodes of a network or only on Edges, Access Routers or proxy nodes, excluding interior nodes?
A: Good question

Q: Hemant Chaskar: Application specific info to the QoS signaling protocol (audio/video)?
A: End-to-end signaling, so application requirement should go in there.

Q: (Unknown) Motivation for the in-band/out-of-band & interworking between the two?
A: in-band etc.: pointer for future work.

Q: (Unknown) Is there a plan to consolidated requirements?
A: John: Yes, WG process will follow

Q: (Unknown): Stateless? Why?
A: Rather "soft state"

Q: (Unknown): What do you mean with "signaling security for packets"?
A: Sec reqts should be in the signaling protocol?

Q: (Unknown): Lightweight auth?
A: John: Will work on the security/auth.

John: Will be application independent.

QoS signalling requirements for Wireless Networks, Georgios Karagiannis

This draft outlines a set of requirements for signalling QoS need in the wired part of IP-based wireless networks. Those requirements are:

* Minimal impacts on performance. Currently RSVP is too heavy, overprovisioning uneconomic and we need to find out what is the right balance between those.
* On demand resource reservation which means the careful use of the bandwidth. Static vs. per flow management by RSVP, where is the middle ground?
* Unicast reservation and we need to modularize multicast parts that we cannot to use.
* Scalability manageable and bi-directional reservations.

The next steps would be to reate a modular QoS signaling toolkit that will contain these mandatory and optional requirements; specify how the protocol functionality should be separated in building blocks and define a minimum set of mandatory reservation options/features that should be processed by interior/intermediate nodes

It was commented that it is good idea to consider signaling to be done per domain.

Q. Michael Thomas: to find middle ground, need to agree that indeed RSVP work is too heavy. A lot of work being done
A: Less-heavy solutions needed for wireless access networks

C: Tricci So: Domain-based consideration important (in the draft?)
C: (Unknown): Per-flow mgmt too heavy and wasteful, however RSVP is a good reference point.
C: George Tsirtsis: RSVP+everything else, why the separation between the wireless/wired?

Requirements for QoS Signalling, Marc Greis

Purpose of the draft is collect requirements for QoS signalling (not for provisioning). Some focus of the draft is on mobile, wireless, cellular networks. This draft provides an opportunity re-think RSVP. It was stated in the discussion of the draft, that prioritization is necessary (must/should/may or high/medium/low priority). Marc showed quite big list of all requirements and he was asking from the group, which requirements are needed in addition to simplicity as basis for future work. The term compatibility raised some concerns and Marc said that term interoperability could be better word to be used. It was asked what is the difference between Marc's and Hemants draft. Hemant's draft is focusing only mobile IP case and Marc's is more general. It was commented that one requirement for QoS signalling is to maintain the session. Also it was said that there should be a link between the routing system and QoS signalling.

Q: Bob Braden: Simplicity really high on the list, do we really want to get there?

Q: (Unknown): The list of reqts more complex than RSVP?

Q: What is the difference to the Hemant's draft?
A: Mobile IP QoS solution really important

C: (Unknown):
Signaling should be application independent, inter-domain will be much more complex than intra-domain

A: (Unknown): Need to find out what applications need to be supported? [multicast?]

C: (Unknown): Maintenance of the session?

C: Dick Knight: At the original BOF for this group, there was a statement that you can't ignore routing when signalling QoS requirements, therefore the requirement for interworking with routing should be re-worded to say "compliments" the routing.

C: (Unknown): Is support for explicit release needed?
A: Soft state could be useful for this.

Analysis of Existing QoS solutions, Piers O'Hanlonn.

In this discussion of the draft, existing QoS mechanisms were presented, which are RSVP for intserv, Diffserv, Dynamic Bandwidth Broker, Intserv over DiffServ, Aggregated RSVP, QOS routing, MPLS and other kind of marking e.g., ECN. The intention should be to have all these features combined in one mechanism. It was also mentioned that MPLS-RSVP should be in the list as well

Q: Jim Kempf: Presentation has no info on why QoS does not work?
A: More detail in the draft?

Q: nagarazi (Sprint?): Diffserv aware RSVP?

Application of Integrated Services on Wireless Accesses - Brian Williams

Brian's presentation covered also a draft-fodor- wireless-params-00.txt. Shortly the draft "issues" is saying that RSVP/intserv mechanism is not sufficient for some layer 2 technologies, when draft "params" examines other information that could be useful.

Q: Tsirtsis: L2 APIs exist?
A: Applications should use L2 independent IP API

A framework for end-to-end user perceived QoS negotiation, Suresh Leroy (Alcatel)

The discussion of this draft, introduced another view for signalling and intention was to use session layer in signalling QoS end-to-end. General requirements were:
* Service access provider may be involved in the negotiation process
* Independent of QoS provisioning mechanism used
* Independent on signalling protocol
* Re-use of existing protocols
* Flexibility to specify the QoS in session

Q: Michael Thomas: signaling path the same as the data path?
A: No, totally independent?

Kempf: End-to-end QoS is really expensive; those that want to give the "busy signal". Should investigate if it can be made cheaper, but not likely.

Hemant: What is missing in SIP?
A: SDP now specifies only the codec, but no QoS parameters (delay, error rate)?

Fundamental Questions Regarding End-to-End QoS, Kristian Nemeth draft-bergsten-e2eqos-questions-00.txt

In the discussion of this draft, issue was divided to 6th pieces: Access network, Core, end-to-end, interdomain, Congestion control and resource forecast. Access networks are the bottlenecks and resources reservation is needed. In the discussion of this draft assumption was to use DiffServ at the core. Inter-domain signalling could be similar e.g., BGP. Congestion control is needed in order to make decision which user to turn down and how (business perspective). Resource demand forecast support was meaning that how to foresee volumes and directions. It was mentioned that solutions are in the different levels and according to presenter Access, end-to-end and congestion control could in the scope of NSIS WG. Also it was proposed that signalling mechanism should be sender oriented, it should support homogeneous multicast only and it should be one-pass reservation mechanism. More info for this draft could be found from the There was a second opinion as well, which was proposing to have core part included instead of access network part to the WG's scope.

Q: Scope: Service control signaling vs. bearer control signaling, Urge WG chair & Area directors to

C: End-to-end? Should be U-N-I

John: rat hole, next lets move on please

Features of Ipv6 Signalling, Jun Kyun Choi

This draft is dealing with the Ipv6 features and especially with the flow label field. It was mentioned that label switching for QoS and TE is needed and Flow Label information should be distributed. Also one target was to improve scalability using aggregations. Next header field is used to identify signalling for entities and separation of signalling from user data traffic, make use of Ipv6 extension header (routing option, hop-by-hop option header).

Chair commented that Ipv6 WG is working with the flow label and not here in NSIS.

Michael Thomas: Flow Label as the flow spec.
Scott Bradner: Don't know if flow label is going to be a useful tool for QoS.

C: Jim Kempf: Access Networks: IP vs. ATM

Q: ??: Access & QoS (SG16): Priority of services useful

Q: Marcus: Discussion points to the list. Scenarios and use cases important.

Q: Ping Pan: WG scope (second the opinion on scenarios)

D: Tsirtsis: How to manage the process forward. Will be difficult task.

C: (Unknown) Scope needs to be defined before requirements?

Scott Bradner: Scope and requirements together, drafts were non-WG docs

Thomas: Long on desirables, short on analysis

?: Can we start narrowing down the scope now?

Ping Pan: Inter-domain out of question
C: Service control out of scope, focus on the bearer control

C: Focus on the bearer, not the service level aspects

C: (Service Provider) Focus on the bearer control

C: QoS signaling for the media path (in IETF language), service provider needs to get paid, need to work over multiple domains for the accounting

Stig Nai?: Option or tool for inter-domain could be available
John: especially roaming should be addressed

Scott Bradner: Internet is multiple domains of technology, would like to (later on) to tease out what people mean with "setting up bearer service"

Thomas: "Bearer" and "Trunk" out-of-scope

C: Separate or common reqts for wired and wireless
John: L2 issues, one document about L3 reqts

Scott Bradner: Explicitly NOT to focus on one or the other, both.

C: These are individual, would be wrong to focus on setting up a "channel" or "path", RSVP works on the path...

A Network Model using Per-Session signalling, Ping Pan

Issues listed in the discussion:
What kind of network (end-to-end, network-to-network. UNI)?
Why admission control? What about the over-provisioning?
What about backbone and inter-domain?
What about security and DOS?
Why/how lightweight? (processing scaling now and future)
Can we use existing RSVPv1? (it is working, deployed...per flow, soft-state, multicast, shared reservation, receiver initiated reservation, two pass reservation and the applications)
What to do from here?
This should be done and urgently. It was asked to take these issues into a consideration in this WG.

It was asked what is the difference between this and RSVP-Diffserv RFC? Chair encourages reading it.

Q: Lightweight protocol scaling?
A: Scaling: state, CPU, BW, manageability. Only processing scaling important

Q: Looks very much like RFC 2998?


It was commented that we should work with signalling in the access networks too. Next step should be to define requirements and scope for the NSIS work. It was mentioned that requirement list is coming to the email list soon. Also scenarios and use cases should be considered. Somebody disagree that we need to define requirements before the scope. AD said that scope is part of the requirements. It was commented that service control type of signalling should be out of the scope of this WG. Chair clarified that we are not going to define any authorization mechanisms here in this WG, but we could provide hooks for authorization purpose implemented by using some mechanism or protocol defined by IETF. Someone had concerns with the possibility that inter-domain signalling is out of the scope of this WG. It was said that we might need to consider that at some level. AD asked some clarification how bearer setup is done in the transport networks (an issue for mailing list). Modular solution is needed in order to suit all QoS mechanisms.


The Features of IPv6 Signaling
Requirements of a QoS Solution for Mobile IP
QoS Signaling Protocol Requirements for Wired Networking
QoS Signalling Requirements for Wireless Networks
Requirements for QoS Signaling
Analysis of Existing QoS Solutions
Wireless Issues and Parameters
A Framework for end-to-end user perceived QoS negotiation
Fundamental Questions Regarding End-to-End QoS
A Network Model for Using Per-Session Signaling
Requirements of a QoS Solution for Mobile IP