2.8.10 Next Steps in Signaling (nsis)
Last Modified: 2003-07-22
John Loughney <email@example.com>
Transport Area Director(s):
Allison Mankin <firstname.lastname@example.org>
Jon Peterson <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
In Body: (un)subscribe
Description of Working Group:
The Next Steps in Signaling Working Group is responsible for
standardizing an IP signaling protocol with QoS signaling as the first
use case. This working group will concentrate on a two-layer
signaling paradigm. The intention is to re-use, where appropriate,
the protocol mechanisms of RSVP, while at the same time simplifying it
and applying a more general signaling model.
The existing work on the requirements, the framework and analysis of
existing protocols will be completed and used as input for the
NSIS will develop a transport layer signaling protocol for the
transport of upper layer signaling. In order to support a toolbox or
building block approach, the two-layer model will be used to separate
the transport of the signaling from the application signaling. This
allows for a more general signaling protocol to be developed to
support signaling for different services or resources, such as NAT &
firewall traversal and QoS resources. The initial NSIS application
will be an optimized RSVP QoS signaling protocol. The second
application will be a middle box traversal protocol. It may be that a
rechartering of the working group occurs before the completion of this
Security is a very important concern for NSIS. The working group will
study and analyze the threats and security requirements for
signaling. Compatibility with authentication and authorization
mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and
RSVP Session Authorization (RFC 3250), will be addressed.
It is a non-goal of the working group to develop new resource
allocation protocols. Resource reservation and traffic engineering are
out of scope of this working group. Additionally, third party
signaling is out of scope of this working group. 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, etc. NSIS also welcomes participation and expression of
requirements from non-IETF standards organization members, for
instance 3GPP, 3GPP2 and ITU-T.
Goals and Milestones:
|Done|| ||Submit 'Signaling Requirements' to IESG for publication as
an Informational RFC. |
|Aug 03|| ||Submit 'RSVP Security Properties' to IESG as Informational
|Aug 03|| ||Submit 'NSIS Threats' to IESG as Informational RFC |
|Sep 03|| ||Submit 'Analysis of Existing Signaling Protocols' to IESG
as Informational RFC |
|Sep 03|| ||Submit 'Next Steps in Signaling: Framework' to IESG for
publication as Informational RFC |
|Feb 04|| ||Submit 'NSIS Transport Protocol' to IESG for publication
for Proposed Standard |
|Mar 04|| ||Submit 'NSIS QoS Application Protocol' to IESG for
publication for Proposed Standard |
|Sep 04|| ||Submit 'NSIS Middle Box Signaling Application Protocol' to
IESG for publication for Proposed Standard |
No Request For Comments
Current Meeting Report
s.Next Steps in Signaling WG (nsis)
MONDAY, July 14 at 1530-1730
CHAIR: John Loughney <email@example.com>
- Hannes Tschofenig
- Sven van den Bosch
Agenda bashing & WG Update 15 min
Requirements Doc update
Everyone should submit comments.
Melinda and Henning were not be able to merge their two documents due to
time constraints. Hence their presentation will be separated.
* "NSIS Transport Protocol" (Henning Schulzrinne)
Henning goes through his presentation:
* toolkit approach
* RSVP like
- follow data path
- soft-state time-out
* transport protocol
- do easy parts with simple transport:
. small messages
. first message of a session
. reliable hop-by-hop delivery
- leave hard parts to real transport protocols
. invoked when needed
. offer fast recovery, flow control, congestion control,
* other design choices: TLV structure, refresh reduction like 2961, no
explicit support for multicast
* what needs work:
- state maintenance
- state estimate (~session+next hops)
- describe NSLP-specific next-hop selection
- packet format
- NAT behaviour
- mobility behaviour
- security mechanisms (TLS, IPSec, ...)
time and space tradeoff
- small messages / - unknown next hop/discovery / - possibly reliable
- hard parts to the professional transport protocols
Georgios: Question regarding the "RSVP philosophy" - message
Are NTLP messages handled the same way as RSVP messages?
Henning: Yes, subject to caveats mentioned at interim meeting
Georgios: Modes of operation (datagram - connection oriented)
Henning: have not received too much comments on that. there are a number of
(a unified choice might not be the best approach everywhere)
NSIS Transport Protocol (Melinda Shore)
* Left out:
- error/exception messages
- NSLP interface
* RFC 2961
- basic functions:
. summary refreshes
. message bundling
. reliable delivery: wants it dropped
message bundling makes security more complex (source
proposal to do nat and firewall + qos signalig together
- does this draft confirm to the requirements
- explicit release of states
- scalability (# of handoffs)
John: the drafts have not been compared against requirements
- Is tunneling considered?
- Only one message?
(coding message type into flags?)
- Path messages must be there? Is this the RSVP type of signaling
- demonstration of reliable need for reliability
- how many of existing protocols use reliable mechanisms?
- we might not need it for all applications
- retransmission would also provide some level of reliability - is it
worth the complexity
- More roundtrips with reliable message delivery
- What is complex about using TCP?
- TCP+IPSec would mean twelve messages before first signaling message.
- If you support key management then you will have extra messages (they are
added for good reasons)
- Is the refresh reduction an NTLP function?
- not obvious
Charles Q. Shen:
- What kind of application are you working on?
- QoS and middlebox traversal
- NSLP nodes should be supported with a reduced NSLP state. This
requires stateless NTLP.
- Take this into account.
- Discovery does not need to be very frequently. Performance is
- Performance with transport protocol is acceptable.
- Agreed to keep semantics of PATH statement.
Sufficient commonality, should merge draft. Areas of disagreement to be
left as open issues with discussion on mailing list. Will organize open
design team conference calls.
Raised concern about process.
Thought we would have a WG draft now.
Wants to see state management clarified. Not clear which information is
kept and to what it is related.
People should make an effort to validate their assessment of 'cheap' and
Security, Threats & Authorization issues (Hannes Tschofenig)
"Security Threats for NSIS"
"RSVP Security Properties"
"QoS NSLP Authorization Issues"
"Security Implications of the Session Identifier"
- What happens if the session identifier is not included?
- Does the problem go away?
- It would be good to add some text to the draft.
- Way forward - make a proposal.
- Document structure will be decided tomorrow
Document offers many options. How are we going to decide?
Decided it should be handled at the NSLP level.
Next Steps in Signaling: Framework (Robert Hancock)
Robert goes through his presentation
- Hennings proposal was to provide selective reliability support. That
sounds good to me.
- sounds also good to me as well.
Concern that framework does not provide all answers. Proper thing would be to
cover the implications and defer decision to protocol
implementation. Framework should list options.
- Who thinks that the framework is in good shape?
Mobility Support in NSIS (Xiaoming Fu)
Xiaoming goes through his presentation.
Charles Q. Shen :
- Session identifier constructed
- Referenced to discussions between Melinda and Henning at the mailing list
- Most of the stuff is already covered in the framework document
- Proposal: cover it in the framework document
- Unique global id: we don't need one (hop-by-hop scope)
- How get around this requirement
- Where should mobility go with regard the layer split?
- Many things are signaling application dependent.
- Some parts should go into the analysis document.
- It shouldn't go all into the framework document.
- If there implications for addressing then it might be go into the NTLP.
- We need to study this.
Analysis of Existing Signaling Protocols (Jukka Manner)
- The document is also ready for last call.
Jukka goes through his presentation
Ping Pan incorporated his document into the draft (became co-author)
- Appendix : RSVP/NSIS comparison
Action: Summary of the RSVP security properties
- Merge with Michael Thomas draft? Should still get input from Michael.
- I will talk to Michael Thomas
- Policy handling stuff should not be incorporated into the analysis
document. Instead it is more relevant for the authorization draft.
- Could we add RMD to the draft?
- Please send text to the mailing list. Have been asking for text for
- Should the Appendix about the RSVP / NSIS evaluation be removed.
TUESDAY, July 15, 2003
1300-1400 Afternoon Session I
- General Guidelines:
We should comment to what conclusion we came. This avoids
continuously reconsidering the same issues again. We need to come to a
decision on the NSLP stuff.
"NSIS QoS Application Protocol" (Robert Hancock)
Robert goes through his presentation
- We concluded that various QoS reservation model have to be
- Some people need to take a look at what QoS reservation model they want. We
should take a look at RSVP/DiffServ to make it more general.
- Default mode is to route messages back to originator
(hop-by-hop). It is hard to use a stateless approach only. Error
handling is challenging.
- Error handling is much more complicated.
- The current security documents does not clearly describe at which layer
security is handled.
- That is true. The NTLP proposals have been submitted recently and hence
there was not enough room for discussion on them.
- Is multicast excluded from the architecture?
- It is not included in framework or requirements. no commitment at the
moment to think about it now.
- Is there again another additional layer?
- A lot of communality between different QoS signaling protocol
proposals using different QoS reservation models. Whether there is a 100%
split is not certainly clear.
Charles Q. Shen :
- What are the dependicies with other protocols?
- The QoS signaling protocol is independent but there are some
interactions with other protocol.
- There might be a problem in cases where you don't have mapping between
different QoS reservation models.
- How to proceed: Authors of the three documents will edit a new version of
=> short document.
=> they also have to create a timetable (roadmap, review teams, open issue
list, telephone conferences).
- What kind of document?
- Solutions document, plus keep appendix with open issues.
- Sense of the room on proposal.
- All in favour.
"NSIS Middle Box Signaling Application Protocol" (Marcus Brunner)
Marcus went through his presentation:
Objective: dynamically allocate pinholes or NAT bindings along the path
- applications: VoIP, gaming
Non-objective: IPSec endpoint discovery
- application specific firewalls
- midcom wg
Draft lists various scenarios:
- FW/NAT related scenarios
- Security related
NAT/FW NSLP solves
- topology problem of other midcom related proposals
- easily works with more than one NAT/FW in a row
- application independent
- missing network-network trust relationship
- going into a NAT from the outside
- quickly deal with route changes
Should document cover
- NAT handling of other NSLP
- interop with non-NSIS aware NAT
- solution specific aspects
- Is there interest in this work?
- One or two docs.
- One document, there are already too many documents
- Ask the other authors for input.
- Prepare a timetable in a similar fashion as the QoS NSLP
Wrapup & Next Steps - 10 minutes - chair
Other relevant documents
Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for
modifications on RFC2205
Requirements for IPv6 Signaling as NTLP
Mobility Support in NSIS
QoS Signaling for IP-based Radio Access Networks
RSVP Domain of Interpretation for ISAKMP
Signaling for QoS Measurement
RSVP Security Properties
NTLP strawman draft-schulzrinne-gimps
Mobility Support in NSIS
QoS NSLP Authorization Issues
Security Implications of the Session Identifier
NSIS Framework Issues
An NSLP for Quality of Service
Problem Statement and Framework
nsis ntlp discussion
Security Threats for NSIS