Last Modified: 2005-06-27
| Done | Submit 'Signaling Requirements' to IESG for publication as an Informational RFC. | |
| Done | Submit 'Next Steps in Signaling: Framework' to IESG for publication as Informational RFC | |
| Done | Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC | |
| Done | Submit 'RSVP Security Properties' to IESG as Informational RFC | |
| Done | Submit 'NSIS Threats' to IESG as Informational RFC | |
| Apr 05 | Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard | |
| May 05 | Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard | |
| May 05 | Submit 'NSIS QoS Specification Template' to IESG for publication as an Informational RFC | |
| Jun 05 | Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard | |
| Sep 05 | Submit 'Applicability Statement of NSIS Protocols in Mobile Environments' to the IESG as an Informational RFC | |
| Sep 05 | Submit 'Differentiated Service Signaling on the Internet' to the IESG for publication as an Informational RFC |
| RFC | Status | Title |
|---|---|---|
| RFC3583 | I | Requirements of a Quality of Service (QoS)Solution for Mobile IP |
| RFC3726 | I | Requirements for Signaling Protocols |
| RFC4080 | I | Next Steps in Signaling (NSIS): Framework |
| RFC4081 | I | Security Threats for Next Steps in Signaling (NSIS) |
| RFC4094 | I | Analysis of Existing Quality of Service Signaling Protocols |
|
Next Steps in Signaling WG (nsis)
THURSDAY, August 4 at 0900-1000 =============================== CHAIRS: John Loughney <john.loughney@nokia.com > Scribes: - Andrew McDonald - Andreas Pashalidis Agenda ------ John Loughney http://www.ietf-nsis.org/nsis/IETF63/agenda.ppt agenda bashing unofficial web page: http://www.ietf-nsis.org wg update: three new rfcs: rfc4094, rfc4080, rfc4081 in rfc-ed queue: rsvp-sec-properties two new charter items: y1541, ntlp state machine nsis-implementors: a separate mailing list exists a few implementations available coimbra implementation: http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00056.html goettingen implementation: http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00051.html possibility of another interop before next ietf meeting some work going on implementing nslps, so may be opportunity to interop those Interop ------- Martin Stiemerling http://www.ietf-nsis.org/nsis/IETF63/ietf63_nsis_interop.ppt organised by EU IST MOME and Eurolabs projects 5 indepedent NSIS implementations based on ntlp-06 draft variety of tests covered only a few issues - now in issue tracker - Issue61: NLI selection - Issue59: Interpretation of D flag in MRI - Issue58: S flag from end system - Issue57: setting/interpreting the R-flag - Object order - does it matter? - TCP connections only need to be accepted from peers they have been offered to Next steps: University of Coimbra offered to host an interop Interested parties should contact nsis implementors list Cedric: it would be nice to have nodes available on internet, to check ip options are received properly Tra Luu: can you get information about implementations? John: I believe two implementations have released their implementations with source - see implementors list GIMPS: General Internet Messaging Protocol for Signaling --------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-07.txt http://www.ietf-nsis.org/nsis/IETF63/draft-ietf-nsis-ntlp-07.ppt Robert Hancock Loose-end MRM: new section 5.8.2 - find edge of network in the nat case Upstream query for signalling localisation - 5.8.1.3 defn of how to encapsulate upstream query Error messages - added text on general error messages, still need to add some more specific information Open issues in -07: On-reverse-path threat (issue 17) - propose to document as residual threat Hannes: i think it would be worth dealing with it - yes there is some additional complexity and specification - I think we should do it Robert: primarily specification effort. we can't prevent this on the forward path. specification issue - especially once extensibility is taken into account Channel security choice (issue 29) front runners: TLS, IPsec propose: TLS NAT traversal aspects (issues 24, 22, 23) Issue24 - defer to separate doc Issue22 - text already included Issue23 - defer to separate doc Cedric: are we depending on nat/fw nslp Robert: two issues: from impl point of view does an NTLP impl have nat/fw nslp is different question from whether messages needed to do nat traversal are done at ntlp or nslp Cedric: you cannot update the mri without having access to the nat binding table Robert: that is a separate issue Martin: the gimps-aware is not a problem to implement for sending from inside to outside. is it ok to define a gimps proxy on nat? so can traverse without nat/fw nslp? Robert: I think that is something we can define without changing protocol specification John: more a nat implementation issue Configuration data format (issue 14) only serious remaining issue - already knew about before interop solution proposed on issue tracker rapid feedback from implementors desired Henning Schulzrinne: can you describe it so we can reach a conclusion here? Robert: include protocol+config data. alternative is to do it by ordering Henning: a bit like dns srv records - transport, shim and preferences Robert: signalling preferences is a separate issue - not done up until now. there is no negotiation - initiator chooses. not keen on ordering - difficult to do bullet proof specification Martin: i think the preference issue is the profiles you offer to the initiator. introducing an order is not an issue - you have to keep them ready in any case. clarifications/refinements - as martin described earlier spec finalisation iana considerations - strawman list of policies - tehcnical criteria are documented separately MUST-ification still required John: issue from other working groups - when you choose SHOULD you need to say why Henning: in other working groups there has been pushback on SHOULD - each SHOULD adds one bit of implementation variation and interop issue John: want to make sure that nsis nodes are robust in a wide variety of signalling situations Henning: also from a customer perspective MUST sets expectations - had issue with SIP of people regarding all SHOULDs as optional and finally: what should we call it [slide with a long list of random names] John: go ahead henning [nobody goes to microphones] Robert: looks like nobody wants to comment Henning: this is fun exercise that probably requires one beer for each participant. Robert: that's how we got Shingou Henning: i'd like to avoid something that refers to NSIS as a working group. anything with N in it referring to NSIS will make no sense ten years from now. names with negative connotations probably bad Allison: i'd like to make the case for a simple name. in american english gimps is a negative word. I suggest NST for network signalling transport. NSQ for network signalling qos. need to get away from gimps, which we got used to Robert: i never got used to it Allison: outside of our world they call the protocol nsis, but ask why it is called that Henning: i made an early suggestion for GIST - Generic Internet Signalling Transport Allison: that would be ok too Henning: only issue with NST (pronoucing is as nist) is that NIST already exists ???: GIMPS also is Great Internet Mersenne Prime Search Henning: i had something to do with gimps name, but always saw gimps as temporary name John: we'll hum: NST, GIST or something else to be resolved John: GIST had strongest hum - confirm on mailing list John: interop gave strong validation of spec. have asked rob to clear up reamining issues. will then be ready for WGLC Applicability Statement of NSIS Protocols in Mobile Environments ---------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-nsis-mobility-02.txt Sung-Hyuck Lee http://www.ietf-nsis.org/nsis/IETF63/NSIS-mobility_63rd_ietf.ppt Sung-Hyuck Lee there is an issue tracker draft-02 - some issues resolved at interim remaining issues: - CRN discovery - mobile ip specific api - invalid nsis responder problem - optimal refresh timers - CRN discovery and path update on ip-tunnelling path - localized path update new issues: make-before-break last node problem prority over signaling api explicit indicaion of refresh node failure and restart handling Martin: CRN discovery - either done on NTLP or NSLP layer - only usable thing is to do it on NSLP layer, otherwise don't gain anything Seong-Ho Jeong: the reason why we raised this was because ntlp seems to have sufficient information, so might be easier processing for nslp layer Robert: i think there are 2 points: by construction of ntlp - or gist in fact - if there is a crossover node, then discovery is an implementation issue John: take further issues to list NSIS Flow ID and packet classification issues --------------------------------------------- http://www.ietf.org/internet-drafts/draft-cheng-nsis-flowid-issues-01.txt Takako Sanda http://www.ietf-nsis.org/nsis/IETF63/nsis-flowid-issues-01.ppt generating packet classifier from mri may not be able to function properly in off-path case packet classifier needs to be different from mri sharing qos resources between multiple flows support for multiple addresses - e.g. multiple ports considerations: - nat traversal - need to translate filter list as will as MRI John: any comments? John: send issues to list John: we're out of time. will handle multi-homing draft tomorrow FRIDAY, August 5 at 0900-1130 =============================== NSIS Signaling Protocols in Multihomed Mobile Networks ------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-lee-nsis-multihoming-mobility-00.txt Suwon Lee http://www.ietf-nsis.org/nsis/IETF63/NSIS_Multihoming.ppt roland: may have impact on shim6 john: i agree. i have had some discussions with wg chairs - they are interested in issues of path, but not developing protocols elwyn: suggesting distributing packets from flows across multiple interfaces. often this is deemed to be a bad thing - reordering issues. hannes: considerable overlap with mobility work john: let's discuss this robert: followup comment on loadsharing - implies flow over multiple paths Y.1541 QoS Model for Networks Using Y.1541 QoS Classes ------------------------------------------------------ http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qosm-00.txt Jerry Ash http://www.ietf-nsis.org/nsis/IETF63/y1541-qosm.ppt robert: are there actually any technical open issues about this draft? jerry: not that i know of john: i suggest that people review the document and check for technical open issues al morton: i guess that since the basis recommendation has just been posted, some issues may emerge. posted version is extended version, but diff marks won't go back to published version. User Application-to-User Plane Vertical Interface ------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-interface-00.txt Jerry Ash http://www.ietf-nsis.org/nsis/IETF63/vertical-interface.ppt john: discussions over coffee point out need to identify when to perform nsis signalling hannes: martin wrote a document talking about sip and nsis signalling. you might want to take a look at it. NSIS Operation Over IP Tunnels ------------------------------ http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt Henning Schulzrinne rob: should get this into the first round of things, so don't have to guess if other end is tunnel aware hannes: should we add something to the nslps? gaps between functionality between nslps? henning: if putting into nslps have to make sure new ones don't miss it out hannes: how should we deal with things where we overlap with existing work steve: have you looked at interaction with ipsec henning: have not. would value input on that. NAT/Firewall NSIS Signaling Layer Protocol (NSLP) ------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-07.txt Cedric Aoun http://www.ietf-nsis.org/nsis/IETF63/IETF63-NATFWNSLP-07.ppt John: you might want to indicate in the draft what the impact of an on-path adversary is. John: next step is to work through the remaining open issues. Requirements for Firewall Configuration Protocol ------------------------------------------------ http://www.ietf.org/internet-drafts/draft-bajko-nsis-fw-reqs-02.txt Gabor Bajko http://www.ietf-nsis.org/nsis/IETF63/fw-req.ppt John: 3ggp2 liaison asked for a semiofficial statement about working with 3gpp2 and firewalls. This is what this presentation is about. It must be possible to query the firewall to get the list of all installed pinholes; this should of course only be possible from authorized clients, for LI purposes. John: this is an administrative issue, not subject of NSIS signaling, correct? Gabor: basically agrees. 3gpp2 keeps the multihomed firewalls in synch, this is not done in NSIS. Problem in 3gpp2 is that they have parallel firewalls (maybe even nats); the opportunistic address approach does not suffice, because stuff has to be kept in synch. John: configuration issues should be given consideration. On path signaling gets rid of certain configuration overheads. Martin: nsis can only work on sessions that you are signaling. Signaling for multiple session ids is different. This is a question for the NTLP group. Robert: session means NSIS session of 3gpp2 session in the second bullet? Gabor: it is an application session. Cedric: you could still aggregate at session association level. Use nagle algorithm or whatever… Gabor: is that possible in theory. Cedric: theory yes. Depends on MTU as well. John: since 3gpp2 wants to use this for firewall signaling, we should provide appropriate guidance for them. Send 3gpp-2 related issues to the mailing list NSLP for Quality-of-Service signalling -------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-07.txt Andrew McDonald http://www.ietf-nsis.org/nsis/IETF63/qos-nslp-ietf63.ppt Andrew: There are some open issues regarding security and aaa interworking. Hannes: we are working on some of those issues. To some extend the AAA stuff is relevant. We are asking the qos guys to see if our AAA is properly aligned. Of course we looked at the docs, but it would still be good to get your feedback. Andrew: there maybe natfw related things that we might want to look at too. Cedric: how do you realize that you are just became the last node (NR) from after a situation where you were just a NF? Andrew: we have not decided yet. QSPEC update ------------ http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-05.txt Cornelia Kappler http://www.ietf-nsis.org/nsis/IETF63/qspec.ietfparis.ck2.ppt henning: do we need the h.460/h.323 elements - deployment is going down rather than up. could they define these later? there is always one more david: i still owe cornelia/jerry some text on using token buckets related to diffserv. will send it in so that they can incorporate it before vancouver Controlled Load QoSM ------------------- http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledload-02.txt Cornelia Kappler http://www.ietf-nsis.org/nsis/IETF63/CLSoverNSIS.ppt Cornelia: Idea: Verify qos nslp qspec applicability to known ietf qos model We got in contact with john wroclawski, in order to get expert feedback on cntrl load. Cornelia: I think the controlled load QoSM should be done in a separate draft. QSPEC draft is already long. There is always one more thing to add John: have you filed this as an open issue? Cornelia: no John: then post it as an open issue to see what people think. Cornelia: for the next meeting we are aiming to have something stable. Hannes: I think that one of the open issues is the interworking with the AAA. We came across open issues. John: it should be on the mailing list, otherwise it is not an issue. David Black: I owe people some text. Resource Management in Diffserv QOS Model ----------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-03.txt Attila Bader http://www.ietf-nsis.org/nsis/IETF63/draft-ietf-nsis-rmd-03.ppt john: rt ecn is open issue in tsvwg david black: if you need 16 dscp this is an issue due to limited supply david: i would suggest considering getting this down to 4 it would be worth looking at diffserv aggregation drafts in tsv 16 is just going nowhere 3GPP QoSM --------- http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-01.txt Seong-Ho Jeong http://www.ietf-nsis.org/nsis/IETF63/draft-ietf-nsis-rmd-03.ppt ??: you mention some docs from the 3gpp, most like this is not going anywhere in the 3gpp. The end to end qos is not 3gpp style. They have a model already. John: it would be useful if you could send more information about this to the WG. ??: mapping of qos to diffserv is also already done. When you talk interworking and end-to-end, 3gpp is not that much interested. John: we should have a review from the 3gpp side to see what is reasonable from their perspective. Cornelia: this is basically how to interwork with other qos models. How does the qspec look like. I also do not understand, if you signal to wimax or wlan, then you would use there the local qos models and not the 3gpp qos model. John: 3gpp is working on wlan interworking. The issues you raise may be outside the scope. I do not think this can be a WG draft until the 3gpp asks for it. The ietf cannot tell to the 3gpp “this is how you do qos signaling”. There has to be more discussion with the 3gpp to see their opinion and to see if they are going to adopt what we are doing. QoS NSLP Implementation ----------------------- Xiaoming Fu http://www.ietf-nsis.org/nsis/IETF63/QoSImpl.ppt Xiaoming talks about an ongoing QoS NSLP implementation. Details can be found at: http://user.informatik.uni-goettingen.de/~qos No questions NSIS Ping tool -------------- http://www.ietf.org/internet-drafts/draft-juchem-nsis-ping-tool-02.txt Christian Dickmann http://www.ietf-nsis.org/nsis/IETF63/PingTool_IETF63.ppt John: it is a very good effort, we should see what sort of diagnostics we need. Metering NSLP ------------- http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-01.txt http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-02.txt Ali Fessi http://www.ietf-nsis.org/nsis/IETF63/nsis-m-nslp-ietf-63.ppt No questions. NAT Traversal for GIMPS ----------------------- http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimps-nattraversal-00.txt Andreas Pashalidis No questions. In-Band QoS Signaling for IPv6 ------------------------------ http://www.ietf.org/internet-drafts/draft-roberts-inband-qos-ipv6-00.txt Jim Harford Slides cannot be added to the meeting minutes since they contain a copyright statement that is incompatible with the copyright approach taken by the ietf. al morton: sg12 polite nodding not consensus scott brim: similarly, sg13 agreed on problem statement john: point of order - better not have an itu meeting here. should use itu liaison channel john: is current spec publically available jim: understand that there are copyright/ipr issues john: we would of course need specs for interworking david: are you aware of tcp quickstart draft? jim: no david: you should do. solves some of the problems with inband signalling roland: maybe inband signalling is much more difficult for security issues. our current approach allows sophisticated security mechanisms that might be difficult for inband mechanism jim: requests/responses not encyrpted so possibly some denial of service issues hannes: there are many security aspects to deal with. gorry: the tia1039 talks a lot about ipv4 and doing unusual tcp. are you dropping the ipv4 stuff? jim: no. initial point of draft was to get an ipv6 codepoint, so that's the focus gorry: are you going to write a draft on how you interact with the transport layer in ipv4 and ipv6 jim: goes along with point of availability of spec tom phelan: may fit into the qos model architecture elwyn: from point of view of ipv6 side. in terms of intent of hop-by-hop options, this almost certainly doesn't fit. since you won't get all routers to support it. the amount of data in this option creates a severe burden for other routers. discussion in ipv6 world that the content of the hop-by-hop option should be limited to allow processing in the fast path. jim: you're saying this will significantly cause problem for router that doesn't. elwyn: yes, they've still got to look at it. one option may be to use a router alert option, and then a separate option for this, so that every router doesn't have to look at it. not convinced can be done in fast path, since probably involves call out to policy server. bob hinden: proposes lots of changes to many ietf protocols - tcp, ip. but, not publishing specs in ietf. you'd be more likely to get support if you did this work in the ietf francois le faucheur: similarity to quick start. they've looked at the tradeoff and kept the hop-by-hop option there very simple. they've selected a different compromise. hannes: have you thought about issues like mobility, multihoming, tunneling, aggregation, extensibility, non-end2end scenarios, etc.? |