Next Steps in Signaling (nsis) Charter

Current Meeting Report
Slides

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

Chair(s):

John Loughney <john.loughney@nokia.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>

Transport Area Advisor:

A. Mankin <mankin@isi.edu>

Mailing Lists:

General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

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

Internet-Drafts:

- draft-ietf-nsis-req-02.txt

No Request For Comments

Current Meeting Report

Agenda

Tuesday May 21, 2002

10:00 Scoping Discussion - John Loughney

10:30 Requirements of a QoS Solution for Mobile IP - John Loughney
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt

11:00 Requirements for QoS Signaling Protocols - Marcus Brunner
http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt

13:00 Requirements for QoS Signaling Protocols continued - Marcus Brunner
http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-02.txt

15:00 NSIS Threats - Hannes Tschofenig
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-00.txt

Wednesday May 22, 2002
9:00 An Outline Framework for QoS Signaling - Robert Hancock
http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-outline-00.txt

13:45 Localized RSVP - Jukka Manner
http://www.ietf.org/internet-drafts/draft-manner-lrsvp-00.txt

14:00 Two-plane and Three-tier QoS Framework for Mobile IPv6 Networks - Jussi
Ruutu
http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt

14:30 Framework for edge to edge QoS signaling - Georgios Karagiannis
http://www.ietf.org/internet-drafts/draft-westberg-nsis-edge-edge-framework-00.txt

15:00 Relationship of Context Transfer to NSIS - Rajeev Koodli
http://www.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-03.txt

15:30 Two-level Architecture for Internet Signaling
http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-00.txt

Thursday Thursday May 23, 2002
9:00 Framework summary - all

10:00 "Analysis of Existing QoS Solutions" - Georgios Karagiannis
http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-01.txt

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
that).
Concern (Ilya): IP telephony tends to use signalling initiated off the data
path.
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
section.
[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
contributions.
[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
section.
[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
(http://search.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt)
- Presentation by Robert Hancock outlining purpose and structure of the
framework draft.
Purpose:
* 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.

Structure:
* 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
document.

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,
notification).
Some parts were already deemed out of scope (SLS negotiation, next hop
discovery)
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
transport).

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
scenario.
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 -
draft-kan-qos-framework-00.txt
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 -
draft-westberg-nsis-edge-edge-framework-00.txt

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

Questions:
* 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
stage.
* 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 -
draft-braden-2level-signal-arch-00.txt
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
noted.

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
others).
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.

DOCUMENTTYPE

5 (6)

TypeUnitOrDepartmentHere

TypeYourNameHere
TypeDateHere