s.Next Steps in Signaling WG (nsis)
=================================

MONDAY, July 14 at 1530-1730 

CHAIR:	John Loughney <john.loughney@nokia.com>

MINUTE TAKER:
- Hannes Tschofenig
- Sven van den Bosch

AGENDA:

Agenda bashing & WG Update 15 min
        Milestones
        Charter Update 
        Requirements Doc update

Everyone should submit comments. 

John:
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)
==================


http://www.ietf.org/internet-drafts/draf
t-schulzrinne-nsis-ntlp-00.txt

Henning goes through his presentation:

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, 
fragmentation
* 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
- multihoming
- NAT behaviour
- mobility behaviour
- security mechanisms (TLS, IPSec, ...)

- Philosophy
  time and space tradeoff
  
  requirements: 
  - small messages / - unknown next hop/discovery / - possibly reliable 
hop-by-hop delivery
  - hard parts to the professional transport protocols

Questions:

Georgios: Question regarding the "RSVP philosophy" - message 
addressing
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 
choices 
(a unified choice might not be the best approach everywhere)

NSIS Transport Protocol (Melinda Shore)
=================


http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt

* Left out:
- security
- IANA
- fragmentation
- mobility
- 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 
authentication)
proposal to do nat and firewall + qos signalig together

Xiaoming : 
- does this draft confirm to the requirements
- explicit release of states
- scalability (# of handoffs)

John: the drafts have not been compared against requirements

Xiaoming: 
- Is tunneling considered?

Melinda: 
- no

Marcus: 
- Only one message? 
(coding message type into flags?)

Melinda:
- ok.

Cornelia:
- Path messages must be there? Is this the RSVP type of signaling 
handling? 

Melinda:
- ok. 

Ruediger:
- demonstration of reliable need for reliability
- how many of existing protocols use reliable mechanisms?

Melinda:
- 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

Ruediger:
- What is complex about using TCP?

Melinda:
- TCP+IPSec would mean twelve messages before first signaling message.

Hannes:
- If you support key management then you will have extra messages (they are 
added for good reasons)

Robert:
- Is the refresh reduction an NTLP function?

Melinda:
- not obvious

Charles Q. Shen:
- What kind of application are you working on?

John:
- QoS and middlebox traversal

Georgios: 
- NSLP nodes should be supported with a reduced NSLP state. This 
requires stateless NTLP.
- Take this into account. 

Xiaoming:
- Discovery does not need to be very frequently. Performance is 
reasonable. 
- Performance with transport protocol is acceptable.

John:
- Agreed to keep semantics of PATH statement.

John:
Summary
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.

Marcus:
Raised concern about process.

John:
Thought we would have a WG draft now.

Ruediger:
Wants to see state management clarified. Not clear which information is 
kept and to what it is related.

Henning:
People should make an effort to validate their assessment of 'cheap' and 
'overhead'.

Security, Threats & Authorization issues (Hannes Tschofenig)
==================

(30 minutes)

"Security Threats for NSIS" 

http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-threats-02.txt

"RSVP Security Properties"

http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-rsvp-sec-properties-02.txt

"QoS NSLP Authorization Issues"

http://www.ietf.org/internet-drafts/draf
t-tschofenig-nsis-qos-authz-issues-00.txt

"Security Implications of the Session Identifier"

http://www.ietf.org/internet-drafts/draf
t-tschofenig-nsis-sid-00.txt

Ruediger: 
- 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. 

John: 
- Way forward - make a proposal.
- Document structure will be decided tomorrow 

Ruediger:
Document offers many options. How are we going to decide?

John:
Decided it should be handled at the NSLP level.

Next Steps in Signaling: Framework  (Robert Hancock)
===========================

(15 minutes)


http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-fw-03.txt

http://www.ietf.org/internet-drafts/draf
t-hancock-nsis-overload-00.txt

Robert goes through his presentation

Marcus: 
- Hennings proposal was to provide selective reliability support. That 
sounds good to me.

Robert:
- sounds also good to me as well.


John:
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?
WG: yes 

Mobility Support in NSIS (Xiaoming Fu)
===========================


http://www.ietf.org/internet-drafts/draf
t-fu-nsis-mobility-00.txt

Xiaoming goes through his presentation.

Charles Q. Shen :
- Session identifier constructed

Xiaoming: 
- Referenced to discussions between Melinda and Henning at the mailing list

Marcus: 
- Most of the stuff is already covered in the framework document
- Proposal: cover it in the framework document

Melinda:
- Unique global id: we don't need one (hop-by-hop scope)
- How get around this requirement

Robert:
- 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.

Melinda:
- 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)
===========================

(15 minutes)


http://www.ietf.org/internet-drafts/draf
t-ietf-nsis-signalling-analysis-02.txt

John: 
- 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

Jukka:

- Merge with Michael Thomas draft? Should still get input from Michael.

John: 
- I will talk to Michael Thomas

Hannes:
- Policy handling stuff should not be incorporated into the analysis 
document. Instead it is more relevant for the authorization draft.

Georgios: 
- Could we add RMD to the draft?

Jukka:
- Please send text to the mailing list. Have been asking for text for 
months.
 
Jukka: 
- Should the Appendix about the RSVP / NSIS evaluation be removed.  

Audience: 
- YES


TUESDAY, July 15, 2003
1300-1400 Afternoon Session I
=============================

John: 
- 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)
===========================

(20 minutes)

http://www.ietf.org/internet-drafts/draf
t-buchli-nsis-nslp-00.txt

http://www.ietf.org/internet-drafts/draf
t-mcdonald-nsis-qos-nslp-00.txt

http://www.ietf.org/internet-drafts/draf
t-westberg-proposal-for-rsvpv2-nslp-00.txt

Robert goes through his presentation

Robert: 
- We concluded that various QoS reservation model have to be 
supported. 

John:
- 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.

Henning:
- 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.

Robert: 
- Error handling is much more complicated. 

Ruediger:
- The current security documents does not clearly describe at which layer 
security is handled. 

Hannes:
- That is true. The NTLP proposals have been submitted recently and hence 
there was not enough room for discussion on them.


Unknown:
- Is multicast excluded from the architecture?

Robert:
- It is not included in framework or requirements. no commitment at the 
moment to think about it now.

Marcus:
- Is there again another additional layer?

Robert: 
- 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?

Robert:
- The QoS signaling protocol is independent but there are some 
interactions with other protocol. 

Ruediger:
- There might be a problem in cases where you don't have mapping between 
different QoS reservation models.

John:
- How to proceed: Authors of the three documents will edit a new version of 
the document. 
=> short document. 
=> they also have to create a timetable (roadmap, review teams, open issue 
list, telephone conferences). 

Ruediger:
- What kind of document?

John: 
- Solutions document, plus keep appendix with open issues.
- Sense of the room on proposal. 

Audience:
- All in favour.


"NSIS Middle Box Signaling Application Protocol" (Marcus Brunner)
===========================

(20 minutes)


http://www.ietf.org/internet-drafts/draf
t-brunner-nsis-midcom-ps-00.txt

Marcus went through his presentation:

Objective: dynamically allocate pinholes or NAT bindings along the path
- applications: VoIP, gaming
Non-objective: IPSec endpoint discovery

Other solutions:
- 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

Technical problems:
- 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

John:
- Is there interest in this work?

Audience: 
- yes

John:
- One or two docs.

Allison: 
- One document, there are already too many documents

John: 
- 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

http://www.ietf.org/internet-drafts/draf
t-westberg-nsis-rsvp-as-ntlp-01.txt


Requirements for IPv6 Signaling as NTLP

http://www.ietf.org/internet-drafts/draf
t-choi-ipv6-signaling-req-ntlp-00.txt


Mobility Support in NSIS

http://www.ietf.org/internet-drafts/draf
t-fu-nsis-mobility-00.txt


QoS Signaling for IP-based Radio Access Networks

http://www.ietf.org/internet-drafts/draf
t-lee-nsis-signaling-ran-00.txt


RSVP Domain of Interpretation for ISAKMP

http://www.tschofenig.com/drafts/draft-t
schofenig-rsvp-doi-00.txt


Signaling for QoS Measurement

http://www.ietf.org/internet-drafts/draf
t-couturier-nsis-measure-00.txt