2.8.11 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Interim Meeting - Next Steps in Signaling (nsis)

Last Modified: 2004-06-07

John Loughney <john.loughney@nokia.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/nsis/index.html
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 protocol work.

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 milestone.

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.
Done  Submit 'Next Steps in Signaling: Framework' to IESG for publication as Informational RFC
Jan 04  Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC
Jan 04  Submit 'RSVP Security Properties' to IESG as Informational RFC
Jan 04  Submit 'NSIS Threats' to IESG as Informational RFC
Sep 04  Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard
Nov 04  Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard
Jan 05  Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard
  • - draft-ietf-nsis-fw-06.txt
  • - draft-ietf-nsis-threats-05.txt
  • - draft-ietf-nsis-rsvp-sec-properties-04.txt
  • - draft-ietf-nsis-signalling-analysis-04.txt
  • - draft-ietf-nsis-qos-nslp-04.txt
  • - draft-ietf-nsis-nslp-natfw-03.txt
  • - draft-ietf-nsis-ntlp-03.txt
  • Request For Comments:
    RFC3583 I Requirements of a Quality of Service (QoS)Solution for Mobile IP
    RFC3726 I Requirements for Signaling Protocols

    Current Meeting Report

    NSIS Working Group Meeting (IETF#59)

    NSIS Working Group Meeting

    IETF#60 (60th IETF - San Diego, CA, USA, August 1-6, 2004)



    John Loughney <john.loughney@nokia.com>

    Transport Area Director(s):

    Allison Mankin <mankin@psg.com>
    Jon Peterson <jon.peterson@neustar.biz>

    Transport Area Advisor:

    Allison Mankin <mankin@psg.com>


    Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>


    Minute Taker: 

    • Hannes Tschofenig
    • Sven Van Den Bosch

    Jabber Scribe:

    • Fred Baker
    • Andrew McDonald



    • John (John Loughney) 
    • Allison (Allison Mankin)
    • Robert (Robert Hancock)
    • Hannes (Hannes Tschofenig)
    • Cedric (Cedric Aoun) 
    • Martin (Martin Stiemerling)
    • Pete (Pete McCann)
    • Brian (Brian Carpenter)
    • Tom (Tom Phelan) 
    • Sung-Hyuck (Sung-Hyuck Lee)
    • Attila (Attila Bader)
    • Brian (Brian Carpenter)
    • Bob (Bob Braden)
    • Ruediger (Ruediger Geib)

    Unofficial IETF NSIS Weblog: http://www.tschofenig.com/cgi-bin/nsis.cgi


    MONDAY, August 2, 2004 (1300-1500)


    Agenda bashing & WG Update - 20 min

    John:  http://www.tschofenig.com/nsis/IETF60/NSIS_IETF60.ppt

    John explains the current draft status and asked the working group to make three new drafts working group items. The slides list the status and the drafts.


    GIMPS:  General Internet Messaging Protocol for Signaling

     Robert: 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-03.txt

    Robert goes through his presentation which can be found at  http://www.tschofenig.com/nsis/IETF60/draft-ietf-nsis-ntlp-03.ppt


    Open Issue 1: C-Mode Protocol Discovery

    Cedric: Racing conditions; upstream & downstream peer need to be able  

    Robert: We need to have some paper in front of us to figure out what these race conditions are.

    Bob: If you have reliable delivery how many packets go back and forth.

    Robert: There will be application level acks for some messages. Application recovery will be implemented.

    Bob: I like the answer.

    Ruediger: The current draft does not state how the priority handling is handled.  Could you add some text on the benefits and the costs?

    Robert: This request came from the signaling application authors. I would like to forward your request.


    Open Issue 2: Protocol Extensibility

    Robert talks about Section 8.11 of the GIMPS draft with regard to the flat space for the flags

    Gimps could define these common flags.

    Robert asks two questions:

    a) Should we have these flags?

    - Critical bit
    - Propagate bit
    - Refresh bit

    b) Should we use a different approach?


    John: I would like to solicit some comments on the extensibility.

    Allison: I had it on my list and i haven't done it. This is the place where RSVP got swamped and overrun. I don't know the right answer. It is not a pure transport here. It is a key feature and we need to get it right. You might want to ask the question again at the next session.

    Robert: There some bits which are not totally isolated (e.g., object format)

    Bob: Maybe some folks from the label switching community can give some help here.

    Bob: It's time to start implementations. We had implementation experience in RSVP.

    John: Implementation work is ongoing.

    Ruediger: I was reading the draft and the keywords MUST, MAY and SHOULD are missing. I have difficulty to see how a draft can be implemented with many different options.

    Robert: It is true that there are not too many keywords. Robert thinks that many of them are obvious. Will be provided in future versions.

    Cedric: It would be good to have some state machines in the draft.

    Robert: It would be good to document some processing rules. In RSVP it was in a separate document.


    Applicability Statement of NSIS Protocols in Mobile Environments

    Sung-Hyuck: 10 min http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mobility-01.txt

    Sung-Hyuck starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/NSIS_mobility.pdf


    Ruediger: If HIP comes then it would be good to describe the interworking between NSIS and HIP.

    Martin: There is some work ongoing with HIP and NAT.


    NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

    Cedric - 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-03.txt

    Cedric goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/IETF60-NATFWNSLP-02.ppt


    Cedric: DoS describes a dos attack  sending fake path change messages.

    Robert: There is nothing you can do about this.

    Cedric+Robert: Discuss this offline

    Cedric: We haven't received comments. Are people ok with the changes?

    John: There is no reason to wait since we need to make progress. Send a mail to the mailing list a few weeks before you send the update. If there are no objections then incorporate it.


    Path-coupled NAT/Firewall Signaling Security Problems

    Hannes: 10 min http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-natfw-security-problems-00.txt

    Hannes goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/Path_coupled_NATFW_Signaling_Security_Problems.ppt


    John: NSIS working group members should read the document. It is quite short.


    Security Threats for the NATFW NSLP

    Martin: 10 min http://www.ietf.org/internet-drafts/draft-fessi-nsis-natfw-threats-01.txt

    Martin goes through his slides which can be found at http://www.tschofenig.com/nsis/IETF60/IETF60-NATFW-threats.ppt 


    No comments.


    NAT/Firewall NSLP Migration Considerations

    Cedric: 10 min http://www.ietf.org/internet-drafts/drafts/draft-aoun-nsis-nslp-natfw-migration-01.txt

    Cedric starts with his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/IETF60-NATFWNSLP-ops-01.ppt


    Robert: This is about optimization of the flow path of NSIS-unaware NAT?

    Cedric: No, this is about NSIS-aware NAT traversal.


    NAT/Firewall NSLP Intra-Realm Considerations

    Cedric: 10 min http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-intrarealm-01.txt


    No comments.


    Tuesday, August 3, 2004 (1700-1800)


    NSLP for Quality-of-Service signalling

    Sven: 15 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-04.txt

    Sven starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/draft-ietf-nsis-qos-nslp-04-ietf60.ppt


    Ruediger: Two major issues -

    a) Default behavior for RESV is that it is not acknowledged. I suggest to change this. RESERV should always be ACKed

    b) You have changed the behavior of the QUERY message - you use it as a reserve. You install state. It is a zero-reservation.


    Sven: Regarding (a) we could discuss your idea. Regarding (b) i am not sure. It has to install NTLP path state but it does not install QoS NSLP.

    Sven and Ruediger cannot agree on the text written in the draft.

    Bob: Comment on the error code. This might be a huge process. I suggest you start to write the IANA consideration part now. There are a lot more detail than you think now.



    QoS-NSLP QSpec Template

    Attila: - 10 min http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qspec-01.txt

    Attila goes through his slides  which can be found at http://www.tschofenig.com/nsis/IETF60/QSPEC-Model.ppt


    Bob: Why are you using a sequence and impose an order.

    Attila: There is no order assumed.

    John: In the QSPEC document you need to fix the notation correct.


     John: Felt at interim meeting that it would be useful to have as a WG draft.

    Resource Management In Diffserv

    Attila: 10 min http://www.ietf.org/internet-drafts/draft-bader-nsis-rmd-diffserv-qsm-00.txt

    Attila starts his presentation. The slides can be found at http://www.tschofenig.com/nsis/IETF60/RMD_IETF60.ppt


    John: General support at interim. One question that was not address: do we want a general DiffServ model or is RMD enough.

    Attila describes the RMD model.


    Ruediger: I like the work. This document may become a working group document. Much too thin for a WG document now.

    John: My advise it to review the draft and the authors resubmit the draft. Then the

    Brian: This is new to me. A number of bells are ringing in my head. It talks about DiffServ and talks about per-flow signaling. I am going to read the document.


    Tom: You talked something about a generic or a specific QoS model

    John: I only wanted to know what the working group thinks.

    Bob: I will hope that the NSIS working group would simply. There are many models around. Simplifying the whole picture is a good approach.

    John: Simplifying into a uniform model might be difficult.


    Attila: If we specify


    Extended QoS Authorization for the QoS NSLP

    Hannes: - 10 min http://www.tschofenig.com/drafts/draft-tschofenig-nsis-qos-ext-authz-00.txt


    Hannes starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/Extended_QoS_Authorization_for_the_QoS_NSLP.ppt


    John: This is one of the major open issues. I would like to encourage the WG to comment it before next IETF meeting.


    NSLP for Accounting Configuration Signaling

    Hannes:  10 min http://www.ietf.org/internet-drafts/draft-dressler-nsis-accounting-nslp-00.txt


    Hannes starts his presentation which can be found at http://www.tschofenig.com/nsis/IETF60/NSLP_for_Accounting_Configuration_Signaling.ppt


    Tom: The question 'how to proceed with future NSLPs' is important.


    John: We need to get the current documents done first before we take on more work.



    Diameter Quality of Service Application

    Pete - 5 min http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-00.txt


    John: This document will progress an individual document. The work is relevant for the NSIS working group.


    Pete goes through his presentation which can be found at  http://www.tschofenig.com/nsis/IETF60/diameter-qos.ppt


    Helen Butcher: It seems to be you can solve this problem with resource management. You don't want to modify SIP.


    Pete: Resource management is independent of the AAA procedure. We do not modify SIP. Does this answer your question?


    Helen Butcher: I disagree.


    Pete: Please send comments to the list.


    Wrap Up

    For next meeting want basic design of NTLP and NSLP finalized. I would like to have people to read and comment newly proposed drafts. Then we also need to update the charter.


    GIMPS* - The NSIS Transport Layer
    Applicability Statement of NSIS Protocols in Mobile Environments
    NAT/Firewall NSLP Activities
    Path-coupled NAT/Firewall Signaling Security Problems
    Security Threats for the NATFW NSLP
    NATFW NSLP deployment/integration considerations
    NSLP for Quality of Service
    QoS-NSLP QSpec Template
    RMD - an NSIS QoS Signaling Model for Diffserv
    Extended QoS Authorization for the QoS NSLP
    NSLP for Accounting Configuration Signaling
    Diameter QoS Application