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 <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Mailing Lists:
General Discussion:
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
  • - draft-ietf-nsis-req-02.txt
  • 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
    Meeting Minutes

    NSIS Scoping
    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.

    Agenda Bashing
    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
    later on.
    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
    [1] 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.
    [2] Sender/receiver - still open.
    [4] MUST/SHOULD/MAY (do this later)
    [7] 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.
    [8] NSIS should allow bidirectional reservations as an optimisation where the
    network topology allows it.
    [14] Grouping of microflows. Added (as a MAY, probably). Network does not need
    to know relationship exists. Add justification of why this is an optimisation.
    [16] Closed.
    [26] Interaction with seamoby. Add requirement to say that we are interworking
    in the area of mobility protocols (e.g. CT and CAR discovery).
    [28] Asynchronous events from the network. REH & Sven to propose wording
    including some motivation as examples. Issues to do with locality and scenarios.

    [29] NSIS in case of handovers. No change needed concerning handovers.
    [37] Ownership of a reservation. Close issue and handle it within security
    [39] Simplify security section. Postpone.
    [40] Mobility requirements - don't add. Closed.
    [42] Add assumption that QoS monitoring is application/service specific and out
    of scope.
    [43] Notification of QI/QC/QR. Closed earlier.
    [44] Resource availability query. Query not as 'real' reservation is part of
    service definition. May need new requirement about endpoint controlling locality
    of signalling.
    [45] Automatic re-installation. Removed, leave open option to supply text for
    new requirement.
    [46] Scenarios for failure and recovery cases. Remove, invite individual
    [47] 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.
    [52] Closed. Aspect of AAA (authentication --> authorisation) solution or
    service definition.
    [53] Sven et al. to write submissions.
    [59] Covered under [53].
    [61] Closed.
    [64] Closed (no new text except maybe motherhood statements).
    [65] Considered [53].
    [66] Closed (not included elsewhere).
    [67] Closed (already covered).
    [68] Merge with 5.3.2 to reflect wanting to avoid stale state (somehow).
    [69] Closed (already covered in transport service quality requirement). Protocol
    design must take into account reliability concerns.
    [70] Add something about graceful failover to general protocol requirements
    [72] 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).

    Wednesday AM
    9 AM Towards a Framework for QoS Signaling in the Internet
    - Presentation by Robert Hancock outlining purpose and structure of the
    framework draft.
    * 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
    address manipulation
    * 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
    framework level
    - 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.


    5 (6)




    Interim- Agenda
    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
    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