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