Current Meeting Report
2.8.10 Next Steps in Signaling (nsis)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/06/2002
John Loughney <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
A. Mankin <firstname.lastname@example.org>
Transport Area Advisor:
A. Mankin <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
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,
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
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
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
|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
|DEC 02|| ||If criteria were met, submit 'Next Step QoS Signaling' as a
standards track RFC |
No Request For Comments
Current Meeting Report
Tuesday May 21, 2002
10:00 Scoping Discussion - John Loughney
10:30 Requirements of a QoS Solution for Mobile IP - John Loughney
11:00 Requirements for QoS Signaling Protocols - Marcus Brunner
13:00 Requirements for QoS Signaling Protocols continued - Marcus Brunner
15:00 NSIS Threats - Hannes Tschofenig
Wednesday May 22, 2002
9:00 An Outline Framework for QoS Signaling - Robert Hancock
13:45 Localized RSVP - Jukka Manner
14:00 Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks - Jussi
14:30 Framework for edge to edge QoS signaling - Georgios Karagiannis
15:00 Relationship of Context Transfer to NSIS - Rajeev Koodli
15:30 Two-level Architecture for Internet Signaling
Thursday Thursday May 23, 2002
9:00 Framework summary - all
10:00 "Analysis of Existing QoS Solutions" - Georgios Karagiannis
11:00 Summary - all
NSIS Interim Meeting 21/5/02
John: Signalling from interior devices, proxies etc. are still in scope. 3rd
party QoS controller = "not in data path". The main issue is that the ADs want
us to avoid QoS architecture & service issues discussions (no objections to
Concern (Ilya): IP telephony tends to use signalling initiated off the data
Comment (Olov): Actual impact on protocol should be minimal.
Comment (John): If people have concerns, they should write them up. Will check
issue of hard vs. soft and in/out band, with ADs
Comment (Georgios, Lasse): In-band/out-band are totally different, Ilya/Marcus:
not much different.
Question: how binding are the requirements; John - they should focus discussion,
but should not be a straight-jacket.
Requirements of a QoS Solution for Mobile IP (John)
WG draft (-02) has passed last call, with IESG. Contains some MUSTs, some
SHOULDs. Question on 'QoS heterogeneity' - does it mean 'be independent of
service' or 'handle negotiation about service types' (to be clarified).
Comment: Thinking about mapping down to particular QoS paradigms can happen
Some requirements on general protocol quality. Comment: clarification on what
things like 'scalability' mean.
Boundaries with other protocols to be analysed, this draft only considers QoS
establishment for the new path (not query/discovery). Wireless aspects are part
of the service definition. When it becomes RFC (Informational) NSIS takes it as
an input but is not bound by it.
Requirements (Open Issues) - Marcus
 Scenarios add/change/remove (e.g. VPN).
Question: scenarios covering signalling for things other than QoS?
Georgios/Lars will provide justification & if successful Marcus will add it.
 Sender/receiver - still open.
 MUST/SHOULD/MAY (do this later)
 Handoff decision and trigger sources (in or out of scope). Agreed: NSIS is
not going to solve this problem, has to interact with protocols that do. Add
text to exclusions section.
 NSIS should allow bidirectional reservations as an optimisation where the
network topology allows it.
 Grouping of microflows. Added (as a MAY, probably). Network does not need
to know relationship exists. Add justification of why this is an optimisation.
 Interaction with seamoby. Add requirement to say that we are interworking
in the area of mobility protocols (e.g. CT and CAR discovery).
 Asynchronous events from the network. REH & Sven to propose wording
including some motivation as examples. Issues to do with locality and scenarios.
 NSIS in case of handovers. No change needed concerning handovers.
 Ownership of a reservation. Close issue and handle it within security
 Simplify security section. Postpone.
 Mobility requirements - don't add. Closed.
 Add assumption that QoS monitoring is application/service specific and out
 Notification of QI/QC/QR. Closed earlier.
 Resource availability query. Query not as 'real' reservation is part of
service definition. May need new requirement about endpoint controlling locality
 Automatic re-installation. Removed, leave open option to supply text for
 Scenarios for failure and recovery cases. Remove, invite individual
 Traffic engineering and route pinning issues. Assumption: NSIS should work
with networks using standard L3 routing. NSIS should not be broken by networks
which do non-traditional L3 routing.
 Closed. Aspect of AAA (authentication --> authorisation) solution or
 Sven et al. to write submissions.
 Covered under .
 Closed (no new text except maybe motherhood statements).
 Considered .
 Closed (not included elsewhere).
 Closed (already covered).
 Merge with 5.3.2 to reflect wanting to avoid stale state (somehow).
 Closed (already covered in transport service quality requirement). Protocol
design must take into account reliability concerns.
 Add something about graceful failover to general protocol requirements
 Closed. Should be possible for NSIS to transport useful error messages.
NSIS Threats (Hannes Tschofenig)
Non-repudiation covered under service heading. Clarification that NSIS is
concerned about accounting in the sense of metering, not charging. Charging is
not in scope of the working group. On the other hand, authorisation is still a
hard problem. The meeting thought that this document was important. Next steps:
requirements draft will have a 'simple' requirements section, pointing to a i-d
on threats (as a new separate working group item).
9 AM Towards a Framework for QoS Signaling in the Internet
- Presentation by Robert Hancock outlining purpose and structure of the
* Refine requirements
* Refine scope of NSIS
* Help analyze proposed solutions
* Allow more detailed analysis of smaller parts of the problem
* Capture assumptions on the NSIS structure.
It is remarked that the purpose should be to contextualize requirements, not
refine them. Solution analysis is excluded from the framework (will be handled
elsewhere). Additional signaling needs may be discovered that cannot be
addressed under the charter. They should be documented.
* building blocks and interactions
* deployment scenarios
* motherhood section
It is remarked that deployment validation should take place after protocol work
and documented in an additional set of documents. The framework should specify
how incremental deployment can be achieved. Building blocks and interactions
should be the main focus of the framework. Motherhood issues (security,
resilience, scalability) can be included if needed.
After some discussion it is stated that the protocol MUST support security even
if its use is not mandatory.
There was a side discussion on classification of the requirements (indicate how
they apply differently to different parts of the network). The working group was
asked to signal this kind of requirements if they are found in the requirements
Basic assumptions for the draft were pointed out:
* end-points for peer-peer signalling (NSIS agents): specialised QI/QC/QR,
pre-dominantly hop-by-hop signalling
* overall protocol chosen locally
* functionality split in two phases:
+ preparatory phase (may not be part of nsis)
+ execution phase (core nsis part: resource request/modify/delete, response,
Some parts were already deemed out of scope (SLS negotiation, next hop
There was some discussion on error handling and congestion notification. Error
handling was deemed to be part of the execution phase, congestion notification
more of the preparatory phase.
The hop-by-hop assumption was felt to be a restriction of the solution. The term
was found to be confusing. It was decided to find better terminology and list
restrictions of the hop-by-hop approach and define the implications of changing
it (by having non-local interactions in the protocol).
A proposal for a protocol element structure was made:
* Protocol transport
* NSIS control information
* Flow description: to allow to go through non-QoS aware entities that do
* QoS description: separated from nsis (opaque)
The scope of NSIS would be mainly control info and flow description.
The question was raised that separating flow from QoS description might not
always be easy. It was noted that this is useful for traversal of non-QoS-aware
entities doing address manipulation. It was also remarked that the flow
description could potentially be inferred from other fields (e.g. protocol
There was some discussion on non-local aspects
* sender/receiver initiated reservations
- the meaning of a response message needs to be decided at the framework level
- the decision to have receiver-initiated reservation needs to be made at the
- the interaction with AAA was discussed
It was decided that charging issues are not in the scope of NSIS. Determining or
indicating who is authorized to make reservations is (the protocol MUST support
passing of authorisation information). A question regarding who needs to add the
authorisation token should be considered.
* bi-directional cases: See decision May 21.
On/off path signalling was discussed:
* provisioning issue
* implicit/explicit routing
* non-traditional routing anywhere can break e2e on-path assumptions.
It was remarked that several situations can lead to the control and data plane
being different. This can be e.g. the case with load-balancing or QoS routing.
It can happen in NSIS-aware and NSIS-unaware networks. It is also likely to
occur in the early stages of deployment. It was asked to have the issues clearly
documented and have more discussion on them.
There was some discussion on (revising) the charter. A formal question regarding
the charter will be addressed to the ADs.
Hans Lippitsch presented a short summary on his interpretation of the charter
and the intention of the NSIS work, presenting and inter-domain end-to-end QoS
Chair remarks that this can not be the first output of NSIS. It was remarked
that the original charter focused on multi-domain QoS signaling. Chair states
that the focus is and was on signaling, not resource provisioning, over an open
internet, possibly traversing different providers.
1.45 PM Localized RSVP - draft-manner-lrsvp-00.txt
Presentation made by Jukka Manner outlining the need for a local entity that
would work of behalf of an end-host.
Following points were discussed:
* location of the proxy at the cross-over router: this was seen as a possibility
but not a necessity
* relation to MPLS: this was not considered in the draft
* motivation to decide on localised signalling: to restrict the scope of the
path. A point was raised that a similar thing exists in mobile IP.
Chair mentioned that several people suggested considering the use of the RSVP
proxy in the NSIS solution.
1.20 PM Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks -
Presentation made by Jussi Ruutu, replacing the authors proposing a framework
consisting of a data plane and a control plane with inter-domain communication
between QoS Agents (QA), intra-domain communication between QAs and localised
QAs (LQAs) and communication between access router and end-host.
Questions were asked regarding:
* specific mobile IP extensions
* interaction between mobility and QoS agents
* information exchanged between the different entities
* reason why QAs weren't used for mobility as well
All questions should be referred to the list for the authors of the draft.
1.35 PM Framework for edge-to-edge QoS signaling -
Presentation by Georgios Karagiannis arguing the need for lightweight in-band
signalling and describing a framework for edge-to-edge communication. The draft
identifies three types of interactions and calls for a hierarchical approach in
which the edge-to-edge (intra-domain) solution could be part of an end-to-end
solution. The terminology used in the draft was felt to be confusing, especially
the use of edge-to-edge for intra-domain signalling. It was agreed that better
terminology was needed. It was remarked that the charter doesn't talk about
intra-domain signalling. The authors felt it to be applicable in case the
'single domain' was realised by means of tunnels (e.g. MPLS). A formal statement
regarding the charter will be requested from the ADs. It was not considered out
of scope and no reason was found to exclude it from the framework if sufficient
commonality with more general approaches could be found.
The question was asked how much the solution depends on the MBAC assumption
(measurement-based admission control). The authors replied the solution uses
MBAC principles but provides guarantees similar to per-flow guarantees. It was
asked whether the proposed functionality needed to be available at every hop.
The authors felt this was not necessary.
2.20 PM Relationship of Context Transfer to NSIS
Presentation by Rajeev Koodli on context transfer after hand-over
* identification of target router? needs to be done prior to handover.
* consider signaling after transfer, e.g. to exploit the availablility of a
bigger air-link? This was felt to be hard in practice and possible by combining
two elementary capabilities (transfer and modification of existing reservation)
* do we consider different sessions? This was felt to have some commonalities
with the issue of grouping micro-flows. It should be discussed at the solution
* what gain do you expect? interruption time of service, needs to restart
signaling procedure after handover.
* what do you want to transfer? -> referred to seamoby list
3 PM Two-level Architecture for Internet Signaling -
Presentation by Gabor Fodor on the two-level approach proposed in this draft
Chair proposed to consider the approach for our framework. The similarity with
the protocol element structure in draft-hancock-nsis-outline-fw-00.txt was
3 PM Next steps on the framework
A more high-level framework document bringing out the most important issues was
asked. Four options were proposed as a next step for the framework:
- promote a document to wg draft
- revise existing documents and discuss more
- combine existing documents
- assign small team to prepare framework draft, including authors of existing
drafts (Robert Hancock, Georgios Karagiannis, Sven Van den Bosch, Kan, maybe
The last option was felt to be appropriate, provided an outline could be agreed
upon. The agenda for May 23 was modified accordingly to include table of
contents discussion and charter review.
Thursday May 23, 2002
(need additional minutes)
9:00 Charter Discussion
The chair presented an edited charter. Some additional discussion ensued, with
additional editing. See edited charter. Next steps are to discuss with the Area
Directors, and if it is thought to be useful, the charter can be modified, after
some comment from the mailing list.
9:30 Next Steps in the Framework
There was considerable support to speed the process for submitting a working
group draft on Framework issues. The Chair presented a possible outline for the
framework. Discussion ensued. Resulting discussion is captured in the outline.
Next steps, propose the framework ono the mailing list, arrange conference calls
and begin work on the framework. It was felt that the authors of the individual
submissions on Framework issues should be involved.
10:30 Analysis of Existing QoS Solutions - Georgios Karagiannis
Georgios presented the draft. The chair noted that the presentation captured the
main issues perhaps better than the draft. Comparision against the Working Group
Requirements and an additional individual requirements draft are premature. Some
discussion on Analysis vs. Comparison. The chair thought that the document
should be focused on learning what has been done before. This can help us when
we work on the framework & and any protocol work.
11:00 Mobile IP and RSVP - Marc Greiss
Marc discussed issues related to RSVP and Mobile IP interaction.
Interim- Requirements of a QoS Solution for Mobile IP
Interim- Open Issues: from draft-ietf-nsis-req-02.txt
Interim- NSIS Threats & Security Requirements
Interim- An Outline Framework for QoS Signalling
Interim- Two-plane and Three-tier QoS Framework for MIPv6 networks
- Robert Hancock
- Eleanor Hepworth
Interim- Framework for Edge-to-Edge NSIS Signaling
Interim- A Two-Level Architecture for Internet Signaling
Interim- CT and NSIS
Interim- Analysis of existing QoS solutions
NSIS Framework Outline