From daemon@optimus.ietf.org Fri Mar 1 03:48:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01415 for ; Fri, 1 Mar 2002 03:48:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09261 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 03:48:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09112; Fri, 1 Mar 2002 03:42:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09083 for ; Fri, 1 Mar 2002 03:42:05 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01316 for ; Fri, 1 Mar 2002 03:42:02 -0500 (EST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g218g3B12300 for ; Fri, 1 Mar 2002 09:42:03 +0100 (MET) Received: from era.ericsson.se (rcur181ip162.ericsson.se [147.214.181.162]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GSA00I0NDI25U@mbb1.ericsson.se> for nsis@ietf.org; Fri, 1 Mar 2002 09:42:02 +0100 (MET) Date: Fri, 01 Mar 2002 09:41:55 +0100 From: "Lars.Westberg" Subject: Re: [NSIS] Re: Modularity and grouping QoS requirements To: Cedric Westphal Cc: "Vlora Rexhepi (ELN)" , "'brunner@ccrle.nec.de'" , "Georgios Karagiannis (ELN)" , "'john.loughney@nokia.com'" , nsis@ietf.org Message-id: <3C7F3ED2.40C11CA2@era.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3C7EDD9A.1010609@iprg.nokia.com> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Comments Cedric Westphal wrote: > Vlora and all, > > one reason for using the model in draft-nsis rather than the one in > draft-partain is that it allows to define mobility requirements. > For instance, think of a handoff, where the previous access router (PAR) > transfers QoS context to the new access router (NAR). > There is no NAR-PAR interface in draft-partain; however, it is easy > to see that the NAR is a QC (making the CAC decision at least) for > the new path, and PAR a QI. > What are you refrering to ? Do you want that NSIS should specify how mobility should be solved or ...? We have a scenarion chapter incorporating scenarios for different apects. I sounds for that this is what you are refering to but you are very wellcome to define a new interface if that is needed from requirements perspective. What is the new requirements at the new interface that we have not included ? > > Another drawback of the 'interface' framework is that QoS signaling is > not necessary limited to interfaces. For instance, to update some > reservation > after a handoff, you'd need to signal to the crossover router(s), > wherever it > is. Most likely this crossover router does not correspond to any interface. > Note that draft-nsis either does not provide such framework, but it could > easily (should) be added with a QoS Termination point abstraction. I think > it is a dead end to assume the starting point and the end point of the > QoS signaling to > be some pre-defined interface. Draft-nsis goes a half step in the right > direction by allowing the starting point to be anywhere and abstracting > it into > the QI, which is a better starting point. RSVP assumes that all router are processing the same functionality model. We trying to differentiate the functionality on different type routers to get better processing performance. To have a model which assumes that all routers should process everything will probably get difficulties with scaling. I think that the two approaches are complementing each other and I would appreciate the discussion how we could combine the benefits of the two models. Our main target is improved processing in routers by structuring the requirements on different interfaces. The purpose is to get a modular solution with improved scaling propery in a new version of RSVP. > > > > Cheers, > > Cedric. > > Vlora Rexhepi (ELN) wrote: > > >Hi Marcus, > > > >|I am open to the consensus of the WG. Just some remarks inline. > >Great. > > > >|> One of the outcomes of the NSIS meeting in Salt Lake City was > >|> to start working on defining QoS requirements based on > >|scenario cases. > >|> > >|> Furthermore, we all agreed that modularity is very important; > >|> During that meeting many people agreed that after the QoS > >|requirements > >|> are defined, then they will be grouped according to network > >|> interfaces (e.g., UNI (access), NNI (backbone)); > >| > >|Here you have at least 4 types (UNI with home network, UNI > >|with foreign > >|network, NNI within same administrative domain, NNI across > >|admin domains. > > > >In draft-partain-nsis-requirements-00.txt there are three types > >of interfaces identified: > >- interior <-> interior interface > >- border node <-> border node interface > >- host <-> border node interface > >Please see the draft for detailed info. > > > > > >|> A reasonable way of doing the above, is in my opinion the following: > >|> * First define the scenario cases; > >|Agreed > >Great. > > > > > >|> * Second using these scenario cases, define which QoS > >|requirements will > >|> have to be satisfied on each network interface, and on > >|each network > >|> node type, e.g., host, access router, interior router, > >|border router, > >|> edge router, proxy, bandwidth broker, ... > >| > >|We can still do it my concern is that we have then with N scenarios (N > >|currently 5 to be more) and M interfaces (M as mentioned above > >|=4) and L > >|node types (L=7 in your proposal) > >| > >|This implies NxMxL entities we have to define requirements > >|for. And this I > >|am definitly not willing to do. > >Understandable. No one is suggesting to have more entities than > >the number of typical network nodes known in the Internet > >community. > >What, Georgios is suggesting is that the [NSIS] WG derives requirements > >from the scenarios and group them into particular interfaces between > >different nodes they apply to. This is already done in > >draft-partain-nsis-requirements-00.txt. > >Based on this, the QoS model entities would be defined later. > > > > > >|> Third the outcome of this > >|> separation of QoS requirements it will result in an > >|efficient grouping > >|> of the QoS requirements. > >| > >|We can discuss the grouping (I was just to lazy to change it so far) > >I already mentioned above one possible way to do it :-). > > > > > >|> After the QOS requirements grouping is done, then we could > >|define a QoS > >|> model. This QoS model could have entities such as a QoS > >|initiator and a > >|> QoS controller. > >| > >|Yes, that is what the framework document does. > >Exactly. The framework should be a result of scenarios and the > >requirements derived from them. As it is now in the [NSIS] WG > >draft the things are done in a different order. And as we could > >see it the "problem discussion model" has a problem when one wants > >to apply it in other scenarios rather than the ones described in > >the [NSIS] WG draft. > > > > > >|> The problem I have with the NSIS WG requirements draft is that these > >|> sequence of doing things is very much opposite to the > >|sequence mentioned > >|> above. In the NSIS WG requirements draft the following sequence of > >|> actions is followed: > >| > >|> First a QoS model and its QoS model entities are > >|> defined. At this stage, these QoS model entities, e.g., > >|QoS initiator > >|> and QoS controller, are not representing network entities. > >| > >|This is the second step in the draft and it is ment to reduce the node > >|types. > >Yes, but it does also impact the QoS requirements. > > > > > >|I understand that some people have problems to see the value > >|of it, others > >|very much appreciated the more abstract way of thinking. I > >|would say it is > >|50:50 so far. > >| > >|And some even think we should get more abstract > >| > >|> * Second, the QoS requirements are grouped according to > >|these QoS model > >|> entities and not grouped according to any network > >|interface or any > >|> network node type! > >| > >|No they are grouped into topics like security, flow definition, > >|architectural, etc. The grouping actually as nothing to do > >|with the model > >Right. But, I think the grouping should be done based on the > >agreement in the meeting at Salt Lake City. > > > >|>*Third, the QoS model entites are assigned to > >|> specific network node types. In my opinion this step is > >|difficult to > >|> be accomplished and for some scenarios is impossible to be done. > >| > >|You might be right, but we have done it so far. Currently I do > >|not see it > >|as too difficult, but I might be wrong. > >We already heard from Danny that in their scenarios it was not > >an "easy exercise"... > >So, could someone (other than the authors) please try to relate > >one of the Scenarios from draft-partain-nsis-requirements-00.txt > >with "Problem Discussion Model" from the [NSIS] WG draft such that > >we can close the discussion on the generality of the model? That > >would be appreciated very much. > > > >Regards, > >Vlora > > > > > > > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 1 04:51:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02701 for ; Fri, 1 Mar 2002 04:51:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11535 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 04:52:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11029; Fri, 1 Mar 2002 04:47:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10998 for ; Fri, 1 Mar 2002 04:47:22 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02395 for ; Fri, 1 Mar 2002 04:47:19 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1S9WNW72>; Fri, 1 Mar 2002 09:45:45 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41830ED11@rsys002a.roke.co.uk> From: "Hepworth, Eleanor" To: "'sven.van_den_bosch@alcatel.be'" , "'danny.goderis@alcatel.be'" Cc: "'nsis@ietf.org'" Date: Fri, 1 Mar 2002 09:45:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] Comments on draft-buchli-nsis-req-00 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Danny, Sven Couple of comments on draft-buchli-nsis-req-00.txt. I'm glad you seem to have found the QI/QC concepts useful;) Firstly, some more general comments. I think the discussions in this draft are valuable, and raise some interesting questions related to the scope of the NSIS WG. It is important to clarify the scope of NSIS as regards what functionality is part of the NSIS problem space. In your draft, you have identified a number of protocol interactions that it may be worth generalising a bit to cover a few other situations where I think the issues you raise in the draft are still true. Host<->QI. As I understand it, this protocol interface triggers the generation of an NSIS signalling message at the QI. I think this is analogous to having the QI present on the host and receiving triggers from the application. Certainly the same issues apply: what information is provided to the QI, and how is this used to generate the NSIS message. I agree that we need to study the information passed across this interface but think, as you do, that otherwise it is out of scope of NSIS. QC<->NMS and QI<->AG I would regard both the protocol interfaces as part of the interaction with the local QoS provisioning mechanism. The first, because how the pipes are actually setup, or indeed if they are used is part of the provisioning mechanism used within the domain, and the second because policing methods etc. tend to be dependent on the QoS provisioning method anyway. Issues concerning this interaction with the QoS provisioning function include: who maintains the resource usage information and carries out admission control (i.e. does the QC manage all this information, or does it interrogate the QoS provisioning mechanism for this information), how is monitoring information passed to the QC etc. (A lot of these issues are discussed in section 4.2 of draft-hancock-nsis-framework-00, we'd be interested to know if you agree with our assumptions about scope). You also identify some stages required in resource allocation, reservation setup, which I think have similarities to those identified in draft-hancock-.., e.g. the exchange of SLS information and the creation of the traffic pipes could take place as part of the 'Peer Agent Discovery' process. Do you think this division of the signalling into stages is a requirement on the protocol structure, or just useful for discussing it? Secondly, a couple of more specific comments regarding some of your requirements. 6.1 Signalling requirements 2) The time to set up a QoS connection should be constrained to one or a few round trip times. Would this requirement be better as a part of a set of evaluation criteria for analysing protocol options? While it is a desirable feature of the NSIS solution, can we really require a hard limit as part of the protocol. 3) Support of priority What do you envisage the scope of this information being? How do we determine the priority for a flow, is it per-user or something to do with inter-domain relationships? If it is per-user, is it relevant end-to-end or only locally? Are there any interactions with AAA functions to do with authorisation information? 6) The protocol should be independent of the core transport technology as opposed to the access part where the transport and QoS are technology specific. I agree with this first part (that the protocol should be independent of the transport technology), but I'm not sure the second bit should be part of the requirement. We're not using NSIS signalling between the host and the QI so the second part of the requirement is not on the NSIS protocol. This goes back to the discussion mentioned above as to whether you consider the QI to be in the host or not. 8) Multicast consideration should not impact the protocol complexity for unicast flows. I don't think NSIS has yet reached a consensus on support for multicast, so I would be interested to know how important you think this requirement is. We considered it a design goal to 'do unicast first and think about multicast later'. 9) Effective support of unidirectional reservations You've included comments on support for bidirectional reservations. I agree with your concerns, and I think this requirement might need to be phrased in a more restrictive way. In our framework draft, the options for supporting bidirectional reservations are discussed and it seems in general that we need to decompose this requirement further, i.e. are we discussing bidirectional signalling or bidirectional data paths (if we can make this distinction), and especially are we discussing end-to-end bidirectional reservations, or allowing them on a more per Qx/Qx link basis as a local optimisation? 10) Mobility aspects should have no impact on the NSIS protocol. This might be quite hard to achieve, and there are also situations where the signalling could be optimised for mobility, see draft-chaskar-mobileip-qos-01 for example. 11) Optimization for interactive multimedia services. What does optimised mean in practice? It is clearly important to consider this when thinking about requirements, but do we want to consider only one type of service? The draft also contains some valuable analyses on the service levels and information/parameters and some associated requirements (especially section 6.2). How much detail do you think we need to go into concerning QoS parameters for the requirements stage? Yours, Ele Hepworth --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 1 04:53:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02766 for ; Fri, 1 Mar 2002 04:53:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11632 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 04:53:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11337; Fri, 1 Mar 2002 04:49:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11283 for ; Fri, 1 Mar 2002 04:49:09 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02498 for ; Fri, 1 Mar 2002 04:49:06 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1S9WNW7J>; Fri, 1 Mar 2002 09:45:45 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA18E@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , brian.williams@ericsson.com.au Cc: jmanner@cs.Helsinki.FI, Gabor.Fodor@era-t.ericsson.se, nsis@ietf.org Subject: RE: another requirements question (was: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt) Date: Fri, 1 Mar 2002 09:45:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" John, I think we need to distinguish a requirement on what information the signalling is capable of conveying, from a requirement on how lower layer entities might be affected by that signalling. If the lower layer isn't visible to the IP layer, it doesn't matter what L2-related requirements we write (and this applies to many of the other requirements in draft-fodor-... as well). Your additional text basically clarifies this, but I see it in fact as more of a statement about the scope/boundary of the NSIS problem as a whole. So, maybe we should have something like it in the earlier sections of the requirements i-d; later requirements would be about specific capabilities that it might be useful for NSIS signalling to have to support certain link types, but the 'hints' term in 'wireless hints' conveys exactly the right impression. Robert H. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 28 February 2002 22:09 > To: Hancock, Robert; brian.williams@ericsson.com.au > Cc: jmanner@cs.Helsinki.FI; Gabor.Fodor@era-t.ericsson.se; > nsis@ietf.org > Subject: RE: another requirements question (was: RE: [NSIS] A few > comments to draft-fodor-reqts-cellular-netwks-00 .txt) > > > Hi Robert, > > > Does the NSIS signalling need to be able to convey/negotiate > > information about which end of a link is going to be > > responsible for initiating lower layer bearer setup? > > One problem with the above requirement might be that the > entity that does that layer 2 bearer setup might not be > visible to the IP layer. > > However, we could put some fuzzyness into the requirement, > such as: > > NSIS signaling MAY interact with layer 2 entities for > setting layer 2 resources. > > Or something like that. > > John > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 1 05:29:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05333 for ; Fri, 1 Mar 2002 05:29:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27495 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 05:29:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26238; Fri, 1 Mar 2002 05:25:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26200 for ; Fri, 1 Mar 2002 05:25:01 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05091 for ; Fri, 1 Mar 2002 05:24:58 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g21AOxB04916 for ; Fri, 1 Mar 2002 11:24:59 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 01 11:20:33 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 11:20:26 +0100 Message-ID: From: "Vlora Rexhepi (ELN)" To: "'Cedric Westphal'" Cc: "'brunner@ccrle.nec.de'" , "Georgios Karagiannis (ELN)" , "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Re: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 11:20:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cedric, |one reason for using the model in draft-nsis rather than the one in |draft-partain is that it allows to define mobility requirements. I do not agree. In the draft-partain QoS requirements are derived from particular scenarios, one of them being the Mobile IP scenario and the mobility requirements are part of the draft. In the Mobile IP scenario this is already shown, when a handoff occurs the new reservation is needed from the NAR to the "Joint point of reservation" router that is located into the QoS aware segment that maintains an end to end reservation but due to handover it may change/modify this reservation. [NSIS] WG draft on the other hand on the mobility requirements refers draft-ietf-mobileip-qos-requirements-01.txt. If you compare the draft-partain and draft-ietf-mobileip-qos-requirements-02.txt. you'll see that that these mobility requirements are in both drafts. |For instance, think of a handoff, where the previous access |router (PAR) |transfers QoS context to the new access router (NAR). |There is no NAR-PAR interface in draft-partain; however, it is easy |to see that the NAR is a QC (making the CAC decision at least) for |the new path, and PAR a QI. Note that in draft-partain the Access Routers are denoted as Border Node, so one of the QoS context transfer requirements that will apply to an interface similar to your the NAR-PAR is given in Section 5.2.2, draft-partain. However, this is not explained in detail how it would be done. Probably there may be more issues related to the interworking with QoS context transfer protocols defined in SEAMOBY. Do you already see any other requirements on such interface? |Another drawback of the 'interface' framework is that QoS signaling is |not necessary limited to interfaces. For instance, to update some |reservation |after a handoff, you'd need to signal to the crossover router(s), |wherever it |is. Most likely this crossover router does not correspond to |any interface. |Note that draft-nsis either does not provide such framework, |but it could |easily (should) be added with a QoS Termination point |abstraction. I think |it is a dead end to assume the starting point and the end point of the |QoS signaling to |be some pre-defined interface. Draft-nsis goes a half step in the right |direction by allowing the starting point to be anywhere and |abstracting |it into |the QI, which is a better starting point. The purpose of grouping the requirements according to different interfaces where they apply to is not to limit the starting and ending point of the protocol. The purpose is to see which requirements apply to different parts of the network in the end-to-end path. We all agree that what is needed in the access is not the same as what is needed in the core, which means that we need to identify these requirements for a protocol that we would like to use end-to-end. The only way to achieve this is by supporting modularity in the protocol. Further draft-partain does not restrict the starting point of the protocol either. The major problem in the [NSIS] WG draft is that the requirements are deined for the abstract entities QI/QC and if there is no idea on where in the network this requirements apply it is going to be difficult to design an NSIS protocol fulfilling these requirements. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 1 05:58:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07725 for ; Fri, 1 Mar 2002 05:58:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13058 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 05:58:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11351; Fri, 1 Mar 2002 05:53:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11315 for ; Fri, 1 Mar 2002 05:53:46 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07425 for ; Fri, 1 Mar 2002 05:53:43 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g21ArjZc008278 for ; Fri, 1 Mar 2002 11:53:45 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 01 11:53:45 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 11:52:49 +0100 Message-ID: From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" , robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 11:53:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, |> |1. that we should annotate requirements according to which |> |network environments they are particularly applicable to or |> |crucial for (e.g. 'scalability is important in the core' and so on) |> |> I would rather say that the QoS requirements would be derived |> from different scenarios/use cases and than grouped according to |> the interfaces they apply to. | |I agree. For example, on a small lightweight device, scalability |is very important as well. True. |> |I'm entirely in sympathy with (1) - indeed, that's what I |> |thought section 6 of the WG draft was trying to do. (More |> |scenarios and the format might start to be tricky, but that's |> |another question...) |> |> Section 6 of the WG draft gives a good overview on the importance |> of the requirements to the Scenarios 1 - 5, but I would prefer |> to see which requirements apply to particular interfaces |> in the Scenarios 1-5. | |My feeling is that requirements should be left as requirements, |and we will specify the interfaces in the framework document. |If we need to provide some textual wrapping to help frame the |requirement, then we should. | Are you suggesting to keep the definition of QI/QC in the requirements as well? If so, than the requirements should be defined such that the modularity concept is introduced in the definition of QI and QC. For example if the QI is in the host different requirements apply from the case when QI is elsewhere. The same would be in case when QC is a centralized point or resides in border or interior node. In all these cases there will be specific requirements that would apply. |For example, what does scalablity mean? It could mean several |things: | | 1) Create minimal state in nodes. | 2) Ability to aggrate traffic. | 3) ... others ... | |If we define all of the requirements in terms of existing solutions or |scenarios, I think we will have done the wrong job. Agree. The requirements should be derived from the scenarios, but not defined specifically for them. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 1 08:11:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20913 for ; Fri, 1 Mar 2002 08:11:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25564 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 08:11:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25400; Fri, 1 Mar 2002 08:07:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25369 for ; Fri, 1 Mar 2002 08:07:50 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20089 for ; Fri, 1 Mar 2002 08:07:47 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g21D7oZc029003 for ; Fri, 1 Mar 2002 14:07:50 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 01 14:06:16 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 14:05:13 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 13:59:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear all I think there is a disagreement on how the requirements are separated/grouped. I will try to propose another solution. Maybe we can separate the QoS requirements in QoS complexity levels: For example: * QoS complexity level (1): minimum QoS functionality, that is the simplest QoS functionality possible, e.g., requirements for scalability, simplicity, speed; * QoS complexity level (2): a higher level of QoS functionality complexity than complexity level (1), e.g., requirements for QoS domain admission control; * QoS complexity level (3): a higher level of QoS functionality complexity than complexity level (2), e.g., requirements for security and accounting (related to QoS); . . * QoS complexity level (N): a higher level of QoS functionality complexity than complexity level (N-1) (e.g., centralised QoS functionality); In this way we define some kind of QoS toolbox, that can be used in a flexible way by e.g., a network provider. For example a network provider could choose to implement the QoS complexity level (2) in a border router. Some other network provider may choose to implement the QoS complexity level (3) into a border router; The same holds for other network entities; Can we reach a consensus on this? Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: donderdag 28 februari 2002 22:31 To: Vlora.Rexhepi@eln.ericsson.se; robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Hi All, > |1. that we should annotate requirements according to which > |network environments they are particularly applicable to or > |crucial for (e.g. 'scalability is important in the core' and so on) > > I would rather say that the QoS requirements would be derived > from different scenarios/use cases and than grouped according to > the interfaces they apply to. I agree. For example, on a small lightweight device, scalability is very important as well. > |I'm entirely in sympathy with (1) - indeed, that's what I > |thought section 6 of the WG draft was trying to do. (More > |scenarios and the format might start to be tricky, but that's > |another question...) > > Section 6 of the WG draft gives a good overview on the importance > of the requirements to the Scenarios 1 - 5, but I would prefer > to see which requirements apply to particular interfaces > in the Scenarios 1-5. My feeling is that requirements should be left as requirements, and we will specify the interfaces in the framework document. If we need to provide some textual wrapping to help frame the requirement, then we should. For example, what does scalablity mean? It could mean several things: 1) Create minimal state in nodes. 2) Ability to aggrate traffic. 3) ... others ... If we define all of the requirements in terms of existing solutions or scenarios, I think we will have done the wrong job. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 10:05:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28799 for ; Fri, 1 Mar 2002 10:05:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01430 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 10:05:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00689; Fri, 1 Mar 2002 09:59:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00610 for ; Fri, 1 Mar 2002 09:59:43 -0500 (EST) Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28475 for ; Fri, 1 Mar 2002 09:59:42 -0500 (EST) Received: from ee.ryerson.ca ([24.112.177.95]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020301145914.TYGW159916.fep04-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 1 Mar 2002 09:59:14 -0500 Message-ID: <3C7F973E.5020303@ee.ryerson.ca> Date: Fri, 01 Mar 2002 09:59:10 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.112.177.95] using ID at Fri, 1 Mar 2002 09:59:14 -0500 Content-Transfer-Encoding: 7bit Subject: [NSIS] CFP: IFIP/IEEE International Conference on Management of Multimedia Networks and Services Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit IFIP/IEEE International Conference on Management of Multimedia Networks and Services MMNS 2002 Managing IP Multimedia End-To-End October 6-9, 2002 Santa Barbara, CA USA http://www.cs.ucsb.edu/conferences/MMNS02 CALL FOR PAPERS With the popularity of the IP-based Internet, there has been a major shift towards building a worldwide, all-service and all-media network based on the next-generation of IP technology. Rich multimedia is increasingly being incorporated into Internet applications (like Voice-over-IP, streaming video, etc.). However, more work is needed to evolve the Internet and the underlying networking technologies into an infrastructure capable of supporting all- service and all-media traffic. Significant management functionality is required to ensure that these applications have a network that is both capable and available. Management requirements may ensue from the fact that multimedia traffic may traverse networks using a wide variety of technology and each network may be owned, operated, and controlled by a different organization. In order to provide end-to-end, high quality multimedia services, the network must provide robust management functionality. The IFIP/IEEE International Conference on Management of Multimedia Networks and Services will hold its fifth annual meeting Oct. 6 through Oct. 9, 2002 in Santa Barbara, CA. The IFIP/IEEE MMNS is a single-track conference and provides an intimate setting for discussion and debate. The program committee is soliciting original papers describing research in the area of management of multimedia networks and services. Topics of interest include, but are not limited to, the following: o End-to-end IP multimedia network and service management o VoIP service management o IP Video, streaming, interactive video service management o Provisioning of multimedia networks and services o Wireless and mobile multimedia network management o Optical multimedia network management o Cable multimedia network management o Multimedia network traffic engineering and optimization o Distributed multimedia service management o Network management models and architectures o Billing and security for multi-media services o Content distribution internetworking o Resource, performance and fault management o Multi-point, multicast services management o Network programmability for multimedia services o Policy-based management for multimedia services o QoS management o Multimedia traffic management o Multimedia content protection o Deployment of multimedia services o Active multimedia network management o Multimedia session management o Middleware support for management PAPER SUBMISSION Papers must be submitted electronically in postscript or PDF format. Detailed instructions are provided on the conference web site, http://www.cs.ucsb.edu/conferences/MMNS02. Paper length is limited to 20 double-spaced pages. The paper's cover page must include: title of paper, authors' names and affiliations, contact author's name and address (both postal and electronic), a short abstract, keywords, and submission area (from the list of relevant topics of interest). For any further information, please refer to the conference home page or direct your questions to almeroth@cs.ucsb.edu. IMPORTANT DATES Submission deadline: April 7, 2002 Notification of acceptance: June 30, 2002 Final version: July 28, 2002 Conference: October 6-9, 2002 -- ================================================== Muhammad Jaseemuddin Associate Professor Departement of Electrical and Computer Engineering Ryerson University 350 Victoria Street Toronto, ON M5B 2K3 Tel: +1 416 979-5000x6073 Fax: +1 416 979-5280 Email: jaseem@ee.ryerson.ca Web: http://www.ee.ryerson.ca/~jaseem ================================================== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 10:07:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28930 for ; Fri, 1 Mar 2002 10:07:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01556 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 10:07:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01340; Fri, 1 Mar 2002 10:03:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01309 for ; Fri, 1 Mar 2002 10:03:15 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28660 for ; Fri, 1 Mar 2002 10:03:14 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g21F2h404828; Fri, 1 Mar 2002 16:02:43 +0100 (MET) To: "Hepworth, Eleanor" Cc: danny.goderis@alcatel.be, "'nsis@ietf.org'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 1 Mar 2002 16:02:41 +0100 Subject: Re: [NSIS] Comments on draft-buchli-nsis-req-00 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/01/2002 16:02:42 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256B6F00528DCF8f9e8a93df938690918cC1256B6F00528DCF" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --0__=C1256B6F00528DCF8f9e8a93df938690918cC1256B6F00528DCF Content-type: text/plain; charset=us-ascii Hi Eleanor, Thanks for your feedback on our draft. We are going through the same process regarding draft-hancock-... and expect to comment next week. In the mean time, please see additional comments/clarifications inline (Sven>>) Yours, Sven. "Hepworth, Eleanor" on 01/03/2002 10:45:44 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Danny GODERIS/BE/ALCATEL@ALCATEL cc: "'nsis@ietf.org'" Subject Comments on draft-buchli-nsis-req-00 : Hi Danny, Sven Couple of comments on draft-buchli-nsis-req-00.txt. I'm glad you seem to have found the QI/QC concepts useful;) Firstly, some more general comments. I think the discussions in this draft are valuable, and raise some interesting questions related to the scope of the NSIS WG. It is important to clarify the scope of NSIS as regards what functionality is part of the NSIS problem space. In your draft, you have identified a number of protocol interactions that it may be worth generalising a bit to cover a few other situations where I think the issues you raise in the draft are still true. Host<->QI. As I understand it, this protocol interface triggers the generation of an NSIS signalling message at the QI. I think this is analogous to having the QI present on the host and receiving triggers from the application. Certainly the same issues apply: what information is provided to the QI, and how is this used to generate the NSIS message. I agree that we need to study the information passed across this interface but think, as you do, that otherwise it is out of scope of NSIS. Sven>> We agree with your view that host-QI may not be the primary scope of NSIS. However, the placement of the QI-QC on the physical infrastructure may have an impact on the grouping of requirements. We were thinking about grouping requirements as QI-QC, host-QI (if in scope, ...). This only makes sense if the placement of the QI-QC is such that we can assume that the requirements are similar in all cases. When the QI can be at the host or in the access, this may not be the case. The main problem seems to be that the placement of the QC is very loose. An idea could be to have QI proxies that relay the QI info to the QC. Then, the placement of the QC could be more aligned with the physical infrastructure and the requirements on the (proxy)QI-QC interface could be relaxed (like no need to support mobility). QC<->NMS and QI<->AG I would regard both the protocol interfaces as part of the interaction with the local QoS provisioning mechanism. The first, because how the pipes are actually setup, or indeed if they are used is part of the provisioning mechanism used within the domain, and the second because policing methods etc. tend to be dependent on the QoS provisioning method anyway. Issues concerning this interaction with the QoS provisioning function include: who maintains the resource usage information and carries out admission control (i.e. does the QC manage all this information, or does it interrogate the QoS provisioning mechanism for this information), how is monitoring information passed to the QC etc. (A lot of these issues are discussed in section 4.2 of draft-hancock-nsis-framework-00, we'd be interested to know if you agree with our assumptions about scope). Sven>> We agree with several statements made in the section you refer to. For instance, we believe that 'a generic interface is required to exchange parameters for various purposes between NSIS agents and QoS provisioning systems'. We think a resource allocation protocol might indeed be useful for dynamic negotiation over the QC-provisioning interface. However, since the QoS provisioning method is a local matter, we thought this protocol, if it is used, would also be local. You also identify some stages required in resource allocation, reservation setup, which I think have similarities to those identified in draft-hancock-.., e.g. the exchange of SLS information and the creation of the traffic pipes could take place as part of the 'Peer Agent Discovery' process. Do you think this division of the signalling into stages is a requirement on the protocol structure, or just useful for discussing it? Sven>> I agree with you that SLS information for the provisioning interface could be exchanged during neighbour discovery. I think that the discovery and the signalling process are separate issues though. We think it is feasible to have preprovisioned resources controlled by each QC that can handle signalling without having to interact with provisioning. Secondly, a couple of more specific comments regarding some of your requirements. 6.1 Signalling requirements 2) The time to set up a QoS connection should be constrained to one or a few round trip times. Would this requirement be better as a part of a set of evaluation criteria for analysing protocol options? While it is a desirable feature of the NSIS solution, can we really require a hard limit as part of the protocol. Sven>> Agree. It should be part of the criteria to evaluate different otherwise requirements-compliant options. 3) Support of priority What do you envisage the scope of this information being? How do we determine the priority for a flow, is it per-user or something to do with inter-domain relationships? If it is per-user, is it relevant end-to-end or only locally? Are there any interactions with AAA functions to do with authorisation information? Sven>> The application we had in mind were emergency calls. They have the same QoS requirements but clearly have a much higher priority than ordinary calls. This suggests that priority and QoS are orthogonal issues (which I believe was also the conclusion that was reached in the context of DiffServ-TE). It would also seem to suggest that priority has end-to-end meaning, because you wouldn't want the next network to block the call. Whether this should be done per-class or per-flow might be open for discussion. 6) The protocol should be independent of the core transport technology as opposed to the access part where the transport and QoS are technology specific. I agree with this first part (that the protocol should be independent of the transport technology), but I'm not sure the second bit should be part of the requirement. We're not using NSIS signalling between the host and the QI so the second part of the requirement is not on the NSIS protocol. This goes back to the discussion mentioned above as to whether you consider the QI to be in the host or not. Sven>> This again relates to the access-core discussion. It all depends where you want to be able to put the QCs and QIs. 8) Multicast consideration should not impact the protocol complexity for unicast flows. I don't think NSIS has yet reached a consensus on support for multicast, so I would be interested to know how important you think this requirement is. We considered it a design goal to 'do unicast first and think about multicast later'. Sven>> We fully agree. I think our statement ('should not impact', 'adversely impact' maybe?) matches yours ('do unicast first'). 9) Effective support of unidirectional reservations You've included comments on support for bidirectional reservations. I agree with your concerns, and I think this requirement might need to be phrased in a more restrictive way. In our framework draft, the options for supporting bidirectional reservations are discussed and it seems in general that we need to decompose this requirement further, i.e. are we discussing bidirectional signalling or bidirectional data paths (if we can make this distinction), and especially are we discussing end-to-end bidirectional reservations, or allowing them on a more per Qx/Qx link basis as a local optimisation? Sven>> Unless I am wrong, this is the way it is done in UMTS. This could obviously be allowed. The only problem I see is that if you proxy the bidirectional reservation to the QC, than this one needs to recognise both uni- and bi-directional reservations. If we do not make it an explicit requirement we might be able to keep this complexity out. Another way to support bidirectional support could be through higher layers (application layer). 10) Mobility aspects should have no impact on the NSIS protocol. This might be quite hard to achieve, and there are also situations where the signalling could be optimised for mobility, see draft-chaskar-mobileip-qos-01 for example. Sven>> Again relation to the QI-QC placement. This should probably be the first thing to clarify a bit further. 11) Optimization for interactive multimedia services. What does optimised mean in practice? It is clearly important to consider this when thinking about requirements, but do we want to consider only one type of service? Sven>> This more or less relates to the comment made for 9). Interactive multimedia services might use the application layer (e.g. for support of bidirectionality). This could be taken into account by the NSIS protocol. The draft also contains some valuable analyses on the service levels and information/parameters and some associated requirements (especially section 6.2). How much detail do you think we need to go into concerning QoS parameters for the requirements stage? Sven>> We think it might not be unimportant. Although the parameter content might not be a direct requirement of the signalling protocol, the amount and update frequency of it might very well impact/limit the available options. We think the protocol should be very simple. That's why we think it is important to identify the minimum content that the protocol should carry. This will set an upper bound on the signaling complexity. Later on, we can see what additional 'nice to have' stuff can be added. Yours, Ele Hepworth (See attached file: RMRL-Disclaimer.txt) --0__=C1256B6F00528DCF8f9e8a93df938690918cC1256B6F00528DCF Content-type: application/octet-stream; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: base64 VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCB0byBSb2tlIA0KTWFub3IgUmVzZWFyY2ggTHRkIGFuZCBtdXN0 IG5vdCBiZSBwYXNzZWQgdG8gYW55IHRoaXJkIHBhcnR5IHdpdGhvdXQgcGVybWlzc2lvbi4gVGhp cyANCmNvbW11bmljYXRpb24gaXMgZm9yIGluZm9ybWF0aW9uIG9ubHkgYW5kIHNoYWxsIG5vdCBj cmVhdGUgb3IgY2hhbmdlIGFueSBjb250cmFjdHVhbCANCnJlbGF0aW9uc2hpcC4NCg0K --0__=C1256B6F00528DCF8f9e8a93df938690918cC1256B6F00528DCF-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 10:38:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00529 for ; Fri, 1 Mar 2002 10:38:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03684 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 10:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03308; Fri, 1 Mar 2002 10:33:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03279 for ; Fri, 1 Mar 2002 10:33:12 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00236 for ; Fri, 1 Mar 2002 10:33:10 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1S9WNXVC>; Fri, 1 Mar 2002 15:31:58 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA193@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 15:31:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Georgios, I think this could be a useful 'explanatory' grouping method which complements the scenario allocation stuff in the current section 6. I think we're all clear that we will need to be able to tune 'the' NSIS protocol to the point in the network where it is used, and this grouping should give us an idea of what typical option groups might be (e.g. what is the simplest possible protocol we can think of). I wouldn't expect the 'capability sets' to be strictly ordered in complexity, but let's see what happens. I would also see these things applying to protocols rather than nodes (so, in your example, a border router might use one protocol for external communication and another one with different scaling and security properties for internal signalling); we need an NSIS framework to enable us to ensure that these individual protocols do actually fit together. Yours, Robert H. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 01 March 2002 12:59 > To: nsis@ietf.org > Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements > > > Dear all > > I think there is a disagreement on how the requirements > are separated/grouped. > > I will try to propose another solution. > Maybe we can separate the QoS requirements > in QoS complexity levels: > > For example: > * QoS complexity level (1): minimum QoS functionality, that > is the simplest > QoS functionality possible, e.g., > requirements for > scalability, simplicity, speed; > > * QoS complexity level (2): a higher level of QoS > functionality complexity > than complexity level (1), e.g., > requirements for QoS > domain admission control; > * QoS complexity level (3): a higher level of QoS > functionality complexity > than complexity level (2), e.g., > requirements for security and > accounting (related to QoS); > . > . > * QoS complexity level (N): a higher level of QoS > functionality complexity > than complexity > level (N-1) (e.g., centralised QoS functionality); > > > In this way we define some kind of QoS toolbox, that can be > used in a flexible > way by e.g., a network provider. > For example a network provider could choose to implement > the QoS complexity level (2) in a border router. Some other > network provider may choose to implement the QoS complexity > level (3) into a border router; > The same holds for other network entities; > > Can we reach a consensus on this? > > Best regards, > Georgios > > > > > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 28 februari 2002 22:31 > To: Vlora.Rexhepi@eln.ericsson.se; robert.hancock@roke.co.uk; > nsis@ietf.org > Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements > > > Hi All, > > > |1. that we should annotate requirements according to which > > |network environments they are particularly applicable to or > > |crucial for (e.g. 'scalability is important in the core' and so on) > > > > I would rather say that the QoS requirements would be derived > > from different scenarios/use cases and than grouped according to > > the interfaces they apply to. > > I agree. For example, on a small lightweight device, scalability > is very important as well. > > > |I'm entirely in sympathy with (1) - indeed, that's what I > > |thought section 6 of the WG draft was trying to do. (More > > |scenarios and the format might start to be tricky, but that's > > |another question...) > > > > Section 6 of the WG draft gives a good overview on the importance > > of the requirements to the Scenarios 1 - 5, but I would prefer > > to see which requirements apply to particular interfaces > > in the Scenarios 1-5. > > My feeling is that requirements should be left as requirements, > and we will specify the interfaces in the framework document. > If we need to provide some textual wrapping to help frame the > requirement, then we should. > > For example, what does scalablity mean? It could mean several > things: > > 1) Create minimal state in nodes. > 2) Ability to aggrate traffic. > 3) ... others ... > > If we define all of the requirements in terms of existing solutions or > scenarios, I think we will have done the wrong job. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 11:24:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03589 for ; Fri, 1 Mar 2002 11:24:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08511 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 11:24:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07990; Fri, 1 Mar 2002 11:19:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07945 for ; Fri, 1 Mar 2002 11:19:32 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03269 for ; Fri, 1 Mar 2002 11:19:30 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g21GJVZc008660 for ; Fri, 1 Mar 2002 17:19:31 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 01 17:19:30 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 17:19:30 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 17:12:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert Thank you for your reply! Should I and the authors of the "draft-nsis-partain.." think about some text for Section 6? In the mean while we will also list the requirements that are given in the "draft-nsis-partain" and are not listed in the NSIS WG draft. Regarding the NSIS framework we will be happy to co-operate! Best regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: vrijdag 1 maart 2002 16:32 To: 'Georgios Karagiannis (ELN)'; nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Georgios, I think this could be a useful 'explanatory' grouping method which complements the scenario allocation stuff in the current section 6. I think we're all clear that we will need to be able to tune 'the' NSIS protocol to the point in the network where it is used, and this grouping should give us an idea of what typical option groups might be (e.g. what is the simplest possible protocol we can think of). I wouldn't expect the 'capability sets' to be strictly ordered in complexity, but let's see what happens. I would also see these things applying to protocols rather than nodes (so, in your example, a border router might use one protocol for external communication and another one with different scaling and security properties for internal signalling); we need an NSIS framework to enable us to ensure that these individual protocols do actually fit together. Yours, Robert H. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 01 March 2002 12:59 > To: nsis@ietf.org > Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements > > > Dear all > > I think there is a disagreement on how the requirements > are separated/grouped. > > I will try to propose another solution. > Maybe we can separate the QoS requirements > in QoS complexity levels: > > For example: > * QoS complexity level (1): minimum QoS functionality, that > is the simplest > QoS functionality possible, e.g., > requirements for > scalability, simplicity, speed; > > * QoS complexity level (2): a higher level of QoS > functionality complexity > than complexity level (1), e.g., > requirements for QoS > domain admission control; > * QoS complexity level (3): a higher level of QoS > functionality complexity > than complexity level (2), e.g., > requirements for security and > accounting (related to QoS); > . > . > * QoS complexity level (N): a higher level of QoS > functionality complexity > than complexity > level (N-1) (e.g., centralised QoS functionality); > > > In this way we define some kind of QoS toolbox, that can be > used in a flexible > way by e.g., a network provider. > For example a network provider could choose to implement > the QoS complexity level (2) in a border router. Some other > network provider may choose to implement the QoS complexity > level (3) into a border router; > The same holds for other network entities; > > Can we reach a consensus on this? > > Best regards, > Georgios > > > > > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 28 februari 2002 22:31 > To: Vlora.Rexhepi@eln.ericsson.se; robert.hancock@roke.co.uk; > nsis@ietf.org > Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements > > > Hi All, > > > |1. that we should annotate requirements according to which > > |network environments they are particularly applicable to or > > |crucial for (e.g. 'scalability is important in the core' and so on) > > > > I would rather say that the QoS requirements would be derived > > from different scenarios/use cases and than grouped according to > > the interfaces they apply to. > > I agree. For example, on a small lightweight device, scalability > is very important as well. > > > |I'm entirely in sympathy with (1) - indeed, that's what I > > |thought section 6 of the WG draft was trying to do. (More > > |scenarios and the format might start to be tricky, but that's > > |another question...) > > > > Section 6 of the WG draft gives a good overview on the importance > > of the requirements to the Scenarios 1 - 5, but I would prefer > > to see which requirements apply to particular interfaces > > in the Scenarios 1-5. > > My feeling is that requirements should be left as requirements, > and we will specify the interfaces in the framework document. > If we need to provide some textual wrapping to help frame the > requirement, then we should. > > For example, what does scalablity mean? It could mean several > things: > > 1) Create minimal state in nodes. > 2) Ability to aggrate traffic. > 3) ... others ... > > If we define all of the requirements in terms of existing solutions or > scenarios, I think we will have done the wrong job. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 13:34:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13018 for ; Fri, 1 Mar 2002 13:34:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19193 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 13:34:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18430; Fri, 1 Mar 2002 13:29:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18397 for ; Fri, 1 Mar 2002 13:29:51 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12575 for ; Fri, 1 Mar 2002 13:29:47 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA11330; Fri, 1 Mar 2002 10:29:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g21ITJ525570; Fri, 1 Mar 2002 10:29:19 -0800 X-mProtect:  Fri, 1 Mar 2002 10:29:19 -0800 Nokia Silicon Valley Messaging Protection Received: from mvdhcp141150.americas.nokia.com (172.18.141.150, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk9F0BN; Fri, 01 Mar 2002 10:29:17 PST Message-ID: <3C7FC879.3080702@iprg.nokia.com> Date: Fri, 01 Mar 2002 10:29:13 -0800 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Vlora Rexhepi (ELN)" CC: nsis@ietf.org Subject: Re: [NSIS] Re: Modularity and grouping QoS requirements References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Vlora, Vlora Rexhepi (ELN) wrote: >Hi Cedric, > > >|one reason for using the model in draft-nsis rather than the one in >|draft-partain is that it allows to define mobility requirements. > >I do not agree. In the draft-partain QoS requirements are derived from >particular scenarios, one of them being the Mobile IP scenario and the >mobility requirements are part of the draft. >In the Mobile IP scenario this is already shown, when a handoff >occurs the new reservation is needed from the NAR to the "Joint point >of reservation" router that is located into the QoS aware segment that >maintains an end to end reservation but due to handover it >may change/modify this reservation. > there is no such interface however. Maybe your document should be made clearer as to how the 'interface approach' solves this. > > >[NSIS] WG draft on the other hand on the mobility requirements refers >draft-ietf-mobileip-qos-requirements-01.txt. >If you compare the draft-partain and draft-ietf-mobileip-qos-requirements-02.txt. >you'll see that that these mobility requirements are in both drafts. > I do think the framework of the [NSIS] requirements should allow the phrasing of draft-ietf-mobileip-qos-requirements-02.txt's requirement with [NSIS] terminology. > > >|For instance, think of a handoff, where the previous access >|router (PAR) >|transfers QoS context to the new access router (NAR). >|There is no NAR-PAR interface in draft-partain; however, it is easy >|to see that the NAR is a QC (making the CAC decision at least) for >|the new path, and PAR a QI. >Note that in draft-partain the Access Routers are denoted as Border Node, >so one of the QoS context transfer requirements that will apply to an >interface similar to your the NAR-PAR is given in >Section 5.2.2, draft-partain. > Mmmmh, it is bit of a stretch to say that 5.2.2 covers this. I don't see how sending a 'congestion notification' addresses setting up QoS on the new path. > >However, this is not explained in detail how it would be done. > > Probably >there may be more issues related to the interworking with QoS context >transfer protocols defined in SEAMOBY. >Do you already see any other requirements on such interface? > I am not discussing requirements yet, just their framework. > > > >|Another drawback of the 'interface' framework is that QoS signaling is >|not necessary limited to interfaces. For instance, to update some >|reservation >|after a handoff, you'd need to signal to the crossover router(s), >|wherever it >|is. Most likely this crossover router does not correspond to >|any interface. >|Note that draft-nsis either does not provide such framework, >|but it could >|easily (should) be added with a QoS Termination point >|abstraction. I think >|it is a dead end to assume the starting point and the end point of the >|QoS signaling to >|be some pre-defined interface. Draft-nsis goes a half step in the right >|direction by allowing the starting point to be anywhere and >|abstracting >|it into >|the QI, which is a better starting point. >The purpose of grouping the requirements according to different >interfaces where they apply to is not to limit the starting and ending >point of the protocol. > but that's what it does in practice. >The purpose is to see which requirements apply >to different parts of the network in the end-to-end path. We all agree >that what is needed in the access is not the same as what is needed >in the core, which means that we need to identify these requirements for >a protocol that we would like to use end-to-end. > end-to-end is not the only use of the protocol, I am sure you did not mean this. >The only way to achieve >this is by supporting modularity in the protocol. > This is a different point: I agree that supporting modularity in the protocol is a goal here. I disagree that the 'interface signaling' approach is the 'only way' to achieve modularity. > >Further draft-partain does not restrict the starting point of the >protocol either. > The use-case scenario is good for each single one of the described case. So you can draw n diagrams for n situations, and say, in these n cases, QoS is initiated here. But comes case (n+1), and you have to go back to the drawing table. It does not restrict starting point in this sense, but the framework is not scalable. In my view, a scalable framework (in the order of the scenarios) is the best way to get to a scalable protocol. > >The major problem in the [NSIS] WG draft is that the requirements are >deined for the abstract entities QI/QC and if there is no idea on where >in the network this requirements apply it is going to be difficult to >design an NSIS protocol fulfilling these requirements. > The major problem the other way round is that if you define explicitely QI/QC for every n cases you can come up with, you won't address the n+1 case when it arises. So combining both approaches somewhere in the middle should be the objective. The [NSIS] WG is as good a starting point as any. Cedric. > > > >Regards, >Vlora > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27445 for ; Fri, 1 Mar 2002 16:03:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28785 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28048; Fri, 1 Mar 2002 15:58:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27879 for ; Fri, 1 Mar 2002 15:58:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26763 for ; Fri, 1 Mar 2002 15:55:56 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21KuXi24511 for ; Fri, 1 Mar 2002 22:56:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:55:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:55:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] suggestions for draft-ietf-nsis-req-00.txt Date: Fri, 1 Mar 2002 22:55:57 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE24@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] suggestions for draft-ietf-nsis-req-00.txt Thread-Index: AcHAVPwx+ZKP6dstQTaxUe7MWj5J/AA/fDOg To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 20:55:57.0585 (UTC) FILETIME=[7C62B010:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27892 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > > 'Aggregate' > > - add an explicit statement that packets belonging to an aggregate must be > > commonly and uniquely identifiable, because otherwise aggregation doesn't > > make much sense. > > I disagree here, because aggregation is usually performed at service level, > i.e., the service has to have technically the same characteristics/attributes, > e.g., a guaranteed rate. If one considers DiffServ domains as a possible QoS > implementation architecture, each DiffServ domain may use different PHBs > (with different codepoints) to provide an equivalent service. Therefore, > packets will usually be different along the path of an aggregate. I think that seperate from aggregation, there is a need for unique identitiy - user & session identity. Perhaps a simple requirement, seperate from others, should state that. User / session identity will need to be used by any AAA solution for authorization, authentication & accounting purposes. > > Section 5.2.5, IP Fragmentation > > > > I would suggest to remove this requirement as it increases the complexity > > without much benefit. There are good reasons, why IP fragmentation is > > usually not supported by QoS signalling. Further, IPv6 does not support IP > > fragmentation at forwarding nodes. I think we should remove this for now. This gets into questions such as what is the NSIS protocol running on top of - IP/TCP/UDP/SCTP/etc. I think it would be premature to try to sort this out. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27513 for ; Fri, 1 Mar 2002 16:03:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28813 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27987; Fri, 1 Mar 2002 15:58:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27878 for ; Fri, 1 Mar 2002 15:58:25 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26807 for ; Fri, 1 Mar 2002 15:56:07 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21KtZ316777 for ; Fri, 1 Mar 2002 22:55:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:56:08 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:56:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 22:56:08 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE2B@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: Modularity and grouping QoS requirements Thread-Index: AcHAkeG4mmtWbeUTRV2gMl6yk1/cGAAxJG8Q To: , , X-OriginalArrivalTime: 01 Mar 2002 20:56:08.0478 (UTC) FILETIME=[82E0D3E0:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27890 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Vlora, > I would rather say that the QoS requirements would be derived > from different scenarios/use cases and than grouped according to > the interfaces they apply to. Can I ask what will this bring us? Remember, the WG has a framework document on its list of things to do. Frameworks usually suggest creating architectures & giving scenarios. Isn't your suggest a bit like putting the cart before the horse? > Section 6 of the WG draft gives a good overview on the importance > of the requirements to the Scenarios 1 - 5, but I would prefer > to see which requirements apply to particular interfaces > in the Scenarios 1-5. I truly believe it would be much more useful for us to spend time on specifying the requirements correctly than saying 'if you are trying to do this, do this.' We are trying to build some basic building blocks here, so that vendors, service providers, etc. can put them together to do some interesting things. If John Postel had specified UDP so that it could carry VoIP traffic, I think UDP would have suffered from much bloat and be much less useful ... just as an example. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27540 for ; Fri, 1 Mar 2002 16:03:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28841 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28029; Fri, 1 Mar 2002 15:58:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27881 for ; Fri, 1 Mar 2002 15:58:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26835 for ; Fri, 1 Mar 2002 15:56:15 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21KuQZ05896 for ; Fri, 1 Mar 2002 22:56:26 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:56:16 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:56:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Automatic Discovery of QCs Date: Fri, 1 Mar 2002 22:56:15 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE2E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Automatic Discovery of QCs Thread-Index: AcHArQuU8TEAQraTQe2NVn5CshIKdgAqubpA To: , X-OriginalArrivalTime: 01 Mar 2002 20:56:16.0288 (UTC) FILETIME=[87888A00:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27891 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Roland, > I would add another point to section 5.3 of draft-ietf-nsis-req-00: > 5.3.8 Automatic discovery of QoS Controllers. > This will allow some degree of auto configuration which can > be useful in many scenarios. For instance, hosts (especially > mobile ones) will be able to find out the next adjacent Could we blur your requirement somewhat? My suggest is: 5.3.8 Discovery of QoS Controllers NSIS SHOULD support a simple mechanism for discoverying QoS entities. This means that, for example, on-path signaling could be one option - meaning that as the host signals the network, the network can eavesdrop and setup signaling to off-path QoS entities; or access routers could proxy the QoS controllers and interact with them and allow some sort of seamoby context transfer for mobility, etc. For me, a key issue with this topic is how does an end user discover QoS entities? Does it employ a protocol like SLP, or DNS? Does the network do it via a proxy model; is there some pre-configured home QoS entitity that negotiates with the visitied network... or something else? I favor a minimal approach, which allows service providers to implement more complex schemes - but yet still allows the minimal approach to work. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27556 for ; Fri, 1 Mar 2002 16:03:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28855 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28180; Fri, 1 Mar 2002 15:58:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27887 for ; Fri, 1 Mar 2002 15:58:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26799 for ; Fri, 1 Mar 2002 15:56:01 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21Kuci24563 for ; Fri, 1 Mar 2002 22:56:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:56:02 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:56:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft Date: Fri, 1 Mar 2002 22:56:02 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE28@esebe004.NOE.Nokia.com> Thread-Topic: Definition of QI was: Re: [NSIS] WG requirements draft Thread-Index: AcHAaDAzzn4q9nBlS6+jab3OOmjRVgA7P2Sw To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 20:56:03.0085 (UTC) FILETIME=[7FA9EBD0:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27979 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, > How a network provider > modifies resources within his domain and at which layer > doesn't matter to NSIS and therefore isn't relevant for my proposal. Well put. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27574 for ; Fri, 1 Mar 2002 16:03:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28869 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28109; Fri, 1 Mar 2002 15:58:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27886 for ; Fri, 1 Mar 2002 15:58:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26802 for ; Fri, 1 Mar 2002 15:56:03 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21Kudi24579 for ; Fri, 1 Mar 2002 22:56:39 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:56:03 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:56:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Fri, 1 Mar 2002 22:56:03 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE29@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: Modularity and grouping QoS requirements Thread-Index: AcHAaUec+8fiKG9xQKOyvgf96WLiaQA7ABfg To: , X-OriginalArrivalTime: 01 Mar 2002 20:56:04.0148 (UTC) FILETIME=[804C1F40:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27896 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, Putting my chair hat on: > A question on what is really being proposed here (about > modularity/grouping): > > When people say that we should group the requirements > according to things like UNI(access) or NNI(backbone), do they mean > > 1. that we should annotate requirements according to which > network environments they are particularly applicable to or > crucial for (e.g. 'scalability is important in the core' and so on) I think that the above is dangerous because it is limiting. Usage scenarious are useful when they help us understand why a certain requirement is needed. However, if the usage scenario is more important than the requirement, then we are in trouble. > 2. that we already know there will be a UNI NSIS protocol and > an NNI NSIS protocol and we are actually trying to write > requirements specifications for these particular protocols This, imo, is a bad thing. Requirements SHOULD NOT presuppose a network architecure. > Or is there already a consensus on the 'two protocols is the > solution' view within the WG? This is something that the WG cannot decide on yet. We are working on requirements, not solutions yet. To be very specific, I see the current work to be this: create requirements, and use some scenarios to illustrate the requirements (i.e. - try to ground them in some reality). Develop a framework which will support these requirements. Create a solution which fits into the framework & fufills the requirements. Many protocols were less than successful because they attempted to solve a problem which ended-up not being the problem that needed to be solved. If we color the requirements by focusing on specific scenarios, we run the same risk. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27600 for ; Fri, 1 Mar 2002 16:03:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28883 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28082; Fri, 1 Mar 2002 15:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27883 for ; Fri, 1 Mar 2002 15:58:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26787 for ; Fri, 1 Mar 2002 15:55:58 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21Ku9Z05749 for ; Fri, 1 Mar 2002 22:56:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:55:59 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:55:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] suggestions for draft-ietf-nsis-req-00.txt Date: Fri, 1 Mar 2002 22:55:58 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE25@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] suggestions for draft-ietf-nsis-req-00.txt Thread-Index: AcHAWE25adXyWWanSfmL+PmGRbzyPQA+0ZOg To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 20:55:59.0226 (UTC) FILETIME=[7D5D15A0:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27889 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > Correct, but then all packets will all have the same DSCP > within a domain, which essentially is the common and unique > identifier I'm referring to. > > Let me rephrase: > ... packets belonging to an aggregate must be commonly and uniquely > identifiable per QoS domain ... Taking a page from AAA work, the domains are termed 'realms' - somehow, I think that term might be sidestep some of the issues with the terminology. Actually, on a theoretical basis (and probably because I have been editing the Diameter base spec) I do see a lot of comonalities between NSIS and AAA. Perhaps we should consider some of the terminology from that work, however, we can always stick QoS in front, just to be explicit. > > > Section 5.2.5, IP Fragmentation > > > > > > I would suggest to remove this requirement as it > increases the complexity > > > without much benefit. There are good reasons, why IP > fragmentation is > > > usually not supported by QoS signalling. Further, IPv6 > does not support IP > > > fragmentation at forwarding nodes. > > > > IPv6 is definitely not a problem in this context, because > nsis signaling > > will always mean fragmentation from end to end between to > adjacent nsis > > nodes. Thus, every nsis node will able to fragment its signaling > > messages and any router will be able to forward these > messages (but it > > will not fragment by itself at all). On the other hand, why > shouldn't we > > allow fragmentation? It will be an implementation decision > whether the > > nsis protocol should require a reliable transport protocol > such as SCTP > > or whether it should do all the stuff by itself (IMHO it shouldn't). > > Sure, in the latter case an implementation without fragmentation > > will be easier. > > I was assuming that the requirement in 5.2.5 refers to the > data packets > rather than signalling packets. If it only refers to > signalling packets, > then of course, forget my comment. Would a better requirement be something like: NSIS SHOULD provide a robust solution for signaling and handling of data packets irrespective of MTU (maximum transport unit) size. Would that be something that would cover what you were thinking? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:03:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27619 for ; Fri, 1 Mar 2002 16:03:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28914 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:03:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28045; Fri, 1 Mar 2002 15:58:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27876 for ; Fri, 1 Mar 2002 15:58:24 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26793 for ; Fri, 1 Mar 2002 15:55:59 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21KuBZ05764 for ; Fri, 1 Mar 2002 22:56:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:56:01 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:56:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG requirements draft Date: Fri, 1 Mar 2002 22:56:00 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE26@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] WG requirements draft Thread-Index: AcHAWLVcIRT/iWVwR2KRhZMR+ZlouwA+3iyg To: , Cc: , , X-OriginalArrivalTime: 01 Mar 2002 20:56:00.0429 (UTC) FILETIME=[7E14A5D0:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27888 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Roland & Danny, > Yes, I agree that we have to define the interfaces for which we are > developing nsis protocols. But in this context we have also to name > the entities that talk to each other via these interfaces/protocols. > We should consider a wide range of scenarios to find a common > denominator for these interfaces. One think that might be useful in this requirement phase would be to be thinking in terms of clouds rather than strings. Clouds being more like QoS realms (or domains) rather than links. As what we are trying to do is abstract resource signaling from resource reservation, this could be a useful way to try to capture the requirements. In this model, interfaces become more abstract and less literal than if we are thinking about the physical interfaces between 2 network entitites. food for thought, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 16:06:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27859 for ; Fri, 1 Mar 2002 16:06:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29045 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 16:06:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28172; Fri, 1 Mar 2002 15:58:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27882 for ; Fri, 1 Mar 2002 15:58:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26796 for ; Fri, 1 Mar 2002 15:56:00 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21Kubi24548 for ; Fri, 1 Mar 2002 22:56:37 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 22:56:01 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 22:56:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft Date: Fri, 1 Mar 2002 22:56:01 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE27@esebe004.NOE.Nokia.com> Thread-Topic: Definition of QI was: Re: [NSIS] WG requirements draft Thread-Index: AcHAZZ6EKzvyXD9HS6CgCLateZyd5wA7yGjQ To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 20:56:02.0151 (UTC) FILETIME=[7F1B6770:01C1C163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27977 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Danny & Rüdiger, Some comments - text clipped where appropriate. > [DG] OK, we don't want to make the mistake of per-microflow processing > in core routers again, I think nobody objects to that. Agreed. > [DG] However, I think we should make distinction between provisioning > (making the resources available, e.g. fat-pipe set-up) and signaling > (consuming the resources, e.g. multiplexing microflows in the pipes at > the edges). Clearly resource provisioning may depend on the actual > technology of the concrete network (and is an operator's policy). I > should like to call this "local provisioning means" and the end-to-end > NSIS signaling should, in my opinion, be independent of this local > mechanisms. Provisioning, fyi, is out of scope for NSIS. However, placing hooks into an nsis protocol so that mechanisms could do this provisioning is within scope. > > If you'd like to look at it that way, it's a requirement > for NSIS signalling to support some kind of traffic > engineering. Support here is limited to control "fat pipe" > set up, maintenance and release. > > [DG$ Here I am not sure it should be the first focus of NSIS, > imho, NSIS > should have as first target the per-flow signaling and make the "local > provisioning means" transparant for the QoS signaling. Again, placing hooks in NSIS for TE is OK, but mandating TE or specifying a specific form of TE is out of scope. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 17:12:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03021 for ; Fri, 1 Mar 2002 17:12:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03441 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 17:12:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03247; Fri, 1 Mar 2002 17:08:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03213 for ; Fri, 1 Mar 2002 17:07:57 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02853 for ; Fri, 1 Mar 2002 17:07:56 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21MA2x17442 for ; Fri, 1 Mar 2002 16:10:02 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 1 Mar 2002 16:07:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 16:07:19 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [NSIS] Automatic Discovery of QCs Date: Fri, 1 Mar 2002 17:07:18 -0500 Message-ID: Thread-Topic: [NSIS] Automatic Discovery of QCs Thread-Index: AcHArQuU8TEAQraTQe2NVn5CshIKdgAqubpAAATcV+A= To: X-OriginalArrivalTime: 01 Mar 2002 22:07:19.0128 (UTC) FILETIME=[74624D80:01C1C16D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA03214 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John: In the interest of simplicity, allow me to turn around the blurred requirement. Can we actually say that "NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities." In other words, can't a host just shoot an NSIS signal towards the network (destined to a well-known IP address for example or identifiable by some field in the packet header) and the routers can forward it to appropriate QCs in their network domain. Hemant -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: Friday, March 01, 2002 3:56 PM To: bless@tm.uka.de; nsis@ietf.org Subject: RE: [NSIS] Automatic Discovery of QCs Hi Roland, > I would add another point to section 5.3 of draft-ietf-nsis-req-00: > 5.3.8 Automatic discovery of QoS Controllers. > This will allow some degree of auto configuration which can > be useful in many scenarios. For instance, hosts (especially > mobile ones) will be able to find out the next adjacent Could we blur your requirement somewhat? My suggest is: 5.3.8 Discovery of QoS Controllers NSIS SHOULD support a simple mechanism for discoverying QoS entities. This means that, for example, on-path signaling could be one option - meaning that as the host signals the network, the network can eavesdrop and setup signaling to off-path QoS entities; or access routers could proxy the QoS controllers and interact with them and allow some sort of seamoby context transfer for mobility, etc. For me, a key issue with this topic is how does an end user discover QoS entities? Does it employ a protocol like SLP, or DNS? Does the network do it via a proxy model; is there some pre-configured home QoS entitity that negotiates with the visitied network... or something else? I favor a minimal approach, which allows service providers to implement more complex schemes - but yet still allows the minimal approach to work. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 1 17:44:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04338 for ; Fri, 1 Mar 2002 17:44:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05009 for nsis-archive@odin.ietf.org; Fri, 1 Mar 2002 17:44:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04923; Fri, 1 Mar 2002 17:40:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04841 for ; Fri, 1 Mar 2002 17:40:14 -0500 (EST) Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04275 for ; Fri, 1 Mar 2002 17:40:12 -0500 (EST) Received: from ee.ryerson.ca ([24.112.177.95]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020301223944.XUXK5932.fep03-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca>; Fri, 1 Mar 2002 17:39:44 -0500 Message-ID: <3C80032E.9000706@ee.ryerson.ca> Date: Fri, 01 Mar 2002 17:39:42 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Automatic Discovery of QCs References: Content-Type: multipart/alternative; boundary="------------020609040505070509090503" X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.112.177.95] using ID at Fri, 1 Mar 2002 17:39:44 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------020609040505070509090503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Hemant: I like your wording. The signaling should not include the QC discovery as an additional step, but if the network operator wants to configure the host with the QC address should resort to any other means, e.g. DHCP etc. The implication would be the QC implementation would need DNS like robustness. Hence, for the network operator the more preferred way would be to configure access routers as either QC or proxy. Anyway, the following wording gives much latitude to implementation and deployment of QC. - Muhammad Hemant.Chaskar@nokia.com wrote: >Hi John: > >In the interest of simplicity, allow me to turn around the blurred requirement. Can we actually say that > >"NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities." > >In other words, can't a host just shoot an NSIS signal towards the network (destined to a well-known IP address for example or identifiable by some field in the packet header) and the routers can forward it to appropriate QCs in their network domain. > >Hemant > > >-----Original Message----- >From: Loughney John (NRC/Helsinki) >Sent: Friday, March 01, 2002 3:56 PM >To: bless@tm.uka.de; nsis@ietf.org >Subject: RE: [NSIS] Automatic Discovery of QCs > > >Hi Roland, > > >>I would add another point to section 5.3 of draft-ietf-nsis-req-00: >>5.3.8 Automatic discovery of QoS Controllers. >> This will allow some degree of auto configuration which can >> be useful in many scenarios. For instance, hosts (especially >> mobile ones) will be able to find out the next adjacent >> > >Could we blur your requirement somewhat? My suggest is: > > 5.3.8 Discovery of QoS Controllers > > NSIS SHOULD support a simple mechanism for discoverying > QoS entities. > >This means that, for example, on-path signaling could be one >option - meaning that as the host signals the network, the >network can eavesdrop and setup signaling to off-path >QoS entities; or access routers could proxy the QoS >controllers and interact with them and allow some >sort of seamoby context transfer for mobility, etc. > >For me, a key issue with this topic is how does an end user >discover QoS entities? Does it employ a protocol like SLP, >or DNS? Does the network do it via a proxy model; is there >some pre-configured home QoS entitity that negotiates >with the visitied network... or something else? > >I favor a minimal approach, which allows service providers >to implement more complex schemes - but yet still allows the >minimal approach to work. > >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > -- ================================================== Muhammad Jaseemuddin Associate Professor Departement of Electrical and Computer Engineering Ryerson University 350 Victoria Street Toronto, ON M5B 2K3 Tel: +1 416 979-5000x6073 Fax: +1 416 979-5280 Email: jaseem@ee.ryerson.ca Web: http://www.ee.ryerson.ca/~jaseem ================================================== --------------020609040505070509090503 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hemant:

 I like your wording. The signaling should not include the QC discovery as an additional step, but if the network operator wants to configure the host with the QC address should resort to any other means, e.g. DHCP etc. The implication would be the QC implementation would need DNS like robustness. Hence, for the network operator the more preferred way would be to configure access routers as either QC or proxy. Anyway, the following wording gives much latitude to implementation and deployment of QC.

- Muhammad

Hemant.Chaskar@nokia.com wrote:
Hi John:

In the interest of simplicity, allow me to turn around the blurred requirement. Can we actually say that

"NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities."

In other words, can't a host just shoot an NSIS signal towards the network (destined to a well-known IP address for example or identifiable by some field in the packet header) and the routers can forward it to appropriate QCs in their network domain.

Hemant


-----Original Message-----
From: Loughney John (NRC/Helsinki) 
Sent: Friday, March 01, 2002 3:56 PM
To: bless@tm.uka.de; nsis@ietf.org
Subject: RE: [NSIS] Automatic Discovery of QCs


Hi Roland,


I would add another point to section 5.3 of draft-ietf-nsis-req-00:
5.3.8 Automatic discovery of QoS Controllers.
      This will allow some degree of auto configuration which can
      be useful in many scenarios. For instance, hosts (especially 
      mobile ones) will be able to find out the next adjacent 

Could we blur your requirement somewhat?  My suggest is:
 
  5.3.8 Discovery of QoS Controllers

	NSIS SHOULD support a simple mechanism for discoverying
	QoS entities.

This means that, for example, on-path signaling could be one
option - meaning that as the host signals the network, the
network can eavesdrop and setup signaling to off-path 
QoS entities; or access routers could proxy the QoS 
controllers and interact with them and allow some 
sort of seamoby context transfer for mobility, etc.

For me, a key issue with this topic is how does an end user
discover QoS entities?  Does it employ a protocol like SLP,
or DNS? Does the network do it via a proxy model; is there
some pre-configured home QoS entitity that negotiates
with the visitied network... or something else?

I favor a minimal approach, which allows service providers
to implement more complex schemes - but yet still allow
s the
minimal approach to work.

John

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

-- 
==================================================
Muhammad Jaseemuddin
Associate Professor
Departement of Electrical and Computer Engineering
Ryerson University
350 Victoria Street
Toronto, ON M5B 2K3
Tel: +1 416 979-5000x6073
Fax: +1 416 979-5280
Email: jaseem@ee.ryerson.ca
Web: http://www.ee.ryerson.ca/~jaseem
==================================================

--------------020609040505070509090503-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sat Mar 2 11:14:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02010 for ; Sat, 2 Mar 2002 11:14:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22072 for nsis-archive@odin.ietf.org; Sat, 2 Mar 2002 11:14:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21993; Sat, 2 Mar 2002 11:09:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21964 for ; Sat, 2 Mar 2002 11:09:26 -0500 (EST) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01862 for ; Sat, 2 Mar 2002 11:09:22 -0500 (EST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id RAA24198; Sat, 2 Mar 2002 17:08:54 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g22G8N011400; Sat, 2 Mar 2002 17:08:23 +0100 Message-Id: <200203021608.g22G8N011400@KOM.tu-darmstadt.de> Subject: Re: [NSIS] suggestions for draft-ietf-nsis-req-00.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE25@esebe004.NOE.Nokia.com> from "john.loughney@nokia.com" at "Mar 1, 2002 10:55:58 pm" To: john.loughney@nokia.com Date: Sat, 2 Mar 2002 17:08:23 +0100 (CET) CC: bless@tm.uka.de, nsis@ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi John. > > Correct, but then all packets will all have the same DSCP > > within a domain, which essentially is the common and unique > > identifier I'm referring to. > > > > Let me rephrase: > > ... packets belonging to an aggregate must be commonly and uniquely > > identifiable per QoS domain ... > > Taking a page from AAA work, the domains are termed 'realms' - > somehow, I think that term might be sidestep some of the issues > with the terminology. Actually, on a theoretical basis > (and probably because I have been editing the Diameter > base spec) I do see a lot of comonalities between NSIS > and AAA. Perhaps we should consider some of the terminology > from that work, however, we can always stick QoS in front, > just to be explicit. That might be fine, but I don't know the current AAA terminology. I was referring to the fact that one cannot just arbitrarily aggregate IP flows and then treat it as an IP aggregate. A common identifier, e.g. MPLS label, DSCP, IP tunnel, CIDR prefix, or anything else is always needed to achieve anything with respect to QoS aggregation. I thought that an explicit statement might be useful to avoid too optimistic assumptions resulting from the requirements. Of course, the mapping between a set of flow filters and the common identifier might be hidden within a QoS domain and since NSIS is focusing on inter-domain QoS signalling, it is debatable what level of detail should be included in the requirements. > > I was assuming that the requirement in 5.2.5 refers to the data packets > > rather than signalling packets. If it only refers to signalling packets, > > then of course, forget my comment. > > Would a better requirement be something like: > > NSIS SHOULD provide a robust solution for signaling > and handling of data packets irrespective of MTU > (maximum transport unit) size. > > Would that be something that would cover what you were thinking? I don't know whether I fully understand the meaning of this statement. The way I understand it, it sounds correct, but maybe trivial. The essential question is whether the MTU of data packets must be fixed along a path or whether it can vary in a sense that IPv4 fragmentation requires to transform the QoS specification. I would think that requiring support for the latter does not make much sense, because it increases complexity and is obsolete for IPv6. Greetings, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Mar 3 19:34:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01639 for ; Sun, 3 Mar 2002 19:34:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA09643 for nsis-archive@odin.ietf.org; Sun, 3 Mar 2002 19:34:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09040; Sun, 3 Mar 2002 19:29:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08995 for ; Sun, 3 Mar 2002 19:29:41 -0500 (EST) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01590 for ; Sun, 3 Mar 2002 19:29:37 -0500 (EST) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g240S4h19870; Mon, 4 Mar 2002 11:28:05 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA16317; Mon, 4 Mar 2002 11:29:31 +1100 (EST) Received: from localhost.localdomain (146.11.239.86 [146.11.239.86]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FPARN9RT; Mon, 4 Mar 2002 11:29:31 +1100 Subject: Re: another requirements question (was: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt) From: Brian Williams To: "Hancock, Robert" Cc: "'Jukka Manner'" , Gabor Fodor , nsis@ietf.org In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA17F@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA17F@rsys002a.roke.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 11:24:16 +1100 Message-Id: <1015201461.3455.26.camel@mindy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Robert. See my 2c on the requirements question. /brian On Thu, 2002-02-28 at 04:27, Hancock, Robert wrote: > Hi Brian, > > [others: the requirements question is at the end if you want to skip to it.] > *** Requirements question *** > Does the NSIS signalling need to be able to convey/negotiate information about which end of a link is going to be responsible for initiating lower layer bearer setup? > > I don't think the answer is obviously yes or no here. There's a lot of different wireless link types out there. I haven't thought about this previously, but my opinion is that it should not be necessary. I think that layer 2 managers must have rules to deal with deciding which end controls L2 establishment, and they already have to deal with RSVP which does not provide negotiation on which end does this. Thus, the L2 manager must be able to deal with protocols which do not provide control negotiation already, and I don't see a strong requirement to solve this at present. > Yours, > > Robert H. > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 21 February 2002 07:41 > > To: Hancock, Robert > > Cc: 'Jukka Manner'; Gabor Fodor; nsis@ietf.org > > Subject: RE: [NSIS] A few comments to > > draft-fodor-reqts-cellular-netwks-00 .txt > > > > > > Hi Robert. > > I would definitely agree that there are many different scenarios, and > > one with the application node sitting behind a wireless router/gateway > > is the most obvious situation which introduces signalling > > requirements. > > > > I would also add though that even within one physical node, > > there can be > > scenarios that effectively become an equivalent to this > > application node > > behind a gateway router. For example, on my PC I have run multiple > > virtual machines. The communication between these virtual machines > > occurs over a virtual ethernet, but it is all within one node. > > > > There can also be cases where a node works towards one > > logical interface > > internally, which is then adapted one or more times until it > > reaches the > > real interface such as with levels of tunneling. > > > > And finally, we should not rule out that other wireless networks could > > control the link layer signalling from the network instead of from the > > terminal. > > > > In all of these cases, there are reasons to have additional > > information > > important for the wireless operation available from the application > > level QoS interface, and possibly carried in the IP level QoS > > protocol. > > I do agree though that dependent on the exact scenario, this > > information > > may not need to be transmitted over the wireless link. > > /brian > > > > On Thu, 2002-02-21 at 01:18, Hancock, Robert wrote: > > > Hi Jukka, Gabor, > > > > > > On the UDP-lite issue, my understanding is that UDP-lite > > only tells you that some of the packet is checksum protected > > and some isn't. The sophistication of signalling required for > > full UEP (e.g. to support AMR codec operation) is much > > greater. I guess if you had UEP QoS signalling you wouldn't > > need UDP-lite, you could just switch the checksum off > > altogether (at least for IPv4). > > > > > > I was more concerned about whether the scenario as > > presented really justifies the need for wireless-related > > parameters at all. It seems to concentrate on the case where > > the wireless link is the last hop, directly connected to the > > node where the end application is running. In that case, it's > > clear that good quality IP QoS (fine grained, efficient, > > local etc.) is important, more so than in fixed networks. I > > think it's less clear that the IP layer signalling needs to > > have link (or 'link-ish') parameters in it. After all, the > > link layers already have their own signalling, and can tune > > the link to the required QoS even more tightly. > > > > > > It's true that if applications use the IntServ classes to > > request QoS from their network stack, these classes need to > > be extended with wireless hints. But that's a comment on the > > deficiency of basing inter-layer interfaces on protocols, not > > a requirement to extend the protocol itself. > > > > > > One reason we thought to be very careful here was that if > > you have wireless-related parameters being exchanged at both > > IP (RSVP) and link layers, it might be hard for independent > > implementors of each end to work out which layer to use for > > negotiation and in which order, and which layer was in > > charge. This was raised after SLC as an open issue on the > > list, but the argument wasn't really clear (partly my fault). > > > > > > I think there _is_ actually a good case for having wireless > > related parameters, but that the justifying scenario is where > > the wireless link is 'interior' (e.g. 3G mobile acting as a > > wireless router for a local subnet), but in that case you > > might need take into account other considerations as well. > > Then you need to get the wireless-related information from > > the application into the router. But in either case, we need > > to have a clear model of how the link layer negotiation > > interacts with the IP layer negotiation. > > > > > > Or did I miss something? > > > > > > Robert H. > > > > > > > -----Original Message----- > > > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: 20 February 2002 12:00 > > > > To: Gabor Fodor > > > > Cc: nsis@ietf.org > > > > Subject: [NSIS] A few comments to > > > > draft-fodor-reqts-cellular-netwks-00.txt > > > > > > > > > > > > > > > > Hi, > > > > > > > > As I read the draft, two requirements left me wondering: > > > > > > > > R2: how does this match with the UDP-lite proposal, > > > > where the UDP > > > > header indicates the need for UEP. Thus, does the QoS primitives / > > > > signalling need to indicate the need for UEP? If the > > > > transport protocol > > > > does not support UEP, you won't get the packet sent > > to/accepted at the > > > > receiver. Also, you don't even need any QoS mechanism to > > use UDP-lite. > > > > > > > > R3: you seem to assume that doing bi-directional resource > > > > allocations also implies that routing is symmetric for uplink and > > > > downlink. Since IP routing is asymmetric, I doubt that > > bi-directional > > > > reservations are possible with a single mechanism, but rather > > > > imply that > > > > there must be separate signalling for the two directions. > > > > Thus, eg. RSVP > > > > makes it possible to have asymmetric reservations on the two > > > > directions. > > > > > > > > Cheers, > > > > > > > > Jukka > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > ---- > > > > > > > > The information contained in this e-mail and any > > attachments is confidential to Roke > > > Manor Research Ltd and must not be passed to any third > > party without permission. This > > > communication is for information only and shall not create > > or change any contractual > > > relationship. > > > > > > ---- > > The information contained in this e-mail and any attachments is confidential to Roke > Manor Research Ltd and must not be passed to any third party without permission. This > communication is for information only and shall not create or change any contractual > relationship. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 02:29:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16240 for ; Mon, 4 Mar 2002 02:29:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08251 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 02:29:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08080; Mon, 4 Mar 2002 02:25:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08049 for ; Mon, 4 Mar 2002 02:25:21 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16224 for ; Mon, 4 Mar 2002 02:25:09 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g247PKZ28739 for ; Mon, 4 Mar 2002 09:25:20 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 09:25:10 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 09:25:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Mon, 4 Mar 2002 09:25:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AC1@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: Modularity and grouping QoS requirements Thread-Index: AcHBIimezyBEX3nzTuuKIwu1TyTjZQCK0vIw To: , X-OriginalArrivalTime: 04 Mar 2002 07:25:10.0734 (UTC) FILETIME=[B7D78EE0:01C1C34D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA08050 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georios, > I think there is a disagreement on how the requirements > are separated/grouped. > In this way we define some kind of QoS toolbox, that can be > used in a flexible way by e.g., a network provider. > For example a network provider could choose to implement > the QoS complexity level (2) in a border router. Some other > network provider may choose to implement the QoS complexity > level (3) into a border router; > The same holds for other network entities; My opinion would be that the framework document can do this. The framework doc will discuss the NSIS architecture & could apply the requirements to the architecture. I think the disagreement on the grouping / seperation of requirements are a bit pointless - we should be focusing on the requirements. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 02:31:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16313 for ; Mon, 4 Mar 2002 02:31:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08799 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 02:31:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08202; Mon, 4 Mar 2002 02:28:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08169 for ; Mon, 4 Mar 2002 02:28:03 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16233 for ; Mon, 4 Mar 2002 02:26:52 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g247RUi19623 for ; Mon, 4 Mar 2002 09:27:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 4 Mar 2002 09:26:53 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 09:26:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Automatic Discovery of QCs Date: Mon, 4 Mar 2002 09:26:53 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AC2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Automatic Discovery of QCs Thread-Index: AcHArQuU8TEAQraTQe2NVn5CshIKdgAqubpAAATcV+AAeJ7TEA== To: , X-OriginalArrivalTime: 04 Mar 2002 07:26:53.0803 (UTC) FILETIME=[F546A3B0:01C1C34D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA08170 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Hemant, > In the interest of simplicity, allow me to turn around the > blurred requirement. Can we actually say that > > "NSIS SHOULD support a signaling mechanism that does not > require explicit discovery of QoS entities." > > In other words, can't a host just shoot an NSIS signal > towards the network (destined to a well-known IP address for > example or identifiable by some field in the packet header) > and the routers can forward it to appropriate QCs in their > network domain. You put it quite well, that was the reqirement that I was trying for. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 05:43:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19076 for ; Mon, 4 Mar 2002 05:43:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19283 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 05:43:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18959; Mon, 4 Mar 2002 05:35:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18930 for ; Mon, 4 Mar 2002 05:35:46 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18936 for ; Mon, 4 Mar 2002 05:35:37 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g24AZmZ10241 for ; Mon, 4 Mar 2002 12:35:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 12:35:39 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 12:35:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG requirements draft Date: Mon, 4 Mar 2002 12:35:38 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AD2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] WG requirements draft Thread-Index: AcG+4VR89sSRSVB5RIe18V+HdG83PAEhtAQw To: , Cc: , X-OriginalArrivalTime: 04 Mar 2002 10:35:39.0149 (UTC) FILETIME=[53B54BD0:01C1C368] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA18931 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Lars, > I would propose the we have two different scenarios explicitly in the > requirements draft: > One for a Bandwidth Broker case and one for a typical RSVP scenario. I think that we could have requirements that place 'should' on both - rather than seperate it out by scenarios. The framework document could further detail when the different approaches apply. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 05:46:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19102 for ; Mon, 4 Mar 2002 05:46:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19426 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 05:46:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18742; Mon, 4 Mar 2002 05:32:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18713 for ; Mon, 4 Mar 2002 05:32:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18894 for ; Mon, 4 Mar 2002 05:32:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g24AX0i15351 for ; Mon, 4 Mar 2002 12:33:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 12:32:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 12:32:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Mon, 4 Mar 2002 12:32:24 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AD1@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: Modularity and grouping QoS requirements Thread-Index: AcHBD2E7t40lQkauQ5C6cEHSC2seTgCWCQyA To: , , X-OriginalArrivalTime: 04 Mar 2002 10:32:24.0516 (UTC) FILETIME=[DFB2A840:01C1C367] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA18714 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Vlora, > Are you suggesting to keep the definition of QI/QC in the requirements > as well? Well, some sort of definition will be needed. I think the WG should try to come up with a definition. If the above terms are not acceptable for everyone, let's try to find ones that are. > If so, than the requirements should be defined such that the > modularity concept is introduced in the definition of QI and QC. > For example if the QI is in the host different requirements apply from > the case when QI is elsewhere. The same would be in case when QC is a > centralized point or resides in border or interior node. In all these > cases there will be specific requirements that would apply. I agree that the requirements should support modularity. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 05:54:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19201 for ; Mon, 4 Mar 2002 05:54:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19840 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 05:54:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19659; Mon, 4 Mar 2002 05:50:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19620 for ; Mon, 4 Mar 2002 05:50:36 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19144 for ; Mon, 4 Mar 2002 05:50:31 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16hq37-0004GS-00; Mon, 04 Mar 2002 11:50:33 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16hq37-00066R-00; Mon, 04 Mar 2002 11:50:33 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g24AoWW27536; Mon, 4 Mar 2002 11:50:32 +0100 Message-Id: <200203041050.g24AoWW27536@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: danny.goderis@alcatel.be, Vlora.Rexhepi@eln.ericsson.se, David.Partain@ericsson.com, nsis@ietf.org Subject: Re: [NSIS] WG requirements draft In-Reply-To: Message from john.loughney@nokia.com of "Fri, 01 Mar 2002 22:56:00 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE26@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE26@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Mar 2002 11:50:32 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > One think that might be useful in this requirement phase would be to > be thinking in terms of clouds rather than strings. Clouds being > more like QoS realms (or domains) rather than links. As what > we are trying to do is abstract resource signaling from resource > reservation, this could be a useful way to try to capture the > requirements. In this model, interfaces become more abstract > and less literal than if we are thinking about the physical > interfaces between 2 network entities. Good point. I also thought about a more abstract model when people wrote about access and core networks, which isn't always appropriate (what is _the_ core?), so this needs clarification. Shouldn't we assume the overall Internet architecture as basis? Therefore, on your proposed abstract level we have interfaces between a) hosts/end-systems b) Autonomous Systems/QoS Domains (Surely, hosts are also part of an AS) There are different type b) networks: - stub (carrying traffic from and to access networks), - pure transit (containing no access networks, thus carrying traffic of other ASs), and - mixed ASs (having access networks as well as forwarding transit traffic) but I don't think we should make an explicit difference between them and assume the last case. This view leads mainly to a kind of UNI/NNI perspective. However, there are many other components within an AS/Domain and thus many additional (mainly already existing) signaling protocols within a Domain (e.g., COPS, MT<->SGSN/GGSN mobility etc) depending on the particular QoS implementation architecture. I thought, that work is mainly needed at the interfaces from a) <-> b) and b) <-> b), therefore being independent from the actual underlying QoS architecture. Interface a) <-> b) should especially consider mobility and security issues, but it should be independent of what is the conrete peer within b): a Domain Manager, an access/edge/boundary router or some kind of proxy. Are there other requirements which won't fit to this more abstract model? Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 05:57:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19283 for ; Mon, 4 Mar 2002 05:57:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19959 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 05:57:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19782; Mon, 4 Mar 2002 05:53:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19749 for ; Mon, 4 Mar 2002 05:53:33 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19188 for ; Mon, 4 Mar 2002 05:53:28 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g24ArJZc016489 for ; Mon, 4 Mar 2002 11:53:19 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 11:52:48 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 11:52:47 +0100 Message-ID: From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Mon, 4 Mar 2002 11:52:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, |> I would rather say that the QoS requirements would be derived |> from different scenarios/use cases and than grouped according to |> the interfaces they apply to. | |Can I ask what will this bring us? Remember, the WG has a framework |document on its list of things to do. Frameworks usually suggest |creating architectures & giving scenarios. Isn't your suggest |a bit like putting the cart before the horse? As I see it is that we are having certain scenarios in mind where an NSIS protocol is needed and these scenarios would help us to be more focussed when defining requirements and grouping them into interfaces would help further into the focussing process. |> Section 6 of the WG draft gives a good overview on the importance |> of the requirements to the Scenarios 1 - 5, but I would prefer |> to see which requirements apply to particular interfaces |> in the Scenarios 1-5. | |I truly believe it would be much more useful for us to spend |time on specifying the requirements correctly than saying |'if you are trying to do this, do this.' True. Definitely agree. But before doing this we need to have a well defined terminology on the entities used when defining requirements. |We are trying to build some basic building blocks here, so |that vendors, service providers, etc. can put them together |to do some interesting things. If John Postel had specified |UDP so that it could carry VoIP traffic, I think UDP would |have suffered from much bloat and be much less useful ... |just as an example. Good point :-). Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 06:09:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19419 for ; Mon, 4 Mar 2002 06:09:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA20825 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 06:09:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20654; Mon, 4 Mar 2002 06:04:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20619 for ; Mon, 4 Mar 2002 06:04:56 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19391 for ; Mon, 4 Mar 2002 06:04:51 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g24B5Ui29606 for ; Mon, 4 Mar 2002 13:05:30 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 13:04:54 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 13:04:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Mon, 4 Mar 2002 13:04:53 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AD5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] RE: Modularity and grouping QoS requirements Thread-Index: AcHDatJaBaij06PYTW6M9plcp5okjAAASbGg To: , X-OriginalArrivalTime: 04 Mar 2002 11:04:54.0045 (UTC) FILETIME=[69B52CD0:01C1C36C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA20620 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Vlora, > As I see it is that we are having certain scenarios in mind where an > NSIS protocol is needed and these scenarios would help us to be more > focussed when defining requirements and grouping them into interfaces > would help further into the focussing process. This isn't a bad thing, if we don't get carried away. IntServ was based on usage for sets of scenarios, which led into some well known results. IntServ, for what it tried to do, is actually quite good - however, in my (personal) opinion, IntServ might have been more successful if it were not bounded by some initial considerations. I want to make sure we don't fall into the same trap. > |I truly believe it would be much more useful for us to spend > |time on specifying the requirements correctly than saying > |'if you are trying to do this, do this.' > > True. Definitely agree. > But before doing this we need to have a well defined terminology > on the entities used when defining requirements. Definately, that is why terminology should be a key subject for discussion. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 07:13:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21165 for ; Mon, 4 Mar 2002 07:13:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24070 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 07:13:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23505; Mon, 4 Mar 2002 07:07:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23474 for ; Mon, 4 Mar 2002 07:07:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20667; Mon, 4 Mar 2002 07:07:28 -0500 (EST) Message-Id: <200203041207.HAA20667@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 04 Mar 2002 07:07:28 -0500 Subject: [NSIS] I-D ACTION:draft-choi-ipv6-signaling-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Features of IPv6 Signaling Author(s) : J. Choi et al. Filename : draft-choi-ipv6-signaling-01.txt Pages : 15 Date : 01-Mar-02 In this memo, we describe the features of IPv6 signaling protocol. We also discuss the related issues and the need of new signaling protocol. We will explain the implementation issues in some detail A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-choi-ipv6-signaling-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-choi-ipv6-signaling-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020301135236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-choi-ipv6-signaling-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-choi-ipv6-signaling-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135236.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 07:36:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22026 for ; Mon, 4 Mar 2002 07:36:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25540 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 07:36:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24544; Mon, 4 Mar 2002 07:24:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24510 for ; Mon, 4 Mar 2002 07:24:18 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21533 for ; Mon, 4 Mar 2002 07:24:14 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16hrVo-0005dp-00; Mon, 04 Mar 2002 13:24:16 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16hrVn-0000dL-00; Mon, 04 Mar 2002 13:24:15 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g24COFW28000; Mon, 4 Mar 2002 13:24:15 +0100 Message-Id: <200203041224.g24COFW28000@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Hemant.Chaskar@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Automatic Discovery of QCs In-Reply-To: Message from Hemant.Chaskar@nokia.com of "Fri, 01 Mar 2002 17:07:18 EST." References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 04 Mar 2002 13:24:15 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Hemant, > In the interest of simplicity, allow me to turn around the blurred requirement. Can we actually say that > > "NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities." Simplicity is usually fine. My proposal had also the objective for simplification: the end-system/user shouldn't have to explicitly know/ configure the QC address. I thought that explicit discovery lets the user/end-system decide which QC should be used subsequently and it might also be a good thing in mobile environments. So I'm not really sure whether we should "exclude" explicit discovery this way. Therefore, I like John's statement: *| I favor a minimal approach, which allows service providers *| to implement more complex schemes - but yet still allows the *| minimal approach to work. > In other words, can't a host just shoot an NSIS signal towards the > network (destined to a well-known IP address for example or identifiable > by some field in the packet header) > and the routers can forward it to appropriate QCs in their network > domain. This sounds like using anycast address mechanisms. In my proposal, the host can send a QC solicitation request to a well-known multicast address. QCs send back information about themselfs. So it would be the end-system/user that can choose between alternatives (meaning a bit more complexity). By using "magic" forwarding, you have to accept the network's decision. What if the host is located in the range of two domains? Towards which domain is the request forwarded? Regards, Roland > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: Friday, March 01, 2002 3:56 PM > To: bless@tm.uka.de; nsis@ietf.org > Subject: RE: [NSIS] Automatic Discovery of QCs > > > Hi Roland, > > > > I would add another point to section 5.3 of draft-ietf-nsis-req-00: > > 5.3.8 Automatic discovery of QoS Controllers. > > This will allow some degree of auto configuration which can > > be useful in many scenarios. For instance, hosts (especially > > mobile ones) will be able to find out the next adjacent > > Could we blur your requirement somewhat? My suggest is: > > 5.3.8 Discovery of QoS Controllers > > NSIS SHOULD support a simple mechanism for discoverying > QoS entities. > > This means that, for example, on-path signaling could be one > option - meaning that as the host signals the network, the > network can eavesdrop and setup signaling to off-path > QoS entities; or access routers could proxy the QoS > controllers and interact with them and allow some > sort of seamoby context transfer for mobility, etc. > > For me, a key issue with this topic is how does an end user > discover QoS entities? Does it employ a protocol like SLP, > or DNS? Does the network do it via a proxy model; is there > some pre-configured home QoS entitity that negotiates > with the visitied network... or something else? > > I favor a minimal approach, which allows service providers > to implement more complex schemes - but yet still allows the > minimal approach to work. > > John -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 08:33:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23699 for ; Mon, 4 Mar 2002 08:33:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29171 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 08:34:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27725; Mon, 4 Mar 2002 08:20:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27694 for ; Mon, 4 Mar 2002 08:20:56 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23150 for ; Mon, 4 Mar 2002 08:20:51 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g24DKqZc013897 for ; Mon, 4 Mar 2002 14:20:52 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 14:20:47 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 14:20:19 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Date: Mon, 4 Mar 2002 14:20:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John I agree with your proposal. However, I think that it will be difficult to specify if a requirement is a MUST, SHOULD or MAY if we don't group the requirements (according to the modularity requirement). Regarding terminology: Do you also mean that the definition of the QoS initiator and QoS Controller will also be moved to the "framework" draft. Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 4 maart 2002 8:25 To: Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements Hi Georios, > I think there is a disagreement on how the requirements > are separated/grouped. > In this way we define some kind of QoS toolbox, that can be > used in a flexible way by e.g., a network provider. > For example a network provider could choose to implement > the QoS complexity level (2) in a border router. Some other > network provider may choose to implement the QoS complexity > level (3) into a border router; > The same holds for other network entities; My opinion would be that the framework document can do this. The framework doc will discuss the NSIS architecture & could apply the requirements to the architecture. I think the disagreement on the grouping / seperation of requirements are a bit pointless - we should be focusing on the requirements. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 4 10:08:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27786 for ; Mon, 4 Mar 2002 10:08:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04509 for nsis-archive@odin.ietf.org; Mon, 4 Mar 2002 10:09:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03175; Mon, 4 Mar 2002 09:55:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03146 for ; Mon, 4 Mar 2002 09:55:50 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26984 for ; Mon, 4 Mar 2002 09:55:47 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16htsT-0000Rq-00; Mon, 04 Mar 2002 15:55:49 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16htsT-0004YH-00; Mon, 04 Mar 2002 15:55:49 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g24EtmW28920; Mon, 4 Mar 2002 15:55:48 +0100 Message-Id: <200203041455.g24EtmW28920@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Automatic Discovery of QCs In-Reply-To: Message from john.loughney@nokia.com of "Fri, 01 Mar 2002 22:56:15 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE2E@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DE2E@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Mar 2002 15:55:48 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > > I would add another point to section 5.3 of draft-ietf-nsis-req-00: > > 5.3.8 Automatic discovery of QoS Controllers. > > This will allow some degree of auto configuration which can > > be useful in many scenarios. For instance, hosts (especially > > mobile ones) will be able to find out the next adjacent > > Could we blur your requirement somewhat? My suggest is: > > 5.3.8 Discovery of QoS Controllers > > NSIS SHOULD support a simple mechanism for discoverying > QoS entities. This sounds better. > This means that, for example, on-path signaling could be one > option - meaning that as the host signals the network, the > network can eavesdrop and setup signaling to off-path > QoS entities; or access routers could proxy the QoS > controllers and interact with them and allow some > sort of seamoby context transfer for mobility, etc. > > For me, a key issue with this topic is how does an end user > discover QoS entities? Does it employ a protocol like SLP, > or DNS? Does the network do it via a proxy model; is there > some pre-configured home QoS entitity that negotiates > with the visitied network... or something else? This was the issue I tried to bring up. In my [maybe too concrete and not simple enough] proposal, the signaling protocol supports the discovery directly. > I favor a minimal approach, which allows service providers > to implement more complex schemes - but yet still allows the > minimal approach to work. This would be fine. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 5 05:04:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22374 for ; Tue, 5 Mar 2002 05:04:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA22549 for nsis-archive@odin.ietf.org; Tue, 5 Mar 2002 05:04:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21633; Tue, 5 Mar 2002 04:49:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21602 for ; Tue, 5 Mar 2002 04:49:02 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22032 for ; Tue, 5 Mar 2002 04:48:59 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA06293 for ; Tue, 5 Mar 2002 10:48:55 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA18149 for ; Tue, 5 Mar 2002 10:48:47 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 10:49:05 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A01265640@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: nsis@ietf.org Subject: RE: [NSIS] Automatic Discovery of QCs Date: Tue, 5 Mar 2002 10:49:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Hemant and Roland, John wrote: > 5.3.8 Discovery of QoS Controllers > > NSIS SHOULD support a simple mechanism for discoverying > QoS entities. Hemant wrote: >"NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities." I could live with either of the two, although the second alternative might be interpreted to actually exclude explicit discovery? However, I think both implicit and explicit discovery are important: On the one hand it is important to have a simple, implicit, default / fall back mechanism for sending NSIS signaling mesages when the address of the next QC is not known explicitly. The address of the next QC might not be available for example because a mobile host attaching to a foreign network doesnt know the local QC, nor should it be burdened with finding out. Or else there was a network failure and QC info got lost, or simply because each router on the data path is a QC (as in IntServ) and no explicit addressing is necessary. In this case the signaling packets should travel on the data path until it encounters a QC which knows the next QC and addresses the signaling explicitly. This QC on the data path would ideally be the access router or edge router as has been suggested - obviously for the fallback case it makes sense to have some routers on the data path which are NSIS aware (= QCs). On the other hand, having each router on the data path look at the NSIS signaling message is not scalable. For optimizing both signaling path and processing load on routers, it is desireable to be able to explicitly address the next QC. Plus the next QC might not automatically be on the data path, either because some kind of QoS routing is being used, or because the next QC is a bandwidth broker. So why not go the same way as RSVP: the default is on-path signaling, with the signaling destination as the destination address and Router Alert Option turned on. However, when the next QC controller is known (by some means e.g. such as have been discussed on the mailing list), the signaling is addressed explicitly, just as in aggregate RSVP the Deaggregator is addressed explicitly, for tunneling per-flow signaling messages accross the aggregation region. (This is also what we suggest in our framework draft http://www.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt.) Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 5 08:44:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29018 for ; Tue, 5 Mar 2002 08:44:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03928 for nsis-archive@odin.ietf.org; Tue, 5 Mar 2002 08:44:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03322; Tue, 5 Mar 2002 08:31:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03289 for ; Tue, 5 Mar 2002 08:31:20 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28546 for ; Tue, 5 Mar 2002 08:31:19 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g25DUno20422; Tue, 5 Mar 2002 14:30:49 +0100 (MET) To: nsis@ietf.org Cc: maarten.buchli@alcatel.be, danny.goderis@alcatel.be, robert.hancock@roke.co.uk, cornelia.kappler@icn.siemens.de X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 5 Mar 2002 14:30:46 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/05/2002 14:30:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] section on QI/QC and QI/QC terminology Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, We have been thinking about the QI/QC definitions and we have tried to arrange the QC/QI functional entities in a logical relation that covers the use case scenarios that have been proposed so far. From this, we hope to derive clearer definitions. The general logical relationships are depicted below (for simplicity, only signaling relations are drawn) +--+ (a) +--+ (a) +--+ (a) +---+ +->|QI|---->|QC|---------------->|QC|---->| QR|--+ QI,QC,QR roles for e2e QoS protocol | +--+ /+--+\ /+--+\ +---+ | | / \ / \ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this pictures we clearly distinguish two applications for the NSIS protocol: (a) NSIS as end-to-end QoS signaling protocol (b) NSIS as local QoS signaling protocol Local, in this case, is defined as local to a QoS domain. A QoS domain is defined as a contiguous part of the network supporting the same QoS technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS actually competes with other technologies offering local QoS, such as PDP, RSVP, ... The above picture seems to suggest an out-of-band approach but this is not the case. The QCs can be implemented in a distributed way and redrawing the picture then gives a different view. +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| QI,QC,QR roles for e2e QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ ^ v ^ v ^ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this case, it is clear that an in-band solution is also supported. The end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a router. Note that in this picture, the signaling in the access is done with a local QoS protocol. This can be either an existing protocol, or the NSIS protocol in its role of local QoS signaling mechanism. This leads to the following requirements: (a) If an NSIS protocol is only used end-to-end, then mobility need not be supported (b) If an NSIS protocol is used as a local QoS signaling mechanism then mobility must be supported, both on the QI-QC and QC-QC interface (c) If the same protocol is desired in (a) and (b), the protocol should be modular and the mobility aspects need to be separable from the rest Both of the above scenarios assume that the host is not NSIS-aware. This is a reasonable assumption in a first phase. In a later stage, when hosts are NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling technology! This allows this case to be backwards compatible with the above scenarios. It means that (b) in the access is an NSIS protocol. It also means that the host will always trigger the local QoS signaling mechanism. This suggests the following definitions for the QI, QC, QR - QoS Initiator: Network entity, located at the boundary of a QoS domain, responsible for initiating a (local or end-to-end) QoS mechanism. If it is the QI of a local protocol, it can be triggered by higher layers (applications or end-to-end QoS Controller). If it is the QI of an end-to-end protocol, it can be triggered by applications or by the QoS Receiver of a local QoS signaling mechanism. - QoS Controller: Network entity responsible for interpreting and implementing the signalled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by a QI or another QC. -QoS Receiver: Network entity, located at the boundary of a QoS domain, responsible for terminating a (local or end-to-end) QoS mechanism. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol. If this can be accepted by the NSIS community, we propose to add this text to the requirements document as a clarification of the QI/QC model that is used there. Hope this helps, Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 6 07:11:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03676 for ; Wed, 6 Mar 2002 07:10:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05428 for nsis-archive@odin.ietf.org; Wed, 6 Mar 2002 07:11:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04338; Wed, 6 Mar 2002 06:54:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04300 for ; Wed, 6 Mar 2002 06:54:18 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02918; Wed, 6 Mar 2002 06:54:09 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26BsFZ07921; Wed, 6 Mar 2002 13:54:15 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 13:54:04 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 13:54:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Mar 2002 13:54:04 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B32@esebe004.NOE.Nokia.com> Thread-Topic: Tentative agenda for NSIS Thread-Index: AcHFBZ1eNJ+PUPZfTgi32PWnkQB1qw== To: Cc: X-OriginalArrivalTime: 06 Mar 2002 11:54:04.0744 (UTC) FILETIME=[9D499C80:01C1C505] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA04301 Subject: [NSIS] Tentative agenda for NSIS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Next Steps in Signaling - IETF 53 TUESDAY, March 19, 2002 0900-1130 Morning Sessions Agenda bashing - John Loughney 10 min Requirements for QoS Signaling Protocols - Markus Brunner 45 min http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-00.txt Issues on NSIS QoS Signalling Requirements - David Partain 10 min http://www.ietf.org/internet-drafts/draft-partain-nsis-requirements-00.txt NSIS Scope Recommendations - Tricci So - 5 min http://www.ietf.org/internet-drafts/draft-so-nsis-scope-00.txt NSIS QoS Signaling Requirements from a Multi-access Wireless Perspective - Gabor Fudor - 10 min http://www.ietf.org/internet-drafts/draft-fodor-reqts-cellular-netwks-00.txt QoS signaling requirements, interfaces and architecture - Sven Van Den Bosch - 10 min http://www.ietf.org/internet-drafts/draft-buchli-nsis-req-00.txt NSIS Framework Issues - Robert Handcock 10 min http://www.ietf.org/internet-drafts/draft-hancock-nsis-framework-00.txt Discussion - all - 30 min Next Steps - all - 20 min _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 6 11:59:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18212 for ; Wed, 6 Mar 2002 11:59:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23972 for nsis-archive@odin.ietf.org; Wed, 6 Mar 2002 11:59:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23374; Wed, 6 Mar 2002 11:46:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23345 for ; Wed, 6 Mar 2002 11:46:27 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17354 for ; Wed, 6 Mar 2002 11:46:22 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 17:46:22 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 6 Mar 2002 17:46:25 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBB5@TMS041MB.tcad.telia.se> Thread-Topic: section 3.5 in nsis-req-00.txt Thread-Index: AcHFLu3uC2sbxkguSvu2i7fsbm9aKA== To: X-OriginalArrivalTime: 06 Mar 2002 16:46:22.0510 (UTC) FILETIME=[729C54E0:01C1C52E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23346 Subject: [NSIS] section 3.5 in nsis-req-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit All, I have read through the requirement draft and I have some comments. In general, there are some detailed requirements that I do not agree to, but there is one high-level issue that I want to address first. In draft-partain we had some discussions relating to section 3.5 (scenario 5) about negotiations over admin boundaries. I recommended this area to be removed from the draft-partain and the requirements that came from this area was removed in the final version. The reason for this was one: making the negotiation between domains automated is, in my opinion, too early for standardisation and this will not be needed for awhile yet. I know the history of this work (Aquila, Tequila, QBBAC and Eurescom-projects) and have been participating in some of them. They have been doing great and solid work but the fact remains - as an operator, I do not see the need for making this automated for the time being. On this area I find myself thinking - leave this to ISPs and operators to take a first step, we (as operators) will know when we run into problems as time progress. Starting standardisation now might only force operators into a (business) model they might not see fit. Even to agree about what negotiation should take place between operators will probably take quite awhile. I have two alternative suggestions 1) either the SLS work is moved into a suitable IRTF-wg until it is ready for standardisation 2) or the SLS work continues under a separate requirement/framework document. I hope I have not offended people bringing this discussion up, but my feeling is that the grouping together every kind of signaling that we can think of into NSIS will delay the work substantially. In the end of this email I want to refer to a presentation Van Jacobson once did, where he talked about complexity in design. There were three problems he talked about. In increasing order of difficulty: "Getting faster, getting bigger, crossing boundaries". Minimizing the difference between a boundary and a core router will make the boundary easier to cross. I suggest relying on the work already done by the diffserv-wg and make minimal changes to its architecture in order to support a call-blocking service. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 02:59:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13419 for ; Thu, 7 Mar 2002 02:59:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03298 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 02:59:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02554; Thu, 7 Mar 2002 02:43:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02523 for ; Thu, 7 Mar 2002 02:42:59 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13046 for ; Thu, 7 Mar 2002 02:42:52 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 7 Mar 2002 08:40:48 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 08:42:19 +0100 Message-Id: From: "Geib, Ruediger" To: Anders.P.Bergsten@telia.se Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Thu, 7 Mar 2002 08:42:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA02524 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > The reason for this was one: making the negotiation between > domains automated is, in my opinion, too early for > standardisation and this will not be needed for awhile yet. I > know the history of this work (Aquila, Tequila, QBBAC and > Eurescom-projects) and have been participating in some of > them. They have been doing great and solid work but the fact > remains - as an operator, I do not see the need for making > this automated for the time being. You may be right with regard to signalling between unrelated ISP's. Related ISPs may very well be interested in automated cross domain QoS services. This holds for my company. So I disagree. But maybe you should clarify your thoughts on what should not be negotiated beween carriers. If your idea is not to negotiate services (i.e. the service definition), then I'm with you. I'd however like to specify a signaling interface allowing to switch "well defined" services. "Well defined" may be limited to the cloud of the related carriers. I don't believe that this requires a protocol substantially different from the NSIS one. (You were mentioning SLS negotiation, maybe you meant what I phrased here and I didn't get you.) > I suggest relying on the work already done by the diffserv-wg > and make minimal changes to its architecture in order to > support a call-blocking service. Which I support. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 03:45:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14566 for ; Thu, 7 Mar 2002 03:45:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06262 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 03:45:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05662; Thu, 7 Mar 2002 03:31:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05633 for ; Thu, 7 Mar 2002 03:31:19 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14345 for ; Thu, 7 Mar 2002 03:31:14 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 09:31:17 +0100 content-class: urn:content-classes:message Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Mar 2002 09:31:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBB7@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHFq6ONoQ3KsqteS5uyog5p6pBzQAAAPcdQ To: Cc: X-OriginalArrivalTime: 07 Mar 2002 08:31:17.0828 (UTC) FILETIME=[73A75040:01C1C5B2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA05634 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Ruediger, > But maybe you should clarify your thoughts on what should not > be negotiated beween carriers. If your idea is not to > negotiate services (i.e. the service definition), then I'm > with you. Agreed. This was one of the things, because even agreeing to a definition would take quite a while I assume [if we could, that would be great though!]. I mean, having looked at SLA's different companies offer, the definitions of for example delay varies substantially (mean, median, 90% percentil, max, and even how you sample/prove the metric differs). My view on SLAs and their relation to signaling here at nsis is the following. (simplified for clarity, lots of negotiation may take place in the business relation between the carriers) (imaging the following) - cloud A - cloud B where B is the customer of cloud A. Well defined SD's will then be sent from the provider (A) to the customer (B). This is done when the business people of A approach B, thus IMO outside the scope of signaling (currently). Then the customer will buy an aggregated amount of bandwidth into A. Also outside the scope, cause this is a business agreement. At this point the mapping between A's services and B's services can be set up in either of the edge routers (through CLI, COPS, ...). By mapping I mean mapping of DSCP's. Thus, what I see outside the scope of nsis is the following (which I, maybe wrongly, assumed was stated in scenario 5): - Service definitions - Exchange of service definitions - Query of services (eg, can I buy a service of 10 ms delay to destination Y from you?) - TCS negotiations (eg, "can I buy 10 Mbit/s to destination Y", "No, try 5", "ok"), especially over multiple domains. (I separate TCS negotiations from signaling because the TCS exchange that I mean is the business contract and the signaling is a resource allocation from the bought capacity). - Exchange of billing information What I believe is in scope is: - nsis must allow dscp's (or whatever constitutes the 'service') to be mapped. This should be under the control of the carrier. - nsis must allow the carrier to set up the bandwidth allowed to be passed between two carriers. nsis must also use this value when doing CAC. - nsis must allow an edge to store accounting information (but I would be happy to restrict this to aggregate bandwidth that has crossed the link between two carriers) I may have forgot a couple of requirements. > I'd however like to specify a signaling interface > allowing to switch "well defined" services. What do you mean by "switch" in this case? (just wanted to understand what you want to do) A short comment in the end - I am not saying that SD and its exchange is not important. I see a lot of benefits of automating this. We are working on this internally, where we have moved the SD exchange into BGP (we have an implementation working on a test-bed). I still think it is research, though. hoped that clarified my stand-point. best regards, Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 06:39:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17690 for ; Thu, 7 Mar 2002 06:39:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16258 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 06:39:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15178; Thu, 7 Mar 2002 06:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15153 for ; Thu, 7 Mar 2002 06:23:47 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17240 for ; Thu, 7 Mar 2002 06:23:42 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 11:21:46 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA1B6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Anders.P.Bergsten@telia.se'" , Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Thu, 7 Mar 2002 11:21:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi all, This is an important set of questions about NSIS scope. I support the view that NSIS is not (should not be) about all signalling protocols associated with QoS including SLA negotiation and so on (apart from anything else, it's probably not a Transport Area subject). On the other hand, it seems clear that the actual QoS signalling (between QI/QC/Qwhatever TBD) for a flow is only meaningful (e.g. will only be taken account of) if it takes place within some sort of context which covers AAA aspects. (I think everything in the emails below can be considered AAA, although it's AAA in the context of network-network relationships rather than user-network relationships.) What isn't clear (at least to me (at least in a concrete form)) is where the boundary between a) information in this 'context' which is pre-existing b) information that is exchanged as part of the NSIS QoS request signalling actually lies, and how signalling (part of (b)) actually refers to the context (part of (a)). [In our framework draft, we considered the almost-equivalent concept of splitting the NSIS signalling into two 'phases', with the intention of making the second phase lightweight, and maybe making the first phase an extension of other protocols, especially to piggyback on existing user authentication and authorisation protocols. So, the minimal solution then makes the registration phase optional/out of scope. However, we still need to determine what functions it is 'assumed' to have carried out.] Some particular concrete questions: *) can the cross-reference between signalling and context be done just by referring to DSCPs? (the number of combinations of AAA attributes between two domains might be > 2^6, or you might not want to do remarking on egress, or use DiffServ at all, or ...) Maybe some other identifier space/referency type is needed? Or maybe the identifier space is opaque to NSIS and agreed bilaterally? (and therefore not part of the data that is transported end-to-end)? *) if the reference is what covers these aspects, does the reference need to be secured? and if so, is it part of NSIS to work out how to secure it? or is that also part of a slightly broader 'opaque context reference' which might or might not be secure in itself? [It may not be a coincidence that this approach starts to look very much like the opaque policy-object transport capability of RSVP. In which case, it would be interesting if any of the RSVP-analysis papers raised any issues with this approach, or whether we should be happy to take it as a model which needs just limited generalisation or simplification...] To put it more directly: are there requirements for NSIS in this area that go beyond what is already done for RSVP by rfc2750 section 3, and if not, should NSIS be scoped to say that it 'hooks' into policy etc. systems the same way RFC2750 says RSVP does - or is something different needed? Robert H. > -----Original Message----- > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > Sent: 07 March 2002 08:31 > To: Ruediger.Geib@t-systems.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Ruediger, > > > But maybe you should clarify your thoughts on what should not > > be negotiated beween carriers. If your idea is not to > > negotiate services (i.e. the service definition), then I'm > > with you. > Agreed. This was one of the things, because even agreeing to > a definition would take quite a while I assume [if we could, > that would be great though!]. I mean, having looked at SLA's > different companies offer, the definitions of for example > delay varies substantially (mean, median, 90% percentil, max, > and even how you sample/prove the metric differs). > > My view on SLAs and their relation to signaling here at nsis > is the following. (simplified for clarity, lots of > negotiation may take place in the business relation between > the carriers) > > (imaging the following) > - cloud A - cloud B > where B is the customer of cloud A. > > Well defined SD's will then be sent from the provider (A) to > the customer (B). This is done when the business people of A > approach B, thus IMO outside the scope of signaling > (currently). Then the customer will buy an aggregated amount > of bandwidth into A. Also outside the scope, cause this is a > business agreement. > > At this point the mapping between A's services and B's > services can be set up in either of the edge routers (through > CLI, COPS, ...). By mapping I mean mapping of DSCP's. > > Thus, what I see outside the scope of nsis is the following > (which I, maybe wrongly, assumed was stated in scenario 5): > - Service definitions > - Exchange of service definitions > - Query of services (eg, can I buy a service of 10 ms delay > to destination Y from you?) > - TCS negotiations (eg, "can I buy 10 Mbit/s to destination > Y", "No, try 5", "ok"), especially over multiple domains. (I > separate TCS negotiations from signaling because the TCS > exchange that I mean is the business contract and the > signaling is a resource allocation from the bought capacity). > - Exchange of billing information > > What I believe is in scope is: > - nsis must allow dscp's (or whatever constitutes the > 'service') to be mapped. This should be under the control of > the carrier. > - nsis must allow the carrier to set up the bandwidth allowed > to be passed between two carriers. nsis must also use this > value when doing CAC. > - nsis must allow an edge to store accounting information > (but I would be happy to restrict this to aggregate bandwidth > that has crossed the link between two carriers) > > I may have forgot a couple of requirements. > > > I'd however like to specify a signaling interface > > allowing to switch "well defined" services. > What do you mean by "switch" in this case? (just wanted to > understand what you want to do) > > A short comment in the end - I am not saying that SD and its > exchange is not important. I see a lot of benefits of > automating this. We are working on this internally, where we > have moved the SD exchange into BGP (we have an > implementation working on a test-bed). I still think it is > research, though. > > hoped that clarified my stand-point. > > best regards, > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 08:09:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21892 for ; Thu, 7 Mar 2002 08:09:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21695 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 08:09:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20376; Thu, 7 Mar 2002 07:53:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20347 for ; Thu, 7 Mar 2002 07:53:14 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21043 for ; Thu, 7 Mar 2002 07:53:11 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 7 Mar 2002 13:26:05 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 13:27:35 +0100 Message-Id: From: "Geib, Ruediger" To: Anders.P.Bergsten@telia.se Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Thu, 7 Mar 2002 13:27:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA20348 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Anders, thanks for your clarification. I largely agree with your postions. Some comments in line. Regards, Rüdiger > Thus, what I see outside the scope of nsis is the following > (which I, maybe wrongly, assumed was stated in scenario 5): > - Service definitions > - Exchange of service definitions > - Query of services (eg, can I buy a service of 10 ms delay > to destination Y from you?) > - TCS negotiations (eg, "can I buy 10 Mbit/s to destination > Y", "No, try 5", "ok"), especially over multiple domains. > (I separate TCS negotiations from signaling because the > TCS exchange that I mean is the business contract and the > signaling is a resource allocation from the bought > capacity). > - Exchange of billing information Agreed. I'd however allow a query to find out whether a certain service (e.g. called "Premium") is supported by a domain. This assumes that the terminal knows the service definition and wants to check whether the interface it is attached to supports this service. This may be done by AAA, as Robert suggested in his reply. > > What I believe is in scope is: > - nsis must allow dscp's (or whatever constitutes the > 'service') to be mapped. This should be under the > control of the carrier. > - nsis must allow the carrier to set up the bandwidth allowed > to be passed between two carriers. nsis must also use > this value when doing CAC. > - nsis must allow an edge to store accounting information > (but I would be happy to restrict this to aggregate > bandwidth that has crossed the link between two carriers) Agreed too. And I really appreciate that you restrict the only service parameter to be communicated by signaling to bandwidth. Keep things simple! > > I'd however like to specify a signaling interface > > allowing to switch "well defined" services. > What do you mean by "switch" in this case? (just wanted to > understand what you want to do) Switching here means automated negotiation of service specific resources between domains. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 08:17:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22318 for ; Thu, 7 Mar 2002 08:17:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22110 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 08:17:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21237; Thu, 7 Mar 2002 08:01:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21190 for ; Thu, 7 Mar 2002 08:01:30 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21464 for ; Thu, 7 Mar 2002 08:01:27 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for nsis@ietf.org; Thu, 7 Mar 2002 13:41:40 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 13:43:10 +0100 Message-Id: From: "Geib, Ruediger" To: nsis@ietf.org Date: Thu, 7 Mar 2002 13:43:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21191 Subject: [NSIS] Interdomain QoS signalling scenario Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Anders and I provided some discussions. Here's some more information to clarify my views: A service is pre-defined by e.g. loss, delay, burst size or other parameters. Performance figures related to reference configuration are given thus allowing flexible service implementation architectures. This results in a service definition X. User requests a certain amount of bandwidth for service FOO. No negotiation on FOO's characteristics. No negotiation of the requested bandwidth (the requested value or nothing). The latter reflects my personal preference. The more negotiation of service parameters the more complex is the implementation. Anders ideas may not be far from that. He suggested to limit the service related signaling to bandwidth and to use DiffServ ideas. DiffServ suggested to define Per Domain Behaviours as I scetched above (ITU uses the same methodology). I look at service definition as out of scope of NSIS. Signaling mechanisms must be flexible to support privately defined services as well as publicly defined services. Queries on a service supported by a domain must be possible. By that I only mean a request whether FOO is supported on the interface the requestor is connected to. This is not a parameter negotioation. Should be easy if public services are queried. In the case of private services the terminal probably must be customer of the provider to get a response. If not, the service definition and use conditions were to be communicated to the terminal. I wouldn't want to specify this. The query mechanism would be supported by AAA features. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 08:31:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23057 for ; Thu, 7 Mar 2002 08:31:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22792 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 08:31:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22027; Thu, 7 Mar 2002 08:15:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21996 for ; Thu, 7 Mar 2002 08:15:17 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22226 for ; Thu, 7 Mar 2002 08:15:13 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 14:15:20 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 7 Mar 2002 14:15:20 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBB9@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHFyl1RI0yOmxtmT6yBX89p2cT1qgAA98rg To: , Cc: X-OriginalArrivalTime: 07 Mar 2002 13:15:20.0593 (UTC) FILETIME=[21EEE010:01C1C5DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21997 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Robert, > On the other hand, it seems clear that the actual QoS > signalling (between QI/QC/Qwhatever TBD) for a flow is only > meaningful (e.g. will only be taken account of) if it takes > place within some sort of context which covers AAA aspects. Agreed. > What isn't clear (at least to me (at least in a concrete > form)) is where the boundary between > a) information in this 'context' which is pre-existing > b) information that is exchanged as part of the NSIS QoS > request signalling > actually lies, and how signalling (part of (b)) actually > refers to the context (part of (a)). > [In our framework draft, we considered the almost-equivalent > concept of splitting the NSIS signalling into two 'phases', > with the intention of making the second phase lightweight, > and maybe making the first phase an extension of other > protocols, especially to piggyback on existing user > authentication and authorisation protocols. So, the minimal > solution then makes the registration phase optional/out of > scope. However, we still need to determine what functions it > is 'assumed' to have carried out.] Yes, I agree definately to your last sentence. I would assume that all business agreements between carriers are in place before the nsis-protocol kicks in. This means for me that: 1) the services have been described and exchanged by the carriers. 2) the needed mapping between services is understood and configured in the edge router (by some mean) 3) billing aspects are agreed upon. This will, IMHO, be done pretty much like today, where a diff in incoming/outgoing bandwidth utilization is the basis for billing. This means that the nsis protocol (or diffserv mibs) needs to provides the carrier with (some) aggregated bandwidth usage per service. 4) the bandwidth bought for an explicit service is known and configured in the edge routers. (for signaling to work upon). 5) the policy about what the customer is allowed to do is described in some form of policy language (similar to RPSL for routing) and instantiated in the edge router (through e.g. COPS-PR) (coming to think of it, the 'service' is probably describe here and not only by the DSCP, thus the accounting data needs to be couple with this and not with the dscp.) Furthermore, I think it is safe to assume that the carrier have taken approriate steps to assure that the blocking rate of 'calls' (or breach of the SLA) is minimized. How we assure it is up to us as a carrier. Thus, the likelihood that a signaling message comes through is generally very low (10^-x). I would also assume that the services that are being sold are in line with diffserv (ie DSCPs are the minimal level of aggregation). [you can make a similar analysis for the end-customer to ISP interface and land in a similar list of pre-requisitions (some parts different though)] You asked how this was interconnected with the end-to-end signaling: I would say pretty much like RSVP does it. Either with a explicit or an implicit policy attribut (the latter would mean that the router must deduce the policy from the IP-header). > Some particular concrete questions: > *) can the cross-reference between signalling and context be > done just by referring to DSCPs? No, to make it generic it should probably be described either by the IP-header (the implicit method) or by an opaque policy attribut inside the packet (the explicit method that RSVP uses). I did some (very fast) analysis in the carrier to carrier business and, I think, without loss of generality, you can assume that the policies is based on the IP-header (ie very similar to the COPS-PR work already finished). This implements all I came to think of in the carrier-to-carrier business. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 08:32:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23175 for ; Thu, 7 Mar 2002 08:32:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22988 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 08:32:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22156; Thu, 7 Mar 2002 08:17:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22124 for ; Thu, 7 Mar 2002 08:17:52 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22337 for ; Thu, 7 Mar 2002 08:17:49 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 14:17:56 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 7 Mar 2002 14:17:56 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCBD2@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHF1v48BPqzMNfJTA2k1O33Y2zd3QAA7Haw To: Cc: X-OriginalArrivalTime: 07 Mar 2002 13:17:56.0236 (UTC) FILETIME=[7EB41CC0:01C1C5DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA22125 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Rudiger, thanks for the clarification. I do not think your proposal would add very much overhead to the nsis work, so I have no objections to it. It may prove useful sometimes. Anders > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: den 7 mars 2002 13:27 > To: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98 > Cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Anders, > > thanks for your clarification. I largely agree with your > postions. Some comments in line. > > Regards, Rüdiger > > > > Thus, what I see outside the scope of nsis is the following > > (which I, maybe wrongly, assumed was stated in scenario 5): > > - Service definitions > > - Exchange of service definitions > > - Query of services (eg, can I buy a service of 10 ms delay > > to destination Y from you?) > > - TCS negotiations (eg, "can I buy 10 Mbit/s to destination > > Y", "No, try 5", "ok"), especially over multiple domains. > > (I separate TCS negotiations from signaling because the > > TCS exchange that I mean is the business contract and the > > signaling is a resource allocation from the bought > > capacity). > > - Exchange of billing information > > Agreed. I'd however allow a query to find out whether a > certain service (e.g. called "Premium") is supported by a > domain. This assumes that the terminal knows the service > definition and wants to check whether the interface it is > attached to supports this service. This may be done by AAA, > as Robert suggested in his reply. > > > > > What I believe is in scope is: > > - nsis must allow dscp's (or whatever constitutes the > > 'service') to be mapped. This should be under the > > control of the carrier. > > - nsis must allow the carrier to set up the bandwidth allowed > > to be passed between two carriers. nsis must also use > > this value when doing CAC. > > - nsis must allow an edge to store accounting information > > (but I would be happy to restrict this to aggregate > > bandwidth that has crossed the link between two carriers) > > Agreed too. And I really appreciate that you restrict the > only service parameter to be communicated by signaling to > bandwidth. Keep things simple! > > > > > I'd however like to specify a signaling interface > > > allowing to switch "well defined" services. > > > What do you mean by "switch" in this case? (just wanted to > > understand what you want to do) > > Switching here means automated negotiation of service > specific resources between domains. > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 10:18:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29446 for ; Thu, 7 Mar 2002 10:18:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01286 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 10:18:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28962; Thu, 7 Mar 2002 09:59:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28929 for ; Thu, 7 Mar 2002 09:59:16 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28200 for ; Thu, 7 Mar 2002 09:59:12 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g27EwY618309; Thu, 7 Mar 2002 15:58:38 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: Anders.P.Bergsten@telia.se Cc: Ruediger.Geib@t-systems.com, nsis@ietf.org, danny.goderis@alcatel.be, maarten.buchli@alcatel.be X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 7 Mar 2002 15:58:32 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/07/2002 15:58:37 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA28930 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Anders, Ruediger, all, I have been following your discussion with interest and I particularly recall the following statements/conclusions: - automated service negotiation between domains is not a first phase requirement - service capabilities of a domain may be exchanged ('advertised') - nsis signaling should preferably be simple, maybe only involve bandwidth signaling - service implementation is a local matter I think these map very well with the two-level admission control described in draft-buchli-nsis-req-00.txt. Here it is proposed that a QC has an interface with a NMS that provides certain services. How these are implemented is shielded from the QC by means of an SLS interface (local SLS, not inter-domain SLS). As you said, this interface may not be in scope of nsis. The QC then processes nsis signaling and does very simple admission control, e.g. only based on the requested bandwidth. Given your discussion about these issues, do you think that our model captures your requirements? Thanks, Sven. Anders.P.Bergsten@telia.se on 07/03/2002 14:17:56 To: Ruediger.Geib@t-systems.com cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] section 3.5 in nsis-req-00.txt : Rudiger, thanks for the clarification. I do not think your proposal would add very much overhead to the nsis work, so I have no objections to it. It may prove useful sometimes. Anders > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: den 7 mars 2002 13:27 > To: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98 > Cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Anders, > > thanks for your clarification. I largely agree with your > postions. Some comments in line. > > Regards, Rüdiger > > > > Thus, what I see outside the scope of nsis is the following > > (which I, maybe wrongly, assumed was stated in scenario 5): > > - Service definitions > > - Exchange of service definitions > > - Query of services (eg, can I buy a service of 10 ms delay > > to destination Y from you?) > > - TCS negotiations (eg, "can I buy 10 Mbit/s to destination > > Y", "No, try 5", "ok"), especially over multiple domains. > > (I separate TCS negotiations from signaling because the > > TCS exchange that I mean is the business contract and the > > signaling is a resource allocation from the bought > > capacity). > > - Exchange of billing information > > Agreed. I'd however allow a query to find out whether a > certain service (e.g. called "Premium") is supported by a > domain. This assumes that the terminal knows the service > definition and wants to check whether the interface it is > attached to supports this service. This may be done by AAA, > as Robert suggested in his reply. > > > > > What I believe is in scope is: > > - nsis must allow dscp's (or whatever constitutes the > > 'service') to be mapped. This should be under the > > control of the carrier. > > - nsis must allow the carrier to set up the bandwidth allowed > > to be passed between two carriers. nsis must also use > > this value when doing CAC. > > - nsis must allow an edge to store accounting information > > (but I would be happy to restrict this to aggregate > > bandwidth that has crossed the link between two carriers) > > Agreed too. And I really appreciate that you restrict the > only service parameter to be communicated by signaling to > bandwidth. Keep things simple! > > > > > I'd however like to specify a signaling interface > > > allowing to switch "well defined" services. > > > What do you mean by "switch" in this case? (just wanted to > > understand what you want to do) > > Switching here means automated negotiation of service > specific resources between domains. > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 10:23:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29740 for ; Thu, 7 Mar 2002 10:23:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01587 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 10:23:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29942; Thu, 7 Mar 2002 10:05:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29862 for ; Thu, 7 Mar 2002 10:05:53 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28596 for ; Thu, 7 Mar 2002 10:05:49 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 16:05:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Mar 2002 16:05:56 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBBA@TMS041MB.tcad.telia.se> Thread-Topic: section 5.2.2 in requirement draft Thread-Index: AcHF6g0z64zY4s8nS1GI4FKYFxmysg== To: X-OriginalArrivalTime: 07 Mar 2002 15:05:56.0411 (UTC) FILETIME=[953058B0:01C1C5E9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA29863 Subject: [NSIS] section 5.2.2 in requirement draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit All, to the second major concern I have about the requirement document. That is whether or not to constrain the signaling and controllers onto the datapath. I have seen discussions in various camps that it is a good thing to relax the condition about having "signaling" (let it be QoS-signalinig or routing...) and data on the same plane. For me this boils down to a discussion around fate sharing. Ie whether or not the dataplane forwarding (or the quality of forwarding) should be dependent on a single (or cluster of) device(s). Generally, business agreements and policy management is the two functionality that I see should be centrally controlled, this because of their nature. Anything else should be forced onto the dataplane. That was architecturally, but what about reality? I see a divider between two different form of services: a connection service and a 'call'. A vague definition would be: - connection service: where an ISP sell capacity between two (or more) points, promised at all times. - 'call'-service: where an ISP sell a promise that a call can be delivered at any time. Under connection services you find things like trunk capacity between PSTN-gateways, trunk capacity between VPN-nodes etc. Under 'call' service you find services like PSTN-calls-over IP, SIP-initiated communication (mobile as well as fixed) etc. These two have, IMO, far different requirements when it comes to business agreements and technical solution. One may very well suit a centralised solution (connection services in SDH is usually managed this way). On the other hand, the 'call' service does not usually match a centralised solution, I think a distributed solution is probably the most sensible choice for those. I have still not understood the nsis scope regarding which form of services to consider. My understanding is that nsis focus on the second of these services, is that a correct? If my understanding was correct: does a 'call'-service really necessitate a seperation between signaling plane and data plane? And in that case, why? Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 10:36:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00810 for ; Thu, 7 Mar 2002 10:36:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02889 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 10:36:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01369; Thu, 7 Mar 2002 10:18:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01298 for ; Thu, 7 Mar 2002 10:18:48 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29442 for ; Thu, 7 Mar 2002 10:18:44 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g27FIFH23876; Thu, 7 Mar 2002 16:18:15 +0100 (MET) Subject: Re: [NSIS] section 5.2.2 in requirement draft To: Anders.P.Bergsten@telia.se Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 7 Mar 2002 16:18:12 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/07/2002 16:18:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, I think we have to make a distinction between in-band/out-of-band and centralised/distributed. An out of band solution is not necessarily centralised. It may, however, be convenient to think about it as centralised although its implementation can be distributed. Anyway, in my opinion, out-of-band signaling has several adventages: - deployment: it requires less updates in software/hardware - transparency for other/future technologies: it allows to implement the signaling over other/future technologies that are not necessarily nsis aware because the nsis messages would only be interpreted in the (ou-of-band) QCs. If out-of-band signaling is with a centralised entity, then of course it needs to be scalable in order to be feasible on a per-call basis. This is achieved with the two-level admission control within long-lived pipes with defined QoS. This would relax the requirements on the nsis protocol when used end-to-end because most of the complexity would be in the defintion and provisioing of the long-lived pipes which is a local matter. What do you think?, Sven. Anders.P.Bergsten@telia.se on 07/03/2002 16:05:56 To: nsis@ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject [NSIS] section 5.2.2 in requirement draft : All, to the second major concern I have about the requirement document. That is whether or not to constrain the signaling and controllers onto the datapath. I have seen discussions in various camps that it is a good thing to relax the condition about having "signaling" (let it be QoS-signalinig or routing...) and data on the same plane. For me this boils down to a discussion around fate sharing. Ie whether or not the dataplane forwarding (or the quality of forwarding) should be dependent on a single (or cluster of) device(s). Generally, business agreements and policy management is the two functionality that I see should be centrally controlled, this because of their nature. Anything else should be forced onto the dataplane. That was architecturally, but what about reality? I see a divider between two different form of services: a connection service and a 'call'. A vague definition would be: - connection service: where an ISP sell capacity between two (or more) points, promised at all times. - 'call'-service: where an ISP sell a promise that a call can be delivered at any time. Under connection services you find things like trunk capacity between PSTN-gateways, trunk capacity between VPN-nodes etc. Under 'call' service you find services like PSTN-calls-over IP, SIP-initiated communication (mobile as well as fixed) etc. These two have, IMO, far different requirements when it comes to business agreements and technical solution. One may very well suit a centralised solution (connection services in SDH is usually managed this way). On the other hand, the 'call' service does not usually match a centralised solution, I think a distributed solution is probably the most sensible choice for those. I have still not understood the nsis scope regarding which form of services to consider. My understanding is that nsis focus on the second of these services, is that a correct? If my understanding was correct: does a 'call'-service really necessitate a seperation between signaling plane and data plane? And in that case, why? Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 10:56:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02179 for ; Thu, 7 Mar 2002 10:56:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04091 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 10:56:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03108; Thu, 7 Mar 2002 10:39:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03075 for ; Thu, 7 Mar 2002 10:39:12 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00976 for ; Thu, 7 Mar 2002 10:39:08 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g27FcVm02030; Thu, 7 Mar 2002 16:38:31 +0100 (MET) To: brunner@ccrle.nec.de Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 7 Mar 2002 16:38:28 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/07/2002 16:38:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] draft-ietf-nsis-req-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus, I have a coupled of questions regarding the requirements sections in the draft. I have tried to refer to the appropriate sections in the draft 5. QoS control information 1) mutability: Is this really a hard requirement. The same functionality could be implemented in the host when it gets negative feeback on a request that it may try again with a downgraded request. This would require no extra functionality in the nsis protocol. 2) add/remove local domain information: again I am not sure this is needed. I think the QC could initiate signaling locally, set it up and then tunnel through this. This would not require nsis to take care of it. 3) definition of QoS service classes: I think we should focus here on 'universal parameters' that, when complied with, guarantee the service. In that way the nsis signaling could be limited to support these parameters, leaving the interpreation and translation to be a local matter in the QC. 4) aggregation: it think at most the user should be able to specify aggregate/don't aggregate. But even then I think he doesn't care as long a she gets the required service. I am not sure whether this is a hard requirement. 5) Modification of reserved QoS: again I think this complexity should not be in the nsis protocol, but maybe in the QI as an optimization feature? 6) Priority: I think priority support is extremely important (emergency call services e.g.). We had '3) Support of priority: A minimal support of priority and preemption in case of congestion may be needed in the signaling or in the class description.' 6. Performance I think a requirement might be that nsis signaling will need to have a way to get priority treatment in the networks. It cannot be assumed to have the same priority as the data traffic it is signaling for. 7. Flexibility 4) bi-directional reservations: I am not sure whether this is a hard requirement. You could build this on top of two uni-lateral reservations by means of application signaling. Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 11:18:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04008 for ; Thu, 7 Mar 2002 11:18:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07597 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 11:18:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05623; Thu, 7 Mar 2002 11:04:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05592 for ; Thu, 7 Mar 2002 11:04:01 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02838 for ; Thu, 7 Mar 2002 11:03:56 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 17:04:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Thu, 7 Mar 2002 17:04:05 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBBE@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 5.2.2 in requirement draft Thread-Index: AcHF61N8FxFOBl4PRxONA7NnJmAXlQABIQYg To: Cc: , X-OriginalArrivalTime: 07 Mar 2002 16:04:05.0005 (UTC) FILETIME=[B48D8BD0:01C1C5F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05593 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Sven, > I think we have to make a distinction between in-band/out-of-band and > centralised/distributed. An out of band solution is not necessarily > centralised. It may, however, be convenient to think about it as > centralised although its implementation can be distributed. Agreed, that was what I tried to indicate with a cluster-of QCs. > This is achieved with the two-level admission control within > long-lived pipes with > defined QoS. This would relax the requirements on the nsis > protocol when > used end-to-end because most of the complexity would be in > the defintion > and provisioing of the long-lived pipes which is a local matter. This was my main question: is the "long-lived pipes"-service something that is within focus of nsis or not? This "long-lived pipes" sounds like provisioning of resources to me. We have been playing with this architecture for awhile as well (a paper coming out in Networks 2002) that describes and analyse an architecture for supporting this. The architecture is doable, but is it really the first thing we should tackle? And should it be tackled in nsis? If the consensus is yes, then I suggest for clarity that the requirements for the two different parts be clearly separated. My hunch is that the two different tracks ("layers") will lead to two different architectures and mixing them will create a fuzzy requirements document. From my point of view, I would be as happy to leave this work for future studies and focus on the first tier (the e2e signaling). And then bring up the discussion on the second-tier seperately. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 11:30:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05009 for ; Thu, 7 Mar 2002 11:30:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09164 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 11:30:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07329; Thu, 7 Mar 2002 11:15:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07281 for ; Thu, 7 Mar 2002 11:15:20 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03690 for ; Thu, 7 Mar 2002 11:15:15 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16j0Y0-0007ek-00; Thu, 07 Mar 2002 17:15:16 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16j0Y0-0006dU-00; Thu, 07 Mar 2002 17:15:16 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g27GFFf04613; Thu, 7 Mar 2002 17:15:15 +0100 Message-Id: <200203071615.g27GFFf04613@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: sven.van_den_bosch@alcatel.be cc: nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from sven.van_den_bosch@alcatel.be of "Thu, 07 Mar 2002 15:58:32 +0100." References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 07 Mar 2002 17:15:15 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > I have been following your discussion with interest and I particularly > recall the following statements/conclusions: > - automated service negotiation between domains is not a first phase > requirement > - service capabilities of a domain may be exchanged ('advertised') > - nsis signaling should preferably be simple, maybe only involve bandwidth > signaling > - service implementation is a local matter I agree to most of your statements. I see it this way (much like Ruediger): - Service definition is out of scope for nsis. Providers will negotiate personally on supported services, esp. also agree on mapping of their DSCPs at adjacent boundaries in a DiffServ context. - Providers will possibly have some frame SLAs with their customers. This is mainly a local policy matter: which customer is allowed to use which service (to what extent) at which time? However, this is IMO also not in nsis scope, but may be related to policy-based admission control/AAA. - nsis signaling just transports service objects that contain service dependent parameters (in many cases only bandwidth) which are transparent for nsis protocol. QC must know the semantics of a service and its parameters to perform local admission control and resource allocation. - service implementation is a local matter (internal QoS architecture and signaling, e.g. esp. PDB/PHB/DSCP mapping etc.) [same point as yours] I strongly suggest that nsis should work now on interdomain QoS signaling. This is a major piece missing in global QoS support. A main feature of the Internet is its global connectivity (availability of the "same" basic service), so it would be nice to have at least a few globally available public/standardized services (aggreement on them is a business issue, so out of scope). But nsis signaling would allow to request resources of such services on demand between arbitrary sources and destinations. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 12:11:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07787 for ; Thu, 7 Mar 2002 12:11:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13940 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 12:11:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11628; Thu, 7 Mar 2002 11:54:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11595 for ; Thu, 7 Mar 2002 11:54:02 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06450 for ; Thu, 7 Mar 2002 11:53:52 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA23385; Thu, 7 Mar 2002 17:53:25 +0100 (MET) Subject: RE: [NSIS] section 5.2.2 in requirement draft To: Anders.P.Bergsten@telia.se Cc: Date: Thu, 7 Mar 2002 17:52:58 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/07/2002 17:53:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Anders, I have the feeling that the proposal contained in Sven mail fits well with the definition you gave in a previous mail: - connection service: implemented by long-lived pipes, which can be defined today by provisioning and maybe extending in the future with more semi-dynamic procedures (but still 'maybe'). This entity is not aware of, let's say, the usage of the content of each pipe (micro-flows, etc.) - 'call'-service: the provider of this service is using a "connection service" from a transport provider, so it is the customer of this "connection service", and is considering each pipe much as a link. This entity is fully aware of the content of the pipe, but it does not need to consider how the pipe is actually implemented (diffserv, VPN, etc.) As this, you can break the scalability issue by splitting the global picture in two different roles. Now, concerning the nsis scope, IMHO the general model should consider both roles. However, this does not mean in anyway that e.g. the definitions of SLAs are in the scope of nsis. NSIS should provide the general architecture and the related mechanisms allowing the involved actors to define their needs and negotiate common agreements. It is definitely not in the scope of NSIS to define the services themselves. Best regards Juan Carlos Anders.P.Bergsten@telia.se@ietf.org on 07/03/2002 17:04:05 Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: , Subject: RE: [NSIS] section 5.2.2 in requirement draft Sven, > I think we have to make a distinction between in-band/out-of-band and > centralised/distributed. An out of band solution is not necessarily > centralised. It may, however, be convenient to think about it as > centralised although its implementation can be distributed. Agreed, that was what I tried to indicate with a cluster-of QCs. > This is achieved with the two-level admission control within > long-lived pipes with > defined QoS. This would relax the requirements on the nsis > protocol when > used end-to-end because most of the complexity would be in > the defintion > and provisioing of the long-lived pipes which is a local matter. This was my main question: is the "long-lived pipes"-service something that is within focus of nsis or not? This "long-lived pipes" sounds like provisioning of resources to me. We have been playing with this architecture for awhile as well (a paper coming out in Networks 2002) that describes and analyse an architecture for supporting this. The architecture is doable, but is it really the first thing we should tackle? And should it be tackled in nsis? If the consensus is yes, then I suggest for clarity that the requirements for the two different parts be clearly separated. My hunch is that the two different tracks ("layers") will lead to two different architectures and mixing them will create a fuzzy requirements document. From my point of view, I would be as happy to leave this work for future studies and focus on the first tier (the e2e signaling). And then bring up the discussion on the second-tier seperately. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 12:36:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09507 for ; Thu, 7 Mar 2002 12:36:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15513 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 12:36:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14432; Thu, 7 Mar 2002 12:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14400 for ; Thu, 7 Mar 2002 12:21:43 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08599 for ; Thu, 7 Mar 2002 12:21:37 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 17:20:31 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA1BC@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Anders.P.Bergsten@telia.se'" Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Thu, 7 Mar 2002 17:20:30 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Anders, Thanks for the reply. You allude to one particularly interesting point: > 3) billing aspects are agreed upon. This will, IMHO, be done > pretty much like today, where a diff in incoming/outgoing > bandwidth utilization is the basis for billing. This means > that the nsis protocol (or diffserv mibs) needs to provides > the carrier with (some) aggregated bandwidth usage per service. It seems to me that this is linked to a 'I pay you to handle the user traffic that I am forwarding through you' model of inter-provider settlement (which is what I understand to be the default for IP traffic these days - although you're the carrier, not me...) It would match quite well with 'sender initiated' reservation style, since the party generating the traffic (who will also pay for it) is deciding what QoS to request. But other requirements ask for receiver initiated reservations (and indeed bidrectional, but I believe that's just an signalling optimisation). Does that cause any conflict? Especially, does the (opaque) policy information exchanged by NSIS peers need to include accounting policy (since we can no longer assume that the flow of money is in the same direction as the flow of signalling)? The concern I have is that if receiver (or indeed sender) initiated reservations are going to be administratively rejected for policy reasons, simply to do with policy not allowing a particular reservation style, it is going to be very hard for two endpoints to decide whether the reciever or sender of a flow should take the initiative. (And the existing protocol is already receiver initiated.) I am not sure whether this is part of the NSIS problem or not. It certainly seems to be part of the *end-to-end* QoS negotiation problem. Robert H. > -----Original Message----- > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > Sent: 07 March 2002 13:15 > To: Hancock, Robert; Ruediger.Geib@t-systems.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Robert, > > > On the other hand, it seems clear that the actual QoS > > signalling (between QI/QC/Qwhatever TBD) for a flow is only > > meaningful (e.g. will only be taken account of) if it takes > > place within some sort of context which covers AAA aspects. > Agreed. > > > What isn't clear (at least to me (at least in a concrete > > form)) is where the boundary between > > a) information in this 'context' which is pre-existing > > b) information that is exchanged as part of the NSIS QoS > > request signalling > > actually lies, and how signalling (part of (b)) actually > > refers to the context (part of (a)). > > [In our framework draft, we considered the almost-equivalent > > concept of splitting the NSIS signalling into two 'phases', > > with the intention of making the second phase lightweight, > > and maybe making the first phase an extension of other > > protocols, especially to piggyback on existing user > > authentication and authorisation protocols. So, the minimal > > solution then makes the registration phase optional/out of > > scope. However, we still need to determine what functions it > > is 'assumed' to have carried out.] > > Yes, I agree definately to your last sentence. > > I would assume that all business agreements between carriers > are in place before the nsis-protocol kicks in. This means > for me that: > 1) the services have been described and exchanged by the carriers. > 2) the needed mapping between services is understood and > configured in the edge router (by some mean) > 3) billing aspects are agreed upon. This will, IMHO, be done > pretty much like today, where a diff in incoming/outgoing > bandwidth utilization is the basis for billing. This means > that the nsis protocol (or diffserv mibs) needs to provides > the carrier with (some) aggregated bandwidth usage per service. > 4) the bandwidth bought for an explicit service is known and > configured in the edge routers. (for signaling to work upon). > 5) the policy about what the customer is allowed to do is > described in some form of policy language (similar to RPSL > for routing) and instantiated in the edge router (through > e.g. COPS-PR) (coming to think of it, the 'service' is > probably describe here and not only by the DSCP, thus the > accounting data needs to be couple with this and not with the dscp.) > > Furthermore, I think it is safe to assume that the carrier > have taken approriate steps to assure that the blocking rate > of 'calls' (or breach of the SLA) is minimized. How we assure > it is up to us as a carrier. Thus, the likelihood that a > signaling message comes through is generally very low (10^-x). > > I would also assume that the services that are being sold are > in line with diffserv (ie DSCPs are the minimal level of > aggregation). > > [you can make a similar analysis for the end-customer to ISP > interface and land in a similar list of pre-requisitions > (some parts different though)] > > You asked how this was interconnected with the end-to-end > signaling: I would say pretty much like RSVP does it. Either > with a explicit or an implicit policy attribut (the latter > would mean that the router must deduce the policy from the IP-header). > > > Some particular concrete questions: > > *) can the cross-reference between signalling and context be > > done just by referring to DSCPs? > No, to make it generic it should probably be described either > by the IP-header (the implicit method) or by an opaque policy > attribut inside the packet (the explicit method that RSVP uses). > > I did some (very fast) analysis in the carrier to carrier > business and, I think, without loss of generality, you can > assume that the policies is based on the IP-header (ie very > similar to the COPS-PR work already finished). This > implements all I came to think of in the carrier-to-carrier business. > > Anders > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 7 14:34:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17633 for ; Thu, 7 Mar 2002 14:34:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24561 for nsis-archive@odin.ietf.org; Thu, 7 Mar 2002 14:34:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23178; Thu, 7 Mar 2002 14:19:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23146 for ; Thu, 7 Mar 2002 14:19:53 -0500 (EST) Received: from magenta.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16503 for ; Thu, 7 Mar 2002 14:19:49 -0500 (EST) Received: from juniper.net (ssh.juniper.net [207.17.136.39]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id g27JJK753751; Thu, 7 Mar 2002 11:19:20 -0800 (PST) (envelope-from kdubray@juniper.net) Message-ID: <3C87BD37.1C41EF99@juniper.net> Date: Thu, 07 Mar 2002 14:19:19 -0500 From: Kevin Dubray X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: rap@ops.ietf.org, mpls@uu.net, nsis@ietf.org CC: Randy Bush , Bert Wijnen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] RSVP Benchmarking Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit In the Benchmarking WG, an I-D regarding benchmarking Resource Reservation is going through a WG Last Call: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-benchres-term-01.txt If you have interest, please review the draft. Comments to bmwg@ietf.org are appreciated. Thanks. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 02:22:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24025 for ; Fri, 8 Mar 2002 02:22:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06791 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 02:22:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06297; Fri, 8 Mar 2002 02:09:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06269 for ; Fri, 8 Mar 2002 02:09:52 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23843 for ; Fri, 8 Mar 2002 02:09:48 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA02357; Fri, 8 Mar 2002 08:09:37 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA28638; Fri, 8 Mar 2002 08:09:24 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 08:09:47 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB21F@MCHH241E> From: Winter Martin To: "'Roland Bless'" , nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 08:09:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, I fully agree with these stamements. IMHO it is really important, that NSIS does not forget inter-domain issues or shifts them "for later consideration". See also my comments inserted in the text below. > Hi, > > > I have been following your discussion with interest and I > particularly > > recall the following statements/conclusions: > > - automated service negotiation between domains is not a first phase > > requirement > > - service capabilities of a domain may be exchanged ('advertised') > > - nsis signaling should preferably be simple, maybe only > involve bandwidth > > signaling > > - service implementation is a local matter > > I agree to most of your statements. I see it this way (much > like Ruediger): > - Service definition is out of scope for nsis. Providers will > negotiate > personally on supported services, esp. also agree on > mapping of their DSCPs > at adjacent boundaries in a DiffServ context. I fully agree. Service definition is out of the scope of NSIS. Service mapping and service implementation is a local matter. > - Providers will possibly have some frame SLAs with their > customers. This > is mainly a local policy matter: which customer is allowed > to use which > service (to what extent) at which time? However, this is > IMO also not in > nsis scope, but may be related to policy-based admission > control/AAA. > - nsis signaling just transports service objects that contain service > dependent parameters (in many cases only bandwidth) which > are transparent > for nsis protocol. QC must know the semantics of a service > and its parameters > to perform local admission control and resource allocation. > - service implementation is a local matter (internal QoS architecture > and signaling, e.g. esp. PDB/PHB/DSCP mapping etc.) [same > point as yours] > > I strongly suggest that nsis should work now on interdomain > QoS signaling. > This is a major piece missing in global QoS support. A main feature of > the Internet is its global connectivity (availability of the > "same" basic > service), so it would be nice to have at least a few globally > available > public/standardized services (aggreement on them is a > business issue, so > out of scope). But nsis signaling would allow to request resources of > such services on demand between arbitrary sources and destinations. Exactly! If you want to deliver a "useful" inter-domain service to the end customer, then there must be some common sense between all involved domains about that service. So I think, that a globally well known service will be necessary to achieve that. It is not achievable to negotiate service details between domains for each call. Also aggregation might not be possible without globally well known services. I do not want to define these globally well known services within NSIS. But I think the NSIS signalling should be aware, that such services will exist, and should allow calls based on such services. > > Regards, > Roland > > -- > Roland Bless -- e-Mail: bless@tm.uka.de > Institute of Telematics, University of Karlsruhe, Germany > Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 > Phone: +49 721 608-6413 Fax: +49 721 388097 > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 02:27:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24100 for ; Fri, 8 Mar 2002 02:27:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06939 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 02:27:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06551; Fri, 8 Mar 2002 02:14:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06518 for ; Fri, 8 Mar 2002 02:14:29 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23918 for ; Fri, 8 Mar 2002 02:14:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g287EbZ05607 for ; Fri, 8 Mar 2002 09:14:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 8 Mar 2002 09:14:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 09:14:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 8 Mar 2002 09:14:19 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B63@esebe004.NOE.Nokia.com> Thread-Topic: http://www.rfc-editor.org/policy.html Thread-Index: AcHF7dxbPmTquhJ+R7KtygXTm7L9qwAgsgfw To: X-OriginalArrivalTime: 08 Mar 2002 07:14:20.0114 (UTC) FILETIME=[DDB1D320:01C1C670] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA06519 Subject: [NSIS] Internet Draft Policies Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Just as a reminder, for anyone writing Internet Drafts, some of the policies have changed. Its strongly suggested that you read: http://www.rfc-editor.org/policy.html and http://www.ietf.org/ID-nits.html Failure to follow these guidelines will prevent documents from becoming WG documents and RFCs. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:08:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24918 for ; Fri, 8 Mar 2002 03:08:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09318 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:08:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08372; Fri, 8 Mar 2002 02:55:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08341 for ; Fri, 8 Mar 2002 02:55:42 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24552 for ; Fri, 8 Mar 2002 02:55:40 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 08:55:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 08:55:34 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBBF@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGcEb6VdXZwTTxQfGCwM74rYFZsgAArvRg To: , , X-OriginalArrivalTime: 08 Mar 2002 07:55:41.0746 (UTC) FILETIME=[A4DCD120:01C1C676] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA08342 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Roland and Maring, I sympathize with your wish to define inter-domain QoS. However, I do not fully understand what you are referring to. If service description is out of scope. The 'adverticement' of SDs may be in scope. The SLS negotiation is out of scope (which Ruediger and I discussed before). What do you mean by inter-domain QoS? And, what do you mean is the requirements regarding inter-domain QoS? As a second point, how much of the Inter-domain issues that need to be solved is a technical issue and how much is better left for the carriers to figure out themselves? I would agree that working out an architecture that gives the incentives for the carriers to optimise the Internet on delay would be a truly valuable task. The question for me is what is the minimal thing needed to give the carriers this incentive, without forcing them (us) into a solution that constrains the business models? From my part, I believe that the minimal architectural component that is needed is the 'adverticement' of SDs. That's where I have landed after thinking about this for a long time. This adverticement have the exact same function as BGP adverticement and can be implemented in BGP (see for example draft-jacquenet-qos-nlri-04.txt for one solution). This functionality (assuming some quality parameters and pricing information is included) would give the carrier a tool and some incentive to optimise the network. Observe, I still believe the service description is way out of scope (this is a business issue for me). I can agree to this being important (after all I am working for a carrier...). What I am suggestion - also in my previoius email - is that this part and the requirements for this is clearly separated in the requirement document from the 'call'-signaling that I mentioned in a previous email. This two may lead to two different solutions. Anders > > I strongly suggest that nsis should work now on interdomain > > QoS signaling. > > This is a major piece missing in global QoS support. A main > feature of > > the Internet is its global connectivity (availability of the > > "same" basic > > service), so it would be nice to have at least a few globally > > available > > public/standardized services (aggreement on them is a > > business issue, so > > out of scope). But nsis signaling would allow to request > resources of > > such services on demand between arbitrary sources and destinations. > > Exactly! If you want to deliver a "useful" inter-domain > service to the end customer, then there must be some common > sense between all involved domains about that service. So I > think, that a globally well known service will be necessary > to achieve that. It is not achievable to negotiate service > details between domains for each call. Also aggregation might > not be possible without globally well known services. > > I do not want to define these globally well known services > within NSIS. But I think the NSIS signalling should be aware, > that such services will exist, and should allow calls based > on such services. > > > > > Regards, > > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:33:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25626 for ; Fri, 8 Mar 2002 03:33:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11121 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:33:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09915; Fri, 8 Mar 2002 03:20:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09881 for ; Fri, 8 Mar 2002 03:20:32 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25340 for ; Fri, 8 Mar 2002 03:20:28 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288KdZ21140 for ; Fri, 8 Mar 2002 10:20:39 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:20:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:20:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:20:28 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B78@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHFq6ONoQ3KsqteS5uyog5p6pBzQAAAPcdQADNLysA= To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 08:20:28.0972 (UTC) FILETIME=[1B517EC0:01C1C67A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA09883 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, Catching up on some emails: > What I believe is in scope is: > - nsis must allow dscp's (or whatever constitutes the > 'service') to be mapped. This should be under the control of > the carrier. DSCPs are specific to a resource reservation system, and that is out of scope. Mapping between NSIS and resource reservation is best held for a rechartering of NSIS. > - nsis must allow the carrier to set up the bandwidth allowed > to be passed between two carriers. nsis must also use this > value when doing CAC. This is very close to a specific solution, so I don't think we can go there yet. > - nsis must allow an edge to store accounting information > (but I would be happy to restrict this to aggregate bandwidth > that has crossed the link between two carriers) I think the requirement more properly is: NSIS SHOULD interact with accouting systems. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:35:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25659 for ; Fri, 8 Mar 2002 03:35:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11245 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:35:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10007; Fri, 8 Mar 2002 03:21:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09978 for ; Fri, 8 Mar 2002 03:21:45 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25358 for ; Fri, 8 Mar 2002 03:21:42 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 09:21:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 09:21:25 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBC0@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHF/Huvdg1wLltBTBayCA6SCG2xagAfAdJA To: Cc: X-OriginalArrivalTime: 08 Mar 2002 08:21:32.0621 (UTC) FILETIME=[41418FD0:01C1C67A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA09979 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Robert, You stated a delicate question... I haven't worked with PSTN ever, so I may be off on deep water here, but I think the PSTN works in a similar fascion as today's internet - concerning inter-provider billing. But I may be completely off here! :-) (somebody have to correct me in that case) With similar I am referring to a diff between incoming and outgoing bandwidth/calls is what is the basis for billing and agreements. This does not restrict the call model to be either caller or callee pays. On this issue, I think that the requirement draft should state the following requirement. - The QoS-architecture MUST NOT restrict the carriers inter-provider relationsship, ie the architecture MUST be completely agnostic to what two carriers choose as a bilateral business agreement. (this concerning pricing method). > Anders, > > Thanks for the reply. > You allude to one particularly interesting point: > > > 3) billing aspects are agreed upon. This will, IMHO, be done > > pretty much like today, where a diff in incoming/outgoing > > bandwidth utilization is the basis for billing. This means > > that the nsis protocol (or diffserv mibs) needs to provides > > the carrier with (some) aggregated bandwidth usage per service. > > It seems to me that this is linked to a 'I pay you to handle > the user traffic that I am forwarding through you' model of > inter-provider settlement (which is what I understand to be > the default for IP traffic these days - although you're the > carrier, not me...) > > It would match quite well with 'sender initiated' reservation > style, since the party generating the traffic (who will also > pay for it) is deciding what QoS to request. > > But other requirements ask for receiver initiated > reservations (and indeed bidrectional, but I believe that's > just an signalling optimisation). Does that cause any > conflict? Especially, does the (opaque) policy information > exchanged by NSIS peers need to include accounting policy > (since we can no longer assume that the flow of money is in > the same direction as the flow of signalling)? > > The concern I have is that if receiver (or indeed sender) > initiated reservations are going to be administratively > rejected for policy reasons, simply to do with policy not > allowing a particular reservation style, it is going to be > very hard for two endpoints to decide whether the reciever or > sender of a flow should take the initiative. (And the > existing protocol is already receiver initiated.) > > I am not sure whether this is part of the NSIS problem or > not. It certainly seems to be part of the *end-to-end* QoS > negotiation problem. > > Robert H. > > > -----Original Message----- > > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > > Sent: 07 March 2002 13:15 > > To: Hancock, Robert; Ruediger.Geib@t-systems.com > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Robert, > > > > > On the other hand, it seems clear that the actual QoS > > > signalling (between QI/QC/Qwhatever TBD) for a flow is only > > > meaningful (e.g. will only be taken account of) if it takes > > > place within some sort of context which covers AAA aspects. > > Agreed. > > > > > What isn't clear (at least to me (at least in a concrete > > > form)) is where the boundary between > > > a) information in this 'context' which is pre-existing > > > b) information that is exchanged as part of the NSIS QoS > > > request signalling > > > actually lies, and how signalling (part of (b)) actually > > > refers to the context (part of (a)). > > > [In our framework draft, we considered the almost-equivalent > > > concept of splitting the NSIS signalling into two 'phases', > > > with the intention of making the second phase lightweight, > > > and maybe making the first phase an extension of other > > > protocols, especially to piggyback on existing user > > > authentication and authorisation protocols. So, the minimal > > > solution then makes the registration phase optional/out of > > > scope. However, we still need to determine what functions it > > > is 'assumed' to have carried out.] > > > > Yes, I agree definately to your last sentence. > > > > I would assume that all business agreements between carriers > > are in place before the nsis-protocol kicks in. This means > > for me that: > > 1) the services have been described and exchanged by the carriers. > > 2) the needed mapping between services is understood and > > configured in the edge router (by some mean) > > 3) billing aspects are agreed upon. This will, IMHO, be done > > pretty much like today, where a diff in incoming/outgoing > > bandwidth utilization is the basis for billing. This means > > that the nsis protocol (or diffserv mibs) needs to provides > > the carrier with (some) aggregated bandwidth usage per service. > > 4) the bandwidth bought for an explicit service is known and > > configured in the edge routers. (for signaling to work upon). > > 5) the policy about what the customer is allowed to do is > > described in some form of policy language (similar to RPSL > > for routing) and instantiated in the edge router (through > > e.g. COPS-PR) (coming to think of it, the 'service' is > > probably describe here and not only by the DSCP, thus the > > accounting data needs to be couple with this and not with the dscp.) > > > > Furthermore, I think it is safe to assume that the carrier > > have taken approriate steps to assure that the blocking rate > > of 'calls' (or breach of the SLA) is minimized. How we assure > > it is up to us as a carrier. Thus, the likelihood that a > > signaling message comes through is generally very low (10^-x). > > > > I would also assume that the services that are being sold are > > in line with diffserv (ie DSCPs are the minimal level of > > aggregation). > > > > [you can make a similar analysis for the end-customer to ISP > > interface and land in a similar list of pre-requisitions > > (some parts different though)] > > > > You asked how this was interconnected with the end-to-end > > signaling: I would say pretty much like RSVP does it. Either > > with a explicit or an implicit policy attribut (the latter > > would mean that the router must deduce the policy from the > IP-header). > > > > > Some particular concrete questions: > > > *) can the cross-reference between signalling and context be > > > done just by referring to DSCPs? > > No, to make it generic it should probably be described either > > by the IP-header (the implicit method) or by an opaque policy > > attribut inside the packet (the explicit method that RSVP uses). > > > > I did some (very fast) analysis in the carrier to carrier > > business and, I think, without loss of generality, you can > > assume that the policies is based on the IP-header (ie very > > similar to the COPS-PR work already finished). This > > implements all I came to think of in the carrier-to-carrier > business. > > > > Anders > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:38:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25706 for ; Fri, 8 Mar 2002 03:38:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11339 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:38:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10194; Fri, 8 Mar 2002 03:25:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10159 for ; Fri, 8 Mar 2002 03:25:52 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25511 for ; Fri, 8 Mar 2002 03:25:49 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288Q0Z25346 for ; Fri, 8 Mar 2002 10:26:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:25:46 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:25:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:25:49 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B79@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHFyqkd6IbgPUg/Q9Gq1y+Akgn2zAAr4XhQ To: , , Cc: X-OriginalArrivalTime: 08 Mar 2002 08:25:50.0144 (UTC) FILETIME=[DAC07400:01C1C67A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA10160 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, > This is an important set of questions about NSIS scope. > I support the view that NSIS is not (should not be) about all > signalling protocols associated with QoS including SLA > negotiation and so on (apart from anything else, it's > probably not a Transport Area subject). You are correct that it is out of scope. However, I do think that if NSIS is about a signaling QoS, it is not unreasonable to assume that this could be used on an end-to-end, end-to-edge and an edge-to-edge basis. Having a specific requirement like: NSIS MUST support SLA negotiation is far too specific & solution-oriented. Could we say NSIS SHOULD (or MAY) support some level of QoS negotiation is that acceptable? > On the other hand, it seems clear that the actual QoS > signalling (between QI/QC/Qwhatever TBD) for a flow is only > meaningful (e.g. will only be taken account of) if it takes > place within some sort of context which covers AAA aspects. This is in our charter & in our focus. So a requirement is: NSIS MUST support interaction with AAA entitities and AAA is meant in a broad sense (for example, with CAC modules, HLRs, Diameter / Radius servers= etc. > What isn't clear (at least to me (at least in a concrete > form)) is where the boundary between > a) information in this 'context' which is pre-existing > b) information that is exchanged as part of the NSIS QoS > request signalling actually lies, and how signalling (part of (b)) actually > refers to the context (part of (a)). I support the idea that NSIS MAY interact with policy entities for accessing such information. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:42:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25773 for ; Fri, 8 Mar 2002 03:42:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11508 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:42:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10360; Fri, 8 Mar 2002 03:29:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10285 for ; Fri, 8 Mar 2002 03:29:27 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25561 for ; Fri, 8 Mar 2002 03:29:24 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA13260; Fri, 8 Mar 2002 09:29:22 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA05699; Fri, 8 Mar 2002 09:29:13 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 09:29:33 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB223@MCHH241E> From: Winter Martin To: "'Anders.P.Bergsten@telia.se'" , "'nsis@ietf.org'" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 09:29:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, > > Roland and Maring, > > I sympathize with your wish to define inter-domain QoS. > However, I do not fully understand what you are referring to. > > If service description is out of scope. The 'adverticement' > of SDs may be in scope. The SLS negotiation is out of scope > (which Ruediger and I discussed before). What do you mean by > inter-domain QoS? And, what do you mean is the requirements > regarding inter-domain QoS? I think the final intention of an NSIS signalling protocol is to establish an a-to-b QoS call, where a and b could be hosts or some other entities in the network. When a and b are in the same domain, then just the customer and the domain manager need to know, what the "S" ind "QoS" means. When a and b are in different domains, these domains also need some common understanding. Requirements from inter-domain QoS are (amongst others) - scalability (must work through a backbone network!) - IMHO that means also aggregateability of requests - simplicity (many people stated "just bw" here, I support that) - a common understanding of what a service is. These may not all be hard requirements, but more direction signs. And for the last topic: I just ask for the existence of a common understanding, NOT for the content of that. > As a second point, how much of the Inter-domain issues that > need to be solved is a technical issue and how much is better > left for the carriers to figure out themselves? > > I would agree that working out an architecture that gives the > incentives for the carriers to optimise the Internet on delay > would be a truly valuable task. The question for me is what > is the minimal thing needed to give the carriers this > incentive, without forcing them (us) into a solution that > constrains the business models? > > From my part, I believe that the minimal architectural > component that is needed is the 'adverticement' of SDs. > That's where I have landed after thinking about this for a > long time. This adverticement have the exact same function as > BGP adverticement and can be implemented in BGP (see for > example draft-jacquenet-qos-nlri-04.txt for one solution). Adverticement is IMHO one step before the NSIS signalling. It' still a choice, whether such advertisements are automated as proposed in the draft cited above or is manually and bilaterally between domains. During the set-up of a QoS call, you will make use of that information. > This functionality (assuming some quality parameters and > pricing information is included) would give the carrier a > tool and some incentive to optimise the network. Observe, I > still believe the service description is way out of scope > (this is a business issue for me). Yes! > I can agree to this being important (after all I am working > for a carrier...). > > What I am suggestion - also in my previoius email - is that > this part and the requirements for this is clearly separated > in the requirement document from the 'call'-signaling that I > mentioned in a previous email. This two may lead to two > different solutions. > > Anders > > > > I strongly suggest that nsis should work now on interdomain > > > QoS signaling. > > > This is a major piece missing in global QoS support. A main > > feature of > > > the Internet is its global connectivity (availability of the > > > "same" basic > > > service), so it would be nice to have at least a few globally > > > available > > > public/standardized services (aggreement on them is a > > > business issue, so > > > out of scope). But nsis signaling would allow to request > > resources of > > > such services on demand between arbitrary sources and > destinations. > > > > Exactly! If you want to deliver a "useful" inter-domain > > service to the end customer, then there must be some common > > sense between all involved domains about that service. So I > > think, that a globally well known service will be necessary > > to achieve that. It is not achievable to negotiate service > > details between domains for each call. Also aggregation might > > not be possible without globally well known services. > > > > I do not want to define these globally well known services > > within NSIS. But I think the NSIS signalling should be aware, > > that such services will exist, and should allow calls based > > on such services. > > > > > > > > Regards, > > > Roland > > > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:44:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25831 for ; Fri, 8 Mar 2002 03:44:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11641 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:44:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10908; Fri, 8 Mar 2002 03:31:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10881 for ; Fri, 8 Mar 2002 03:31:27 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25585 for ; Fri, 8 Mar 2002 03:31:22 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 09:31:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 09:31:05 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCBE5@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHF/Huvdg1wLltBTBayCA6SCG2xagAfAdJAAACkj4AAAD0uAA== To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 08:31:12.0668 (UTC) FILETIME=[9AFDB5C0:01C1C67B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA10882 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Yes. Anders > Hi Anders, > > > On this issue, I think that the requirement draft should > > state the following requirement. > > > > - The QoS-architecture MUST NOT restrict the carriers > > inter-provider relationsship, ie the architecture MUST be > > completely agnostic to what two carriers choose as a > > bilateral business agreement. (this concerning pricing method). > > Making this a bit more agnostic: > > > The QoS-architecture MUST NOT restrict the parties > relationship, > i.e. - the architecture MUST be completely agnostic to how > the parties make service agreements. > > Does this still capture your requirement? > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:45:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25856 for ; Fri, 8 Mar 2002 03:45:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11670 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11021; Fri, 8 Mar 2002 03:32:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10988 for ; Fri, 8 Mar 2002 03:32:37 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25597 for ; Fri, 8 Mar 2002 03:32:32 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288XCi18234 for ; Fri, 8 Mar 2002 10:33:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:32:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:32:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:32:33 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7B@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHF6MM2IHTqx7RySWyNAb1hh23tnAAksQsA To: Cc: X-OriginalArrivalTime: 08 Mar 2002 08:32:33.0716 (UTC) FILETIME=[CB4CA740:01C1C67B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA10989 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, > I think these map very well with the two-level admission > control described > in draft-buchli-nsis-req-00.txt. Here it is proposed that a QC has an > interface with a NMS that provides certain services. How these are > implemented is shielded from the QC by means of an SLS > interface (local > SLS, not inter-domain SLS). As you said, this interface may > not be in scope > of nsis. The QC then processes nsis signaling and does very simple > admission control, e.g. only based on the requested > bandwidth. Given your > discussion about these issues, do you think that our model > captures your requirements? Right now, the requirements document should not contain a model - that is what the framework document will do. So, the difficult job will be finding requirements language that is suitable for a more general case, yet still applicable to a model which you have in mind. I really want to get away from designing requirements to fit a model. John PS - I am speficially not commenting on the validity of the model. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:45:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25874 for ; Fri, 8 Mar 2002 03:45:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11684 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:45:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10591; Fri, 8 Mar 2002 03:30:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10544 for ; Fri, 8 Mar 2002 03:30:25 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25570 for ; Fri, 8 Mar 2002 03:30:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288UXZ28937 for ; Fri, 8 Mar 2002 10:30:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:30:23 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:30:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:30:22 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7A@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHF/Huvdg1wLltBTBayCA6SCG2xagAfAdJAAACkj4A= To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 08:30:23.0289 (UTC) FILETIME=[7D8F1290:01C1C67B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA10545 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > On this issue, I think that the requirement draft should > state the following requirement. > > - The QoS-architecture MUST NOT restrict the carriers > inter-provider relationsship, ie the architecture MUST be > completely agnostic to what two carriers choose as a > bilateral business agreement. (this concerning pricing method). Making this a bit more agnostic: The QoS-architecture MUST NOT restrict the parties relationship, i.e. - the architecture MUST be completely agnostic to how the parties make service agreements. Does this still capture your requirement? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:50:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25973 for ; Fri, 8 Mar 2002 03:50:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12043 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:50:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11317; Fri, 8 Mar 2002 03:37:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11286 for ; Fri, 8 Mar 2002 03:37:44 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25700 for ; Fri, 8 Mar 2002 03:37:40 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288cHi21098 for ; Fri, 8 Mar 2002 10:38:17 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:37:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:37:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:37:37 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7C@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGe22iAKbSeboiSC2kYd5TPfV9VwAAIqiw To: , , X-OriginalArrivalTime: 08 Mar 2002 08:37:38.0469 (UTC) FILETIME=[80F24550:01C1C67C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA11287 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Martin, > I think the final intention of an NSIS signalling protocol is > to establish an a-to-b QoS call, where a and b could be hosts > or some other entities in the network. When a and b are in > the same domain, then just the customer and the domain > manager need to know, what the "S" ind "QoS" means. When a > and b are in different domains, these domains also need some > common understanding. Language use alert!! IP is not about calls, nor is it about customers. The work we are doing her should have broad applicability. One use of NSIS would be to provide certain signaling traffic a higher priority than data traffic, for example. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:56:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26152 for ; Fri, 8 Mar 2002 03:56:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12502 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:56:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11614; Fri, 8 Mar 2002 03:43:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11578 for ; Fri, 8 Mar 2002 03:43:09 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25804 for ; Fri, 8 Mar 2002 03:43:05 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 09:43:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 09:43:01 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCBE7@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGe22iAKbSeboiSC2kYd5TPfV9VwAAIqiwAABLC0A= To: , , X-OriginalArrivalTime: 08 Mar 2002 08:43:08.0324 (UTC) FILETIME=[458E2640:01C1C67D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA11579 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, I think that Martin as well as I was referring to 'call' to mean a connection between two 'parties' (hosts, or whatever), and to my knowledge that is what TCP/IP is all about. (connecting people, you know ;-). Anders > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 8 mars 2002 09:38 > To: Martin.Winter@icn.siemens.de; Bergsten, Anders P. /Research > /0920-754 50, 070-661 44 98; nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Hi Martin, > > > I think the final intention of an NSIS signalling protocol is > > to establish an a-to-b QoS call, where a and b could be hosts > > or some other entities in the network. When a and b are in > > the same domain, then just the customer and the domain > > manager need to know, what the "S" ind "QoS" means. When a > > and b are in different domains, these domains also need some > > common understanding. > > Language use alert!! > > IP is not about calls, nor is it about customers. The work > we are doing her should have broad applicability. One use of > NSIS would be to provide certain signaling traffic a higher > priority than data traffic, for example. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 03:58:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26243 for ; Fri, 8 Mar 2002 03:57:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12588 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 03:58:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11502; Fri, 8 Mar 2002 03:42:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11461 for ; Fri, 8 Mar 2002 03:42:10 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25768 for ; Fri, 8 Mar 2002 03:42:07 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288fW325715 for ; Fri, 8 Mar 2002 10:41:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:42:07 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:42:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 10:42:06 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 5.2.2 in requirement draft Thread-Index: AcHF8iV2wuf0S1FOTyC3PAyodMg/+QAior8g To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 08:42:07.0616 (UTC) FILETIME=[215ED800:01C1C67D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA11462 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, To summarize the requirements with regards to on-path vs. off-path signaling, we may have to say this: NSIS SHOULD support on-path signaling. NSIS MAY support signaling to known entities. Perhaps my word-usage could be tweaked, but what I mean is the default signaling is on-path, but if an endpoint knows where it wants to signaling to (pre-configured or something) is should be allowed as well. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:01:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26309 for ; Fri, 8 Mar 2002 04:01:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13231 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:01:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11759; Fri, 8 Mar 2002 03:47:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11724 for ; Fri, 8 Mar 2002 03:47:37 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25910 for ; Fri, 8 Mar 2002 03:47:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288liZ12856 for ; Fri, 8 Mar 2002 10:47:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:47:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:47:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:47:32 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7F@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHF9nM5aPycG5XITfWPnoB1wOilGwAhwjuw To: , Cc: , , X-OriginalArrivalTime: 08 Mar 2002 08:47:32.0314 (UTC) FILETIME=[E2E7D3A0:01C1C67D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA11727 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Roland, > I strongly suggest that nsis should work now on interdomain > QoS signaling. This is a major piece missing in global QoS support. A main > feature of the Internet is its global connectivity (availability of the > "same" basic service), so it would be nice to have at least a few globally > available public/standardized services (aggreement on them is a > business issue, so out of scope). But nsis signaling would allow to request resources of > such services on demand between arbitrary sources and destinations. What are your requirements? Remember, we are not going into how service providers actually provision network resources. Do you want to enable some sort sort of dialog like: Provider A: Hey, do you 10k bandwidth and 50 ms delay? Provider B: Sorry, no. Provider A: Well howabout just 10k bandwidth? Provider B: I do. Provider A: Then I will take it. Or do you want something more complex? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:04:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26374 for ; Fri, 8 Mar 2002 04:04:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13448 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:04:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12180; Fri, 8 Mar 2002 03:51:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12151 for ; Fri, 8 Mar 2002 03:51:26 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26008 for ; Fri, 8 Mar 2002 03:51:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288pYZ15823 for ; Fri, 8 Mar 2002 10:51:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:51:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:51:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:51:24 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B81@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGe22iAKbSeboiSC2kYd5TPfV9VwAAIqiwAABLC0AAAEtroA== To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 08:51:24.0548 (UTC) FILETIME=[6D53EC40:01C1C67E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA12152 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, Understood - I just trying to remind folks that calls have a specific connotation, and we should be aware of this. John > -----Original Message----- > From: ext [mailto:Anders.P.Bergsten@telia.se] > Sent: 08 March, 2002 10:43 > To: Loughney John (NRC/Helsinki); Martin.Winter@icn.siemens.de; > nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > John, > > I think that Martin as well as I was referring to 'call' to > mean a connection between two 'parties' (hosts, or whatever), > and to my knowledge that is what TCP/IP is all about. > (connecting people, you know ;-). > > Anders > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: den 8 mars 2002 09:38 > > To: Martin.Winter@icn.siemens.de; Bergsten, Anders P. /Research > > /0920-754 50, 070-661 44 98; nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Hi Martin, > > > > > I think the final intention of an NSIS signalling protocol is > > > to establish an a-to-b QoS call, where a and b could be hosts > > > or some other entities in the network. When a and b are in > > > the same domain, then just the customer and the domain > > > manager need to know, what the "S" ind "QoS" means. When a > > > and b are in different domains, these domains also need some > > > common understanding. > > > > Language use alert!! > > > > IP is not about calls, nor is it about customers. The work > > we are doing her should have broad applicability. One use of > > NSIS would be to provide certain signaling traffic a higher > > priority than data traffic, for example. > > > > John > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:11:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26489 for ; Fri, 8 Mar 2002 04:11:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13930 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:11:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12642; Fri, 8 Mar 2002 03:58:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12613 for ; Fri, 8 Mar 2002 03:58:27 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26258 for ; Fri, 8 Mar 2002 03:58:24 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288x5i01623 for ; Fri, 8 Mar 2002 10:59:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:58:25 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:58:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 10:58:25 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B82@esebe004.NOE.Nokia.com> Thread-Topic: section 5.2.2 in requirement draft Thread-Index: AcHF6g0z64zY4s8nS1GI4FKYFxmysgAlPXKA To: , X-OriginalArrivalTime: 08 Mar 2002 08:58:25.0837 (UTC) FILETIME=[686F85D0:01C1C67F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA12614 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > - connection service: where an ISP sell capacity between two > (or more) points, promised at all times. > - 'call'-service: where an ISP sell a promise that a call can > be delivered at any time. I would suggest that NSIS will be working on a connection basis, however, the specifics of the connection may be a detail that NSIS tackles, but also may be left up to deployment. I do think we will have a hard discussion ahead (not for the requiements draft) of how we classify the quality in QoS. Is it reliability, is it bandwidth, is it delay; is it absolute; is it relative ... However, I don't think we can go into that level of detail here. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:12:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26523 for ; Fri, 8 Mar 2002 04:12:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14050 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:12:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12729; Fri, 8 Mar 2002 03:59:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12690 for ; Fri, 8 Mar 2002 03:59:48 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26277 for ; Fri, 8 Mar 2002 03:59:45 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288xuZ23455 for ; Fri, 8 Mar 2002 10:59:56 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:59:46 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:59:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 10:59:45 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B83@esebe004.NOE.Nokia.com> Thread-Topic: section 5.2.2 in requirement draft Thread-Index: AcHF6g0z64zY4s8nS1GI4FKYFxmysgAlPXKAAAAfCKA= To: , , X-OriginalArrivalTime: 08 Mar 2002 08:59:45.0995 (UTC) FILETIME=[9836A9B0:01C1C67F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA12691 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit > I do think we will have a hard discussion ahead (not for the > requiements draft) of how we classify the quality in QoS. > Is it reliability, is it bandwidth, is it delay; is it > absolute; is it relative ... However, I don't think we > can go into that level of detail here. PS - (talking to myself, I guess) we should make sure that the requirements do not unduely restrict the possibilities here. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:16:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26578 for ; Fri, 8 Mar 2002 04:16:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14267 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:16:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13044; Fri, 8 Mar 2002 04:00:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12991 for ; Fri, 8 Mar 2002 04:00:37 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26292 for ; Fri, 8 Mar 2002 04:00:34 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28903H27960; Fri, 8 Mar 2002 10:00:03 +0100 (MET) Subject: RE: [NSIS] section 5.2.2 in requirement draft To: Anders.P.Bergsten@telia.se Cc: nsis@ietf.org, Niklas.G.Borg@telia.se X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 09:59:52 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 10:00:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Anders, Thanks for you reply. You mentioned that you would like to focus on e2e signaling first. There can be two definitions of this: 1) between the first and the last nsis speaker 2) between end-hosts I think everyone agrees that the (nsis) signaling from end-host to end-host will have different requirements than from edge to edge. If you assume for a minute that not all end-hosts will be nsis speakers right away then this means that the edge-to-edge case is certainly in the scope of nsis. In that case it makes sense to think of the 'edge-to-edge application' of nsis as the first step. This would then need to be complemented with a 'local QoS signaling' for the end-host to first nsis speaker connection and possibly also for mapping of the edge-to-edge signaling to local mechanisms. I believe it has been stated as a requirement that NSIS can be used as a local mechanism (in its own right) as well. This would then map very nicely to this second 'local application' of NSIS. I think this would be a useful distinction to aggregate the requirements for. In my opinion, the requirements for the local mechanism would be a superset of the edge-to-edge requirements. Sven. Anders.P.Bergsten@telia.se on 07/03/2002 17:04:05 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org, Niklas.G.Borg@telia.se Subject RE: [NSIS] section 5.2.2 in requirement draft : Sven, > I think we have to make a distinction between in-band/out-of-band and > centralised/distributed. An out of band solution is not necessarily > centralised. It may, however, be convenient to think about it as > centralised although its implementation can be distributed. Agreed, that was what I tried to indicate with a cluster-of QCs. > This is achieved with the two-level admission control within > long-lived pipes with > defined QoS. This would relax the requirements on the nsis > protocol when > used end-to-end because most of the complexity would be in > the defintion > and provisioing of the long-lived pipes which is a local matter. This was my main question: is the "long-lived pipes"-service something that is within focus of nsis or not? This "long-lived pipes" sounds like provisioning of resources to me. We have been playing with this architecture for awhile as well (a paper coming out in Networks 2002) that describes and analyse an architecture for supporting this. The architecture is doable, but is it really the first thing we should tackle? And should it be tackled in nsis? If the consensus is yes, then I suggest for clarity that the requirements for the two different parts be clearly separated. My hunch is that the two different tracks ("layers") will lead to two different architectures and mixing them will create a fuzzy requirements document. From my point of view, I would be as happy to leave this work for future studies and focus on the first tier (the e2e signaling). And then bring up the discussion on the second-tier seperately. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:21:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26757 for ; Fri, 8 Mar 2002 04:21:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14862 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:21:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13711; Fri, 8 Mar 2002 04:09:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13680 for ; Fri, 8 Mar 2002 04:09:10 -0500 (EST) Received: from odin.di.uoa.gr (odin.di.uoa.gr [195.134.67.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26439 for ; Fri, 8 Mar 2002 04:09:07 -0500 (EST) Received: (from sarantis@localhost) by odin.di.uoa.gr (8.11.6/8.11.6) id g2893PK19905 for nsis@ietf.org; Fri, 8 Mar 2002 11:03:25 +0200 Date: Fri, 8 Mar 2002 11:03:25 +0200 From: Sarantis Paskalis To: nsis@ietf.org Message-ID: <20020308110325.A19599@odin.di.uoa.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [NSIS] Comment on draft-ietf-nsis-req-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi all, While reading the requirement draft I fell upon this requirement: 5.3.7 Automatic notification on available resources not been granted before In many cases, a QoS initiator does want to get a notification when the resource, he requested for some time ago, gets free. In order to keep it simple, information on how long a request is kept and notified. It implies keeping state about requests, which have been rejected. I believe this could lead to scalability and/or security problems and should be removed from the requirements list. To elaborate: - A QI will most likely request again for the service after some time (since this requirement is optional). The QC must then associate the new request with the blocked request, and so on for any further requests. - On peak traffic time, there has to be a policy about informing the blocked QIs or accepting new requests, leading to possible DoS attacks. - It adds design complexity, without catering to NSIS scope. Best Regards, -- Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:22:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26781 for ; Fri, 8 Mar 2002 04:22:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14934 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:22:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13788; Fri, 8 Mar 2002 04:09:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13743 for ; Fri, 8 Mar 2002 04:09:51 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26442 for ; Fri, 8 Mar 2002 04:09:49 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2898Xd02588; Fri, 8 Mar 2002 10:08:45 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: john.loughney@nokia.com Cc: bless@tm.uka.de, nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 10:08:16 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 10:08:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Couldn't it also be something like: Provider A: Of the service S I know you provide I would like 10k Provider B: OK. What do you think? Sven. john.loughney@nokia.com on 08/03/2002 09:47:32 To: bless@tm.uka.de, Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com Subject RE: [NSIS] section 3.5 in nsis-req-00.txt : Roland, > I strongly suggest that nsis should work now on interdomain > QoS signaling. This is a major piece missing in global QoS support. A main > feature of the Internet is its global connectivity (availability of the > "same" basic service), so it would be nice to have at least a few globally > available public/standardized services (aggreement on them is a > business issue, so out of scope). But nsis signaling would allow to request resources of > such services on demand between arbitrary sources and destinations. What are your requirements? Remember, we are not going into how service providers actually provision network resources. Do you want to enable some sort sort of dialog like: Provider A: Hey, do you 10k bandwidth and 50 ms delay? Provider B: Sorry, no. Provider A: Well howabout just 10k bandwidth? Provider B: I do. Provider A: Then I will take it. Or do you want something more complex? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:27:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26867 for ; Fri, 8 Mar 2002 04:27:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15436 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:27:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14171; Fri, 8 Mar 2002 04:14:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14144 for ; Fri, 8 Mar 2002 04:14:17 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26550 for ; Fri, 8 Mar 2002 04:14:14 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA11453; Fri, 8 Mar 2002 10:14:09 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA16619; Fri, 8 Mar 2002 10:14:03 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 10:14:24 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB226@MCHH241E> From: Winter Martin To: "'sven.van_den_bosch@alcatel.be'" , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:14:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Sven > Hi John, > > Couldn't it also be something like: > > Provider A: Of the service S I know you provide I would like 10k > Provider B: OK. > > What do you think? > Sven. > That goes into my direction. The "I know" is important. Let me try to formulate that inter-domain issue as requirement: The QoS protocol MUST support the use of pre-defined services (globally well known services) for requests between domains. > Roland, > > > I strongly suggest that nsis should work now on interdomain > > QoS signaling. This is a major piece missing in global QoS > support. A > main > > feature of the Internet is its global connectivity > (availability of the > > "same" basic service), so it would be nice to have at least a few > globally > > available public/standardized services (aggreement on them is a > > business issue, so out of scope). But nsis signaling would allow to > request resources of > > such services on demand between arbitrary sources and destinations. > > What are your requirements? Remember, we are not going into how > service providers actually provision network resources. Do you want > to enable some sort sort of dialog like: > > Provider A: Hey, do you 10k bandwidth and 50 ms delay? > Provider B: Sorry, no. > Provider A: Well howabout just 10k bandwidth? > Provider B: I do. > Provider A: Then I will take it. > > Or do you want something more complex? > > John > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:28:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26884 for ; Fri, 8 Mar 2002 04:28:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15487 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:28:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14039; Fri, 8 Mar 2002 04:12:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14006 for ; Fri, 8 Mar 2002 04:12:10 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26518 for ; Fri, 8 Mar 2002 04:12:08 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 10:12:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt Date: Fri, 8 Mar 2002 10:12:10 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCBE8@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] Comment on draft-ietf-nsis-req-00.txt Thread-Index: AcHGgOrUAOmAFBFSTfKRSlR9yOkiBAAAIgUg To: , X-OriginalArrivalTime: 08 Mar 2002 09:12:04.0067 (UTC) FILETIME=[50238330:01C1C681] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA14007 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Sarantis, I agree and would propose to write: The nsis architecture MUST NOT support "automatic notification on available resources not been granted before". or just to remove the requirement. Anders > Hi all, > > While reading the requirement draft I fell upon this requirement: > > 5.3.7 Automatic notification on available resources not been granted > before > > In many cases, a QoS initiator does want to get a notification when > the resource, he requested for some time ago, gets free. > In order to > keep it simple, information on how long a request is kept and > notified. It implies keeping state about requests, which have been > rejected. > > I believe this could lead to scalability and/or security problems and > should be removed from the requirements list. > > To elaborate: > - A QI will most likely request again for the service after some time > (since this requirement is optional). The QC must then associate > the new request with the blocked request, and so on for any further > requests. > - On peak traffic time, there has to be a policy about informing the > blocked QIs or accepting new requests, leading to possible > DoS attacks. > - It adds design complexity, without catering to NSIS scope. > > Best Regards, > > -- Sarantis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:29:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26905 for ; Fri, 8 Mar 2002 04:29:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15539 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:29:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14334; Fri, 8 Mar 2002 04:16:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14303 for ; Fri, 8 Mar 2002 04:16:48 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26596 for ; Fri, 8 Mar 2002 04:16:46 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289GsZ07586 for ; Fri, 8 Mar 2002 11:16:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:16:43 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:16:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt Date: Fri, 8 Mar 2002 11:16:43 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B86@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Comment on draft-ietf-nsis-req-00.txt Thread-Index: AcHGgOrUAOmAFBFSTfKRSlR9yOkiBAAAIgUgAAAYw9A= To: , , X-OriginalArrivalTime: 08 Mar 2002 09:16:43.0811 (UTC) FILETIME=[F6E10F30:01C1C681] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA14304 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > I agree and would propose to write: > > The nsis architecture MUST NOT support "automatic > notification on available resources not been granted before". > > or just to remove the requirement. The two things are entirely different. The best solution is to remove the requirement. MUST NOT requirements are generally used when something is known to cause incompatabilities. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:30:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26932 for ; Fri, 8 Mar 2002 04:30:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15695 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:30:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14423; Fri, 8 Mar 2002 04:17:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14385 for ; Fri, 8 Mar 2002 04:17:38 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26614 for ; Fri, 8 Mar 2002 04:17:36 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289IGi10582 for ; Fri, 8 Mar 2002 11:18:16 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:17:37 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:17:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:17:36 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B87@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGgaEZliZQRiR+S2qguCp1LzhroQAAGT6A To: , , X-OriginalArrivalTime: 08 Mar 2002 09:17:37.0313 (UTC) FILETIME=[16C4D110:01C1C682] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA14386 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Martin, > That goes into my direction. The "I know" is important. Let > me try to formulate that inter-domain issue as requirement: > > The QoS protocol MUST support the use of pre-defined services > (globally well known services) for requests between domains. Question - where do the pre-defined services get defined? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:31:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26976 for ; Fri, 8 Mar 2002 04:31:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16129 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:31:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14108; Fri, 8 Mar 2002 04:13:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14079 for ; Fri, 8 Mar 2002 04:13:10 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26538 for ; Fri, 8 Mar 2002 04:13:08 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g289Cbs03999; Fri, 8 Mar 2002 10:12:37 +0100 (MET) Subject: RE: [NSIS] section 5.2.2 in requirement draft To: john.loughney@nokia.com Cc: Anders.P.Bergsten@telia.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 10:12:28 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 10:12:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, I agree with your explanation but I don't think your wording really reflects what you say there. Would you agree to something like: NSIS SHOULD support on-path signaling and signaling to and/or from known entities. The default behaviour SHOULD be on-path signaling. Sven. john.loughney@nokia.com on 08/03/2002 09:42:06 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Anders.P.Bergsten@telia.se cc: nsis@ietf.org Subject RE: [NSIS] section 5.2.2 in requirement draft : Hi Sven, To summarize the requirements with regards to on-path vs. off-path signaling, we may have to say this: NSIS SHOULD support on-path signaling. NSIS MAY support signaling to known entities. Perhaps my word-usage could be tweaked, but what I mean is the default signaling is on-path, but if an endpoint knows where it wants to signaling to (pre-configured or something) is should be allowed as well. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:34:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27029 for ; Fri, 8 Mar 2002 04:34:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16248 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:34:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14787; Fri, 8 Mar 2002 04:20:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14728 for ; Fri, 8 Mar 2002 04:20:41 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26741 for ; Fri, 8 Mar 2002 04:20:38 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289KnZ10290 for ; Fri, 8 Mar 2002 11:20:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:20:36 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:20:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 11:20:38 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B89@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 5.2.2 in requirement draft Thread-Index: AcHGgWVw4aV7/1zJTVeXtAAf3RKUfQAAOFJQ To: Cc: , X-OriginalArrivalTime: 08 Mar 2002 09:20:39.0496 (UTC) FILETIME=[835BBC80:01C1C682] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA14730 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, > I agree with your explanation but I don't think your wording really > reflects what you say there. Would you agree to something like: > NSIS SHOULD support on-path signaling and signaling to and/or > from known entities. The default behaviour SHOULD be on-path signaling. I prefer to have single statement requirements, so I'd suggest we have 3 requirements: NSIS SHOULD support on-path signaling. NSIS SHOULD support signaling to and/or from known entities. The default behaviour SHOULD be on-path signaling. Fufilling requirements with multiple clauses is difficult. (also we can discuss the level - MUST/SHOULD/MAY ...) John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:34:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27045 for ; Fri, 8 Mar 2002 04:34:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16262 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:34:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14748; Fri, 8 Mar 2002 04:20:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14645 for ; Fri, 8 Mar 2002 04:20:37 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26737 for ; Fri, 8 Mar 2002 04:20:35 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jGYF-0005Li-00; Fri, 08 Mar 2002 10:20:35 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jGYE-0007Fs-00; Fri, 08 Mar 2002 10:20:34 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g289KYf14998; Fri, 8 Mar 2002 10:20:34 +0100 Message-Id: <200203080920.g289KYf14998@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from of "Fri, 08 Mar 2002 10:47:32 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7F@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7F@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 10:20:34 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > > I strongly suggest that nsis should work now on interdomain > > QoS signaling. This is a major piece missing in global QoS support. A main > > feature of the Internet is its global connectivity (availability of the > > "same" basic service), so it would be nice to have at least a few globally > > available public/standardized services (aggreement on them is a > > business issue, so out of scope). But nsis signaling would allow to request resources of > > such services on demand between arbitrary sources and destinations. > > What are your requirements? Remember, we are not going into how > service providers actually provision network resources. Do you want Right, this is a local matter. My last phrase could be misinterpreted, sorry. > to enable some sort sort of dialog like: > > Provider A: Hey, do you 10k bandwidth and 50 ms delay? > Provider B: Sorry, no. > Provider A: Well howabout just 10k bandwidth? > Provider B: I do. > Provider A: Then I will take it. > > Or do you want something more complex? No, definitely not. I think that your example may be even too complex. The set of service parameters should be fixed and only depend on the service (so either always bandwidth and delay or only bandwidth). To avoid several iterations of requests, parameter intervals should be allowed within service parameter objects: Provider A: Can I get service X towards destination z with bandwidth between 32k and 128k? Provider B: Service X with 64k is available now. So in the request a range of acceptable parameter values is specified. Any value within the range will be acceptable for the requester, so the last dialogue of your example will not be necessary. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:38:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27088 for ; Fri, 8 Mar 2002 04:38:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16497 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:38:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15237; Fri, 8 Mar 2002 04:25:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15204 for ; Fri, 8 Mar 2002 04:25:32 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26845 for ; Fri, 8 Mar 2002 04:25:29 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289PeZ13986 for ; Fri, 8 Mar 2002 11:25:40 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:25:21 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:25:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:25:24 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8A@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGgokCuG7FXD0cQqu6t7lyYG+qFQAABSMg To: Cc: , , , X-OriginalArrivalTime: 08 Mar 2002 09:25:24.0385 (UTC) FILETIME=[2D2A5910:01C1C683] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15205 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Roland, > So in the request a range of acceptable parameter values is > specified. Any value within the range will be acceptable > for the requester, so the last dialogue of your example will > not be necessary. So, you would like these requirements to be: Ability to request from a range of QoS parameters -> the problem is, then what is the policy in fufilling the range, lowest value, highest value, medium value, etc. One solution is not to use absolute QoS parameters, but to use relative. > So in the request a range of acceptable parameter values is > specified. Any value within the range will be acceptable > for the requester, so the last dialogue of your example will > not be necessary. Does this mean there should not be any acknowledgement of what is then accepted? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:38:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27105 for ; Fri, 8 Mar 2002 04:38:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16512 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:38:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15189; Fri, 8 Mar 2002 04:25:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15161 for ; Fri, 8 Mar 2002 04:25:09 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26836 for ; Fri, 8 Mar 2002 04:25:07 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 10:25:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 10:25:09 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCBEA@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 5.2.2 in requirement draft Thread-Index: AcHGgWVw4aV7/1zJTVeXtAAf3RKUfQAAOFJQAABJTyA= To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 09:25:02.0924 (UTC) FILETIME=[205FA8C0:01C1C683] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15162 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit All, could we agree on the following? NSIS SHOULD support on-path signaling. NSIS MAY support signaling to and/or from known entities. (btw: maybe the first req. should be a MUST) Anders > > I agree with your explanation but I don't think your wording really > > reflects what you say there. Would you agree to something like: > > NSIS SHOULD support on-path signaling and signaling to and/or > > from known entities. The default behaviour SHOULD be > on-path signaling. > > I prefer to have single statement requirements, so I'd suggest we have > 3 requirements: > > > NSIS SHOULD support on-path signaling. > NSIS SHOULD support signaling to and/or from known entities. > The default behaviour SHOULD be on-path signaling. > > Fufilling requirements with multiple clauses is difficult. > (also we can discuss the level - MUST/SHOULD/MAY ...) > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:41:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27196 for ; Fri, 8 Mar 2002 04:41:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16722 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:42:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15334; Fri, 8 Mar 2002 04:26:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15299 for ; Fri, 8 Mar 2002 04:26:17 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26851 for ; Fri, 8 Mar 2002 04:26:15 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289QQZ14696 for ; Fri, 8 Mar 2002 11:26:26 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:26:03 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:26:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 11:26:06 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8B@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 5.2.2 in requirement draft Thread-Index: AcHGgWVw4aV7/1zJTVeXtAAf3RKUfQAAOFJQAABJTyAAAAs1QA== To: , Cc: X-OriginalArrivalTime: 08 Mar 2002 09:26:07.0039 (UTC) FILETIME=[4696D4F0:01C1C683] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15300 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > NSIS SHOULD support on-path signaling. > NSIS MAY support signaling to and/or from known entities. > (btw: maybe the first req. should be a MUST) I agree. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:49:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27300 for ; Fri, 8 Mar 2002 04:49:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17329 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:49:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16379; Fri, 8 Mar 2002 04:35:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16348 for ; Fri, 8 Mar 2002 04:35:57 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27067 for ; Fri, 8 Mar 2002 04:35:50 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA13449; Fri, 8 Mar 2002 10:35:46 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA18316; Fri, 8 Mar 2002 10:35:37 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 10:36:00 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB227@MCHH241E> From: Winter Martin To: "'john.loughney@nokia.com'" , sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:36:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > Martin, > > > That goes into my direction. The "I know" is important. Let > > me try to formulate that inter-domain issue as requirement: > > > > The QoS protocol MUST support the use of pre-defined services > > (globally well known services) for requests between domains. > > Question - where do the pre-defined services get defined? > > John NOT in NSIS. The "where" is a good question. Do we have to solve it here and now? (means: I do not have an answer ;-) My requirement more looks into the consequences and possibilities it offers for interdomain signalling: - globally well known services provide the possibility to aggregate reservations of the same service. I can hardly imagine that this would be possible at some intermediate domain without that. - globally well known services make it easier to define the edge-to-edge (or whatever the range of the NSIS signalling is) service, which originates from chaining of multiple domains. If each domain would be allowed to define fully independently specified services, then you cannot deliver anything well-defined edge-to-edge. Again, I neither want to define these services in NSIS nor specify, how they are chained. But I want to give the possibility to do that. Else I fear, that we might end up with a protocol, which is later on unusable for inter-domain reservations. I just want to avoid that. -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:49:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27318 for ; Fri, 8 Mar 2002 04:49:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17363 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:49:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16428; Fri, 8 Mar 2002 04:36:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16401 for ; Fri, 8 Mar 2002 04:36:37 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27071 for ; Fri, 8 Mar 2002 04:36:35 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 10:36:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 10:36:38 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCBEB@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGgoSGuOdnbFKKQMydJWZgkjqRqAAASCsg To: , Cc: , , X-OriginalArrivalTime: 08 Mar 2002 09:36:38.0186 (UTC) FILETIME=[BEC838A0:01C1C684] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA16402 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John and Roland, I agree with Roland to a large extent (ie this is too complex). I would like the draft to state requirements that the model that should be supproted is: - Provider offers a service (describe by some parameters) - Customer buy from this service (described by some parameters) Thus a behaviour like: Provider A: I have service X, Y, Z (described in some way) Customer B: I want b amount of the service X. Provider A: Ok. So the requirements would be something like: NSIS SHOULD support the advertisement of services from a provider to a customer. NSIS MUST support an instantiation of a service from a customer towards a provider. Furthermore: NSIS MUST NOT restrict the way that a provider is describing the service. NSIS SHOULD support globally well-known service, if such services exists. Anders > > to enable some sort sort of dialog like: > > > > Provider A: Hey, do you 10k bandwidth and 50 ms delay? > > Provider B: Sorry, no. > > Provider A: Well howabout just 10k bandwidth? > > Provider B: I do. > > Provider A: Then I will take it. > > > > Or do you want something more complex? > > No, definitely not. I think that your example may be even too > complex. The set of service parameters should be fixed and only depend > on the service (so either always bandwidth and delay or only > bandwidth). > To avoid several iterations of requests, parameter intervals > should be > allowed within service parameter objects: > Provider A: Can I get service X towards destination z with bandwidth > between 32k and 128k? > Provider B: Service X with 64k is available now. > > So in the request a range of acceptable parameter values is > specified. Any value within the range will be acceptable > for the requester, so the last dialogue of your example will > not be necessary. > > Regards, > Roland > > -- > Roland Bless -- e-Mail: bless@tm.uka.de > Institute of Telematics, University of Karlsruhe, Germany > Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 > Phone: +49 721 608-6413 Fax: +49 721 388097 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:55:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27410 for ; Fri, 8 Mar 2002 04:55:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17681 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:55:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16778; Fri, 8 Mar 2002 04:42:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16736 for ; Fri, 8 Mar 2002 04:42:11 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27210 for ; Fri, 8 Mar 2002 04:42:08 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jGt6-0005jU-00; Fri, 08 Mar 2002 10:42:08 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jGt6-0007l4-00; Fri, 08 Mar 2002 10:42:08 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g289g8f15291; Fri, 8 Mar 2002 10:42:08 +0100 Message-Id: <200203080942.g289g8f15291@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from of "Fri, 08 Mar 2002 11:25:24 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8A@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8A@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 10:42:07 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > > So in the request a range of acceptable parameter values is > > specified. Any value within the range will be acceptable > > for the requester, so the last dialogue of your example will > > not be necessary. > > So, you would like these requirements to be: > > Ability to request from a range of QoS parameters In some sense yes, but this requirement relates to the service object which is transparent for nsis and service dependent, so not really in nsis scope. > -> the problem is, then what is the policy in fufilling > the range, lowest value, highest value, medium value, > etc. One solution is not to use absolute QoS parameters, > but to use relative. Oh, just as I said: Any value within the range will be fine for the requesting party, and, thus accepted. If one needs a specific value, you just set the interval bounds to an equal value. The policy for admission control also depends on the concrete QoS parameter (out of nsis scope). Thus, a service provider may test for the higher bandwidth value at first and later for the lower value, whereas for delay it is typically the other way round. However, this is not something we really have to directly deal with. > > So in the request a range of acceptable parameter values is > > specified. Any value within the range will be acceptable > > for the requester, so the last dialogue of your example will > > not be necessary. > > Does this mean there should not be any acknowledgement > of what is then accepted? Yes, let's keep thing simple. The requesting party won't have to acknowledge the result explicitly, because any result within the range has to be accepted. Otherwise the requester should have specified a different interval. However, there is always the possibility to abort a reservation at any time. An explicit acknowledgement would imply that another round trip time would be required to actually activate the pre-reserved resources along the path. This should be avoided. Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:58:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27480 for ; Fri, 8 Mar 2002 04:58:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17829 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:58:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16961; Fri, 8 Mar 2002 04:44:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16930 for ; Fri, 8 Mar 2002 04:44:22 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27237 for ; Fri, 8 Mar 2002 04:44:19 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289hi329957 for ; Fri, 8 Mar 2002 11:43:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:44:20 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:44:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:44:19 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGgoSGuOdnbFKKQMydJWZgkjqRqAAASCsgAABjA8A= To: , Cc: , , X-OriginalArrivalTime: 08 Mar 2002 09:44:20.0075 (UTC) FILETIME=[D216E3B0:01C1C685] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA16931 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > - Provider offers a service (describe by some parameters) > - Customer buy from this service (described by some parameters) Isn't this the current model in RSVP? How does this work on a peer-to-peer case? If I call you, do I have to see what kind of QoS you are advertising? Shouldn't service advertisement be handled at the application level, not the transport (NSIS) level? In my (non-chair) opinion, I'd prefer this model 1) higher-level service information exchange happens (or is preconfigured / pre-known) 2) Consumer: I want X 3) Provider: Can't fufill X Then the consumer can think if they would like to ask for y ... (note: x may not be able to be fufilled for many reasons, one could be because of a lack of resources, etc.) John > Thus a behaviour like: > Provider A: I have service X, Y, Z (described in some way) > Customer B: I want b amount of the service X. > Provider A: Ok. > > So the requirements would be something like: > > NSIS SHOULD support the advertisement of services from a > provider to a customer. > NSIS MUST support an instantiation of a service from a > customer towards a provider. > Furthermore: > NSIS MUST NOT restrict the way that a provider is describing > the service. > NSIS SHOULD support globally well-known service, if such > services exists. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 04:59:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27512 for ; Fri, 8 Mar 2002 04:59:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17940 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 04:59:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17121; Fri, 8 Mar 2002 04:46:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17088 for ; Fri, 8 Mar 2002 04:46:25 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27270 for ; Fri, 8 Mar 2002 04:46:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g289kWZ29855 for ; Fri, 8 Mar 2002 11:46:32 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:46:21 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:46:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:46:21 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGhZa42ZVdguIBQRu4IHyifWUQfwAAFf6Q To: Cc: , , , X-OriginalArrivalTime: 08 Mar 2002 09:46:21.0633 (UTC) FILETIME=[1A8B2B10:01C1C686] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA17089 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Roland, > > Does this mean there should not be any acknowledgement > > of what is then accepted? > > Yes, let's keep thing simple. > The requesting party won't have to acknowledge the result > explicitly, because any result within the range has to be > accepted. Actually, I meant the provider - does the provider give an ack? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:19:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27822 for ; Fri, 8 Mar 2002 05:19:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19578 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:19:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18726; Fri, 8 Mar 2002 05:06:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18695 for ; Fri, 8 Mar 2002 05:06:43 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27622 for ; Fri, 8 Mar 2002 05:06:40 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jHGr-0006Cc-00; Fri, 08 Mar 2002 11:06:41 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jHGr-0000WC-00; Fri, 08 Mar 2002 11:06:41 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g28A6ef15543; Fri, 8 Mar 2002 11:06:40 +0100 Message-Id: <200203081006.g28A6ef15543@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from of "Fri, 08 Mar 2002 11:46:21 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8E@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8E@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 11:06:40 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > > Yes, let's keep thing simple. > > The requesting party won't have to acknowledge the result > > explicitly, because any result within the range has to be > > accepted. > > Actually, I meant the provider - does the provider give an > ack? Sure. We have a simple request/response dialogue 1. Request: Provider A --> Req --> Provider B 2. Response: Provider A <-- Rsp <-- Provider B The latter is either ACK or NAK. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:20:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27861 for ; Fri, 8 Mar 2002 05:20:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19664 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:20:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18786; Fri, 8 Mar 2002 05:06:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18751 for ; Fri, 8 Mar 2002 05:06:53 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27637 for ; Fri, 8 Mar 2002 05:06:50 -0500 (EST) From: maarten.buchli@alcatel.be Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28A6Io21149; Fri, 8 Mar 2002 11:06:18 +0100 (MET) Subject: RE: [NSIS] section 5.2.2 in requirement draft To: john.loughney@nokia.com Cc: Anders.P.Bergsten@telia.se, sven.van_den_bosch@alcatel.be, nsis@ietf.org Date: Fri, 8 Mar 2002 11:06:17 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 11:06:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Anders, all I fully agree of course that in-band signaling SHOULD be supported (this could be even a MUST). Since we do not want to constrain ourselves to a particular solution I would like propose that both in-band and out-of-band signaling should be supported. Adding a default behavior as proposed before today on the mailinglist is then a good idea. Hence, I am in favor of three requirements: 1. NSIS SHOULD (MUST?) support on-path signaling. 2. NSIS SHOULD support signaling to and/or from known entities. 3. The default behaviour SHOULD be on-path signaling. Maarten. john.loughney@nokia.com on 08/03/2002 10:26:06 To: Anders.P.Bergsten@telia.se, Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org(bcc: Maarten BUCHLI/BE/ALCATEL) Subject: RE: [NSIS] section 5.2.2 in requirement draft Hi Anders, > NSIS SHOULD support on-path signaling. > NSIS MAY support signaling to and/or from known entities. > (btw: maybe the first req. should be a MUST) I agree. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:21:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27880 for ; Fri, 8 Mar 2002 05:20:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19678 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:21:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18849; Fri, 8 Mar 2002 05:08:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18820 for ; Fri, 8 Mar 2002 05:08:23 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27655 for ; Fri, 8 Mar 2002 05:08:20 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 11:06:17 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:07:47 +0100 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:07:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA18821 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, the answer is not within NSIS. The remainder of this reply then is out of scope but it may help to understand the motivation of the requirement of signaling for globally well known services: - Check ITU-T Y.1541 for public service definitions. - Internet2 and the European Geant project specified public services. - Some carriers IP networks are subdivided into autonomus national business units (holds for my company, but I guess also for e.g. UUNET). Here private service definitions apply. For my company there's interest in inter domain resource reservation. - Some research networks are consisting of autonomus regional, national and international IP networks. E.g. Internet2 and Geant. Service negotiation by a signaled service specification is rather complex. Allright. NSIS requirements: NSIS must support a flexible service definition not restricting contents and meaning of individual service descriptions. Services may either be private or public. An example of a solution is: Mandatory TLV: Service ID - private/public service flag - Service Name (16 bit should do it) - Service Specific Parametrisation (required/not required) flag Conditional TLV(i.e. MUST be present according to service definition): Service Specific Parametrisation - Whatever service specification requires as parameters This allows some flexibility. I'm aware that some standards body needs to control public services. But I guess that's feasible. Regards, Rüdiger > > That goes into my direction. The "I know" is important. Let > > me try to formulate that inter-domain issue as requirement: > > > > The QoS protocol MUST support the use of pre-defined services > > (globally well known services) for requests between domains. > > Question - where do the pre-defined services get defined? > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:21:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27897 for ; Fri, 8 Mar 2002 05:21:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19693 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:21:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18898; Fri, 8 Mar 2002 05:08:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18863 for ; Fri, 8 Mar 2002 05:08:30 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27670 for ; Fri, 8 Mar 2002 05:08:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28A8cZ19653 for ; Fri, 8 Mar 2002 12:08:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 12:08:28 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 12:08:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 12:08:27 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B90@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGiQej/YTGSbTtSOqPRsR++mxe/wAAB6CA To: Cc: , , , X-OriginalArrivalTime: 08 Mar 2002 10:08:28.0511 (UTC) FILETIME=[316CAEF0:01C1C689] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA18864 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Roland, > Sure. We have a simple request/response dialogue > > 1. Request: Provider A --> Req --> Provider B > 2. Response: Provider A <-- Rsp <-- Provider B > > The latter is either ACK or NAK. We're in total agreement, then. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:26:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27998 for ; Fri, 8 Mar 2002 05:26:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20042 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:26:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19108; Fri, 8 Mar 2002 05:13:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19077 for ; Fri, 8 Mar 2002 05:13:33 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27731 for ; Fri, 8 Mar 2002 05:13:30 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 11:13:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:13:26 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBC3@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGgoSGuOdnbFKKQMydJWZgkjqRqAAASCsgAABjA8AAAE/uUA== To: , Cc: , , X-OriginalArrivalTime: 08 Mar 2002 10:13:26.0754 (UTC) FILETIME=[E330F420:01C1C689] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA19078 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, here we comes to the split between interdomain and application again. RSVP deals with the latter. The previous is yet undefined when it comes to automatic management (although BGP is advertising one service - connectivity). The requirements that I wrote tried to strike a balance between what can be done and what is necessary between two carriers. The three parts (advertisement, 'query of amount', and an acknowledgement) are necessary to happen. Then you can add a negotiation part, but I do not see this as necessary (neither did Roland, Ruediger etc, if I understood them correctly). (think about RSVP as well, the signaling protocol actually knows what to ask for. Ie an advertisement has occured. This has been specified by a standards body. Relaxing this so that I as a service provider can describe the service is just one step away and is not as restricting as 'globally well-known services'). I tried to capture the required inter-domain parts by saying: the advertisement may be automated (there exists proposals for this), at least it should be open to the carrier/provider to decide what services it offers. The second and third phase must happen. Again, in the inter-domain case, all of this can happen before nsis kicks in. > > - Provider offers a service (describe by some parameters) > > - Customer buy from this service (described by some parameters) > > Isn't this the current model in RSVP? How does this work on > a peer-to-peer case? If I call you, do I have to see > what kind of QoS you are advertising? > > Shouldn't service advertisement be handled at the application > level, not the transport (NSIS) level? > > In my (non-chair) opinion, I'd prefer this model > > 1) higher-level service information exchange happens > (or is preconfigured / pre-known) > 2) Consumer: I want X > 3) Provider: Can't fufill X Yes, this is pretty much what I stated. I used the term SHOULD for the advertisement but could have used the term MAY. At least, we are assuming that such a mechanism exists so either it goes into the assumption part or the requirement part. Did that clarify what I wrote? Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:27:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28029 for ; Fri, 8 Mar 2002 05:27:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20082 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:27:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19160; Fri, 8 Mar 2002 05:15:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19135 for ; Fri, 8 Mar 2002 05:15:12 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27750 for ; Fri, 8 Mar 2002 05:15:09 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 11:13:05 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:14:35 +0100 Message-Id: From: "Geib, Ruediger" To: Martin.Winter@icn.siemens.de Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:14:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA19136 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Martin, I absolutely agree to and appreciate your clarification of how to do per domain aggregation and interdomain automated resource reservation. If scenarios are drafted describing how carriers could make use of NSIS, this should get part of it. Regards, Rüdiger > - globally well known services provide the possibility to > aggregate reservations of the same service. I can hardly > imagine that this would be possible at some intermediate > domain without that. > > - globally well known services make it easier to define the > edge-to-edge (or whatever the range of the NSIS signalling > is) service, which originates from chaining of multiple > domains. If each domain would be allowed to define fully > independently specified services, then you cannot deliver > anything well-defined edge-to-edge. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:31:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28089 for ; Fri, 8 Mar 2002 05:31:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20542 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:31:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19338; Fri, 8 Mar 2002 05:17:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19310 for ; Fri, 8 Mar 2002 05:17:10 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27775 for ; Fri, 8 Mar 2002 05:17:06 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28AHli09016 for ; Fri, 8 Mar 2002 12:17:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 12:17:08 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 12:17:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 12:17:07 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D5A@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGiRztLCLBrHvZTjinJuhrRixK4AAADLJQ To: Cc: X-OriginalArrivalTime: 08 Mar 2002 10:17:08.0179 (UTC) FILETIME=[672BBA30:01C1C68A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA19311 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Rüdiger, > the answer is not within NSIS. The remainder of this reply > then is out of scope but it may help to understand the > motivation of the requirement of signaling for globally well > known services: That is what I was thinking. > Allright. NSIS requirements: > > NSIS must support a flexible service definition not > restricting contents and meaning of individual service > descriptions. Services may either be private or public. Would these requirements be OK? NSIS SHOULD support application level service descriptions. NSIS MAY consider support for service descriptions developed by other SDOs. This would mean that applications could do the service negotiations, and pass this info to NSIS. It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS classes. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:31:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28105 for ; Fri, 8 Mar 2002 05:31:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20612 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:31:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19477; Fri, 8 Mar 2002 05:18:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19436 for ; Fri, 8 Mar 2002 05:18:24 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27802 for ; Fri, 8 Mar 2002 05:18:20 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28AIVZ27911 for ; Fri, 8 Mar 2002 12:18:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 12:18:18 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 12:18:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 12:18:21 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B92@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGh6raFmBE+1AtT2mYLqOopXDadgAAsrFw To: Cc: , , , X-OriginalArrivalTime: 08 Mar 2002 10:18:21.0566 (UTC) FILETIME=[92E9B1E0:01C1C68A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA19437 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, > Couldn't it also be something like: > > Provider A: Of the service S I know you provide I would like 10k > Provider B: OK. Sure, or it could even be: Provider A: Give me service x, and if you can support 150 ms delay, do that too. Provider B: OK. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 05:55:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28399 for ; Fri, 8 Mar 2002 05:55:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21964 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 05:55:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21168; Fri, 8 Mar 2002 05:41:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21094 for ; Fri, 8 Mar 2002 05:41:36 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28265 for ; Fri, 8 Mar 2002 05:41:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28AfiZ16020 for ; Fri, 8 Mar 2002 12:41:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 12:41:26 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 12:41:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 12:41:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B96@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGjaCMOGcXD8FmRR+z52am9KhyBQAAAyTg To: Cc: X-OriginalArrivalTime: 08 Mar 2002 10:41:29.0662 (UTC) FILETIME=[CE4855E0:01C1C68D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA21095 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, > I'd appreciate if NSIS takes care of the issue (a MAY is fine > for now). The first requirement may be reworded to clarify > that NSIS does not define the service (I'm neither a native > speaker nor a legal expert, so I'm not sure whether your > suggestion does so). > NSIS then MAY be the IETF WG to collect, check and > administrate the service description coded according to NSIS > rules? If you don't know the answer we could have a look on > the RTP spec's. Also they support a mechanism offering a > signaling framework which may be (and is) filled by later > individual specifications. This would be a very good way forward - an IANA registry for QoS descriptions. NSIS WG would define the basic way to carry it. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 06:01:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28490 for ; Fri, 8 Mar 2002 06:01:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22585 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 06:01:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21042; Fri, 8 Mar 2002 05:40:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21010 for ; Fri, 8 Mar 2002 05:40:41 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28255 for ; Fri, 8 Mar 2002 05:40:38 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 11:38:37 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:40:08 +0100 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com, "Geib, Ruediger" Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 11:40:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA21011 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John, I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). The first requirement may be reworded to clarify that NSIS does not define the service (I'm neither a native speaker nor a legal expert, so I'm not sure whether your suggestion does so). NSIS then MAY be the IETF WG to collect, check and administrate the service description coded according to NSIS rules? If you don't know the answer we could have a look on the RTP spec's. Also they support a mechanism offering a signaling framework which may be (and is) filled by later individual specifications. Regards, Rüdiger > > NSIS must support a flexible service definition not > > restricting contents and meaning of individual service > > descriptions. Services may either be private or public. > > Would these requirements be OK? > > NSIS SHOULD support application level service descriptions. > > NSIS MAY consider support for service descriptions developed > by other SDOs. > > This would mean that applications could do the service negotiations, > and pass this info to NSIS. > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > classes. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 06:16:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28687 for ; Fri, 8 Mar 2002 06:16:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23179 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 06:16:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22361; Fri, 8 Mar 2002 06:00:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22317 for ; Fri, 8 Mar 2002 06:00:51 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28464 for ; Fri, 8 Mar 2002 06:00:48 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28B0oZc004286 for ; Fri, 8 Mar 2002 12:00:50 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 11:38:09 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:38:09 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , Anders.P.Bergsten@telia.se, sarantis@cnl.di.uoa.gr, nsis@ietf.org Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt Date: Fri, 8 Mar 2002 11:37:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Anders and Paskali I also agree, please remove this requirement! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 8 maart 2002 10:17 To: Anders.P.Bergsten@telia.se; sarantis@cnl.di.uoa.gr; nsis@ietf.org Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt Hi Anders, > I agree and would propose to write: > > The nsis architecture MUST NOT support "automatic > notification on available resources not been granted before". > > or just to remove the requirement. The two things are entirely different. The best solution is to remove the requirement. MUST NOT requirements are generally used when something is known to cause incompatabilities. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 06:24:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28758 for ; Fri, 8 Mar 2002 06:24:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23430 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 06:24:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23035; Fri, 8 Mar 2002 06:11:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23002 for ; Fri, 8 Mar 2002 06:11:04 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28623 for ; Fri, 8 Mar 2002 06:11:01 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jIH8-0007Ky-00; Fri, 08 Mar 2002 12:11:02 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jIH7-0001sH-00; Fri, 08 Mar 2002 12:11:01 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g28BB1f20029; Fri, 8 Mar 2002 12:11:01 +0100 Message-Id: <200203081111.g28BB1f20029@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Anders.P.Bergsten@telia.se cc: john.loughney@nokia.com, sven.van_den_bosch@alcatel.be, nsis@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from of "Fri, 08 Mar 2002 10:36:38 +0100." <1BF8A5964E4EFA41A094B835FCA712912CCBEB@TMS041MB.tcad.telia.se> References: <1BF8A5964E4EFA41A094B835FCA712912CCBEB@TMS041MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 12:11:01 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, > I agree with Roland to a large extent (ie this is too complex). > > I would like the draft to state requirements that the model that should be supproted is: > > - Provider offers a service (describe by some parameters) > - Customer buy from this service (described by some parameters) > > Thus a behaviour like: > Provider A: I have service X, Y, Z (described in some way) > Customer B: I want b amount of the service X. > Provider A: Ok. I don't think we need the service advertisement now (can be an option, but is not a requirement). This can be agreed out of nsis. I would prefer: if customer requests a service (e.g. identified by a unique ID) and if this service is not supported by a provider it rejects the requests with a "service not supported" reply. Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 06:28:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28807 for ; Fri, 8 Mar 2002 06:28:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23627 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 06:28:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22763; Fri, 8 Mar 2002 06:04:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22730 for ; Fri, 8 Mar 2002 06:04:43 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28537 for ; Fri, 8 Mar 2002 06:04:40 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g28B4gB17600 for ; Fri, 8 Mar 2002 12:04:42 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 11:45:05 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:45:02 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Subject: RE: [NSIS] section on QI/QC and QI/QC terminology Date: Fri, 8 Mar 2002 11:43:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven I propose to postpone the terminology of QoS Initiator and QoS Controller to framework draft. Meaning that the terms QoS Initiator and QoS Controller will not be used in the NSIS WG requirements draft. The main reason for this is that, according to John, the NSIS WG requirements draft should not contain any separation/grouping of QoS requirements. This separation will probably be done in the framework draft. There we could also define entities such as QI and QC. Best Regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: dinsdag 5 maart 2002 14:31 To: nsis@ietf.org Cc: maarten.buchli@alcatel.be; danny.goderis@alcatel.be; robert.hancock@roke.co.uk; cornelia.kappler@icn.siemens.de Subject: [NSIS] section on QI/QC and QI/QC terminology Hi, We have been thinking about the QI/QC definitions and we have tried to arrange the QC/QI functional entities in a logical relation that covers the use case scenarios that have been proposed so far. From this, we hope to derive clearer definitions. The general logical relationships are depicted below (for simplicity, only signaling relations are drawn) +--+ (a) +--+ (a) +--+ (a) +---+ +->|QI|---->|QC|---------------->|QC|---->| QR|--+ QI,QC,QR roles for e2e QoS protocol | +--+ /+--+\ /+--+\ +---+ | | / \ / \ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this pictures we clearly distinguish two applications for the NSIS protocol: (a) NSIS as end-to-end QoS signaling protocol (b) NSIS as local QoS signaling protocol Local, in this case, is defined as local to a QoS domain. A QoS domain is defined as a contiguous part of the network supporting the same QoS technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS actually competes with other technologies offering local QoS, such as PDP, RSVP, ... The above picture seems to suggest an out-of-band approach but this is not the case. The QCs can be implemented in a distributed way and redrawing the picture then gives a different view. +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| QI,QC,QR roles for e2e QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ ^ v ^ v ^ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this case, it is clear that an in-band solution is also supported. The end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a router. Note that in this picture, the signaling in the access is done with a local QoS protocol. This can be either an existing protocol, or the NSIS protocol in its role of local QoS signaling mechanism. This leads to the following requirements: (a) If an NSIS protocol is only used end-to-end, then mobility need not be supported (b) If an NSIS protocol is used as a local QoS signaling mechanism then mobility must be supported, both on the QI-QC and QC-QC interface (c) If the same protocol is desired in (a) and (b), the protocol should be modular and the mobility aspects need to be separable from the rest Both of the above scenarios assume that the host is not NSIS-aware. This is a reasonable assumption in a first phase. In a later stage, when hosts are NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling technology! This allows this case to be backwards compatible with the above scenarios. It means that (b) in the access is an NSIS protocol. It also means that the host will always trigger the local QoS signaling mechanism. This suggests the following definitions for the QI, QC, QR - QoS Initiator: Network entity, located at the boundary of a QoS domain, responsible for initiating a (local or end-to-end) QoS mechanism. If it is the QI of a local protocol, it can be triggered by higher layers (applications or end-to-end QoS Controller). If it is the QI of an end-to-end protocol, it can be triggered by applications or by the QoS Receiver of a local QoS signaling mechanism. - QoS Controller: Network entity responsible for interpreting and implementing the signalled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by a QI or another QC. -QoS Receiver: Network entity, located at the boundary of a QoS domain, responsible for terminating a (local or end-to-end) QoS mechanism. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol. If this can be accepted by the NSIS community, we propose to add this text to the requirements document as a clarification of the QI/QC model that is used there. Hope this helps, Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 06:50:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29129 for ; Fri, 8 Mar 2002 06:50:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24769 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 06:49:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24312; Fri, 8 Mar 2002 06:34:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24281 for ; Fri, 8 Mar 2002 06:34:12 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28909 for ; Fri, 8 Mar 2002 06:34:10 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28BYAZc026476 for ; Fri, 8 Mar 2002 12:34:10 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 12:17:39 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 12:17:39 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" , "'nsis@ietf.org'" Date: Fri, 8 Mar 2002 12:16:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Concern on requirement in Section 5.1.6 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus I have a concern regarding the requirement: "Avoid duplication of [sub]domain signalling functions" (Section 5.1.6) In my opinion it is very difficult to define which signalling is duplicated and therefore, I propose to remove this requirement from the NSIS WG draft. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 07:02:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00410 for ; Fri, 8 Mar 2002 07:02:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26266 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 07:02:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24255; Fri, 8 Mar 2002 06:33:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24226 for ; Fri, 8 Mar 2002 06:33:39 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28901 for ; Fri, 8 Mar 2002 06:33:36 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28BXjZ25887 for ; Fri, 8 Mar 2002 13:33:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 13:33:35 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 13:33:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 13:33:35 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B9C@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHGkfY+5rbf3aJSSxi4Frl55om47wAAp4NA To: , Cc: , , X-OriginalArrivalTime: 08 Mar 2002 11:33:35.0646 (UTC) FILETIME=[1583A3E0:01C1C695] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA24227 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > > I agree with Roland to a large extent (ie this is too complex). > > > > I would like the draft to state requirements that the model > that should be supproted is: > > > > - Provider offers a service (describe by some parameters) > > - Customer buy from this service (described by some parameters) > > > > Thus a behaviour like: > > Provider A: I have service X, Y, Z (described in some way) > > Customer B: I want b amount of the service X. > > Provider A: Ok. > > I don't think we need the service advertisement now (can be an option, > but is not a requirement). This can be agreed out of nsis. I would > prefer: if customer requests a service (e.g. identified by a > unique ID) > and if this service is not supported by a provider it rejects the > requests with a "service not supported" reply. Thinking about this function, this will be very difficult, because we will need to create some mechanism to describe services / service offerings. This is a non-trivial thing to do. One way out would be to allow NSIS offerings to be registed in an IANA registry. Each NSIS offering would have a value associated with it. If needed, we could allow a query - response method: Customer: What NSIS offerings do you have: Provider: I have 1, 3, 8 Customer: I would like 3 Provider: ACK I don't think we can get more complex than that. Is this something we want to do in NSIS? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 07:04:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00731 for ; Fri, 8 Mar 2002 07:04:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26391 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 07:04:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24417; Fri, 8 Mar 2002 06:36:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24390 for ; Fri, 8 Mar 2002 06:36:18 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28963 for ; Fri, 8 Mar 2002 06:36:15 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28BZc321846 for ; Fri, 8 Mar 2002 13:35:39 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 13:36:14 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 13:36:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section on QI/QC and QI/QC terminology Date: Fri, 8 Mar 2002 13:36:13 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B9D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section on QI/QC and QI/QC terminology Thread-Index: AcHGkSKgkP0+COJ4Qa2UMyvbTIn3UgAA/nrQ To: , , X-OriginalArrivalTime: 08 Mar 2002 11:36:14.0327 (UTC) FILETIME=[74187070:01C1C695] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA24391 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > I propose to postpone the terminology of QoS Initiator and > QoS Controller to framework draft. Meaning that > the terms QoS Initiator and QoS Controller will not be used > in the NSIS WG requirements draft. > > The main reason for this is that, according to John, > the NSIS WG requirements draft should not contain any > separation/grouping > of QoS requirements. This separation will probably be done in the > framework draft. There we could also define entities such as > QI and QC. Bigger question to the Working Group. Is NSIS peer-to-peer; Client-server; or a mixture. I can see it as a mixture. In end-to-edge signaling, it is client-server, however, in both end-to-end and edge-to-edge, it is peer-to-peer. I think the Requirements document should have some terminology that describes the parties involved in the signaling ... however, I don't think that the WG has decided on what terminology to use. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 07:06:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00947 for ; Fri, 8 Mar 2002 07:06:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26451 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 07:06:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24865; Fri, 8 Mar 2002 06:51:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24838 for ; Fri, 8 Mar 2002 06:51:57 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29147 for ; Fri, 8 Mar 2002 06:51:54 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28Bq3Z09334 for ; Fri, 8 Mar 2002 13:52:03 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 13:51:53 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 13:51:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] suggestions for draft-ietf-nsis-req-00.txt Date: Fri, 8 Mar 2002 13:51:52 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BA0@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] suggestions for draft-ietf-nsis-req-00.txt Thread-Index: AcHCBLmTHYcbIWGvRleZbGGiMg2aawEkqVIw To: Cc: , X-OriginalArrivalTime: 08 Mar 2002 11:51:53.0105 (UTC) FILETIME=[A3A69810:01C1C697] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA24839 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Martin, > I was referring to the fact that one cannot just arbitrarily > aggregate IP flows and then treat it as an IP aggregate. A common > identifier, e.g. MPLS label, DSCP, IP tunnel, CIDR prefix, or anything else > is always needed to achieve > anything with respect to QoS aggregation. I thought that an explicit > statement might be useful to avoid too optimistic assumptions > resulting from the requirements. Of course, the mapping between a set of > flow filters and the common identifier might be hidden within a QoS domain and > since NSIS is focusing on inter-domain QoS signalling, it is debatable what level of > detail should be included in the requirements. agreed. > > Would a better requirement be something like: > > > > NSIS SHOULD provide a robust solution for signaling > > and handling of data packets irrespective of MTU > > (maximum transport unit) size. > > > > Would that be something that would cover what you were thinking? > > I don't know whether I fully understand the meaning of this > statement. The > way I understand it, it sounds correct, but maybe trivial. > The essential > question is whether the MTU of data packets must be fixed > along a path or > whether it can vary in a sense that IPv4 fragmentation > requires to transform > the QoS specification. I would think that requiring support > for the latter > does not make much sense, because it increases complexity and > is obsolete for IPv6. MTU should be over the entire path, so by fitting a packet within an MTU should be enough. I am unsure if we need to address this here, but rather in a protocol ... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 07:26:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01463 for ; Fri, 8 Mar 2002 07:26:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27217 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 07:26:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26561; Fri, 8 Mar 2002 07:09:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26532 for ; Fri, 8 Mar 2002 07:09:27 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01033 for ; Fri, 8 Mar 2002 07:09:25 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28C8cp27508; Fri, 8 Mar 2002 13:08:38 +0100 (MET) Subject: RE: [NSIS] section 5.2.2 in requirement draft To: john.loughney@nokia.com Cc: Anders.P.Bergsten@telia.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 13:08:26 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 13:08:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, A good suggestion. I agree. Thanks, Sven. john.loughney@nokia.com on 08/03/2002 10:20:38 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: Anders.P.Bergsten@telia.se, nsis@ietf.org Subject RE: [NSIS] section 5.2.2 in requirement draft : Hi Sven, > I agree with your explanation but I don't think your wording really > reflects what you say there. Would you agree to something like: > NSIS SHOULD support on-path signaling and signaling to and/or > from known entities. The default behaviour SHOULD be on-path signaling. I prefer to have single statement requirements, so I'd suggest we have 3 requirements: NSIS SHOULD support on-path signaling. NSIS SHOULD support signaling to and/or from known entities. The default behaviour SHOULD be on-path signaling. Fufilling requirements with multiple clauses is difficult. (also we can discuss the level - MUST/SHOULD/MAY ...) John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:18:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03330 for ; Fri, 8 Mar 2002 08:18:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00636 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:19:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29097; Fri, 8 Mar 2002 07:53:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29067 for ; Fri, 8 Mar 2002 07:53:53 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02299 for ; Fri, 8 Mar 2002 07:53:50 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28CrCL08629; Fri, 8 Mar 2002 13:53:12 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: Winter Martin Cc: john.loughney@nokia.com, nsis@ietf.org, maarten.buchli@alcatel.be X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 13:53:01 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 13:53:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Martin, I wouldn't really state it like this. I would rather say The protocol SHOULD provide enough information to allow localised admission control decisions. The protocol MAY support well known services. In this way we don't presuppose a solution. Sven. Winter Martin on 08/03/2002 10:14:21 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, john.loughney@nokia.com, nsis@ietf.org cc: Subject RE: [NSIS] section 3.5 in nsis-req-00.txt : Hi John, Sven > Hi John, > > Couldn't it also be something like: > > Provider A: Of the service S I know you provide I would like 10k > Provider B: OK. > > What do you think? > Sven. > That goes into my direction. The "I know" is important. Let me try to formulate that inter-domain issue as requirement: The QoS protocol MUST support the use of pre-defined services (globally well known services) for requests between domains. > Roland, > > > I strongly suggest that nsis should work now on interdomain > > QoS signaling. This is a major piece missing in global QoS > support. A > main > > feature of the Internet is its global connectivity > (availability of the > > "same" basic service), so it would be nice to have at least a few > globally > > available public/standardized services (aggreement on them is a > > business issue, so out of scope). But nsis signaling would allow to > request resources of > > such services on demand between arbitrary sources and destinations. > > What are your requirements? Remember, we are not going into how > service providers actually provision network resources. Do you want > to enable some sort sort of dialog like: > > Provider A: Hey, do you 10k bandwidth and 50 ms delay? > Provider B: Sorry, no. > Provider A: Well howabout just 10k bandwidth? > Provider B: I do. > Provider A: Then I will take it. > > Or do you want something more complex? > > John > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:26:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03619 for ; Fri, 8 Mar 2002 08:26:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01168 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:26:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29928; Fri, 8 Mar 2002 08:03:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29897 for ; Fri, 8 Mar 2002 08:03:40 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02685 for ; Fri, 8 Mar 2002 08:03:36 -0500 (EST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g28D04dk016119 for ; Fri, 8 Mar 2002 14:03:37 +0100 (MET) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GSN009CVLG7IU@mbb1.ericsson.se> for nsis@ietf.org; Fri, 8 Mar 2002 13:02:31 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 12:43:54 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 08 Mar 2002 12:43:51 +0100 Date: Fri, 08 Mar 2002 12:42:47 +0100 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: nsis@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Subject: [NSIS] Requirement Section 5.3.2 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Regarding requirement in Section 5.3.2: "Ability to signal life-time of a reservation": The problem that I have with this requirement is that it will increase the complexity of the functionality related to the soft state (refresh) principle in a node. Please note that the soft state refresh principle is used to somehow solve unexpected changes in the network, e.g., route changes that are independent of the lifetime of a reservation. Therefore, I do not think that the lifetime of the reservation should affect the duration of the soft state refresh. Please remove it! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:26:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03642 for ; Fri, 8 Mar 2002 08:26:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01188 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:26:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00034; Fri, 8 Mar 2002 08:05:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29994 for ; Fri, 8 Mar 2002 08:04:58 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02717 for ; Fri, 8 Mar 2002 08:04:55 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 14:02:51 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 14:04:22 +0100 Message-Id: From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 14:04:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA29995 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, I prefer Martin's proposal. NSIS MUST support both, well known and private services. If NSIS only may support well known servcies, even interworking with Intserv is at risk. To me, Intserv interworking would be a minimum expectation to NSIS. If NSIS signaling doesn't provide sufficient information to allow admission control, NSIS signaling isn't required itself. I'm favouring a MUST instead of a SHOULD. At least if NSIS signaling is used to reserve QoS resources. Regards, Rüdiger > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Friday, March 08, 2002 1:53 PM > To: Winter Martin > Cc: john.loughney@nokia.com; nsis@ietf.org; maarten.buchli@alcatel.be > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Martin, > > I wouldn't really state it like this. I would rather say > > The protocol SHOULD provide enough information to allow > localised admission > control decisions. > The protocol MAY support well known services. > > In this way we don't presuppose a solution. > > Sven. > > > > > > Winter Martin on 08/03/2002 10:14:21 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, > john.loughney@nokia.com, nsis@ietf.org > > cc: > > > > Subject RE: [NSIS] section 3.5 in nsis-req-00.txt > : > > > > > > > Hi John, Sven > > > Hi John, > > > > Couldn't it also be something like: > > > > Provider A: Of the service S I know you provide I would like 10k > > Provider B: OK. > > > > What do you think? > > Sven. > > > > That goes into my direction. The "I know" is important. Let me try to > formulate that inter-domain issue as requirement: > > The QoS protocol MUST support the use of pre-defined services > (globally > well known services) for requests between domains. > > > Roland, > > > > > I strongly suggest that nsis should work now on interdomain > > > QoS signaling. This is a major piece missing in global QoS > > support. A > > main > > > feature of the Internet is its global connectivity > > (availability of the > > > "same" basic service), so it would be nice to have at least a few > > globally > > > available public/standardized services (aggreement on them is a > > > business issue, so out of scope). But nsis signaling > would allow to > > request resources of > > > such services on demand between arbitrary sources and > destinations. > > > > What are your requirements? Remember, we are not going into how > > service providers actually provision network resources. Do you want > > to enable some sort sort of dialog like: > > > > Provider A: Hey, do you 10k bandwidth and 50 ms delay? > > Provider B: Sorry, no. > > Provider A: Well howabout just 10k bandwidth? > > Provider B: I do. > > Provider A: Then I will take it. > > > > Or do you want something more complex? > > > > John > > > > -- > Martin Winter > AQUILA Project http://www.ist-aquila.org > ------------------------------------------------------ > Siemens AG Voice: +49 89 722-63718 > ICN WN CC NA A19 Fax: +49 89 722-41920 > Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de > 81359 Muenchen > Germany > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:34:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03982 for ; Fri, 8 Mar 2002 08:34:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01987 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:34:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00807; Fri, 8 Mar 2002 08:20:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00773 for ; Fri, 8 Mar 2002 08:20:48 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03415 for ; Fri, 8 Mar 2002 08:20:45 -0500 (EST) From: maarten.buchli@alcatel.be Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28DJBb17092; Fri, 8 Mar 2002 14:19:11 +0100 (MET) Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt To: Roland Bless Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org Date: Fri, 8 Mar 2002 14:19:09 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 14:19:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Roland, The idea of allowing a range for a certain QoS parameter in the request is interesting. You suggest that no explicit acknowledgement is needed of the reservation request since the actual value will be within the requested range. Hence, a simple ACK would be sufficient. Although I agree with the 'keep things simple' principle, there still may be a need to explicitly notify the QoS requester about the actual values for the QoS parameters (e.g. delay, jitter) that the network guarantees. In this case an application may base decisions about packetization delay and dejittering delay on it. Example: for VoIP applications it is known that the maximum mouth-to-ear delay is 150 ms. When the application is explicitly notified about the end-to-end network delay it can decide how much delay budget is left for e.g. packetization delay. Hence, I suggest the following: - ability to request from a range of QoS parameters - the ability to explicitly notify the QoS requester about the actual values of the QoS parameters Maarten. Roland Bless on 08/03/2002 10:42:07 To: john.loughney@nokia.com cc: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org, Anders.P.Bergsten@telia.se, Ruediger.Geib@t-systems.com(bcc: Maarten BUCHLI/BE/ALCATEL) Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt Hi John, > > So in the request a range of acceptable parameter values is > > specified. Any value within the range will be acceptable > > for the requester, so the last dialogue of your example will > > not be necessary. > > So, you would like these requirements to be: > > Ability to request from a range of QoS parameters In some sense yes, but this requirement relates to the service object which is transparent for nsis and service dependent, so not really in nsis scope. > -> the problem is, then what is the policy in fufilling > the range, lowest value, highest value, medium value, > etc. One solution is not to use absolute QoS parameters, > but to use relative. Oh, just as I said: Any value within the range will be fine for the requesting party, and, thus accepted. If one needs a specific value, you just set the interval bounds to an equal value. The policy for admission control also depends on the concrete QoS parameter (out of nsis scope). Thus, a service provider may test for the higher bandwidth value at first and later for the lower value, whereas for delay it is typically the other way round. However, this is not something we really have to directly deal with. > > So in the request a range of acceptable parameter values is > > specified. Any value within the range will be acceptable > > for the requester, so the last dialogue of your example will > > not be necessary. > > Does this mean there should not be any acknowledgement > of what is then accepted? Yes, let's keep thing simple. The requesting party won't have to acknowledge the result explicitly, because any result within the range has to be accepted. Otherwise the requester should have specified a different interval. However, there is always the possibility to abort a reservation at any time. An explicit acknowledgement would imply that another round trip time would be required to actually activate the pre-reserved resources along the path. This should be avoided. Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:40:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04205 for ; Fri, 8 Mar 2002 08:40:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02347 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:40:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01153; Fri, 8 Mar 2002 08:26:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01077 for ; Fri, 8 Mar 2002 08:26:24 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03610 for ; Fri, 8 Mar 2002 08:26:21 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g28DQ9B17915 for ; Fri, 8 Mar 2002 14:26:09 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 08 13:58:05 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 13:57:49 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Date: Fri, 8 Mar 2002 13:56:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] 5.3.6: Requirement Section 5.3.6 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear Marcus Problem with requirement in Section 5.3.6: "Feedback about the actually received level of QoS guarantees" I do not know how to interpret this requirement. Will this feedback be generated by only one entity, e.g., end host, or it will be generated by many (all) nodes (routers) in a communication path that somehow use/process the NSIS signaling? If it is the first one then we could have it as a MAY, but if it is the latter one then I think that it will be very complex and therefore I propose to remove it! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:50:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04708 for ; Fri, 8 Mar 2002 08:50:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02971 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:50:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02155; Fri, 8 Mar 2002 08:36:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02126 for ; Fri, 8 Mar 2002 08:36:48 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04086 for ; Fri, 8 Mar 2002 08:36:45 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g28DakB26375 for ; Fri, 8 Mar 2002 14:36:46 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 08 14:06:56 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 14:06:40 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Date: Fri, 8 Mar 2002 14:05:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] 5.5.4 requirement (Section 5.5.4) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Regarding requirement: "Aggregation method specification" used in Section 5.5.4 I do not know if any initiator will be able to define an aggregation method. An edge node of a domain can do it, but an end host can in my opinion not do it. Thus I do not know how to interpret this requirement! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:51:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04772 for ; Fri, 8 Mar 2002 08:51:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03014 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:51:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02266; Fri, 8 Mar 2002 08:38:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02235 for ; Fri, 8 Mar 2002 08:38:27 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04165 for ; Fri, 8 Mar 2002 08:38:24 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jKZi-0001sq-00; Fri, 08 Mar 2002 14:38:23 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jKZi-00050W-00; Fri, 08 Mar 2002 14:38:22 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g28DcMf20677; Fri, 8 Mar 2002 14:38:22 +0100 Message-Id: <200203081338.g28DcMf20677@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: Anders.P.Bergsten@telia.se, sven.van_den_bosch@alcatel.be, nsis@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from of "Fri, 08 Mar 2002 13:33:35 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFC64B9C@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B9C@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 14:38:22 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > > I don't think we need the service advertisement now (can be an option, > > but is not a requirement). This can be agreed out of nsis. I would > > prefer: if customer requests a service (e.g. identified by a > > unique ID) > > and if this service is not supported by a provider it rejects the > > requests with a "service not supported" reply. > > Thinking about this function, this will be very difficult, because we will > need to create some mechanism to describe services / service offerings. > This is a non-trivial thing to do. I think my statements were misinterpreted, so let me clarify: Service descriptions should be defined outside of nsis. There should only be an agreement on service identification (IANA issue): For instance, Id 1 means standardized service X Id 645656 means local service Z' Service X is defined elsewhere to have parameters x.a,x.b,... So it should not be necessary to propagate service descriptions by nsis (because they require interpretation). However, one may advertise supported service IDs. So the scenario would be: Customer/Provider Provider I want service X with parameter values x.a=[l1,u1] and x.b=[l2,u2]. I do not support service X or You can use service X with x.a=v1 and x.b=v2 > One way out would be to allow NSIS offerings to be registed in an > IANA registry. Each NSIS offering would have a value associated > with it. If needed, we could allow a query - response method: > > Customer: What NSIS offerings do you have: > Provider: I have 1, 3, 8 > Customer: I would like 3 > Provider: ACK > > I don't think we can get more complex than that. With the providers advertisement ("I have 1, 3, 8") being optional and the customers request being "I would like 3 with value x=10", I would agree on that. > Is this something we want to do in NSIS? I don't think we need to negotiate services, but we need to negotiate service parameter _values_. Is this more clear? Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 08:56:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04932 for ; Fri, 8 Mar 2002 08:56:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03268 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 08:56:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02424; Fri, 8 Mar 2002 08:40:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02391 for ; Fri, 8 Mar 2002 08:40:31 -0500 (EST) Received: from Fusberta.Elet.PoliMi.IT (bianchi@fusberta.elet.polimi.it [131.175.120.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04199 for ; Fri, 8 Mar 2002 08:40:27 -0500 (EST) Received: from host localhost and sender bianchi@localhost; by mail relay Fusberta.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998); with protocol ESMTP and identifier OAA31827; on date and time Fri, 8 Mar 2002 14:40:20 +0100 (MET). Date: Fri, 8 Mar 2002 14:40:20 +0100 (MET) From: Giuseppe Bianchi To: john.loughney@nokia.com cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B9C@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > One way out would be to allow NSIS offerings to be registed in an > IANA registry. Each NSIS offering would have a value associated > with it. If needed, we could allow a query - response method: > > Customer: What NSIS offerings do you have: > Provider: I have 1, 3, 8 > Customer: I would like 3 > Provider: ACK As discussed some time ago, a simpler two-way solution appears to be: Customer: I want service 8, but can downgrade down to 2 ACK: you receive 3 (providers forward the request and mark downgrades on it) This solution can be made more applicable to user's needs by providing a service description hierarchy, e.g. service class and service level within the class, i.e: Customer: I want service class A, level 8 downdradable down to 2 ACK: you receive level 3 within service class A (reject if minimum level not available within that class). Regardless of the class, level 0 should be reserved to best effort. Giuseppe --- Giuseppe Bianchi bianchi@elet.polimi.it http://cerbero.elet.polimi.it/people/bianchi _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:01:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05221 for ; Fri, 8 Mar 2002 09:01:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03842 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:01:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02793; Fri, 8 Mar 2002 08:46:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02758 for ; Fri, 8 Mar 2002 08:46:29 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04519 for ; Fri, 8 Mar 2002 08:46:26 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA10499; Fri, 8 Mar 2002 14:46:24 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA14619; Fri, 8 Mar 2002 14:46:13 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 14:46:33 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB22B@MCHH241E> From: Winter Martin To: "'Geib, Ruediger'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 14:46:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA02759 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, Sven, > Hi Sven, > > I prefer Martin's proposal. NSIS MUST support both, well > known and private services. If NSIS only may support well > known servcies, even interworking with Intserv is at risk. To > me, Intserv interworking would be a minimum expectation to NSIS. That's fine. I also see the well known services as a MUST, because the protocol will otherwise be unable to support inter-domain services for the reasons I stated in a previous mail. The private services are more a MAY in my opinion. Here it depends on the expectations the people have from such a signalling protocol. If the well known service set is good enough to fit all expectations, then private services are not needed. > If NSIS signaling doesn't provide sufficient information to > allow admission control, NSIS signaling isn't required > itself. I'm favouring a MUST instead of a SHOULD. At least if > NSIS signaling is used to reserve QoS resources. Sven said "localised admission control decision" and I want to stress "Localised". He might be right in stating that explicitely. Perhaps the meaning of these words must be explained in more detail. I interpret it in that way, that NSIS should support and carry so much information, that admission control decisions for a edge-to-edge path can be taken without asking each "hop" along the path. We should e.g. allow for solutions, where a very early hop on a long inter-domain request can take the AC decision for the whole path by taking into account some knowledge it has gathered throuhg the NSIS signalling protocol. This is however just a SHOULD. > Regards, Rüdiger > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: Friday, March 08, 2002 1:53 PM > > To: Winter Martin > > Cc: john.loughney@nokia.com; nsis@ietf.org; > maarten.buchli@alcatel.be > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Martin, > > > > I wouldn't really state it like this. I would rather say > > > > The protocol SHOULD provide enough information to allow > > localised admission > > control decisions. > > The protocol MAY support well known services. > > > > In this way we don't presuppose a solution. > > > > Sven. > > Hi John, Sven > > > > > Hi John, > > > > > > Couldn't it also be something like: > > > > > > Provider A: Of the service S I know you provide I would like 10k > > > Provider B: OK. > > > > > > What do you think? > > > Sven. > > > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:05:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05434 for ; Fri, 8 Mar 2002 09:05:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03989 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:05:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03141; Fri, 8 Mar 2002 08:53:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03112 for ; Fri, 8 Mar 2002 08:53:13 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04813 for ; Fri, 8 Mar 2002 08:53:09 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA10925; Fri, 8 Mar 2002 14:53:09 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA18262; Fri, 8 Mar 2002 14:52:58 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 14:53:19 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB22C@MCHH241E> From: Winter Martin To: "'Georgios Karagiannis (ELN)'" , "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Date: Fri, 8 Mar 2002 14:53:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, I support your view. An initiator is not able to exactly know the impact of aggregation on his QoS, so he also cannot specify an aggregation method. What an initiator wants, is not a specific aggregation method, but just a service. It does not matter, how it is realised. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, March 08, 2002 2:06 PM > To: 'brunner@ccrle.nec.de' > Cc: 'nsis@ietf.org' > Subject: [NSIS] 5.5.4 requirement (Section 5.5.4) > > > Hi Marcus > > Regarding requirement: > "Aggregation method specification" > used in Section 5.5.4 > > I do not know if any initiator will be able to define an > aggregation method. > An edge node of a domain can do it, but an end host can in my > opinion not do > it. > Thus I do not know how to interpret this requirement! > > > Best regards, > Georgios > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:19:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06181 for ; Fri, 8 Mar 2002 09:19:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04782 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:19:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03237; Fri, 8 Mar 2002 08:55:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03197 for ; Fri, 8 Mar 2002 08:55:13 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04896 for ; Fri, 8 Mar 2002 08:55:09 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jKpy-0002Ff-00; Fri, 08 Mar 2002 14:55:10 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jKpy-0005PJ-00; Fri, 08 Mar 2002 14:55:10 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g28DtAf20934; Fri, 8 Mar 2002 14:55:10 +0100 Message-Id: <200203081355.g28DtAf20934@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: maarten.buchli@alcatel.be cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from maarten.buchli@alcatel.be of "Fri, 08 Mar 2002 14:19:09 +0100." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 14:55:10 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Maarten, > The idea of allowing a range for a certain QoS parameter in the request is > interesting. > You suggest that no explicit acknowledgement is needed of the reservation > request since > the actual value will be within the requested range. Hence, a simple ACK > would be sufficient. Yes (but for the ACK see below). > Although I agree with the 'keep things simple' principle, there still may > be a need to explicitly > notify the QoS requester about the actual values for the QoS parameters > (e.g. delay, jitter) > that the network guarantees. In this case an application may base decisions > about > packetization delay and dejittering delay on it. Oh, you took my ACK to literally. Sure, the response should contain the actual supplied parameter values (I assumed this implicitly :-). > Example: for VoIP applications it is known that the maximum mouth-to-ear > delay is 150 ms. > When the application is explicitly notified about the end-to-end network > delay it can decide > how much delay budget is left for e.g. packetization delay. > > Hence, I suggest the following: > - ability to request from a range of QoS parameters > - the ability to explicitly notify the QoS requester about > the actual values of the QoS parameters Sure, full agreement with my view. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:20:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06217 for ; Fri, 8 Mar 2002 09:20:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04832 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:20:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04036; Fri, 8 Mar 2002 09:06:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04005 for ; Fri, 8 Mar 2002 09:06:19 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05480 for ; Fri, 8 Mar 2002 09:06:16 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 15:04:07 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:05:37 +0100 Message-Id: From: "Geib, Ruediger" To: Martin.Winter@icn.siemens.de Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 15:05:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA04006 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Martin, > That's fine. I also see the well known services as a MUST, > because the protocol will otherwise be unable to support > inter-domain services for the reasons I stated in a previous > mail. The private services are more a MAY in my opinion. Here > it depends on the expectations the people have from such a > signalling protocol. If the well known service set is good > enough to fit all expectations, then private services are not needed. I appreciate your optimism with regard to the availability of globally well defined services, but I don't share it. In the long run, you are hopefully right (me talking as customer). But in the mean time, private services may be useful to push NSIS implementation (me talking as employee). Therefore I favour two SHOULDs (private and public services). > Sven said "localised admission control decision" and I want > to stress "Localised". He might be right in stating that > explicitely. Perhaps the meaning of these words must be > explained in more detail. I interpret it in that way, that > NSIS should support and carry so much information, that > admission control decisions for a edge-to-edge path can be > taken without asking each "hop" along the path. > > We should e.g. allow for solutions, where a very early hop on > a long inter-domain request can take the AC decision for the > whole path by taking into account some knowledge it has > gathered throuhg the NSIS signalling protocol. > > This is however just a SHOULD. No matter where and how you are doing it, NSIS signalling MUST carry the information required for admission control. It doesn't matter where and how you do admission control. Your explanation seems to say that NSIS must not pre-suppose how admission control is done (single edge system, centralised or per router). I agree to the latter. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:28:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06593 for ; Fri, 8 Mar 2002 09:28:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05203 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:28:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04422; Fri, 8 Mar 2002 09:11:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04395 for ; Fri, 8 Mar 2002 09:11:28 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05792 for ; Fri, 8 Mar 2002 09:11:24 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 15:09:21 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:10:51 +0100 Message-Id: From: "Geib, Ruediger" To: Martin.Winter@icn.siemens.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Date: Fri, 8 Mar 2002 15:10:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA04396 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Martin, Georgios, I agree too, an end system can't specify how to aggregate. A domain accepting a reservation is committing itself to provide the requested service. It doesn't matter to the end system how this is done. Regards, Rüdiger > I support your view. An initiator is not able to exactly know > the impact of aggregation on his QoS, so he also cannot > specify an aggregation method. What an initiator wants, is > not a specific aggregation method, but just a service. It > does not matter, how it is realised. > > > Hi Marcus > > > > Regarding requirement: > > "Aggregation method specification" > > used in Section 5.5.4 > > > > I do not know if any initiator will be able to define an > > aggregation method. > > An edge node of a domain can do it, but an end host can in my > > opinion not do it. > > Thus I do not know how to interpret this requirement! _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:29:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06651 for ; Fri, 8 Mar 2002 09:29:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05240 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:29:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04657; Fri, 8 Mar 2002 09:16:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04629 for ; Fri, 8 Mar 2002 09:16:05 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06024 for ; Fri, 8 Mar 2002 09:16:01 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA12696; Fri, 8 Mar 2002 15:16:01 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA01730; Fri, 8 Mar 2002 15:15:50 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:16:10 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB22D@MCHH241E> From: Winter Martin To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 15:16:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA04630 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger, > Hello Martin, > > > That's fine. I also see the well known services as a MUST, > > because the protocol will otherwise be unable to support > > inter-domain services for the reasons I stated in a previous > > mail. The private services are more a MAY in my opinion. Here > > it depends on the expectations the people have from such a > > signalling protocol. If the well known service set is good > > enough to fit all expectations, then private services are > not needed. > > I appreciate your optimism with regard to the availability of > globally well defined services, but I don't share it. In the > long run, you are hopefully right (me talking as customer). > But in the mean time, private services may be useful to push > NSIS implementation (me talking as employee). Therefore I > favour two SHOULDs (private and public services). I did not state, that well known public services MUST be defined! I stated, that the NSIS protocol MUST support them, if they are defined (at some time, and you may be right, this may take a while). You may initially deploy an NSIS protocol just with private services and just in a limited area of one or a few domains. But if it really comes to inter-domain deployment, then you can only do that with public services. > > > Sven said "localised admission control decision" and I want > > to stress "Localised". He might be right in stating that > > explicitely. Perhaps the meaning of these words must be > > explained in more detail. I interpret it in that way, that > > NSIS should support and carry so much information, that > > admission control decisions for a edge-to-edge path can be > > taken without asking each "hop" along the path. > > > > We should e.g. allow for solutions, where a very early hop on > > a long inter-domain request can take the AC decision for the > > whole path by taking into account some knowledge it has > > gathered throuhg the NSIS signalling protocol. > > > > This is however just a SHOULD. > > No matter where and how you are doing it, NSIS signalling > MUST carry the information required for admission control. It > doesn't matter where and how you do admission control. Your > explanation seems to say that NSIS must not pre-suppose how > admission control is done (single edge system, centralised or > per router). I agree to the latter. Agreed. > Regards, Rüdiger > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:43:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07532 for ; Fri, 8 Mar 2002 09:43:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06362 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:43:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04995; Fri, 8 Mar 2002 09:24:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04960 for ; Fri, 8 Mar 2002 09:24:11 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06352 for ; Fri, 8 Mar 2002 09:24:07 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28EO3Zc018795 for ; Fri, 8 Mar 2002 15:24:03 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 15:14:06 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:14:03 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Date: Fri, 8 Mar 2002 15:12:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] 5.5.7 requirement (Section 5.5.7) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Regarding requirement "Independence of reservation identifier" in Section 5.5.7 I do not know how to interpret this requirement. What I mean is that in many cases the reservation has to depend on the flow identifier, i.e., similar to RSVPv1. However, I know that in Mobile IP this will cause severe problems due to handoff situations where Care of Addresses are changing. Therefore, I propose to emphasise that the reservation identifier SHOULD be independent, when Mobile IP scenarios are used. However, for scenarios/applications that are not using Mobile IP, the reservation identifier is defined as in RSVPv1. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:43:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07607 for ; Fri, 8 Mar 2002 09:43:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06377 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:43:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05295; Fri, 8 Mar 2002 09:29:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05257 for ; Fri, 8 Mar 2002 09:29:35 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06673 for ; Fri, 8 Mar 2002 09:29:31 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 15:27:14 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:28:45 +0100 Message-Id: From: "Geib, Ruediger" To: Martin.Winter@icn.siemens.de Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Fri, 8 Mar 2002 15:28:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA05258 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Martin, As I mentioned in an earlier mail, privately defined NSIS services my very well be getting available between domains. As an example look at the GEANT project (different National European Reasearch Networks connected to one Research Backbone - they just deploy a staticly provisioned Real Time service) and look at my own company: friendly autonomus national IP networks linked together by Deutsche Telekom's Global Network. In both cases, NSIS signalling may be used to support automated privately defined QoS reservations accross domain boundaries. Private here may be translated to carrier specifc or regional. I don't talk about user defined services. Regards, Rüdiger > > > That's fine. I also see the well known services as a MUST, > > > because the protocol will otherwise be unable to support > > > inter-domain services for the reasons I stated in a previous > > > mail. The private services are more a MAY in my opinion. Here > > > it depends on the expectations the people have from such a > > > signalling protocol. If the well known service set is good > > > enough to fit all expectations, then private services are > > not needed. > > > > I appreciate your optimism with regard to the availability of > > globally well defined services, but I don't share it. In the > > long run, you are hopefully right (me talking as customer). > > But in the mean time, private services may be useful to push > > NSIS implementation (me talking as employee). Therefore I > > favour two SHOULDs (private and public services). > > I did not state, that well known public services MUST be > defined! I stated, that the NSIS protocol MUST support them, > if they are defined (at some time, and you may be right, this > may take a while). You may initially deploy an NSIS protocol > just with private services and just in a limited area of one > or a few domains. But if it really comes to inter-domain > deployment, then you can only do that with public services. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:44:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07650 for ; Fri, 8 Mar 2002 09:44:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06434 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:44:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05357; Fri, 8 Mar 2002 09:30:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05316 for ; Fri, 8 Mar 2002 09:30:01 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06718 for ; Fri, 8 Mar 2002 09:29:57 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28ETRA07337; Fri, 8 Mar 2002 15:29:27 +0100 (MET) Subject: RE: [NSIS] section on QI/QC and QI/QC terminology To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 15:28:49 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 15:29:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, OK, if that is the consensus. Let's get back to the suggestion when we discuss the framework then. One of the basic points in the referenced mail was the distinction between NSIS as a local QoS protocol and an end-to-end protocol. Do you think it makes sense to have this? Sven. "Georgios Karagiannis (ELN)" on 08/03/2002 11:43:59 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org cc: Subject RE: [NSIS] section on QI/QC and QI/QC : terminology Hi Sven I propose to postpone the terminology of QoS Initiator and QoS Controller to framework draft. Meaning that the terms QoS Initiator and QoS Controller will not be used in the NSIS WG requirements draft. The main reason for this is that, according to John, the NSIS WG requirements draft should not contain any separation/grouping of QoS requirements. This separation will probably be done in the framework draft. There we could also define entities such as QI and QC. Best Regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: dinsdag 5 maart 2002 14:31 To: nsis@ietf.org Cc: maarten.buchli@alcatel.be; danny.goderis@alcatel.be; robert.hancock@roke.co.uk; cornelia.kappler@icn.siemens.de Subject: [NSIS] section on QI/QC and QI/QC terminology Hi, We have been thinking about the QI/QC definitions and we have tried to arrange the QC/QI functional entities in a logical relation that covers the use case scenarios that have been proposed so far. From this, we hope to derive clearer definitions. The general logical relationships are depicted below (for simplicity, only signaling relations are drawn) +--+ (a) +--+ (a) +--+ (a) +---+ +->|QI|---->|QC|---------------->|QC|---->| QR|--+ QI,QC,QR roles for e2e QoS protocol | +--+ /+--+\ /+--+\ +---+ | | / \ / \ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this pictures we clearly distinguish two applications for the NSIS protocol: (a) NSIS as end-to-end QoS signaling protocol (b) NSIS as local QoS signaling protocol Local, in this case, is defined as local to a QoS domain. A QoS domain is defined as a contiguous part of the network supporting the same QoS technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS actually competes with other technologies offering local QoS, such as PDP, RSVP, ... The above picture seems to suggest an out-of-band approach but this is not the case. The QCs can be implemented in a distributed way and redrawing the picture then gives a different view. +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| QI,QC,QR roles for e2e QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ ^ v ^ v ^ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this case, it is clear that an in-band solution is also supported. The end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a router. Note that in this picture, the signaling in the access is done with a local QoS protocol. This can be either an existing protocol, or the NSIS protocol in its role of local QoS signaling mechanism. This leads to the following requirements: (a) If an NSIS protocol is only used end-to-end, then mobility need not be supported (b) If an NSIS protocol is used as a local QoS signaling mechanism then mobility must be supported, both on the QI-QC and QC-QC interface (c) If the same protocol is desired in (a) and (b), the protocol should be modular and the mobility aspects need to be separable from the rest Both of the above scenarios assume that the host is not NSIS-aware. This is a reasonable assumption in a first phase. In a later stage, when hosts are NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling technology! This allows this case to be backwards compatible with the above scenarios. It means that (b) in the access is an NSIS protocol. It also means that the host will always trigger the local QoS signaling mechanism. This suggests the following definitions for the QI, QC, QR - QoS Initiator: Network entity, located at the boundary of a QoS domain, responsible for initiating a (local or end-to-end) QoS mechanism. If it is the QI of a local protocol, it can be triggered by higher layers (applications or end-to-end QoS Controller). If it is the QI of an end-to-end protocol, it can be triggered by applications or by the QoS Receiver of a local QoS signaling mechanism. - QoS Controller: Network entity responsible for interpreting and implementing the signalled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by a QI or another QC. -QoS Receiver: Network entity, located at the boundary of a QoS domain, responsible for terminating a (local or end-to-end) QoS mechanism. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol. If this can be accepted by the NSIS community, we propose to add this text to the requirements document as a clarification of the QI/QC model that is used there. Hope this helps, Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:52:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08048 for ; Fri, 8 Mar 2002 09:52:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06796 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:52:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05993; Fri, 8 Mar 2002 09:35:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05963 for ; Fri, 8 Mar 2002 09:35:04 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06999 for ; Fri, 8 Mar 2002 09:35:00 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28EZ1Zc025977 for ; Fri, 8 Mar 2002 15:35:01 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 15:28:29 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:28:26 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Date: Fri, 8 Mar 2002 15:27:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] 5.5.10 requirement (Section 5.5.10) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Another requirement that I have problems with: Requirement: "QoS conformance specification" in Section 5.5.10 I do not know what it means when you say that the initiator should be able to indicate how faithfully the QoS provided by the network should conform to that requested. This might be useful only when the QoS information is used by certain specific entities, such proxies and centralised resource managers. However, it is very complex and requires un-scalable solutions when it will have to be supported by simple nodes (routers). Maybe a MAY in the text will solve the problem that I have! best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 09:56:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08223 for ; Fri, 8 Mar 2002 09:56:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06984 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 09:56:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06298; Fri, 8 Mar 2002 09:42:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06215 for ; Fri, 8 Mar 2002 09:42:50 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07472 for ; Fri, 8 Mar 2002 09:42:48 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Mar 2002 15:40:46 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:42:17 +0100 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Date: Fri, 8 Mar 2002 15:42:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06216 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Georgios I'm sticking with Markus' definition: A reservation ID must be independant. The reservation ID may carry the full flow information as part of it. The reseravtion ID may as well carry only part of the flow spec and it may further be service specific. I'd suggest to stay flexible here. Regards, Rüdiger > Regarding requirement "Independence of reservation > identifier" in Section 5.5.7 > > I do not know how to interpret this requirement. > What I mean is that in many cases the reservation has to depend on > the flow identifier, i.e., similar to RSVPv1. > However, I know that in Mobile IP this will cause severe problems > due to handoff situations where Care of Addresses are changing. > > Therefore, I propose to emphasise that the reservation identifier > SHOULD be independent, when Mobile IP scenarios are used. > However, for scenarios/applications that are not using Mobile IP, > the reservation identifier is defined as in RSVPv1. > > Best Regards, > Georgios > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 10:09:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08852 for ; Fri, 8 Mar 2002 10:09:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08210 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 10:09:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06933; Fri, 8 Mar 2002 09:55:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06870 for ; Fri, 8 Mar 2002 09:55:35 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08181 for ; Fri, 8 Mar 2002 09:55:29 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28Eswj14768; Fri, 8 Mar 2002 15:54:58 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: Winter Martin Cc: "'Geib, Ruediger'" , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 15:54:46 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 15:54:58 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA06874 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Martin, The nail on the head. I sent a similar mail some minutes ago, before I had read yours, with an example. Thanks, Sven. Winter Martin on 08/03/2002 14:46:33 To: "'Geib, Ruediger'" , Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject RE: [NSIS] section 3.5 in nsis-req-00.txt : Hi Rüdiger, Sven, > Hi Sven, > > I prefer Martin's proposal. NSIS MUST support both, well > known and private services. If NSIS only may support well > known servcies, even interworking with Intserv is at risk. To > me, Intserv interworking would be a minimum expectation to NSIS. That's fine. I also see the well known services as a MUST, because the protocol will otherwise be unable to support inter-domain services for the reasons I stated in a previous mail. The private services are more a MAY in my opinion. Here it depends on the expectations the people have from such a signalling protocol. If the well known service set is good enough to fit all expectations, then private services are not needed. > If NSIS signaling doesn't provide sufficient information to > allow admission control, NSIS signaling isn't required > itself. I'm favouring a MUST instead of a SHOULD. At least if > NSIS signaling is used to reserve QoS resources. Sven said "localised admission control decision" and I want to stress "Localised". He might be right in stating that explicitely. Perhaps the meaning of these words must be explained in more detail. I interpret it in that way, that NSIS should support and carry so much information, that admission control decisions for a edge-to-edge path can be taken without asking each "hop" along the path. We should e.g. allow for solutions, where a very early hop on a long inter-domain request can take the AC decision for the whole path by taking into account some knowledge it has gathered throuhg the NSIS signalling protocol. This is however just a SHOULD. > Regards, Rüdiger > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: Friday, March 08, 2002 1:53 PM > > To: Winter Martin > > Cc: john.loughney@nokia.com; nsis@ietf.org; > maarten.buchli@alcatel.be > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Martin, > > > > I wouldn't really state it like this. I would rather say > > > > The protocol SHOULD provide enough information to allow > > localised admission > > control decisions. > > The protocol MAY support well known services. > > > > In this way we don't presuppose a solution. > > > > Sven. > > Hi John, Sven > > > > > Hi John, > > > > > > Couldn't it also be something like: > > > > > > Provider A: Of the service S I know you provide I would like 10k > > > Provider B: OK. > > > > > > What do you think? > > > Sven. > > > -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 10:11:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09018 for ; Fri, 8 Mar 2002 10:11:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08351 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 10:11:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07084; Fri, 8 Mar 2002 09:58:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07051 for ; Fri, 8 Mar 2002 09:58:24 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08320 for ; Fri, 8 Mar 2002 09:58:22 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jLpA-0003ZZ-00; Fri, 08 Mar 2002 15:58:24 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jLp9-0006mz-00; Fri, 08 Mar 2002 15:58:23 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g28EwNf21337; Fri, 8 Mar 2002 15:58:23 +0100 Message-Id: <200203081458.g28EwNf21337@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Anders.P.Bergsten@telia.se Cc: , Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Your message of "Fri, 08 Mar 2002 08:55:34 +0100." <1BF8A5964E4EFA41A094B835FCA7129110CBBF@TMS041MB.tcad.telia.se> References: <1BF8A5964E4EFA41A094B835FCA7129110CBBF@TMS041MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 08 Mar 2002 15:58:23 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > If service description is out of scope. The 'adverticement' of SDs may > be in scope. The SLS negotiation is out of scope (which Ruediger and I > discussed before). What do you mean by inter-domain QoS? And, what do > you mean is the requirements regarding inter-domain QoS? I mean that one can request some service X for a flow with certain parameter values (e.g. bandwidth=100kbit/s). Service X is defined outside of nsis. Now, if the flow traverses several domains or ASs every provider should be able to request the same service from its adjacent provider. The most important requirement is IMO scalability, so -- as already many others stated -- essentially support of eastablishing and managing reservation aggregates (aka pipes,tunnels,...) for services. > As a second point, how much of the Inter-domain issues that need to be > solved is a technical issue and how much is better left for the carriers > to figure out themselves? I think there is a lot for providers to figure out: - local QoS provisioning architecture - admission and resource reservation policies > I would agree that working out an architecture that gives the incentives > for the carriers to optimise the Internet on delay would be a truly > valuable task. The question for me is what is the minimal thing needed > to give the carriers this incentive, without forcing them (us) into a > solution that constrains the business models? I think there is a solution, that doesn't constrain the business models of providers so much. Surely, reservation aggregates will require some pricing model that gives incentives to initiate creation of aggregates, but that's it. > From my part, I believe that the minimal architectural component that > is needed is the 'adverticement' of SDs. That's where I have landed > after thinking about this for a long time. This adverticement have the > exact same function as BGP adverticement and can be implemented in BGP > (see for example draft-jacquenet-qos-nlri-04.txt for one solution). I even don't think that one needs to advertise service descriptions, because they have to be interpreted, understood and implemented somehow. > This functionality (assuming some quality parameters and pricing > information is included) would give the carrier a tool and some > incentive to optimise the network. Observe, I still believe the service > description is way out of scope (this is a business issue for me). Yes, I agree fully with that. > I can agree to this being important (after all I am working for a > carrier...). > What I am suggestion - also in my previoius email - is that this part > and the requirements for this is clearly separated in the requirement > document from the 'call'-signaling that I mentioned in a previous email. > This two may lead to two different solutions. I don't think that they lead to two different solutions. One can cover them together easily, and, they will fit perfectly together. On-demand aggregate signaling is not that different from flow signaling. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 10:20:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09373 for ; Fri, 8 Mar 2002 10:20:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08761 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 10:20:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07946; Fri, 8 Mar 2002 10:03:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07913 for ; Fri, 8 Mar 2002 10:03:40 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08609 for ; Fri, 8 Mar 2002 10:03:38 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28F3dZc016105 for ; Fri, 8 Mar 2002 16:03:39 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 15:53:51 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:53:51 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Date: Fri, 8 Mar 2002 15:53:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] 5.8.5 requirement (Section 5.8.5) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear Marcus Another problem, requirement: "The QoS signaling protocol must allow for hop-by-hop security" in Section 5.8.5 I do not agree that all intermediate routers located in a communication path should support this requirement. However, I agree that some nodes, e.g., end host, Access routers, proxies, centralised resource managers need to support security issues; Therefore, I propose to either remove this requirement or emphasisse that this requirement is not hop-by-hop but applied on certain specialised nodes, e.g., .end host, access routers, centralised resource managers.... Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 10:21:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09516 for ; Fri, 8 Mar 2002 10:21:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08806 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 10:21:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07122; Fri, 8 Mar 2002 09:58:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07093 for ; Fri, 8 Mar 2002 09:58:32 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08331 for ; Fri, 8 Mar 2002 09:58:30 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g28EvsH15655; Fri, 8 Mar 2002 15:57:54 +0100 (MET) Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) To: "Geib, Ruediger" Cc: Martin.Winter@icn.siemens.de, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 8 Mar 2002 15:57:28 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/08/2002 15:57:53 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA07094 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I agree as well. I even think the end-user doesn't really care, as long as he gets the requested service (whether he is aggregated with others or not). Just my 2cc, Sven "Geib, Ruediger" on 08/03/2002 15:10:45 To: Martin.Winter@icn.siemens.de cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) : Hi Martin, Georgios, I agree too, an end system can't specify how to aggregate. A domain accepting a reservation is committing itself to provide the requested service. It doesn't matter to the end system how this is done. Regards, Rüdiger > I support your view. An initiator is not able to exactly know > the impact of aggregation on his QoS, so he also cannot > specify an aggregation method. What an initiator wants, is > not a specific aggregation method, but just a service. It > does not matter, how it is realised. > > > Hi Marcus > > > > Regarding requirement: > > "Aggregation method specification" > > used in Section 5.5.4 > > > > I do not know if any initiator will be able to define an > > aggregation method. > > An edge node of a domain can do it, but an end host can in my > > opinion not do it. > > Thus I do not know how to interpret this requirement! _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 10:26:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09817 for ; Fri, 8 Mar 2002 10:26:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09004 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 10:26:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08436; Fri, 8 Mar 2002 10:13:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08403 for ; Fri, 8 Mar 2002 10:12:59 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09067 for ; Fri, 8 Mar 2002 10:12:57 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jM3E-0003qi-00; Fri, 08 Mar 2002 16:12:56 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16jM3E-00075k-00; Fri, 08 Mar 2002 16:12:56 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g28FCuf21413; Fri, 8 Mar 2002 16:12:56 +0100 Message-Id: <200203081512.g28FCuf21413@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: Anders.P.Bergsten@telia.se, sven.van_den_bosch@alcatel.be, nsis@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt In-Reply-To: Message from john.loughney@nokia.com of "Fri, 08 Mar 2002 11:44:19 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8D@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B8D@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 2002 16:12:56 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, > Shouldn't service advertisement be handled at the application > level, not the transport (NSIS) level? Yes. > In my (non-chair) opinion, I'd prefer this model > > 1) higher-level service information exchange happens > (or is preconfigured / pre-known) > 2) Consumer: I want X > 3) Provider: Can't fufill X Great, I share this view. > Then the consumer can think if they would like to ask for y ... > (note: x may not be able to be fufilled for many reasons, one > could be because of a lack of resources, etc.) Exactly. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 10:43:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10969 for ; Fri, 8 Mar 2002 10:43:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09966 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 10:41:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08606; Fri, 8 Mar 2002 10:17:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08571 for ; Fri, 8 Mar 2002 10:17:45 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09256 for ; Fri, 8 Mar 2002 10:17:43 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28FHiZc026514 for ; Fri, 8 Mar 2002 16:17:44 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 16:13:48 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 16:13:48 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Date: Fri, 8 Mar 2002 16:13:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA08572 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Rüdiger I think that we should be flexible only if it is required to be flexible. In the case of Mobile IP, it is required that the reservation ID must be independent, due to the Care of Addresses changes. Could you please give other examples where you will need to have an independent reservation ID. Please note that due to this independence of reservation ID, each router in a communication path must change its packet classification algorithm for each accepted flow. This will become to be a very complex procedure. In Mobile IP this is much easier, since it can be predicted when the Care of Address changes. best Regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: vrijdag 8 maart 2002 15:42 To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Hello Georgios I'm sticking with Markus' definition: A reservation ID must be independant. The reservation ID may carry the full flow information as part of it. The reseravtion ID may as well carry only part of the flow spec and it may further be service specific. I'd suggest to stay flexible here. Regards, Rüdiger > Regarding requirement "Independence of reservation > identifier" in Section 5.5.7 > > I do not know how to interpret this requirement. > What I mean is that in many cases the reservation has to depend on > the flow identifier, i.e., similar to RSVPv1. > However, I know that in Mobile IP this will cause severe problems > due to handoff situations where Care of Addresses are changing. > > Therefore, I propose to emphasise that the reservation identifier > SHOULD be independent, when Mobile IP scenarios are used. > However, for scenarios/applications that are not using Mobile IP, > the reservation identifier is defined as in RSVPv1. > > Best Regards, > Georgios > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 11:06:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12260 for ; Fri, 8 Mar 2002 11:06:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11452 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 11:06:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10478; Fri, 8 Mar 2002 10:53:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10448 for ; Fri, 8 Mar 2002 10:53:21 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11485 for ; Fri, 8 Mar 2002 10:53:15 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA10452; Fri, 8 Mar 2002 16:53:11 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA21202; Fri, 8 Mar 2002 16:53:05 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 16:53:26 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A0126566D@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'john.loughney@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: RE: [NSIS] section on QI/QC and QI/QC terminology Date: Fri, 8 Mar 2002 16:53:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John and Georgios, as probably everybody else I agree we need to settle on some terminology. The alternative is, in each requirement, to list all possibilities we can think of. Instead of e.g.: "5.3.1. Possibility for automatic release of resources after failure When the QoS Intitiator goes down, the resources it requested should be released since they are no longer necessary" we put "5.3.1... When an end system, an edge router, or a signalling proxy go down and they have been initiating a reservation, the resources they requested should be released since..." not too elegant, and, more importantly, not sufficiently general. So lets say "5.3.1 ...When an entity that initiated a reservation goes down, the resources it requested..." To make it more legible we replace "entity that initiated a reservation" = QoS Intitiator This provides the additional benefit that in a terminology section we can more precisely define what a QoS Initiator is (may be the perfectly precise definition could be left to the framework). Likewise QoS Controller. [If you would rather use "ETIAR" (Entity That Intitiated A Reservation) or whatever fine with me. (sorry for becoming silly)] I dont understand yet how this implies a separation / grouping of requirements. There has been so much going on on this list that I lost this bit. Georgios, may be you could expand on this problem? Regarding whether NSIS is client/server or peer2peer or a mixture, do we need to fix this in the requirements? Cornelia > -----Original Message----- > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > Sent: Friday, March 08, 2002 12:36 PM > To: Georgios.Karagiannis@eln.ericsson.se; sven.van_den_bosch@alcatel.be; nsis@ietf.org > Subject: RE: [NSIS] section on QI/QC and QI/QC terminology > > Hi Georgios, > > > I propose to postpone the terminology of QoS Initiator and > > QoS Controller to framework draft. Meaning that > > the terms QoS Initiator and QoS Controller will not be used > > in the NSIS WG requirements draft. > > > > The main reason for this is that, according to John, > > the NSIS WG requirements draft should not contain any > > separation/grouping > > of QoS requirements. This separation will probably be done in the > > framework draft. There we could also define entities such as > > QI and QC. > > Bigger question to the Working Group. Is NSIS peer-to-peer; > Client-server; or a mixture. I can see it as a mixture. > In end-to-edge signaling, it is client-server, however, in > both end-to-end and edge-to-edge, it is peer-to-peer. > > I think the Requirements document should have some terminology > that describes the parties involved in the signaling ... however, > I don't think that the WG has decided on what terminology to use. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 11:48:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15525 for ; Fri, 8 Mar 2002 11:48:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15478 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 11:48:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13072; Fri, 8 Mar 2002 11:27:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13014 for ; Fri, 8 Mar 2002 11:27:00 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13531 for ; Fri, 8 Mar 2002 11:26:56 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g28GQvd10221; Fri, 8 Mar 2002 17:26:57 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g28GQvg22664; Fri, 8 Mar 2002 17:26:57 +0100 (MET) From: "Hannes Tschofenig" To: "Georgios Karagiannis \(ELN\)" , Cc: Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Fri, 8 Mar 2002 17:30:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit dear georgios! > Dear Marcus > Another problem, requirement: > "The QoS signaling protocol must allow for hop-by-hop security" in Section 5.8.5 > I do not agree that all intermediate routers located in a communication path > should support this requirement. > However, I agree that some nodes, e.g., end host, Access routers, proxies, centralised resource > managers need to support security issues; > Therefore, I propose to either remove this requirement or emphasisse that this requirement > is not hop-by-hop but applied on certain specialised nodes, e.g., .end host, access routers, centralised > resource managers.... The requirement of section 5.8.5 "The QoS signaling protocol must allow for hop-by-hop security" does not necessarily mean that every router must enforce hop-by-hop security protection. a qos protocol must however support mechanisms that allow hop-by-hop security mechanism to be used between qos signaling aware nodes. > Best regards, > Georgios ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 14:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29134 for ; Fri, 8 Mar 2002 14:43:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00469 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 14:43:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28826; Fri, 8 Mar 2002 14:30:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28763 for ; Fri, 8 Mar 2002 14:30:38 -0500 (EST) Received: from fig.isi.edu (fig.isi.edu [128.9.160.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28046 for ; Fri, 8 Mar 2002 14:30:35 -0500 (EST) Received: from localhost (berson@localhost) by fig.isi.edu (8.11.6/8.11.6) with ESMTP id g28JUSw09539; Fri, 8 Mar 2002 11:30:28 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs Date: Fri, 8 Mar 2002 11:30:28 -0800 (PST) From: Steven Berson To: "Georgios Karagiannis (ELN)" cc: "'brunner@ccrle.nec.de'" , Subject: Re: [NSIS] Requirement Section 5.3.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, I am not sure if it is a good idea to support reservation life-times, but at this time, it does not seem like a good idea to preclude it. Also, the reservation life-time is not necessarily related to the soft-state refresh timer. Steve On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > Hi Marcus > > Regarding requirement in Section 5.3.2: > > "Ability to signal life-time of a reservation": > > The problem that I have with this requirement is that it will > increase the complexity of the functionality related to the soft > state (refresh) principle in a node. > Please note that the soft state refresh principle is used > to somehow solve unexpected changes in the network, e.g., route changes > that are independent of the lifetime of a reservation. > Therefore, I do not think that the lifetime of the reservation > should affect the duration of the soft state refresh. > Please remove it! > > Best regards, > Georgios > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 14:45:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29324 for ; Fri, 8 Mar 2002 14:45:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00693 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 14:46:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28241; Fri, 8 Mar 2002 14:27:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28212 for ; Fri, 8 Mar 2002 14:27:50 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27702 for ; Fri, 8 Mar 2002 14:27:43 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28JRiZc013192 for ; Fri, 8 Mar 2002 20:27:44 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 08 20:27:56 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 20:27:43 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Hannes Tschofenig'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Fri, 8 Mar 2002 20:27:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear Hannes Do you mean that this requirement is different than the one supported by RSVPv1? Please note that RSVPv1 performs hop-by-hop security by using e.g., a hop-by-hop authentication mechanism which uses an encrypted hash function. If that is the case (not an RSVPv1 hop-by-hop security) then maybe we could emphasise that this is not a hop-by-hop authentication mechanism, but something else.... Best regards, Georgios -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: vrijdag 8 maart 2002 17:30 To: Georgios Karagiannis (ELN); brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) dear georgios! > Dear Marcus > Another problem, requirement: > "The QoS signaling protocol must allow for hop-by-hop security" in Section 5.8.5 > I do not agree that all intermediate routers located in a communication path > should support this requirement. > However, I agree that some nodes, e.g., end host, Access routers, proxies, centralised resource > managers need to support security issues; > Therefore, I propose to either remove this requirement or emphasisse that this requirement > is not hop-by-hop but applied on certain specialised nodes, e.g., .end host, access routers, centralised > resource managers.... The requirement of section 5.8.5 "The QoS signaling protocol must allow for hop-by-hop security" does not necessarily mean that every router must enforce hop-by-hop security protection. a qos protocol must however support mechanisms that allow hop-by-hop security mechanism to be used between qos signaling aware nodes. > Best regards, > Georgios ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 14:52:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29630 for ; Fri, 8 Mar 2002 14:52:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01191 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 14:52:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00037; Fri, 8 Mar 2002 14:36:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29998 for ; Fri, 8 Mar 2002 14:36:29 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28589 for ; Fri, 8 Mar 2002 14:36:26 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28JaRZc014454 for ; Fri, 8 Mar 2002 20:36:27 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 20:35:01 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 20:36:26 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Fri, 8 Mar 2002 20:36:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Steve The associated motivation given for this requirement in the NSIS WG draft is that "allows reducing the reservation update frequency in case of soft state based signaling." (from draft) Therefore, I thought that it was related to the soft-state refresh timer. Do you have another motivation to keep this requirement. Best regards, Georgios -----Original Message----- From: Steven Berson [mailto:berson@isi.edu] Sent: vrijdag 8 maart 2002 20:30 To: Georgios Karagiannis (ELN) Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: Re: [NSIS] Requirement Section 5.3.2 Georgios, I am not sure if it is a good idea to support reservation life-times, but at this time, it does not seem like a good idea to preclude it. Also, the reservation life-time is not necessarily related to the soft-state refresh timer. Steve On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > Hi Marcus > > Regarding requirement in Section 5.3.2: > > "Ability to signal life-time of a reservation": > > The problem that I have with this requirement is that it will > increase the complexity of the functionality related to the soft > state (refresh) principle in a node. > Please note that the soft state refresh principle is used > to somehow solve unexpected changes in the network, e.g., route changes > that are independent of the lifetime of a reservation. > Therefore, I do not think that the lifetime of the reservation > should affect the duration of the soft state refresh. > Please remove it! > > Best regards, > Georgios > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00278 for ; Fri, 8 Mar 2002 15:05:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02583 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:05:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01063; Fri, 8 Mar 2002 14:50:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01026 for ; Fri, 8 Mar 2002 14:50:53 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29591 for ; Fri, 8 Mar 2002 14:50:49 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 19:47:23 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594B46@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Georgios Karagiannis (ELN)" , "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Date: Fri, 8 Mar 2002 19:47:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Georgios, That's not how I read the requirement. The requirement is that it = should be possible to refer to the reservation in a way which is = independent of the flow classifier being used (e.g. for the reasons you = mention to do with MIP, but we can't rule out other applications as = well). This is an entirely different question from what flow classifiers = actually are allowed, which is what the routers care about.=20 If the mapping between (fixed) reservation identifier and flow = classifier changes, the router will have to be updated. But it would = have to do this in any case. And in the meantime, the signalling is = simplified. If the mapping is fixed, no one is hurt by the fact that we had an = identifier available in the QoS signals just in case. This requirement = doesn't place any extra burden on the router so far as I can see. We haven't got enough discussion of flow classifiers in the = requirements draft. Martin Karsten raised a related issue with = aggregation (for which I proposed some text), but a more general = discussion is needed. Robert H. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 08 March 2002 15:14 > To: 'Geib, Ruediger' > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) >=20 >=20 > Hello R=FCdiger >=20 > I think that we should be flexible only if it is required=20 > to be flexible. In the case of Mobile IP, it is required that the=20 > reservation ID must be independent, due to the Care of=20 > Addresses changes.=20 > Could you please give other examples where you will need to > have an independent reservation ID. >=20 > Please note that due to this independence of reservation ID,=20 > each router in a=20 > communication path must change its packet classification=20 > algorithm for=20 > each accepted flow. This will become to be a very complex procedure. >=20 > In Mobile IP this is much easier, since it can be predicted when=20 > the Care of Address changes. >=20 >=20 > best Regards, > Georgios >=20 >=20 > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: vrijdag 8 maart 2002 15:42 > To: Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) >=20 >=20 > Hello Georgios >=20 > I'm sticking with Markus' definition: A reservation ID must=20 > be independant. The reservation ID may carry the full flow=20 > information as part of it. The reseravtion ID may as well=20 > carry only part of the flow spec and it may further be=20 > service specific. I'd suggest to stay flexible here.=20 >=20 > Regards, R=FCdiger >=20 > > Regarding requirement "Independence of reservation=20 > > identifier" in Section 5.5.7 > >=20 > > I do not know how to interpret this requirement. > > What I mean is that in many cases the reservation has to depend on > > the flow identifier, i.e., similar to RSVPv1. > > However, I know that in Mobile IP this will cause severe problems > > due to handoff situations where Care of Addresses are changing. > >=20 > > Therefore, I propose to emphasise that the reservation identifier=20 > > SHOULD be independent, when Mobile IP scenarios are used. > > However, for scenarios/applications that are not using Mobile IP, > > the reservation identifier is defined as in RSVPv1. > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:06:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00314 for ; Fri, 8 Mar 2002 15:06:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02607 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:06:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01298; Fri, 8 Mar 2002 14:53:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01265 for ; Fri, 8 Mar 2002 14:53:19 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29703 for ; Fri, 8 Mar 2002 14:53:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 19:47:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594B4A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: sven.van_den_bosch@alcatel.be, john.loughney@nokia.com Cc: Anders.P.Bergsten@telia.se, nsis@ietf.org Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 19:47:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi all, I'm slightly confused by the process being followed in the refinement of this requirement. we have scenarios in the draft, and a mapping of the requirements to the scenarios (in section 6) with an interpreted may/must/should/whatever. the currently phrased requirement tries to capture the fact that in several of the scenarios the QoS entities are not (should not be forced to be) in the data path. it appears that the mapping for 5.2.2 is currently assigned as 'MUST' for all scenarios. so, when people are suggesting MAY/SHOULD for signalling to known entities, is this a reflection of the view that *) the relationship between the requirement and the scenario is wrong, or *) the scenario is not important, or *) something else. likewise, if there is a MUST to support on-path signalling, i'd be interested to know what scenarios it relates to. (they probably aren't hard to find, of course.) [Note: i'm not saying that on-path signalling is a bad thing. Indeed, in many situations, it may be the best thing. But in that case, it will come in as part of the solution anyway, we don't need to write a requirement that says it is the best thing. In particular, writing a requirement that it should be the default strikes me as very close to being 'solution oriented' which we are supposedly trying to avoid...] robert h. PS this is entirely in addition to the question of whether on/off path and directed signalling are even related concepts in the first place, and what it actually means to say 'NSIS must/may whatever'. but i'll pose those questions separately. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 08 March 2002 12:08 > To: john.loughney@nokia.com > Cc: Anders.P.Bergsten@telia.se; nsis@ietf.org > Subject: RE: [NSIS] section 5.2.2 in requirement draft > > > Hi John, > > A good suggestion. I agree. > > Thanks, > Sven. > > > > > > john.loughney@nokia.com on 08/03/2002 10:20:38 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > > cc: Anders.P.Bergsten@telia.se, nsis@ietf.org > > > > Subject RE: [NSIS] section 5.2.2 in requirement draft > : > > > > > > > Hi Sven, > > > I agree with your explanation but I don't think your wording really > > reflects what you say there. Would you agree to something like: > > NSIS SHOULD support on-path signaling and signaling to and/or > > from known entities. The default behaviour SHOULD be > on-path signaling. > > I prefer to have single statement requirements, so I'd suggest we have > 3 requirements: > > > NSIS SHOULD support on-path signaling. > NSIS SHOULD support signaling to and/or from known entities. > The default behaviour SHOULD be on-path signaling. > > Fufilling requirements with multiple clauses is difficult. > (also we can discuss the level - MUST/SHOULD/MAY ...) > > John > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:06:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00342 for ; Fri, 8 Mar 2002 15:06:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02626 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:06:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01350; Fri, 8 Mar 2002 14:53:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01321 for ; Fri, 8 Mar 2002 14:53:48 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29714 for ; Fri, 8 Mar 2002 14:53:45 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 19:47:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594B4B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Hannes Tschofenig , "Georgios Karagiannis (ELN)" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Fri, 8 Mar 2002 19:47:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Exactly. The requirement relates to 'NSIS hops' i.e. the signalling between QI and first QC, or between a pair of QCs, or between QC and last QR. I don't see any reason for NSIS to specify security requirements for entities that don't take part in NSIS signalling. We might say that some QC pairs don't need a security relationship, e.g. if they're in the same domain. (I guess this is more the scenario Georgios is referring to???) But we need to be careful here: I think what we would actually be saying is that interiors of domains can be protected from unauthorised traffic so they can assume that they can trust any NSIS signalling they get. In that case, we should define very carefully how this shielding is done. I see a close parallel here with routing protocol security. Basic IGPs (RIP, OSPF, ...) usually have an authentication capability, but as an option. Do people actually use these options? (Would they be prepared to admit it if they didn't? In today's uncertain world, would they be better off if they did?) robert h. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: 08 March 2002 16:30 > To: Georgios Karagiannis (ELN); brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) > > > dear georgios! > > > Dear Marcus > > > Another problem, requirement: > > "The QoS signaling protocol must allow for hop-by-hop > security" in Section > 5.8.5 > > > I do not agree that all intermediate routers located in a > communication > path > > should support this requirement. > > However, I agree that some nodes, e.g., end host, Access > routers, proxies, > centralised resource > > managers need to support security issues; > > > Therefore, I propose to either remove this requirement or > emphasisse that > this requirement > > is not hop-by-hop but applied on certain specialised nodes, > e.g., .end > host, access routers, centralised > > resource managers.... > > The requirement of section 5.8.5 "The QoS signaling protocol > must allow for > hop-by-hop security" does not > necessarily mean that every router must enforce hop-by-hop security > protection. a qos protocol must however > support mechanisms that allow hop-by-hop security mechanism to be used > between qos signaling aware nodes. > > > Best regards, > > Georgios > > ciao > hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:06:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00368 for ; Fri, 8 Mar 2002 15:06:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02656 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:06:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01396; Fri, 8 Mar 2002 14:53:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01363 for ; Fri, 8 Mar 2002 14:53:53 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29725 for ; Fri, 8 Mar 2002 14:53:49 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 19:47:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594B49@rsys002a.roke.co.uk> From: "Hancock, Robert" To: sven.van_den_bosch@alcatel.be, john.loughney@nokia.com Cc: Anders.P.Bergsten@telia.se, nsis@ietf.org Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 19:47:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi all, in this discussion it appears that we have two pairs of alternatives being considered as parts of requirements: A1) signalling is addressed to the flow endpoint (and intercepted) OR A2) signalling is addressed explicitly to the next QC/QR (if you like this 'QR' term, which I am coming round to) AND B1) signalling goes to entities on the flow data path OR B2) signalling goes to entities away from the flow path. In theory, people worried about the need for QC/QR discovery procedures etc. should be worried about the choice between A1 and A2. People worried about the cost of distributing QoS information from centralised entities to the routers, or about fate sharing/resilience issues should be worried about the choice between B1 and B2. (Georgios and Anders have made these points, and there is also a discussion in 10.1 of our framework document draft-hancock-... which comes to a slightly different conclusion...). I want to stress that A1 != B1, and A2 != B2. QoS routing (or indeed load sharing or indeed any other sort of traffic engineering) *anywhere* between the flow endpoints can allow implicitly addressed signalling to drift away from the data path. So, if the fundamental requirement is B1, we have to allow A2. So, what are the requirements? Currently we have B1=SHOULD and A2=SHOULD. Do people care about A1 and B2 or not? Are all four SHOULD? Robert H. PS I apologise if this seems pedantic [colleagues of mine will not be shocked], but I think the distinction is real and significant. I also think that the A1/A2 requirements are framework rather than requirements issues. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 08 March 2002 12:08 > To: john.loughney@nokia.com > Cc: Anders.P.Bergsten@telia.se; nsis@ietf.org > Subject: RE: [NSIS] section 5.2.2 in requirement draft > > > Hi John, > > A good suggestion. I agree. > > Thanks, > Sven. > > > > > > john.loughney@nokia.com on 08/03/2002 10:20:38 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > > cc: Anders.P.Bergsten@telia.se, nsis@ietf.org > > > > Subject RE: [NSIS] section 5.2.2 in requirement draft > : > > > > > > > Hi Sven, > > > I agree with your explanation but I don't think your wording really > > reflects what you say there. Would you agree to something like: > > NSIS SHOULD support on-path signaling and signaling to and/or > > from known entities. The default behaviour SHOULD be > on-path signaling. > > I prefer to have single statement requirements, so I'd suggest we have > 3 requirements: > > > NSIS SHOULD support on-path signaling. > NSIS SHOULD support signaling to and/or from known entities. > The default behaviour SHOULD be on-path signaling. > > Fufilling requirements with multiple clauses is difficult. > (also we can discuss the level - MUST/SHOULD/MAY ...) > > John > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:06:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00413 for ; Fri, 8 Mar 2002 15:06:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02675 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:06:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01533; Fri, 8 Mar 2002 14:54:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01455 for ; Fri, 8 Mar 2002 14:54:22 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29753 for ; Fri, 8 Mar 2002 14:54:19 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 19:47:44 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594B4C@rsys002a.roke.co.uk> From: "Hancock, Robert" To: sven.van_den_bosch@alcatel.be, "Geib, Ruediger" Cc: Martin.Winter@icn.siemens.de, nsis@ietf.org Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Date: Fri, 8 Mar 2002 19:47:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, i suspect i have to own up to originating this requirement. my (possibly rather feeble) background thinking was that the user's = original reservation can be accepted in some absolute sense. however, when the flow gets thrown in with an aggregate, the original = QoS is probably only guaranteed in some statistical sense. therefore, = while the user doesn't care about *how* the aggregation is done, he = might have some views about the *strength* of the statistical guarantee = that was desired (in other words, how aggressively it is reasonable to = aggregate his flows.) but maybe the original reservation is also generally admitted = statistically, and maybe statistical issues are part of service = definition (a.k.a. the 'section 3.5' thread) and therefore out of NSIS = signalling scope anyway. i'm not wedded to it, in any case. r. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 08 March 2002 14:57 > To: Geib, Ruediger > Cc: Martin.Winter@icn.siemens.de; nsis@ietf.org > Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) >=20 >=20 > Hi all, >=20 > I agree as well. I even think the end-user doesn't really=20 > care, as long as > he gets the requested service (whether he is aggregated with others = or > not). >=20 > Just my 2cc, > Sven >=20 >=20 >=20 >=20 >=20 > "Geib, Ruediger" on 08/03/2002 15:10:45 > =20 > =20 > =20 > To: Martin.Winter@icn.siemens.de =20 > =20 > cc: nsis@ietf.org(bcc: Sven VAN DEN =20 > BOSCH/BE/ALCATEL) =20 > =20 > =20 > =20 > Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) =20 > : =20 > =20 >=20 >=20 >=20 >=20 >=20 > Hi Martin, Georgios, >=20 > I agree too, an end system can't specify how to aggregate. A domain > accepting a reservation is committing itself to provide the requested > service. It doesn't matter to the end system how this is done. >=20 > Regards, R=FCdiger >=20 > > I support your view. An initiator is not able to exactly know > > the impact of aggregation on his QoS, so he also cannot > > specify an aggregation method. What an initiator wants, is > > not a specific aggregation method, but just a service. It > > does not matter, how it is realised. > > >=20 > > > Hi Marcus > > > > > > Regarding requirement: > > > "Aggregation method specification" > > > used in Section 5.5.4 > > > > > > I do not know if any initiator will be able to define an > > > aggregation method. > > > An edge node of a domain can do it, but an end host can in my > > > opinion not do it. > > > Thus I do not know how to interpret this requirement! >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:07:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00447 for ; Fri, 8 Mar 2002 15:07:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02694 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:07:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01586; Fri, 8 Mar 2002 14:54:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01544 for ; Fri, 8 Mar 2002 14:54:32 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29758 for ; Fri, 8 Mar 2002 14:54:28 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 19:47:23 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594B47@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "Georgios Karagiannis (ELN)" , "'john.loughney@nokia.com'" , Anders.P.Bergsten@telia.se, sarantis@cnl.di.uoa.gr, nsis@ietf.org Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt Date: Fri, 8 Mar 2002 19:47:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi all, we should not remove a requirement just because it is hard. we should remove it if it is too hard for the benefit obtained. in this particular case, i think the requirement came from the context of not wanting to have a frustrated QI polling an access network (e.g. a cellular one) at some ridiculous rate to find out if resources have become available. (note in particular that it is quite hard in some cellular architectures to bill for this sort of polling, so far as i know.) in some environments, this will be worth doing, and in some it won't. i guess that makes it a SHOULD (which is what the draft says), and there are a number of different modularity approaches which would minimise the pain caused by providing it as an option. (existence argument: QI says 'I want QoS for flow labelled by reference R', QC responds in the event of failure with either 'sorry, try later, in the meantime i've forgotten about R' or 'sorry, i'll tell you later, in the meantime don't ask again for flow R'. related tricks are needed in mobile scenarios. if QI doesn't want notification it omits R. the overhead in the protocol is some optional fields, which either end can ignore. i'm not saying that this is the right way to do it, but i don't see that allowing this as a should causes too much pain for people who don't actually want to implement the functionality.) robert h. ps the security/DoS argument is also valid. but there are security/DoS arguments about all aspects of QoS signalling. i agree that the DoS requirement is probably more important than this one, but if we can solve the DoS problem for the core parts of the signalling, I doubt this non-core part will be much harder. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 08 March 2002 10:37 > To: 'john.loughney@nokia.com'; Anders.P.Bergsten@telia.se; > sarantis@cnl.di.uoa.gr; nsis@ietf.org > Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt > > > Hi John, Anders and Paskali > > I also agree, please remove this requirement! > > Best Regards, > Georgios > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: vrijdag 8 maart 2002 10:17 > To: Anders.P.Bergsten@telia.se; sarantis@cnl.di.uoa.gr; nsis@ietf.org > Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt > > > Hi Anders, > > > I agree and would propose to write: > > > > The nsis architecture MUST NOT support "automatic > > notification on available resources not been granted before". > > > > or just to remove the requirement. > > The two things are entirely different. The best solution is > to remove the requirement. > > MUST NOT requirements are generally used when something is > known to cause incompatabilities. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:08:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00513 for ; Fri, 8 Mar 2002 15:08:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02806 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:08:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00935; Fri, 8 Mar 2002 14:50:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00906 for ; Fri, 8 Mar 2002 14:50:13 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29544 for ; Fri, 8 Mar 2002 14:50:10 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g28Jo9Zc015977 for ; Fri, 8 Mar 2002 20:50:09 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 08 20:50:20 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 20:50:07 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Fri, 8 Mar 2002 20:50:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Steve Okay, but this should be then made very clear. In my opinion it is not clear! Best Regards, Georgios -----Original Message----- From: Steven Berson [mailto:berson@isi.edu] Sent: vrijdag 8 maart 2002 20:45 To: Georgios Karagiannis (ELN) Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Georgios, Section 5.3.2 mentions that advance reservations are not required, but if you wanted advance reservations, then reservation duration seems like a useful thing to have. Steve On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > Hi Steve > > The associated motivation given for this requirement > in the NSIS WG draft is that "allows reducing the reservation > update frequency in case of soft state based signaling." (from draft) > > Therefore, I thought that it was related to the soft-state refresh > timer. Do you have another motivation to keep this requirement. > > Best regards, > Georgios > > > -----Original Message----- > From: Steven Berson [mailto:berson@isi.edu] > Sent: vrijdag 8 maart 2002 20:30 > To: Georgios Karagiannis (ELN) > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > Georgios, > > I am not sure if it is a good idea to support reservation life-times, > but at this time, it does not seem like a good idea to preclude it. > Also, the reservation life-time is not necessarily related to the > soft-state refresh timer. > > Steve > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > Hi Marcus > > > > Regarding requirement in Section 5.3.2: > > > > "Ability to signal life-time of a reservation": > > > > The problem that I have with this requirement is that it will > > increase the complexity of the functionality related to the soft > > state (refresh) principle in a node. > > Please note that the soft state refresh principle is used > > to somehow solve unexpected changes in the network, e.g., route changes > > that are independent of the lifetime of a reservation. > > Therefore, I do not think that the lifetime of the reservation > > should affect the duration of the soft state refresh. > > Please remove it! > > > > Best regards, > > Georgios > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:13:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01116 for ; Fri, 8 Mar 2002 15:13:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03118 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:13:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00658; Fri, 8 Mar 2002 14:45:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00629 for ; Fri, 8 Mar 2002 14:45:28 -0500 (EST) Received: from fig.isi.edu (fig.isi.edu [128.9.160.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29286 for ; Fri, 8 Mar 2002 14:45:25 -0500 (EST) Received: from localhost (berson@localhost) by fig.isi.edu (8.11.6/8.11.6) with ESMTP id g28JjN110105; Fri, 8 Mar 2002 11:45:23 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs Date: Fri, 8 Mar 2002 11:45:23 -0800 (PST) From: Steven Berson To: "Georgios Karagiannis (ELN)" cc: "'brunner@ccrle.nec.de'" , Subject: RE: [NSIS] Requirement Section 5.3.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, Section 5.3.2 mentions that advance reservations are not required, but if you wanted advance reservations, then reservation duration seems like a useful thing to have. Steve On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > Hi Steve > > The associated motivation given for this requirement > in the NSIS WG draft is that "allows reducing the reservation > update frequency in case of soft state based signaling." (from draft) > > Therefore, I thought that it was related to the soft-state refresh > timer. Do you have another motivation to keep this requirement. > > Best regards, > Georgios > > > -----Original Message----- > From: Steven Berson [mailto:berson@isi.edu] > Sent: vrijdag 8 maart 2002 20:30 > To: Georgios Karagiannis (ELN) > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > Georgios, > > I am not sure if it is a good idea to support reservation life-times, > but at this time, it does not seem like a good idea to preclude it. > Also, the reservation life-time is not necessarily related to the > soft-state refresh timer. > > Steve > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > Hi Marcus > > > > Regarding requirement in Section 5.3.2: > > > > "Ability to signal life-time of a reservation": > > > > The problem that I have with this requirement is that it will > > increase the complexity of the functionality related to the soft > > state (refresh) principle in a node. > > Please note that the soft state refresh principle is used > > to somehow solve unexpected changes in the network, e.g., route changes > > that are independent of the lifetime of a reservation. > > Therefore, I do not think that the lifetime of the reservation > > should affect the duration of the soft state refresh. > > Please remove it! > > > > Best regards, > > Georgios > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 15:14:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01146 for ; Fri, 8 Mar 2002 15:14:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03135 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 15:14:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01878; Fri, 8 Mar 2002 14:57:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01840 for ; Fri, 8 Mar 2002 14:57:50 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29941 for ; Fri, 8 Mar 2002 14:57:47 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g28JvmB15684 for ; Fri, 8 Mar 2002 20:57:48 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 08 20:58:00 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 20:57:47 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , Hannes Tschofenig , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Fri, 8 Mar 2002 20:57:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Robert It is also exactly to what I am referring, when I am referring to hop-by-hop security. There will be intermediate routers that will use NSIS. Not all the intermediate routers should process the hop-by-hop security option! Best regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: vrijdag 8 maart 2002 20:48 To: Hannes Tschofenig; Georgios Karagiannis (ELN); brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Hi, Exactly. The requirement relates to 'NSIS hops' i.e. the signalling between QI and first QC, or between a pair of QCs, or between QC and last QR. I don't see any reason for NSIS to specify security requirements for entities that don't take part in NSIS signalling. We might say that some QC pairs don't need a security relationship, e.g. if they're in the same domain. (I guess this is more the scenario Georgios is referring to???) But we need to be careful here: I think what we would actually be saying is that interiors of domains can be protected from unauthorised traffic so they can assume that they can trust any NSIS signalling they get. In that case, we should define very carefully how this shielding is done. I see a close parallel here with routing protocol security. Basic IGPs (RIP, OSPF, ...) usually have an authentication capability, but as an option. Do people actually use these options? (Would they be prepared to admit it if they didn't? In today's uncertain world, would they be better off if they did?) robert h. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: 08 March 2002 16:30 > To: Georgios Karagiannis (ELN); brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) > > > dear georgios! > > > Dear Marcus > > > Another problem, requirement: > > "The QoS signaling protocol must allow for hop-by-hop > security" in Section > 5.8.5 > > > I do not agree that all intermediate routers located in a > communication > path > > should support this requirement. > > However, I agree that some nodes, e.g., end host, Access > routers, proxies, > centralised resource > > managers need to support security issues; > > > Therefore, I propose to either remove this requirement or > emphasisse that > this requirement > > is not hop-by-hop but applied on certain specialised nodes, > e.g., .end > host, access routers, centralised > > resource managers.... > > The requirement of section 5.8.5 "The QoS signaling protocol > must allow for > hop-by-hop security" does not > necessarily mean that every router must enforce hop-by-hop security > protection. a qos protocol must however > support mechanisms that allow hop-by-hop security mechanism to be used > between qos signaling aware nodes. > > > Best regards, > > Georgios > > ciao > hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 8 17:10:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07061 for ; Fri, 8 Mar 2002 17:10:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09760 for nsis-archive@odin.ietf.org; Fri, 8 Mar 2002 17:10:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08450; Fri, 8 Mar 2002 16:48:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08415 for ; Fri, 8 Mar 2002 16:48:01 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06076 for ; Fri, 8 Mar 2002 16:47:32 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id g28Ln7G14202; Fri, 8 Mar 2002 15:49:07 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g28LjqD20571; Fri, 8 Mar 2002 15:45:52 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 15:46:29 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA1F@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Anders.P.Bergsten@telia.se'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org, Niklas.G.Borg@telia.se Subject: RE: [NSIS] section 5.2.2 in requirement draft Date: Fri, 8 Mar 2002 15:46:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Anders, I think our first priority is a protocol that allows an application (QOS Initiator?) to request(from a QOS Controller?) a qos connection service between its host and another host. Next we need to consider what other signaling will be necessary to produce an end-to-end result. In one approach a QOS controller might setup several QOS connections/channels independently and splice them together. By connection/channel I mean an entrance and exit through a network with a qos service guarantee. In another approach a QOS controller may arrange for a qos connection/channel in its domain and pass on a request to the next domain to arrange for a qos connection/channel towards an eventual destination. This is analagous to hop by hop signaling only it is domain by domain under the assumption that there are many existing techniques (such as long lived pipes) to arrange for the qos within a particular domain. Best Regards, Marco > -----Original Message----- > From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] > Sent: Thursday, March 07, 2002 10:04 AM > To: sven.van_den_bosch@alcatel.be > Cc: nsis@ietf.org; Niklas.G.Borg@telia.se > Subject: RE: [NSIS] section 5.2.2 in requirement draft > > > Sven, > > > I think we have to make a distinction between > in-band/out-of-band and > > centralised/distributed. An out of band solution is not necessarily > > centralised. It may, however, be convenient to think about it as > > centralised although its implementation can be distributed. > Agreed, that was what I tried to indicate with a cluster-of QCs. > > > This is achieved with the two-level admission control within > > long-lived pipes with > > defined QoS. This would relax the requirements on the nsis > > protocol when > > used end-to-end because most of the complexity would be in > > the defintion > > and provisioing of the long-lived pipes which is a local matter. > This was my main question: > > is the "long-lived pipes"-service something that is within > focus of nsis or not? > > This "long-lived pipes" sounds like provisioning of resources > to me. We have been playing with this architecture for awhile > as well (a paper coming out in Networks 2002) that describes > and analyse an architecture for supporting this. The > architecture is doable, but is it really the first thing we > should tackle? And should it be tackled in nsis? > > If the consensus is yes, then I suggest for clarity that the > requirements for the two different parts be clearly > separated. My hunch is that the two different tracks > ("layers") will lead to two different architectures and > mixing them will create a fuzzy requirements document. > > From my point of view, I would be as happy to leave this work > for future studies and focus on the first tier (the e2e > signaling). And then bring up the discussion on the > second-tier seperately. > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 02:34:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00674 for ; Mon, 11 Mar 2002 02:34:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19563 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 02:34:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18052; Mon, 11 Mar 2002 02:18:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18020 for ; Mon, 11 Mar 2002 02:18:25 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00463 for ; Mon, 11 Mar 2002 02:18:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2B7J6i20980 for ; Mon, 11 Mar 2002 09:19:06 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Mar 2002 09:18:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 09:18:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Date: Mon, 11 Mar 2002 09:18:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64BB7@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] 5.5.4 requirement (Section 5.5.4) Thread-Index: AcHG4cV2jRNFnc12QwW3junFntbIqgB6vdaQ To: Cc: X-OriginalArrivalTime: 11 Mar 2002 07:18:23.0787 (UTC) FILETIME=[EE2C9FB0:01C1C8CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA18021 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Robert, > i suspect i have to own up to originating this requirement. > > my (possibly rather feeble) background thinking was that the > user's original reservation can be accepted in some absolute sense. > however, when the flow gets thrown in with an aggregate, the > original QoS is probably only guaranteed in some statistical > sense. therefore, while the user doesn't care about *how* the > aggregation is done, he might have some views about the > *strength* of the statistical guarantee that was desired (in > other words, how aggressively it is reasonable to aggregate > his flows.) > > but maybe the original reservation is also generally admitted > statistically, and maybe statistical issues are part of > service definition (a.k.a. the 'section 3.5' thread) and > therefore out of NSIS signalling scope anyway. I concur - I think that this goes to far down the implementation / service definition road to be useful in the general requirements document - so it should be removed. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 03:37:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01563 for ; Mon, 11 Mar 2002 03:37:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23069 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 03:37:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22033; Mon, 11 Mar 2002 03:24:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22001 for ; Mon, 11 Mar 2002 03:24:55 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01249 for ; Mon, 11 Mar 2002 03:24:51 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2B8OH417278; Mon, 11 Mar 2002 09:24:17 +0100 (MET) Subject: RE: [NSIS] section on QI/QC and QI/QC terminology To: Kappler Cornelia Cc: "'john.loughney@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 11 Mar 2002 09:24:11 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 09:24:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Cornelia, I agree with you that we need to have easy terminology to describe what we are talking about. There is one thing missing in the QI/QC terminology. As far as I understand, the QI initiates the QoS *for the NSIS signaling*. So it is not necessarily the end host even if the end host initiates the signaling. Therefore, I would propose to call it 'initiating a particular level of NSIS signaling' Do you agree?, Svenm. Kappler Cornelia on 08/03/2002 16:53:22 To: "'john.loughney@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] section on QI/QC and QI/QC : terminology Hi John and Georgios, as probably everybody else I agree we need to settle on some terminology. The alternative is, in each requirement, to list all possibilities we can think of. Instead of e.g.: "5.3.1. Possibility for automatic release of resources after failure When the QoS Intitiator goes down, the resources it requested should be released since they are no longer necessary" we put "5.3.1... When an end system, an edge router, or a signalling proxy go down and they have been initiating a reservation, the resources they requested should be released since..." not too elegant, and, more importantly, not sufficiently general. So lets say "5.3.1 ...When an entity that initiated a reservation goes down, the resources it requested..." To make it more legible we replace "entity that initiated a reservation" = QoS Intitiator This provides the additional benefit that in a terminology section we can more precisely define what a QoS Initiator is (may be the perfectly precise definition could be left to the framework). Likewise QoS Controller. [If you would rather use "ETIAR" (Entity That Intitiated A Reservation) or whatever fine with me. (sorry for becoming silly)] I dont understand yet how this implies a separation / grouping of requirements. There has been so much going on on this list that I lost this bit. Georgios, may be you could expand on this problem? Regarding whether NSIS is client/server or peer2peer or a mixture, do we need to fix this in the requirements? Cornelia > -----Original Message----- > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > Sent: Friday, March 08, 2002 12:36 PM > To: Georgios.Karagiannis@eln.ericsson.se; sven.van_den_bosch@alcatel.be; nsis@ietf.org > Subject: RE: [NSIS] section on QI/QC and QI/QC terminology > > Hi Georgios, > > > I propose to postpone the terminology of QoS Initiator and > > QoS Controller to framework draft. Meaning that > > the terms QoS Initiator and QoS Controller will not be used > > in the NSIS WG requirements draft. > > > > The main reason for this is that, according to John, > > the NSIS WG requirements draft should not contain any > > separation/grouping > > of QoS requirements. This separation will probably be done in the > > framework draft. There we could also define entities such as > > QI and QC. > > Bigger question to the Working Group. Is NSIS peer-to-peer; > Client-server; or a mixture. I can see it as a mixture. > In end-to-edge signaling, it is client-server, however, in > both end-to-end and edge-to-edge, it is peer-to-peer. > > I think the Requirements document should have some terminology > that describes the parties involved in the signaling ... however, > I don't think that the WG has decided on what terminology to use. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 03:50:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01779 for ; Mon, 11 Mar 2002 03:50:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23860 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 03:50:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22939; Mon, 11 Mar 2002 03:34:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22904 for ; Mon, 11 Mar 2002 03:34:39 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01525 for ; Mon, 11 Mar 2002 03:34:35 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 11 Mar 2002 09:32:32 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 09:33:59 +0100 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Date: Mon, 11 Mar 2002 09:33:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA22905 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > I think that we should be flexible only if it is required > to be flexible. In the case of Mobile IP, it is required that the > reservation ID must be independent, due to the Care of > Addresses changes. > Could you please give other examples where you will need to > have an independent reservation ID. Yep. The scenario I'm talking about all the time is edge to edge aggregate reservation. In that case all I need is some unique ID, a destination address and a prefix. Instead of a destination address, we may even need a couple of addresses and more than one prefix. Then a reference to e.g. a directory entry may even be more useful. Of course you could add source IP addresses, prefixes, ports and applications and wildcard all of it as it may be not required. What's the benefit of signaling useless information? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 04:14:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02168 for ; Mon, 11 Mar 2002 04:14:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA25710 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 04:15:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24726; Mon, 11 Mar 2002 04:00:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24694 for ; Mon, 11 Mar 2002 04:00:49 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01948 for ; Mon, 11 Mar 2002 04:00:45 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2B906E28667; Mon, 11 Mar 2002 10:00:07 +0100 (MET) To: "Hancock, Robert" Cc: "Geib, Ruediger" , Martin.Winter@icn.siemens.de, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 11 Mar 2002 10:00:00 +0100 Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 10:00:07 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256B79003117268f9e8a93df938690918cC1256B7900311726" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --0__=C1256B79003117268f9e8a93df938690918cC1256B7900311726 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Robert, I must admit I feel more for your second suggestion. I suspect guarante= es will always come with some statistics attached to them. There may be ot= her reasons, however, to request that you will not be aggregated with other= flows (security?). If such reasons exist, I think it may be advantageou= s to specify whether or not you are aggregated (so just 1 bit). Regards, Sven. "Hancock, Robert" on 08/03/2002 20:47:34 =20 =20 =20 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, "Geib, =20 Ruediger" =20 =20 cc: Martin.Winter@icn.siemens.de, nsis@ietf.org =20 =20 =20 =20 Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) =20 : =20 =20 hi all, i suspect i have to own up to originating this requirement. my (possibly rather feeble) background thinking was that the user's original reservation can be accepted in some absolute sense. however, when the flow gets thrown in with an aggregate, the original Q= oS is probably only guaranteed in some statistical sense. therefore, while= the user doesn't care about *how* the aggregation is done, he might have so= me views about the *strength* of the statistical guarantee that was desire= d (in other words, how aggressively it is reasonable to aggregate his flo= ws.) but maybe the original reservation is also generally admitted statistically, and maybe statistical issues are part of service definit= ion (a.k.a. the 'section 3.5' thread) and therefore out of NSIS signalling scope anyway. i'm not wedded to it, in any case. r. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 08 March 2002 14:57 > To: Geib, Ruediger > Cc: Martin.Winter@icn.siemens.de; nsis@ietf.org > Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) > > > Hi all, > > I agree as well. I even think the end-user doesn't really > care, as long as > he gets the requested service (whether he is aggregated with others o= r > not). > > Just my 2cc, > Sven > > > > > > "Geib, Ruediger" on 08/03/2002 15:10:45= > > > > To: Martin.Winter@icn.siemens.de > > cc: nsis@ietf.org(bcc: Sven VAN DEN > BOSCH/BE/ALCATEL) > > > > Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) > : > > > > > > > Hi Martin, Georgios, > > I agree too, an end system can't specify how to aggregate. A domain > accepting a reservation is committing itself to provide the requested= > service. It doesn't matter to the end system how this is done. > > Regards, R=FCdiger > > > I support your view. An initiator is not able to exactly know > > the impact of aggregation on his QoS, so he also cannot > > specify an aggregation method. What an initiator wants, is > > not a specific aggregation method, but just a service. It > > does not matter, how it is realised. > > > > > > Hi Marcus > > > > > > Regarding requirement: > > > "Aggregation method specification" > > > used in Section 5.5.4 > > > > > > I do not know if any initiator will be able to define an > > > aggregation method. > > > An edge node of a domain can do it, but an end host can in my > > > opinion not do it. > > > Thus I do not know how to interpret this requirement! > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > (See attached file: RMRL-Disclaimer.txt) = --0__=C1256B79003117268f9e8a93df938690918cC1256B7900311726 Content-type: application/octet-stream; name="=?iso-8859-1?Q?RMRL-Disclaimer.txt?=" Content-Disposition: attachment; filename="=?iso-8859-1?Q?RMRL-Disclaimer.txt?=" Content-Transfer-Encoding: base64 VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCB0byBSb2tlIA0KTWFub3IgUmVzZWFyY2ggTHRkIGFuZCBtdXN0 IG5vdCBiZSBwYXNzZWQgdG8gYW55IHRoaXJkIHBhcnR5IHdpdGhvdXQgcGVybWlzc2lvbi4gVGhp cyANCmNvbW11bmljYXRpb24gaXMgZm9yIGluZm9ybWF0aW9uIG9ubHkgYW5kIHNoYWxsIG5vdCBj cmVhdGUgb3IgY2hhbmdlIGFueSBjb250cmFjdHVhbCANCnJlbGF0aW9uc2hpcC4NCg0K --0__=C1256B79003117268f9e8a93df938690918cC1256B7900311726-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 04:24:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02400 for ; Mon, 11 Mar 2002 04:24:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26324 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 04:24:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25484; Mon, 11 Mar 2002 04:12:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25453 for ; Mon, 11 Mar 2002 04:12:18 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02106 for ; Mon, 11 Mar 2002 04:12:14 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 11 Mar 2002 10:10:00 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 10:11:28 +0100 Message-Id: From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Date: Mon, 11 Mar 2002 10:11:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA25454 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Sven, > There may be other reasons, however, to request that you > will not be aggregated with other flows (security?). > If such reasons exist, I think it may be advantageous to > specify whether or not you are aggregated (so just 1 bit). Could you go into more detail what you mean by security reasons preventing aggregation? Also "secure" ATM/FR cells are multiplexed on transmission systems and switches. I don't think aggregation means much more than multiplexing. Or would your understanding of aggregation be something like "set up a container and fill packets belonging to different flows into container & forward container instead of individual packets"? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 04:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02596 for ; Mon, 11 Mar 2002 04:31:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27129 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 04:32:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25972; Mon, 11 Mar 2002 04:19:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25937 for ; Mon, 11 Mar 2002 04:19:22 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02249 for ; Mon, 11 Mar 2002 04:19:18 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2B9JKB26341 for ; Mon, 11 Mar 2002 10:19:20 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Mar 11 10:15:42 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 10:15:27 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Date: Mon, 11 Mar 2002 10:08:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA25938 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rüdiger I think that you might be right, but emphasising that the reservation ID is independent of any information it will cause a complex specification and implementation of the NSIS protocol. In my opinion we should not say that the reservation ID is completely independent. I think that the reservation ID and its relation to e.g., flow ID, DSCP, DCLASS, etc., should be specified. I agree with you that this specification will be difficult but we will have to do it. We could probably say (in the requirement) that the specification of the reservation ID depends on the scenario used. During the specification of a scenario, also the specification of the reservation ID should be provided. Best Regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: maandag 11 maart 2002 9:34 To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Hi Georgios, > I think that we should be flexible only if it is required > to be flexible. In the case of Mobile IP, it is required that the > reservation ID must be independent, due to the Care of > Addresses changes. > Could you please give other examples where you will need to > have an independent reservation ID. Yep. The scenario I'm talking about all the time is edge to edge aggregate reservation. In that case all I need is some unique ID, a destination address and a prefix. Instead of a destination address, we may even need a couple of addresses and more than one prefix. Then a reference to e.g. a directory entry may even be more useful. Of course you could add source IP addresses, prefixes, ports and applications and wildcard all of it as it may be not required. What's the benefit of signaling useless information? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 04:38:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02662 for ; Mon, 11 Mar 2002 04:38:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27536 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 04:38:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26163; Mon, 11 Mar 2002 04:23:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26118 for ; Mon, 11 Mar 2002 04:23:30 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02325 for ; Mon, 11 Mar 2002 04:23:26 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 11 Mar 2002 10:21:27 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 10:22:54 +0100 Message-Id: From: "Geib, Ruediger" To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) Date: Mon, 11 Mar 2002 10:22:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA26119 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Georgios > We could probably say (in the requirement) that the specification of > the reservation ID depends on the scenario used. During the > specification of a scenario, also the specification of the > reservation ID should be provided. Would be allright with me. > Best Regards, > Georgios > > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: maandag 11 maart 2002 9:34 > To: Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.5.7 requirement (Section 5.5.7) > > > Hi Georgios, > > > I think that we should be flexible only if it is required > > to be flexible. In the case of Mobile IP, it is required that the > > reservation ID must be independent, due to the Care of > > Addresses changes. > > Could you please give other examples where you will need to > > have an independent reservation ID. > > Yep. The scenario I'm talking about all the time is edge to > edge aggregate reservation. In that case all I need is some > unique ID, a destination address and a prefix. Instead of a > destination address, we may even need a couple of addresses > and more than one prefix. Then a reference to e.g. a > directory entry may even be more useful. > > Of course you could add source IP addresses, prefixes, ports > and applications and wildcard all of it as it may be not > required. What's the benefit of signaling useless information? > > Regards, Rüdiger > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 04:38:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02679 for ; Mon, 11 Mar 2002 04:38:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27551 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 04:38:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26269; Mon, 11 Mar 2002 04:24:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26234 for ; Mon, 11 Mar 2002 04:24:15 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02359 for ; Mon, 11 Mar 2002 04:24:10 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2B9Ngn08017; Mon, 11 Mar 2002 10:23:42 +0100 (MET) Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) To: "Geib, Ruediger" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 11 Mar 2002 10:23:40 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 10:23:41 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA26235 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Ruediger, I am by no means a security specialist. I reacted to the requirement of 'needing to signal aggregation type' because I thought it was both infeasible and unneeded. But I didn't want to make such a hard statement because I couldn't assess all possible security risks. Therefore I thought we could the possibility for a boolean aggregation parameter open. What do you think? Sven. "Geib, Ruediger" on 11/03/2002 10:11:20 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) : Hello Sven, > There may be other reasons, however, to request that you > will not be aggregated with other flows (security?). > If such reasons exist, I think it may be advantageous to > specify whether or not you are aggregated (so just 1 bit). Could you go into more detail what you mean by security reasons preventing aggregation? Also "secure" ATM/FR cells are multiplexed on transmission systems and switches. I don't think aggregation means much more than multiplexing. Or would your understanding of aggregation be something like "set up a container and fill packets belonging to different flows into container & forward container instead of individual packets"? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 04:50:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02823 for ; Mon, 11 Mar 2002 04:50:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28037 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 04:50:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27500; Mon, 11 Mar 2002 04:37:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27468 for ; Mon, 11 Mar 2002 04:37:24 -0500 (EST) Received: from odin.di.uoa.gr (odin.di.uoa.gr [195.134.67.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02646 for ; Mon, 11 Mar 2002 04:37:19 -0500 (EST) Received: (from sarantis@localhost) by odin.di.uoa.gr (8.11.6/8.11.6) id g2B9ZeB04024; Mon, 11 Mar 2002 11:35:40 +0200 Date: Mon, 11 Mar 2002 11:35:39 +0200 From: Sarantis Paskalis To: "Hancock, Robert" Cc: "Georgios Karagiannis (ELN)" , "'john.loughney@nokia.com'" , Anders.P.Bergsten@telia.se, sarantis@cnl.di.uoa.gr, nsis@ietf.org Subject: Re: [NSIS] Comment on draft-ietf-nsis-req-00.txt Message-ID: <20020311113539.A3965@odin.di.uoa.gr> References: <76C92FBBFB58D411AE760090271ED41804594B47@rsys002a.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <76C92FBBFB58D411AE760090271ED41804594B47@rsys002a.roke.co.uk>; from robert.hancock@roke.co.uk on Fri, Mar 08, 2002 at 07:47:20PM -0000 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org On Fri, Mar 08, 2002 at 07:47:20PM -0000, Hancock, Robert wrote: > hi all, > > we should not remove a requirement just because it is hard. we should remove it if it is too hard for the benefit obtained. > > in this particular case, i think the requirement came from the context of not wanting to have a frustrated QI polling an access network (e.g. a cellular one) at some ridiculous rate to find out if resources have become available. (note in particular that it is quite hard in some cellular architectures to bill for this sort of polling, so far as i know.) > > in some environments, this will be worth doing, and in some it won't. i guess that makes it a SHOULD (which is what the draft says), and there are a number of different modularity approaches which would minimise the pain caused by providing it as an option. (existence argument: QI says 'I want QoS for flow labelled by reference R', QC responds in the event of failure with either 'sorry, try later, in the meantime i've forgotten about R' or 'sorry, i'll tell you later, in the meantime don't ask again for flow R'. related tricks are needed in mobile scenarios. if QI doesn't want notification it omits R. the overhead in the protocol is some optional fields, which either end can ignore. i'm not saying that this is the right way to do it, but i don't see that allowing this as a should causes too much pain for people who don't actually want to implement the functionality.) In that case the requirement should probably be: "The QI MAY (or SHOULD) support being automatically notified from QCs for resources not previously available" No requirement should be placed on QCs (or whatever they will be named). -- Sarantis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 05:18:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03446 for ; Mon, 11 Mar 2002 05:18:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00778 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 05:18:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29604; Mon, 11 Mar 2002 05:04:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29541 for ; Mon, 11 Mar 2002 05:04:35 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03066 for ; Mon, 11 Mar 2002 05:04:30 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g2BA4WR21357; Mon, 11 Mar 2002 11:04:32 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g2BA4Vg05291; Mon, 11 Mar 2002 11:04:31 +0100 (MET) From: "Hannes Tschofenig" To: "Georgios Karagiannis \(ELN\)" , "'Hancock, Robert'" , Cc: Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Mon, 11 Mar 2002 11:07:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit hi georgios > Hi Robert > It is also exactly to what I am referring, when I am referring > to hop-by-hop security. There will be intermediate routers that will use > NSIS. Not all the intermediate routers should process the hop-by-hop > security option! but we cannot formulate this as a requirement. the requirement can only be that a qos signaling protocol must provide a hop-by-hop security element. for some parts of the path (for example within a administrativek domain) the network service provider may choose not to use it e.g. because of the strong trust assumtpions, because of other security mechanisms deployed etc. without knowing the constrainsts and the architecture of service provider's network it should be assumed that the provided security mechanisms are deployed. some questions that usually arise are: - why do we think that such a protection is necessary? in general, without the requirement for a minimum of a security protection it is possible to inject faked messages (and other types of attacks). - are there possibilities when to relax this requirement? if a network service provider thinks for example that his core-network is "secure" and no adversary is able to inject bogus signaling messages into the network (e.g. because only authenticated are allowed to enter the domain) then he may do so. this change does not "destroy" the hop-by-hop requirement. it only changes the number of nodes participating in the hop-by-hop protection (i.e. because the service providers feels that the core network should only represent one hop). you may argue that there is a question of what is considered to be a hop. this is actually true! - are these mechanisms performance intensive? usually hop-by-hop protection is achieved by using an keyed message digest such as SHA-1, RIPEMD-160 or MD5 computed over the entire message including a replay protection field. these algorithms are known to be very fast. - is it difficult to establish the security association within the core-network (between neighboring routers. our current view is that such a security association establishment is not too difficult because of * the trust relationship within the core network (run by a single network provider) * the limited number of security associations required (only neighboring routers need to have a security association with each other) the security association between the user and a node in the network is in general more difficult to established. (if i use the term router i refer to a router participating in the qos signaling.) ciao hannes > Best regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 05:18:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03462 for ; Mon, 11 Mar 2002 05:18:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00814 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 05:18:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29598; Mon, 11 Mar 2002 05:04:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29540 for ; Mon, 11 Mar 2002 05:04:35 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03065 for ; Mon, 11 Mar 2002 05:04:30 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g2BA4WR21359; Mon, 11 Mar 2002 11:04:32 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g2BA4Wg05305; Mon, 11 Mar 2002 11:04:32 +0100 (MET) From: "Hannes Tschofenig" To: "Georgios Karagiannis \(ELN\)" , Cc: Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Mon, 11 Mar 2002 11:07:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit hi georgios >Dear Hannes > Do you mean that this requirement is different than the one > supported by RSVPv1? the situation for rsvpv1 are more complicated if you take the policy aware and policy unware routers into consideration. there you have basically two "hop-by-hop" security mechanisms. the rsvp integrity object however provides similar functionality. the protocol needs to have an option for hop-by-hop protection. for some interface this protection is strongly advised whereas others are left open to the network operator. it is the choice of the network operator how to protect his internal network. > Please note that RSVPv1 performs hop-by-hop security by > using e.g., a hop-by-hop authentication > mechanism which uses an encrypted hash function. a keyed message digest > If that is the case (not an RSVPv1 hop-by-hop security) > then maybe we could emphasise that this > is not a hop-by-hop authentication mechanism, we could clearify the term hop-by-hop and mention some example of nodes involved in the hops. > but something else.... there are only two terms to choose from: hop-by-hop and end-to-end. i don't want to invent a new term since it is used in many protocols and it is not useful (i think)! what do you think? ciao hannes >Best regards, > Georgios hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 05:44:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03862 for ; Mon, 11 Mar 2002 05:44:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03051 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 05:44:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02051; Mon, 11 Mar 2002 05:32:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01937 for ; Mon, 11 Mar 2002 05:31:56 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03628 for ; Mon, 11 Mar 2002 05:31:51 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 11 Mar 2002 11:26:13 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 11:27:41 +0100 Message-Id: From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Date: Mon, 11 Mar 2002 11:27:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA01946 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, to me end systems telling routers how to aggregate services sounds a bit like active networking. I'm favouring the classic approach that a customer negotiates a service with a provider and leaves it to the provider how that service is realised. If there's a no-aggregation issue, it should be part of the service definition rather than the signalling. In consequence, I don't look at aggregation/no-aggregation as a signaling issue. I don't want to spend the bit. Regards, Rüdiger > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Monday, March 11, 2002 10:24 AM > To: Geib, Ruediger > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) > > > Hi Ruediger, > > I am by no means a security specialist. I reacted to the > requirement of > 'needing to signal aggregation type' because I thought it was both > infeasible and unneeded. But I didn't want to make such a > hard statement > because I couldn't assess all possible security risks. > Therefore I thought > we could the possibility for a boolean aggregation parameter > open. What do > you think? > > Sven. > > > > > > "Geib, Ruediger" on 11/03/2002 10:11:20 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > > > Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) > : > > > > > > > Hello Sven, > > > There may be other reasons, however, to request that you > > will not be aggregated with other flows (security?). > > If such reasons exist, I think it may be advantageous to > > specify whether or not you are aggregated (so just 1 bit). > > Could you go into more detail what you mean by security > reasons preventing > aggregation? Also "secure" ATM/FR cells are multiplexed on > transmission > systems and switches. I don't think aggregation means much more than > multiplexing. > Or would your understanding of aggregation be something like "set up a > container and fill packets belonging to different flows into > container & > forward container instead of individual packets"? > > Regards, Rüdiger > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 05:57:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04067 for ; Mon, 11 Mar 2002 05:57:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04035 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 05:57:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03035; Mon, 11 Mar 2002 05:44:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03006 for ; Mon, 11 Mar 2002 05:44:11 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03857 for ; Mon, 11 Mar 2002 05:44:06 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2BAi9Zc021655 for ; Mon, 11 Mar 2002 11:44:09 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 11 11:44:00 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 11:44:01 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Hannes Tschofenig'" , "'Hancock, Robert'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Mon, 11 Mar 2002 11:36:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Hannes What about saying something like: The initiator of the NSIS protocol can require the support of the hop-by-hop security feature. However, an administrator of a QoS domain is able to deactivate this feature, when the NSIS protocol is used within its administrative QoS domain. Best Regards, Georgios -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: maandag 11 maart 2002 11:07 To: Georgios Karagiannis (ELN); 'Hancock, Robert'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) hi georgios > Hi Robert > It is also exactly to what I am referring, when I am referring > to hop-by-hop security. There will be intermediate routers that will use > NSIS. Not all the intermediate routers should process the hop-by-hop > security option! but we cannot formulate this as a requirement. the requirement can only be that a qos signaling protocol must provide a hop-by-hop security element. for some parts of the path (for example within a administrativek domain) the network service provider may choose not to use it e.g. because of the strong trust assumtpions, because of other security mechanisms deployed etc. without knowing the constrainsts and the architecture of service provider's network it should be assumed that the provided security mechanisms are deployed. some questions that usually arise are: - why do we think that such a protection is necessary? in general, without the requirement for a minimum of a security protection it is possible to inject faked messages (and other types of attacks). - are there possibilities when to relax this requirement? if a network service provider thinks for example that his core-network is "secure" and no adversary is able to inject bogus signaling messages into the network (e.g. because only authenticated are allowed to enter the domain) then he may do so. this change does not "destroy" the hop-by-hop requirement. it only changes the number of nodes participating in the hop-by-hop protection (i.e. because the service providers feels that the core network should only represent one hop). you may argue that there is a question of what is considered to be a hop. this is actually true! - are these mechanisms performance intensive? usually hop-by-hop protection is achieved by using an keyed message digest such as SHA-1, RIPEMD-160 or MD5 computed over the entire message including a replay protection field. these algorithms are known to be very fast. - is it difficult to establish the security association within the core-network (between neighboring routers. our current view is that such a security association establishment is not too difficult because of * the trust relationship within the core network (run by a single network provider) * the limited number of security associations required (only neighboring routers need to have a security association with each other) the security association between the user and a node in the network is in general more difficult to established. (if i use the term router i refer to a router participating in the qos signaling.) ciao hannes > Best regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 06:21:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04712 for ; Mon, 11 Mar 2002 06:21:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07114 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 06:21:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05635; Mon, 11 Mar 2002 06:08:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05604 for ; Mon, 11 Mar 2002 06:08:00 -0500 (EST) Received: from eugnpop1.eugn.uswest.net (eugnpop1.eugn.uswest.net [207.109.240.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04359 for ; Mon, 11 Mar 2002 06:07:54 -0500 (EST) Message-Id: <200203111107.GAA04359@ietf.org> Received: (qmail 29390 invoked by uid 0); 11 Mar 2002 11:07:56 -0000 Received: from unknown (HELO SOLTANI) (63.224.205.30) by eugnpop1.eugn.uswest.net with SMTP; 11 Mar 2002 11:07:56 -0000 Date: Mon, 11 Mar 2002 03:19:16 -0800 From: "Jamshid Pashutan" <> To: nsis@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: SA-SMTPMail 1.0 (http://www.aspstudio.com) Reply-To: pashutan@qwest.net Content-Transfer-Encoding: 7bit Subject: [NSIS] Urgent! Iran! Can you help? Please also forward. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit The purpose of my letter is to introduce the Azadegan Foundation and to request your assistance. The Azadegan Foundation is a Not-for-Profit 501c3 organization dedicated to the promotion of democracy, human rights, and the establishment of a secular government in Iran. Our organization has a concrete, measurable strategy for facilitating change, and it is crucial for us at this juncture to secure your financial and moral support in order to accomplish our objectives. The clerical clique in Tehran views the world as a Mosque to be run by clerics who are inspired by the ecumenical revolutionary ideals of Ayatollah Khomeini. As each day passes, The Islamic regime of Tehran is ever increasing its covert political, financial, military and logistical support to a variety of terrorist groups. Citizens who have risen against the tyrannical rule of the clerics have been repressed brutally. Despite the danger they face, they are demanding that the regime put an end to its arbitrary rule, and to free political prisoners. Their struggle will continue and will intensify until the retreat of the ruling clerics to mosques, and the ultimate transfer of power to the people. Today, persecution of religious minorities continues, almost all pro-democracy newspapers have been shut down, and editors and writers have been imprisoned. Student leaders and all nationalist opposition leaders are being arrested and mercilessly tortured in prison, and women (even pregnant women) are stoned to death. Iran's population is now 70 million, with 45 million under 25 years of age. The economic situation and the over all standard of living is rapidly deteriorating. Discontent among the military, and even the Revolutionary Guard created by the regime, is ever increasing. Religious leaders and religious foundations totally control the economy. The Iranian people desire freedom, democracy, and the establishment of a secular Government. Please reply to this Email for more information about volunteering or supporting the Azadegan Foundation. Support the struggle of the Iranian people! Volunteers are always welcome. Contributions and Inquiries should be addressed to: Azadegan Foundation, PO Box 40152, Washington, DC 20016, USA Phone 541-606-3050 Fax 202-363-5985. Email: pashutan@qwest.net Thank you very much for your time and consideration in to this matter. I look forward to speaking with you further. Please forward this letter to your friends and associates. You can help make a difference! Sincerely Yours, Jamshid Pashutan Advocate for the People Please reply by Email, call us, fax, or snail mail us for more information and reference material. Email me at:: pashutan@qwest.net You received this Email because we aquire Email lists of individuals who may be interested in supporting the Iranian people and their struggle for freedom and democracy. If you have received this message in error, or if you do not wish any further communications from our office, Please respond with 'remove' in the subject line. To stop all Emails instantly, Email pashutan@qwest.net with subject of 'remove'. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 09:55:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10307 for ; Mon, 11 Mar 2002 09:55:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21364 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 09:55:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20418; Mon, 11 Mar 2002 09:42:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20386 for ; Mon, 11 Mar 2002 09:42:21 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09614 for ; Mon, 11 Mar 2002 09:42:16 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA08381; Mon, 11 Mar 2002 15:41:47 +0100 (MET) Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) To: "Geib, Ruediger" Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org Date: Mon, 11 Mar 2002 15:41:46 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 15:41:47 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA20387 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Rudiger, Sven, I agree with Rudiger's proposal; we should not forget that when we use the words "service provider" and "customer" we are talking about a contractual relation, implying generally some amount of money in between. So, it is hard to imagine that a customer takes a subscription describing the provided service and how it is actually implemented in the network. IMHO, the service provider is free to aggregate (what and at which level), compress, etc. etc. providing that he is still complying with the service definition (behaviour, including QoS guarantees), that is, that the contractual relation with the customer is not violated. Best regards Juan Carlos "Geib, Ruediger" @ietf.org on 11/03/2002 11:27:33 Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) Hi Sven, to me end systems telling routers how to aggregate services sounds a bit like active networking. I'm favouring the classic approach that a customer negotiates a service with a provider and leaves it to the provider how that service is realised. If there's a no-aggregation issue, it should be part of the service definition rather than the signalling. In consequence, I don't look at aggregation/no-aggregation as a signaling issue. I don't want to spend the bit. Regards, Rüdiger > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: Monday, March 11, 2002 10:24 AM > To: Geib, Ruediger > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4) > > > Hi Ruediger, > > I am by no means a security specialist. I reacted to the > requirement of > 'needing to signal aggregation type' because I thought it was both > infeasible and unneeded. But I didn't want to make such a > hard statement > because I couldn't assess all possible security risks. > Therefore I thought > we could the possibility for a boolean aggregation parameter > open. What do > you think? > > Sven. > > > > > > "Geib, Ruediger" on 11/03/2002 10:11:20 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > > > Subject RE: [NSIS] 5.5.4 requirement (Section 5.5.4) > : > > > > > > > Hello Sven, > > > There may be other reasons, however, to request that you > > will not be aggregated with other flows (security?). > > If such reasons exist, I think it may be advantageous to > > specify whether or not you are aggregated (so just 1 bit). > > Could you go into more detail what you mean by security > reasons preventing > aggregation? Also "secure" ATM/FR cells are multiplexed on > transmission > systems and switches. I don't think aggregation means much more than > multiplexing. > Or would your understanding of aggregation be something like "set up a > container and fill packets belonging to different flows into > container & > forward container instead of individual packets"? > > Regards, Rüdiger > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 10:04:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10824 for ; Mon, 11 Mar 2002 10:04:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22457 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 10:05:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21156; Mon, 11 Mar 2002 09:51:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21125 for ; Mon, 11 Mar 2002 09:51:35 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10131 for ; Mon, 11 Mar 2002 09:51:26 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA10665; Mon, 11 Mar 2002 15:50:51 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: "Geib, Ruediger" Cc: john.loughney@nokia.com, "Geib, Ruediger" , nsis@ietf.org Date: Mon, 11 Mar 2002 15:50:50 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 15:50:51 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA21126 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, There is a general agreement that NSIS should not define services (applications); I fully support this view. However, a QoS signalling protocol should provide the necessary mechanisms to allow applications to define, exchange, negotiate QoS characteristics. This seems to me a fondamental question: if we agree that in the NGN providers will sell services and not only some transport capacity, then the QoS story cannot be considered anymore as only a matter of bearer handling, you need to have a global view including the session layer (e.g. SIP/SDP) and the applications. Next, it should be up to the involved actors to define a common agreement on the service that is to be provided. My feeling is that this is fully inline with the IETF philosophy: define basic mechanisms, and next, allow the actors to build services on top of basic mechanisms. Best regards Juan Carlos "Geib, Ruediger" @ietf.org on 08/03/2002 11:40:03 Sent by: nsis-admin@ietf.org To: john.loughney@nokia.com, "Geib, Ruediger" cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Hi John, I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). The first requirement may be reworded to clarify that NSIS does not define the service (I'm neither a native speaker nor a legal expert, so I'm not sure whether your suggestion does so). NSIS then MAY be the IETF WG to collect, check and administrate the service description coded according to NSIS rules? If you don't know the answer we could have a look on the RTP spec's. Also they support a mechanism offering a signaling framework which may be (and is) filled by later individual specifications. Regards, Rüdiger > > NSIS must support a flexible service definition not > > restricting contents and meaning of individual service > > descriptions. Services may either be private or public. > > Would these requirements be OK? > > NSIS SHOULD support application level service descriptions. > > NSIS MAY consider support for service descriptions developed > by other SDOs. > > This would mean that applications could do the service negotiations, > and pass this info to NSIS. > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > classes. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 10:43:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12023 for ; Mon, 11 Mar 2002 10:43:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24986 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 10:43:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23696; Mon, 11 Mar 2002 10:28:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23662 for ; Mon, 11 Mar 2002 10:28:24 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11472 for ; Mon, 11 Mar 2002 10:28:20 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2BFSAZc007225; Mon, 11 Mar 2002 16:28:10 +0100 (MET) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA04938; Mon, 11 Mar 2002 16:28:10 +0100 From: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Received: by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id QAA26848; Mon, 11 Mar 2002 16:28:09 +0100 (MET) Date: Mon, 11 Mar 2002 16:28:09 +0100 (MET) Message-Id: <200203111528.QAA26848@wrtw014.wrn.ki.sw.ericsson.se> To: Juan-Carlos.Rojas@alcatel.fr Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Cc: nsis@ietf.org X-Sun-Charset: ISO-8859-1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Juan-Carlos, in this respect I fully support one view that was expressed in a previous mail on this list, which formulated a requirement that the [NSIS QoS signaling] architecture must be completely agnostic as to how parties make service agreements. That is, the service advertisement shoud be handled at the application level. There are already mechanisms that allow coordination between the session layer and the bearer (IP) layer, including the notion of pre-conditions in SIP. However, I view it as an important requirement that "the information exchanged over the signaling protocol must be in such detail and quantity that it is useful for various QoS technologies" [draft-brunner-nsis..., Section 5.1]. Of course, this "level of detail and quantity" should support various applications without requiring from application programmers that complex and qualitative parameters should be set. Therefore, we have a challange to define such paramater set(s) at the IP level that help various underlying QoS technologies to provide QoS and are "application programmer friendly". Such sets allow parties to configure their QoS parameters after negotiating a service at the application layer. (This definition work is of course left after the requirements discussion.) /Gabor > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > To: "Geib, Ruediger" > Cc: john.loughney@nokia.com, "Geib, Ruediger" , > nsis@ietf.org > Date: Mon, 11 Mar 2002 15:50:50 +0100 > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at > 03/11/2002 15:50:51 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA21126 > X-Mailman-Version: 1.0 > List-Id: Next Steps in Signaling > X-BeenThere: nsis@ietf.org > > > Hi all, > > There is a general agreement that NSIS should not define services > (applications); I fully support this view. > However, a QoS signalling protocol should provide the necessary mechanisms > to allow applications to define, exchange, negotiate QoS characteristics. > This seems to me a fondamental question: if we agree that in the NGN > providers will sell services and not only some transport capacity, then the > QoS story cannot be considered anymore as only a matter of bearer handling, > you need to have a global view including the session layer (e.g. SIP/SDP) > and the applications. > Next, it should be up to the involved actors to define a common agreement > on the service that is to be provided. > My feeling is that this is fully inline with the IETF philosophy: define > basic mechanisms, and next, allow the actors to build services on top of > basic mechanisms. > > Best regards > Juan Carlos > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > 11:40:03 > > Sent by: nsis-admin@ietf.org > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Hi John, > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). The > first requirement may be reworded to clarify that NSIS does not define the > service (I'm neither a native speaker nor a legal expert, so I'm not sure > whether your suggestion does so). > NSIS then MAY be the IETF WG to collect, check and administrate the service > description coded according to NSIS rules? If you don't know the answer we > could have a look on the RTP spec's. Also they support a mechanism offering > a signaling framework which may be (and is) filled by later individual > specifications. > > Regards, Rüdiger > > > > > NSIS must support a flexible service definition not > > > restricting contents and meaning of individual service > > > descriptions. Services may either be private or public. > > > > Would these requirements be OK? > > > > NSIS SHOULD support application level service descriptions. > > > > NSIS MAY consider support for service descriptions developed > > by other SDOs. > > > > This would mean that applications could do the service negotiations, > > and pass this info to NSIS. > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > classes. > > > > John > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 11:33:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13653 for ; Mon, 11 Mar 2002 11:33:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28336 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 11:34:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27086; Mon, 11 Mar 2002 11:17:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27057 for ; Mon, 11 Mar 2002 11:17:41 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13167 for ; Mon, 11 Mar 2002 11:17:37 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA04410; Mon, 11 Mar 2002 17:17:05 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Cc: nsis@ietf.org Date: Mon, 11 Mar 2002 17:17:03 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 17:17:04 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27058 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gabor, No major problem with this. You are right when saying that "There are already mechanisms that allow coordination between the session layer and the bearer (IP) layer"; however, there is no standardized way to exchange and negotiate QoS information at session level (we are currently proposing SDP extensions for that). I'm not asking to define "how parties make service agreements", but the question I'm raising is more "Is in the context of NSIS to define ways of expressing QoS requirements also at the session level ?". The main purpose is that what will be agreed at the session/application layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for resource reservation complying with the QoS requirements. The most straight-forward will be the translation, the less error-prone will be the implementation. And for sure, at the end, the QoS information should allow a mapping on different QoS technologies. Otherwise, I fully agree with you, we are currently specifying requirements, the definition work will come later. Best regards Juan Carlos Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Juan-Carlos, in this respect I fully support one view that was expressed in a previous mail on this list, which formulated a requirement that the [NSIS QoS signaling] architecture must be completely agnostic as to how parties make service agreements. That is, the service advertisement shoud be handled at the application level. There are already mechanisms that allow coordination between the session layer and the bearer (IP) layer, including the notion of pre-conditions in SIP. However, I view it as an important requirement that "the information exchanged over the signaling protocol must be in such detail and quantity that it is useful for various QoS technologies" [draft-brunner-nsis..., Section 5.1]. Of course, this "level of detail and quantity" should support various applications without requiring from application programmers that complex and qualitative parameters should be set. Therefore, we have a challange to define such paramater set(s) at the IP level that help various underlying QoS technologies to provide QoS and are "application programmer friendly". Such sets allow parties to configure their QoS parameters after negotiating a service at the application layer. (This definition work is of course left after the requirements discussion.) /Gabor > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > To: "Geib, Ruediger" > Cc: john.loughney@nokia.com, "Geib, Ruediger" , > nsis@ietf.org > Date: Mon, 11 Mar 2002 15:50:50 +0100 > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at > 03/11/2002 15:50:51 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA21126 > X-Mailman-Version: 1.0 > List-Id: Next Steps in Signaling > X-BeenThere: nsis@ietf.org > > > Hi all, > > There is a general agreement that NSIS should not define services > (applications); I fully support this view. > However, a QoS signalling protocol should provide the necessary mechanisms > to allow applications to define, exchange, negotiate QoS characteristics. > This seems to me a fondamental question: if we agree that in the NGN > providers will sell services and not only some transport capacity, then the > QoS story cannot be considered anymore as only a matter of bearer handling, > you need to have a global view including the session layer (e.g. SIP/SDP) > and the applications. > Next, it should be up to the involved actors to define a common agreement > on the service that is to be provided. > My feeling is that this is fully inline with the IETF philosophy: define > basic mechanisms, and next, allow the actors to build services on top of > basic mechanisms. > > Best regards > Juan Carlos > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > 11:40:03 > > Sent by: nsis-admin@ietf.org > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Hi John, > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). The > first requirement may be reworded to clarify that NSIS does not define the > service (I'm neither a native speaker nor a legal expert, so I'm not sure > whether your suggestion does so). > NSIS then MAY be the IETF WG to collect, check and administrate the service > description coded according to NSIS rules? If you don't know the answer we > could have a look on the RTP spec's. Also they support a mechanism offering > a signaling framework which may be (and is) filled by later individual > specifications. > > Regards, Rüdiger > > > > > NSIS must support a flexible service definition not > > > restricting contents and meaning of individual service > > > descriptions. Services may either be private or public. > > > > Would these requirements be OK? > > > > NSIS SHOULD support application level service descriptions. > > > > NSIS MAY consider support for service descriptions developed > > by other SDOs. > > > > This would mean that applications could do the service negotiations, > > and pass this info to NSIS. > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > classes. > > > > John > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 12:37:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16838 for ; Mon, 11 Mar 2002 12:37:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03408 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 12:37:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01442; Mon, 11 Mar 2002 12:08:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01412 for ; Mon, 11 Mar 2002 12:08:41 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15397 for ; Mon, 11 Mar 2002 12:08:27 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2BH8OZc008513; Mon, 11 Mar 2002 18:08:24 +0100 (MET) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA07854; Mon, 11 Mar 2002 18:08:24 +0100 From: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Received: by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id SAA28094; Mon, 11 Mar 2002 18:08:23 +0100 (MET) Date: Mon, 11 Mar 2002 18:08:23 +0100 (MET) Message-Id: <200203111708.SAA28094@wrtw014.wrn.ki.sw.ericsson.se> To: Juan-Carlos.Rojas@alcatel.fr Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Cc: nsis@ietf.org X-Sun-Charset: ISO-8859-1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Juan-Carlos, my answer to your question : > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". would be "no", becuase in my understanding this WG focuses on IP level QoS signaling mechanisms. However, I agree with you when you say that : > ... what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most Therefore, it is important that we carefully select the bearer level paramaters ("define the bearer service(s)"), when we reach that discussion. To emphasize this, we could consider to add a requirement (at the level of those in Section 5.1) that NSIS signaling should support a wide range of media streams, or something more elaborated. /Gabor > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > Cc: nsis@ietf.org > Date: Mon, 11 Mar 2002 17:17:03 +0100 > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at > 03/11/2002 17:17:04 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27058 > X-Mailman-Version: 1.0 > List-Id: Next Steps in Signaling > X-BeenThere: nsis@ietf.org > > > Hi Gabor, > > No major problem with this. > You are right when saying that "There are already mechanisms that allow > coordination between the session layer and the bearer (IP) layer"; however, > there is no standardized way to exchange and negotiate QoS information at > session level (we are currently proposing SDP extensions for that). > I'm not asking to define "how parties make service agreements", but the > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". > The main purpose is that what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most > straight-forward will be the translation, the less error-prone will be the > implementation. > And for sure, at the end, the QoS information should allow a mapping on > different QoS technologies. > > Otherwise, I fully agree with you, we are currently specifying > requirements, the definition work will come later. > > Best regards > Juan Carlos > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Juan-Carlos, > > in this respect I fully support one view that was expressed > in a previous mail on this list, which formulated a requirement > that the [NSIS QoS signaling] architecture must be completely > agnostic as to how parties make service agreements. That is, > the service advertisement shoud be handled at the application > level. > > There are already mechanisms that allow coordination between the > session layer and the bearer (IP) layer, including the notion > of pre-conditions in SIP. > > However, I view it as an important requirement that > "the information exchanged over the signaling protocol > must be in such detail and quantity > that it is useful for various QoS technologies" > [draft-brunner-nsis..., Section 5.1]. > > Of course, this "level of detail and quantity" > should support various applications without requiring from > application programmers that complex and qualitative parameters > should be set. Therefore, we have a challange to define such > paramater set(s) at the IP level that help various underlying > QoS technologies to provide QoS and are "application programmer > friendly". Such sets allow parties to configure their QoS parameters > after negotiating a service at the application layer. > (This definition work is of course left after the requirements > discussion.) > > /Gabor > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > To: "Geib, Ruediger" > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > , > > nsis@ietf.org > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > |June 18, 2001) at > > 03/11/2002 15:50:51 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > id JAA21126 > > X-Mailman-Version: 1.0 > > List-Id: Next Steps in Signaling > > X-BeenThere: nsis@ietf.org > > > > > > Hi all, > > > > There is a general agreement that NSIS should not define services > > (applications); I fully support this view. > > However, a QoS signalling protocol should provide the necessary > mechanisms > > to allow applications to define, exchange, negotiate QoS characteristics. > > This seems to me a fondamental question: if we agree that in the NGN > > providers will sell services and not only some transport capacity, then > the > > QoS story cannot be considered anymore as only a matter of bearer > handling, > > you need to have a global view including the session layer (e.g. SIP/SDP) > > and the applications. > > Next, it should be up to the involved actors to define a common agreement > > on the service that is to be provided. > > My feeling is that this is fully inline with the IETF philosophy: define > > basic mechanisms, and next, allow the actors to build services on top of > > basic mechanisms. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > 11:40:03 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Hi John, > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). > The > > first requirement may be reworded to clarify that NSIS does not define > the > > service (I'm neither a native speaker nor a legal expert, so I'm not sure > > whether your suggestion does so). > > NSIS then MAY be the IETF WG to collect, check and administrate the > service > > description coded according to NSIS rules? If you don't know the answer > we > > could have a look on the RTP spec's. Also they support a mechanism > offering > > a signaling framework which may be (and is) filled by later individual > > specifications. > > > > Regards, Rüdiger > > > > > > > > NSIS must support a flexible service definition not > > > > restricting contents and meaning of individual service > > > > descriptions. Services may either be private or public. > > > > > > Would these requirements be OK? > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > NSIS MAY consider support for service descriptions developed > > > by other SDOs. > > > > > > This would mean that applications could do the service negotiations, > > > and pass this info to NSIS. > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > classes. > > > > > > John > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 11 13:46:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18983 for ; Mon, 11 Mar 2002 13:46:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08245 for nsis-archive@odin.ietf.org; Mon, 11 Mar 2002 13:46:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06950; Mon, 11 Mar 2002 13:30:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06906 for ; Mon, 11 Mar 2002 13:30:15 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18525 for ; Mon, 11 Mar 2002 13:30:11 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id g2BIWiG21135; Mon, 11 Mar 2002 12:32:44 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2BITIF03692; Mon, 11 Mar 2002 12:29:18 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 12:29:56 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA22@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Georgios Karagiannis (ELN)'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Mon, 11 Mar 2002 12:29:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, I think the ability to control reservation life-times may be a useful capability. Say for instance that I purchase a video call for one hour duration. NSIS should support the ability of the network to end the associated reservation after one hour. While this does not absolutely necessitate making the reservation lifetime an explicit part of the reservation request semantics, I think it would make sense to do so in support of this situation. Marco > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, March 08, 2002 1:36 PM > To: 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Steve > > The associated motivation given for this requirement > in the NSIS WG draft is that "allows reducing the reservation > update frequency in case of soft state based signaling." (from draft) > > Therefore, I thought that it was related to the soft-state refresh > timer. Do you have another motivation to keep this requirement. > > Best regards, > Georgios > > > -----Original Message----- > From: Steven Berson [mailto:berson@isi.edu] > Sent: vrijdag 8 maart 2002 20:30 > To: Georgios Karagiannis (ELN) > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > Georgios, > > I am not sure if it is a good idea to support reservation life-times, > but at this time, it does not seem like a good idea to preclude it. > Also, the reservation life-time is not necessarily related to the > soft-state refresh timer. > > Steve > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > Hi Marcus > > > > Regarding requirement in Section 5.3.2: > > > > "Ability to signal life-time of a reservation": > > > > The problem that I have with this requirement is that it will > > increase the complexity of the functionality related to the soft > > state (refresh) principle in a node. > > Please note that the soft state refresh principle is used > > to somehow solve unexpected changes in the network, e.g., > route changes > > that are independent of the lifetime of a reservation. > > Therefore, I do not think that the lifetime of the reservation > > should affect the duration of the soft state refresh. > > Please remove it! > > > > Best regards, > > Georgios > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 05:12:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18745 for ; Tue, 12 Mar 2002 05:12:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01781 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 05:12:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01014; Tue, 12 Mar 2002 04:55:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00987 for ; Tue, 12 Mar 2002 04:55:29 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18618 for ; Tue, 12 Mar 2002 04:55:24 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2C9tRB06140 for ; Tue, 12 Mar 2002 10:55:27 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Tue Mar 12 10:54:04 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 10:54:04 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Tue, 12 Mar 2002 10:54:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marco I do not know if I understand your point. You can achieve the same operation by just explicitly releasing the resources after one hour! Only the end host has to know that the resources will be kept for one hour. In this case the network will not have to store for each flow the reservation time. If the network would do that then we will have a very non-scalable solution, i.e., increasing number of users the number of reservation lifetime states are increased. However, I think Steve Berson had a reasonable solution on this: Emphasise in the requirement that advance reservations are not required, but if you wanted advance reservations, then reservation duration seems like a useful thing to have. Best regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: maandag 11 maart 2002 19:30 To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, I think the ability to control reservation life-times may be a useful capability. Say for instance that I purchase a video call for one hour duration. NSIS should support the ability of the network to end the associated reservation after one hour. While this does not absolutely necessitate making the reservation lifetime an explicit part of the reservation request semantics, I think it would make sense to do so in support of this situation. Marco > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, March 08, 2002 1:36 PM > To: 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Steve > > The associated motivation given for this requirement > in the NSIS WG draft is that "allows reducing the reservation > update frequency in case of soft state based signaling." (from draft) > > Therefore, I thought that it was related to the soft-state refresh > timer. Do you have another motivation to keep this requirement. > > Best regards, > Georgios > > > -----Original Message----- > From: Steven Berson [mailto:berson@isi.edu] > Sent: vrijdag 8 maart 2002 20:30 > To: Georgios Karagiannis (ELN) > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > Georgios, > > I am not sure if it is a good idea to support reservation life-times, > but at this time, it does not seem like a good idea to preclude it. > Also, the reservation life-time is not necessarily related to the > soft-state refresh timer. > > Steve > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > Hi Marcus > > > > Regarding requirement in Section 5.3.2: > > > > "Ability to signal life-time of a reservation": > > > > The problem that I have with this requirement is that it will > > increase the complexity of the functionality related to the soft > > state (refresh) principle in a node. > > Please note that the soft state refresh principle is used > > to somehow solve unexpected changes in the network, e.g., > route changes > > that are independent of the lifetime of a reservation. > > Therefore, I do not think that the lifetime of the reservation > > should affect the duration of the soft state refresh. > > Please remove it! > > > > Best regards, > > Georgios > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 06:46:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19517 for ; Tue, 12 Mar 2002 06:46:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05418 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 06:46:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04538; Tue, 12 Mar 2002 06:29:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04505 for ; Tue, 12 Mar 2002 06:29:02 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19323 for ; Tue, 12 Mar 2002 06:28:58 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA21984; Tue, 12 Mar 2002 12:28:53 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA08173; Tue, 12 Mar 2002 12:28:38 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 12:29:06 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A0126567A@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" , Kappler Cornelia Cc: "'john.loughney@nokia.com'" , Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: RE: [NSIS] section on QI/QC and QI/QC terminology Date: Tue, 12 Mar 2002 12:29:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I agree. Cornelia > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Monday, March 11, 2002 9:24 AM > To: Kappler Cornelia > Cc: 'john.loughney@nokia.com'; Georgios.Karagiannis@eln.ericsson.se; nsis@ietf.org > Subject: RE: [NSIS] section on QI/QC and QI/QC terminology > > Cornelia, > > I agree with you that we need to have easy terminology to describe what we > are talking about. There is one thing missing in the QI/QC terminology. As > far as I understand, the QI initiates the QoS *for the NSIS signaling*. So > it is not necessarily the end host even if the end host initiates the > signaling. Therefore, I would propose to call it 'initiating a particular > level of NSIS signaling' > > Do you agree?, > Svenm. > > > > > Kappler Cornelia on 08/03/2002 16:53:22 > > > > To: "'john.loughney@nokia.com'" > , > Georgios.Karagiannis@eln.ericsson.se, > nsis@ietf.org > > cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) > > > > Subject RE: [NSIS] section on QI/QC and QI/QC > : terminology > > > > > > > Hi John and Georgios, > > as probably everybody else I agree we need to settle on some terminology. > The alternative is, in each requirement, to list all possibilities we can > think of. Instead of e.g.: > > "5.3.1. Possibility for automatic release of resources after failure > When the QoS Intitiator goes down, the resources it requested should be > released since they are no longer necessary" > > we put > > "5.3.1... When an end system, an edge router, or a signalling proxy go down > and they have been initiating a reservation, the resources they requested > should be released since..." > > not too elegant, and, more importantly, not sufficiently general. So lets > say > > "5.3.1 ...When an entity that initiated a reservation goes down, the > resources it requested..." > > To make it more legible we replace "entity that initiated a reservation" = > QoS Intitiator > > This provides the additional benefit that in a terminology section we can > more precisely define what a QoS Initiator is (may be the perfectly precise > definition could be left to the framework). Likewise QoS Controller. > > [If you would rather use "ETIAR" (Entity That Intitiated A Reservation) or > whatever fine with me. (sorry for becoming silly)] > > I dont understand yet how this implies a separation / grouping of > requirements. There has been so much going on on this list that I lost this > bit. Georgios, may be you could expand on this problem? > > Regarding whether NSIS is client/server or peer2peer or a mixture, do we > need to fix this in the requirements? > > Cornelia > > > -----Original Message----- > > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > > Sent: Friday, March 08, 2002 12:36 PM > > To: Georgios.Karagiannis@eln.ericsson.se; > sven.van_den_bosch@alcatel.be; nsis@ietf.org > > Subject: RE: [NSIS] section on QI/QC and QI/QC terminology > > > > Hi Georgios, > > > > > I propose to postpone the terminology of QoS Initiator and > > > QoS Controller to framework draft. Meaning that > > > the terms QoS Initiator and QoS Controller will not be used> > > > in the NSIS WG requirements draft. > > > > > > The main reason for this is that, according to John, > > > the NSIS WG requirements draft should not contain any > > > separation/grouping > > > of QoS requirements. This separation will probably be done in the > > > framework draft. There we could also define entities such as > > > QI and QC. > > > > Bigger question to the Working Group. Is NSIS peer-to-peer; > > Client-server; or a mixture. I can see it as a mixture. > > In end-to-edge signaling, it is client-server, however, in > > both end-to-end and edge-to-edge, it is peer-to-peer. > > > > I think the Requirements document should have some terminology > > that describes the parties involved in the signaling ... however, > > I don't think that the WG has decided on what terminology to use. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 08:12:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20954 for ; Tue, 12 Mar 2002 08:12:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA10488 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 08:12:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09349; Tue, 12 Mar 2002 07:59:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09309 for ; Tue, 12 Mar 2002 07:59:12 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20712 for ; Tue, 12 Mar 2002 07:59:08 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA10024; Tue, 12 Mar 2002 13:58:29 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, "'brunner@ccrle.nec.de'" Cc: nsis@ietf.org Date: Tue, 12 Mar 2002 13:58:28 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/12/2002 13:58:28 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA09310 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gabor, OK, if this is a general agreement in the NSIS wg, it is not my intention to go against the world. It would be preferable if this is clearly written in the requirements document: see e.g. section "4.3 Exclusions", the point 2 could be extended in this way. Best regards Juan Carlos Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Hi Juan-Carlos, my answer to your question : > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". would be "no", becuase in my understanding this WG focuses on IP level QoS signaling mechanisms. However, I agree with you when you say that : > ... what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most Therefore, it is important that we carefully select the bearer level paramaters ("define the bearer service(s)"), when we reach that discussion. To emphasize this, we could consider to add a requirement (at the level of those in Section 5.1) that NSIS signaling should support a wide range of media streams, or something more elaborated. /Gabor > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > Cc: nsis@ietf.org > Date: Mon, 11 Mar 2002 17:17:03 +0100 > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at > 03/11/2002 17:17:04 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27058 > X-Mailman-Version: 1.0 > List-Id: Next Steps in Signaling > X-BeenThere: nsis@ietf.org > > > Hi Gabor, > > No major problem with this. > You are right when saying that "There are already mechanisms that allow > coordination between the session layer and the bearer (IP) layer"; however, > there is no standardized way to exchange and negotiate QoS information at > session level (we are currently proposing SDP extensions for that). > I'm not asking to define "how parties make service agreements", but the > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". > The main purpose is that what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most > straight-forward will be the translation, the less error-prone will be the > implementation. > And for sure, at the end, the QoS information should allow a mapping on > different QoS technologies. > > Otherwise, I fully agree with you, we are currently specifying > requirements, the definition work will come later. > > Best regards > Juan Carlos > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Juan-Carlos, > > in this respect I fully support one view that was expressed > in a previous mail on this list, which formulated a requirement > that the [NSIS QoS signaling] architecture must be completely > agnostic as to how parties make service agreements. That is, > the service advertisement shoud be handled at the application > level. > > There are already mechanisms that allow coordination between the > session layer and the bearer (IP) layer, including the notion > of pre-conditions in SIP. > > However, I view it as an important requirement that > "the information exchanged over the signaling protocol > must be in such detail and quantity > that it is useful for various QoS technologies" > [draft-brunner-nsis..., Section 5.1]. > > Of course, this "level of detail and quantity" > should support various applications without requiring from > application programmers that complex and qualitative parameters > should be set. Therefore, we have a challange to define such > paramater set(s) at the IP level that help various underlying > QoS technologies to provide QoS and are "application programmer > friendly". Such sets allow parties to configure their QoS parameters > after negotiating a service at the application layer. > (This definition work is of course left after the requirements > discussion.) > > /Gabor > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > To: "Geib, Ruediger" > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > , > > nsis@ietf.org > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > |June 18, 2001) at > > 03/11/2002 15:50:51 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > id JAA21126 > > X-Mailman-Version: 1.0 > > List-Id: Next Steps in Signaling > > X-BeenThere: nsis@ietf.org > > > > > > Hi all, > > > > There is a general agreement that NSIS should not define services > > (applications); I fully support this view. > > However, a QoS signalling protocol should provide the necessary > mechanisms > > to allow applications to define, exchange, negotiate QoS characteristics. > > This seems to me a fondamental question: if we agree that in the NGN > > providers will sell services and not only some transport capacity, then > the > > QoS story cannot be considered anymore as only a matter of bearer > handling, > > you need to have a global view including the session layer (e.g. SIP/SDP) > > and the applications. > > Next, it should be up to the involved actors to define a common agreement > > on the service that is to be provided. > > My feeling is that this is fully inline with the IETF philosophy: define > > basic mechanisms, and next, allow the actors to build services on top of > > basic mechanisms. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > 11:40:03 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Hi John, > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). > The > > first requirement may be reworded to clarify that NSIS does not define > the > > service (I'm neither a native speaker nor a legal expert, so I'm not sure > > whether your suggestion does so). > > NSIS then MAY be the IETF WG to collect, check and administrate the > service > > description coded according to NSIS rules? If you don't know the answer > we > > could have a look on the RTP spec's. Also they support a mechanism > offering > > a signaling framework which may be (and is) filled by later individual > > specifications. > > > > Regards, Rüdiger > > > > > > > > NSIS must support a flexible service definition not > > > > restricting contents and meaning of individual service > > > > descriptions. Services may either be private or public. > > > > > > Would these requirements be OK? > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > NSIS MAY consider support for service descriptions developed > > > by other SDOs. > > > > > > This would mean that applications could do the service negotiations, > > > and pass this info to NSIS. > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > classes. > > > > > > John > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 08:17:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21040 for ; Tue, 12 Mar 2002 08:17:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA10734 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 08:17:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10117; Tue, 12 Mar 2002 08:04:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10041 for ; Tue, 12 Mar 2002 08:04:06 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20824 for ; Tue, 12 Mar 2002 08:04:04 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA11327; Tue, 12 Mar 2002 14:03:16 +0100 (MET) Subject: RE: [NSIS] Requirement Section 5.3.2 To: "Georgios Karagiannis (ELN)" Cc: "'Schneider, Marco'" , "'Steven Berson'" , "'brunner@ccrle.nec.de'" , nsis@ietf.org Date: Tue, 12 Mar 2002 14:03:13 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/12/2002 14:03:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi all, I agree with Georgis reasoning. If the NSIS protocol is focusing on bearers only, then it should have no knowledge on services like, e.g. "video calls", but only on bearers having some properties (bandwidth, delay, etc.), no matter what those bearers are carrying, no matter for which services they are being used. If you "purchase a video call for one hour duration", then the duration of the *service* is one hour, and that's what you are paying for. Best regards Juan Carlos "Georgios Karagiannis (ELN)" @ietf.org on 12/03/2002 10:54:02 Sent by: nsis-admin@ietf.org To: "'Schneider, Marco'" , "'Steven Berson'" cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Marco I do not know if I understand your point. You can achieve the same operation by just explicitly releasing the resources after one hour! Only the end host has to know that the resources will be kept for one hour. In this case the network will not have to store for each flow the reservation time. If the network would do that then we will have a very non-scalable solution, i.e., increasing number of users the number of reservation lifetime states are increased. However, I think Steve Berson had a reasonable solution on this: Emphasise in the requirement that advance reservations are not required, but if you wanted advance reservations, then reservation duration seems like a useful thing to have. Best regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: maandag 11 maart 2002 19:30 To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, I think the ability to control reservation life-times may be a useful capability. Say for instance that I purchase a video call for one hour duration. NSIS should support the ability of the network to end the associated reservation after one hour. While this does not absolutely necessitate making the reservation lifetime an explicit part of the reservation request semantics, I think it would make sense to do so in support of this situation. Marco > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, March 08, 2002 1:36 PM > To: 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Steve > > The associated motivation given for this requirement > in the NSIS WG draft is that "allows reducing the reservation > update frequency in case of soft state based signaling." (from draft) > > Therefore, I thought that it was related to the soft-state refresh > timer. Do you have another motivation to keep this requirement. > > Best regards, > Georgios > > > -----Original Message----- > From: Steven Berson [mailto:berson@isi.edu] > Sent: vrijdag 8 maart 2002 20:30 > To: Georgios Karagiannis (ELN) > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > Georgios, > > I am not sure if it is a good idea to support reservation life-times, > but at this time, it does not seem like a good idea to preclude it. > Also, the reservation life-time is not necessarily related to the > soft-state refresh timer. > > Steve > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > Hi Marcus > > > > Regarding requirement in Section 5.3.2: > > > > "Ability to signal life-time of a reservation": > > > > The problem that I have with this requirement is that it will > > increase the complexity of the functionality related to the soft > > state (refresh) principle in a node. > > Please note that the soft state refresh principle is used > > to somehow solve unexpected changes in the network, e.g., > route changes > > that are independent of the lifetime of a reservation. > > Therefore, I do not think that the lifetime of the reservation > > should affect the duration of the soft state refresh. > > Please remove it! > > > > Best regards, > > Georgios > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 10:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24826 for ; Tue, 12 Mar 2002 10:39:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19572 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 10:39:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18181; Tue, 12 Mar 2002 10:25:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18152 for ; Tue, 12 Mar 2002 10:25:07 -0500 (EST) Received: from cmail.packetcom.com ([63.108.173.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24341 for ; Tue, 12 Mar 2002 10:25:03 -0500 (EST) Received: from caspiannetworks.com (h-64-105-35-30.SNVACAID.covad.net [64.105.35.30]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABU92411 (AUTH tso@caspiannetworks.com); Tue, 12 Mar 2002 07:24:33 -0800 (PST) Message-ID: <3C8E165F.52ABFE@caspiannetworks.com> Date: Tue, 12 Mar 2002 06:53:19 -0800 From: Tricci So Organization: Caspian Networks X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: tricciso@covad.net, nsis@ietf.org References: Content-Type: multipart/mixed; boundary="------------E7D98D467EFAD4F64AED0DAB" Subject: [NSIS] NSIS Scope Discussion Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------E7D98D467EFAD4F64AED0DAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, Since I can't attend the next NSIS meeting, I thought that it may be a good idea to get your input on my draft regarding the scope of the NSIS work over the mailing list. Also, please forgive me that I haven't been following the mailing list discussion 100% due to the volume of the emails and my work load. I hope that I am not repeating something that have been agreed. Anyway, looking forward to hear your view on this subject. I have also attached my draft to this email. Please check it out.... Tricci --------------E7D98D467EFAD4F64AED0DAB Content-Type: text/plain; charset=us-ascii; name="draft-so-nsis-scope-00.txt" Content-Disposition: inline; filename="draft-so-nsis-scope-00.txt" Content-Transfer-Encoding: 7bit NSIS Working Group Tricci So Internet Draft Caspian Networks Expiration Date: Sept 2002 NSIS Scope Recommendations Draft-so-nsis-scope-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The intent of this draft is to recommend the scope of the work for the NSIS working group so that the team can focus on the key work signaling issues that need to be resolved and to develop the solutions promptly. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. So Expires September 2002 [Page 1] Internet Draft draft-so-nsis-scope-00.txt September 2002 Table Of Contents 1. Motivations....................................................3 2. Modified SIP Network Architecture..............................4 3. Concepts of Bearer Control Signaling vs. Call Control Signaling5 4. Rationales.....................................................5 5. Security Considerations........................................5 6. Recommendation.................................................5 7. IANA Consideration.............................................6 8. References.....................................................6 9. Authors' Addresses.............................................6 So Expires September 2002 [Page 2] Internet Draft draft-so-nsis-scope-00.txt September 2002 1. Motivations As indicated in the current working group charter, the objective of the NSIS work is to develop a simplified solution to signal QoS requirements for variety types of multimedia services over the Internet. At the moment, the discussions so far seem to look into all aspects of the signaling issues that were encountered in the network. In addition, there is no specific network model that can be referred by the NSIS working group to focus on the signaling requirements discussion at different network levels. Hence, this draft brings forward a network model that was derived from the Session Initiation Protocol (SIP) [RFC 2543] network architecture so that the NSIS working group can use it as the base to identify the scope of the working area and to build the consensus on the requirements as well as the solutions. However, it is not the objective of this draft to propose the following network model as the NSIS signaling reference model. The intents of this draft are: - to identify the two main streams of control signaling in a telecommunication network to support multi-media services - i.e. call control signaling and bearer control signaling. - to recommend the focus on the bearer control signaling by the NSIS WG since it is more related to use of the Internet as the transport medium to support the requested QoS transport characteristic, and leave the call control signaling to other consortium to tackle since it is more related to the network services and policy control. So Expires September 2002 [Page 3] Internet Draft draft-so-nsis-scope-00.txt September 2002 2. Modified SIP Network Architecture The following describes the network model that is derived from the SIP network architecture that depicts the separation of the call control signaling from the bearer control signaling to support multi-media services. --------------- ----------------- | Applications| | Applications | | or |<-SIP-> | or | | Services | | Services | --------------- ----------------- ^ ^ ^ | | | | SIP SIP Call | | Control v v Signaling ------------ ------------ | | Media | | Media | | | Gateway | <-SIP-T-> | Gateway | | |Controller| |Controller| | ------------ ------------ | e.g. ^ ^ ^ ^ e.g | SS7 / | e.g. e.g. | \ MGCP | ---------- | MGCP H.248 | --------- | |PSTN or | | | | IAD | | | PLMN | | | --------- | ---------- | | v =============== v ================= v ======================= ---------- ---------- - | Media | ---------- | Media | -\ ---/ | Gateway| <- e.g. -> |Gateway | \-----\ / | | RSVP, RTP, | | | | ---------- Diffserv ---------- | | | | <------- Bear Control ------> | | Signaling | \ / \ / ----------------------------------------------- Private and/or Public IP Network where: Diffserv - Differentiated Services IAD - Integrated Access Devices MGCP - Media Gateway Control Protocol PLMN - Public Land Mobile Network PSTN - Public Switching Trunking Network RSVP - Resource ReSerVation Protocol RTP - Realtime Transport Protocol SIP - Session Initiation Protocol SS7 - Signaling System 7 So Expires September 2002 [Page 4] Internet Draft draft-so-nsis-scope-00.txt September 2002 3. Concepts of Bearer Control Signaling vs. Call Control Signaling The purpose of Bearer Control Signaling is to communicate QoS information to the transport network so that the network can make the necessary arrangements and provide to the requesting application a bearer channel/path with the described transport characteristic. Bearer control signaling does not necessarily traverse the transport network end-to-end uninterrupted, but at certain intermediary nodes is elevated and interpreted. These intermediate nodes need therefore to understand the signaling content and make the necessary actions in response to it. The Call Control signaling could logically be modeled after the manner of an end-to-end application layer protocol specifically tailored for the service at hand. For example, SS7 in PSTN is geared towards providing voice grade services on demand and providing policy control. The span of the call control signaling is likely end-to-end. 4. Rationales Although there is a strong desire from the service providers to consolidate their networks to support multi-media services, their main intent is to converge the transport infrastructure and not the services infrastructure. It is because different types of services require different platforms to manage the services, e.g. SS7 IN services for PSTN, of which those infrastructure takes years to build and to mature. It is extremely economical for the service providers to be able to migrate their multi-media traffic from the multi-services network onto the Internet along with their data traffic. It also opens the opportunity for the service providers to offer new services for the emerging new applications, e.g. wireless applications and DSL etc. Hence, it is important for the NSIS WG to develop a generic bearer control signaling mechanism to identify the certain transport characteristic when establishing the bearer path to carry multimedia traffic. 5. Security Considerations N/A 6. Recommendation The intent of this draft is to recommend the scope that the NSIS WG should focus to design a simplified signaling mechanism to provide QoS support for multimedia services over Internet. So Expires September 2002 [Page 5] Internet Draft draft-so-nsis-scope-00.txt September 2002 It is important for the NSIS WG to focus on the bearer control signaling aspect so that the Internet can be used to provide high quality transport of the multimedia traffic. 7. IANA Consideration N/A 8. References IETF RFC [Sig-Arch] Menelaos K. Perdikeas, Iakovos S. Venieris, "Signaling and Service Integration between Internet and PSTN" [RFC2543] M. Handley, H.Schulzrinne, E. Schooler, J. Rosenberg, "Session Initiation Protocol", RFC 2543, March 1999. 9. Authors' Addresses Tricci So Caspian Networks 170 Baytech Drive San Jose, CA, USA 95134 Email: tso@caspiannetworks.com So Expires September 2002 [Page 6] --------------E7D98D467EFAD4F64AED0DAB-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 10:48:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25183 for ; Tue, 12 Mar 2002 10:48:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19935 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 10:48:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18036; Tue, 12 Mar 2002 10:23:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18009 for ; Tue, 12 Mar 2002 10:23:16 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24302 for ; Tue, 12 Mar 2002 10:23:10 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA12334; Tue, 12 Mar 2002 16:22:55 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA10513; Tue, 12 Mar 2002 16:22:45 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 16:23:10 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A0126567E@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" , nsis@ietf.org Cc: maarten.buchli@alcatel.be, danny.goderis@alcatel.be, Hancock Robert Date: Tue, 12 Mar 2002 16:23:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] RE: section on QI/QC and QI/QC terminology Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven, thank you for your detailed analysis. I agree with you the current definition of QI ("receives trigger from _higher_ layer to start signaling") does run into problems for some scenarios, such as in UMTS, where PDP context signaling (from a _lower_ layer) is being translated into normal IP QoS signaling at the GGSN (possibly via the P-CSCF). Your suggestion points a way for solving this problem (by offering an alternative Def of QI, and also of QC and QR). However I have the following comments (inline). Generally I'd like to modify your definitions somewhat to lift unnecessary restrictions on protocol design and network structure they seem to imply. I am not sure though whether my modifications dont run into other problems :-) > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, March 05, 2002 2:31 PM > To: nsis@ietf.org > Cc: maarten.buchli@alcatel.be; danny.goderis@alcatel.be; robert.hancock@roke.co.uk; cornelia.kappler@icn.siemens.de > Subject: section on QI/QC and QI/QC terminology > > Hi, > > We have been thinking about the QI/QC definitions and we have tried to > arrange the QC/QI functional entities in a logical relation that covers the > use case scenarios that have been proposed so far. From this, we hope to > derive clearer definitions. > > The general logical relationships are depicted below (for simplicity, only > signaling relations are drawn) > > +--+ (a) +--+ (a) +--+ (a) +---+ > +->|QI|---->|QC|---------------->|QC|---->| QR|--+ > QI,QC,QR roles for e2e QoS protocol > | +--+ /+--+\ /+--+\ +---+ | > | / \ / \ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this pictures we clearly distinguish two applications for the NSIS > protocol: > (a) NSIS as end-to-end QoS signaling protocol > (b) NSIS as local QoS signaling protocol > The term "end2end QoS signaling protocol" I dont find entirely fitting, since it seems to imply participation of end hosts. However, a typical scenario we discuss is edge2edge signaling. What about "global QoS signaling protocol"? Would e2e per-flow signaling - tunnelled through most of the network - which might be necessary when no SIP-type e2e exchange of QoS took place, be "local" NSIS signaling? Probably not. However when regarded as "global", what about another signaling on top, signaling for aggregates? This is one of the unnecessary restrictions / assumptions I see with your approach. Your figure seems to imply global NSIS QoS signaling is always triggered by end host signaling. However e.g. signaling for aggregates deep in the backbone might only loosly be coupled to end host signaling. (You may not have intended your figure as covering all possible scenarios) > Local, in this case, is defined as local to a QoS domain. A QoS domain is > defined as a contiguous part of the network supporting the same QoS > technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS > actually competes with other technologies offering local QoS, such as PDP, > RSVP, ... > ok. This maps my view. > The above picture seems to suggest an out-of-band approach but this is not > the case. The QCs can be implemented in a distributed way and redrawing the > picture then gives a different view. > > +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ > |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| > QI,QC,QR roles for e2e QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+> > ^ v ^ v ^ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this case, it is clear that an in-band solution is also supported. The > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a > router. Note that in this picture, the signaling in the access is done with > a local QoS protocol. This can be either an existing protocol, or the NSIS > protocol in its role of local QoS signaling mechanism. This leads to the > following requirements: > > (a) If an NSIS protocol is only used end-to-end, then mobility need not be > supported > This seems to already imply a design choice. Why would the "e2e" / global NSIS protocol not also support mobility? In this case local signaling support is not needed. ...In fact I dont have any particular oppinion on this subject. However in my view some detailed analysis is necessary to decide whether mobility support by a local protocol is always sufficient!? > (b) If an NSIS protocol is used as a local QoS signaling mechanism then > mobility must be supported, both on the QI-QC and QC-QC interface > > (c) If the same protocol is desired in (a) and (b), the protocol should be > modular and the mobility aspects need to be separable from the rest > OK. > Both of the above scenarios assume that the host is not NSIS-aware. This is > a reasonable assumption in a first phase. In a later stage, when hosts are > NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling > technology! This allows this case to be backwards compatible with the above > scenarios. It means that (b) in the access is an NSIS protocol. It also > means that the host will always trigger the local QoS signaling mechanism. > Why would the host never trigger the global NSIS protocol? > This suggests the following definitions for the QI, QC, QR > > - QoS Initiator: Network entity, located at the boundary of a QoS domain, > responsible for initiating a (local or end-to-end) QoS mechanism. If it is > the QI of a local protocol, it can be triggered by higher layers > (applications or end-to-end QoS Controller). If it is the QI of an > end-to-end protocol, it can be triggered by applications or by the QoS > Receiver of a local QoS signaling mechanism. > These triggers make sense to me (although a QC isn't a higher layer, is it?). However what about the following problem with this definition: In an RSVP-like scenario, per-flow signaling is tunnelled through an aggregation area (may be this is how the NSIS protocol is going to work, too). The aggregating router initiating the tunnelling, would it be a QR for the per-flow signaling? Not really, because the signalling is not terminated.So it is a QC. But then the QI initiating the aggregation is triggered by a QC. May be we have to become very broad with the QI Def by saying "network entity initiating NSIS signaling, including an entity initiating one type of NSIS signaling after terminating another type of NSIS signaling.In which case it would also be a QR." Note I restrict QI to NSIS signaling because we dont need to worry about other kinds of signaling except by providing hooks for integrating it. With this Def the GGSN (P-CSCF) classifies as QI as well as an aggregating entity. The "including" sentence I put in to provide for interworking of local and global NSIS signaling e.g. at an NSIS proxy. Another point: I'd rather not restrict the QI to be located on the boundary of a QoS Domain: It may be a bandwidth broker, located anywhere in a domain, it may be a end host (is the end host always located "at the boundary" of a QoS domain?). What if there is a address boundary inside a QoS domain? Would address translation involve re-initiating QoS signaling? Plus there may be a number of reasons for not locating the QI at the boundary. Locating the QI at the boundary or a QoS domain includes too many asumption about the network structure. So my suggestion is dropping this restriction. > - QoS Controller: Network entity responsible for interpreting and > implementing the signalled QoS in the network. Failure to do so implies an > admission control decision. It can only be triggered by a QI or another QC. > > -QoS Receiver: Network entity, located at the boundary of a QoS domain, > responsible for terminating a (local or end-to-end) QoS mechanism. It has > the additional functionality that it may initiate an acknowledgment towards > the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol. > Again I have an issue with "located at the boundary..:". Looking forward to your comments Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 11:06:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25681 for ; Tue, 12 Mar 2002 11:06:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21218 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 11:06:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20636; Tue, 12 Mar 2002 11:00:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20549 for ; Tue, 12 Mar 2002 11:00:06 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25510 for ; Tue, 12 Mar 2002 11:00:00 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2CFxRN05561; Tue, 12 Mar 2002 16:59:27 +0100 (MET) To: Kappler Cornelia Cc: nsis@ietf.org, maarten.buchli@alcatel.be, danny.goderis@alcatel.be, Hancock Robert X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 12 Mar 2002 16:59:20 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/12/2002 16:59:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] RE: section on QI/QC and QI/QC terminology Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cornelia, Thanks for your reply. I have some comments inline. Bye, Sven. Kappler Cornelia on 12/03/2002 16:23:06 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org cc: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Danny GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert Subject RE: section on QI/QC and QI/QC terminology : Hi Sven, thank you for your detailed analysis. I agree with you the current definition of QI ("receives trigger from _higher_ layer to start signaling") does run into problems for some scenarios, such as in UMTS, where PDP context signaling (from a _lower_ layer) is being translated into normal IP QoS signaling at the GGSN (possibly via the P-CSCF). Your suggestion points a way for solving this problem (by offering an alternative Def of QI, and also of QC and QR). However I have the following comments (inline). Generally I'd like to modify your definitions somewhat to lift unnecessary restrictions on protocol design and network structure they seem to imply. I am not sure though whether my modifications dont run into other problems :-) > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, March 05, 2002 2:31 PM > To: nsis@ietf.org > Cc: maarten.buchli@alcatel.be; danny.goderis@alcatel.be; robert.hancock@roke.co.uk; cornelia.kappler@icn.siemens.de > Subject: section on QI/QC and QI/QC terminology > > Hi, > > We have been thinking about the QI/QC definitions and we have tried to > arrange the QC/QI functional entities in a logical relation that covers the > use case scenarios that have been proposed so far. From this, we hope to > derive clearer definitions. > > The general logical relationships are depicted below (for simplicity, only > signaling relations are drawn) > > +--+ (a) +--+ (a) +--+ (a) +---+ > +->|QI|---->|QC|---------------->|QC|---->| QR|--+ > QI,QC,QR roles for e2e QoS protocol > | +--+ /+--+\ /+--+\ +---+ | > | / \ / \ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this pictures we clearly distinguish two applications for the NSIS > protocol: > (a) NSIS as end-to-end QoS signaling protocol > (b) NSIS as local QoS signaling protocol > The term "end2end QoS signaling protocol" I dont find entirely fitting, since it seems to imply participation of end hosts. However, a typical scenario we discuss is edge2edge signaling. What about "global QoS signaling protocol"? Sven>> The picture has two layers of NSIS signaling: - end-to-end NSIS signaling (where the QI and the QR are located at the edge of the network). I don't think it completely maps to your edge-to-edge scenario because that specifically talks about edges of domains. Here it is really the edge of the network from the end-hosts point of view. - NSIS as a local QoS signaling protocol. Note that between the end host and the edge of the network, there is only NSIS signaling at this level. This means that NSIS end-to-end does not require participation of the end host. Even if the end host is an NSIS speaker, it will use NSIS as a local QoS signaling protocol to get to the (top-level) QI where mapping will take place and end-to-end signaling is initiated. Would e2e per-flow signaling - tunnelled through most of the network - which might be necessary when no SIP-type e2e exchange of QoS took place, be "local" NSIS signaling? Probably not. However when regarded as "global", what about another signaling on top, signaling for aggregates? This is one of the unnecessary restrictions / assumptions I see with your approach. Sven>> Setting up the aggregates is a local matter for each of the QCs. A QC may choose to modify its aggregate based on incoming micro-flows but this process will not be triggered by microflow arrivals. Your figure seems to imply global NSIS QoS signaling is always triggered by end host signaling. However e.g. signaling for aggregates deep in the backbone might only loosly be coupled to end host signaling. (You may not have intended your figure as covering all possible scenarios) Sven>> Signaling for aggregates in the backbone is not triggered by the NSIS end-to-end signaling. In fact, for this a local QoS technology is used under the authority of the QC (via network management). This local technology may exist or it may be another application of the local NSIS signaling. > Local, in this case, is defined as local to a QoS domain. A QoS domain is > defined as a contiguous part of the network supporting the same QoS > technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS > actually competes with other technologies offering local QoS, such as PDP, > RSVP, ... > ok. This maps my view. > The above picture seems to suggest an out-of-band approach but this is not > the case. The QCs can be implemented in a distributed way and redrawing the > picture then gives a different view. > > +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ > |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| > QI,QC,QR roles for e2e QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+> > ^ v ^ v ^ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this case, it is clear that an in-band solution is also supported. The > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a > router. Note that in this picture, the signaling in the access is done with > a local QoS protocol. This can be either an existing protocol, or the NSIS > protocol in its role of local QoS signaling mechanism. This leads to the > following requirements: > > (a) If an NSIS protocol is only used end-to-end, then mobility need not be > supported > This seems to already imply a design choice. Why would the "e2e" / global NSIS protocol not also support mobility? In this case local signaling support is not needed. ...In fact I dont have any particular oppinion on this subject. However in my view some detailed analysis is necessary to decide whether mobility support by a local protocol is always sufficient!? Sven>> I think mobility definitely needs to be supported in the local protocol. When the (top-level) QI is a fixed point (joint point of reservation) then the end-to-end (or top-level) signaling does not need to support mobility. This relaxes some of the requirements which is a good thing. I think that without loss of generality we can have this situation. The only design impact this may have is when we want to use the same protocol for local and global NSIS signaling. In this case we need to make it modular so that a global QC only has to look at the information relevant to him. This requirement was already identified. > (b) If an NSIS protocol is used as a local QoS signaling mechanism then > mobility must be supported, both on the QI-QC and QC-QC interface > > (c) If the same protocol is desired in (a) and (b), the protocol should be > modular and the mobility aspects need to be separable from the rest > OK. > Both of the above scenarios assume that the host is not NSIS-aware. This is > a reasonable assumption in a first phase. In a later stage, when hosts are > NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling > technology! This allows this case to be backwards compatible with the above > scenarios. It means that (b) in the access is an NSIS protocol. It also > means that the host will always trigger the local QoS signaling mechanism. > Why would the host never trigger the global NSIS protocol? Sven>> It doesn't need to. When he is an NSIS speaker he can initiate the local NSIS protocol. At the global QI his requirement will then be mapped into the e2e NSIS protocol. If he didn't have any requirements that can't be offered be the global NSIS protocol he could theoretically initiate e2e signaling. I don't think it is needed however. > This suggests the following definitions for the QI, QC, QR > > - QoS Initiator: Network entity, located at the boundary of a QoS domain, > responsible for initiating a (local or end-to-end) QoS mechanism. If it is > the QI of a local protocol, it can be triggered by higher layers > (applications or end-to-end QoS Controller). If it is the QI of an > end-to-end protocol, it can be triggered by applications or by the QoS > Receiver of a local QoS signaling mechanism. > These triggers make sense to me (although a QC isn't a higher layer, is it?). However what about the following problem with this definition: In an RSVP-like scenario, per-flow signaling is tunnelled through an aggregation area (may be this is how the NSIS protocol is going to work, too). The aggregating router initiating the tunnelling, would it be a QR for the per-flow signaling? Not really, because the signalling is not terminated.So it is a QC. But then the QI initiating the aggregation is triggered by a QC. Sven>> In the definition, I mentioned application or end-to-end/global QC as possible triggers. So maybe we should say that a QC on the client NSIS layer (global) can trigger a QI on the server NSIS layer (local). Would this solve the issue in you opinion? May be we have to become very broad with the QI Def by saying "network entity initiating NSIS signaling, including an entity initiating one type of NSIS signaling after terminating another type of NSIS signaling.In which case it would also be a QR." Note I restrict QI to NSIS signaling because we dont need to worry about other kinds of signaling except by providing hooks for integrating it. With this Def the GGSN (P-CSCF) classifies as QI as well as an aggregating entity. The "including" sentence I put in to provide for interworking of local and global NSIS signaling e.g. at an NSIS proxy. Sven>> I fully agree: QI/QC only have a meaning in NSIS signaling. Another point: I'd rather not restrict the QI to be located on the boundary of a QoS Domain: It may be a bandwidth broker, located anywhere in a domain, it may be a end host (is the end host always located "at the boundary" of a QoS domain?). What if there is a address boundary inside a QoS domain? Would address translation involve re-initiating QoS signaling? Plus there may be a number of reasons for not locating the QI at the boundary. Locating the QI at the boundary or a QoS domain includes too many asumption about the network structure. So my suggestion is dropping this restriction. Sven>> OK. Maybe we should say: located at the boundary of an NSIS signaling domain. > - QoS Controller: Network entity responsible for interpreting and > implementing the signalled QoS in the network. Failure to do so implies an > admission control decision. It can only be triggered by a QI or another QC. > > -QoS Receiver: Network entity, located at the boundary of a QoS domain, > responsible for terminating a (local or end-to-end) QoS mechanism. It has > the additional functionality that it may initiate an acknowledgment towards > the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol. > Again I have an issue with "located at the boundary..:". Looking forward to your comments Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 11:10:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25811 for ; Tue, 12 Mar 2002 11:10:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21502 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 11:10:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20165; Tue, 12 Mar 2002 10:55:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20136 for ; Tue, 12 Mar 2002 10:55:03 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25382 for ; Tue, 12 Mar 2002 10:54:59 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CFtDZ24421 for ; Tue, 12 Mar 2002 17:55:13 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Mar 2002 17:55:01 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 17:55:01 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 09:54:45 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9DE.3A96CAD6" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 12 Mar 2002 10:54:44 -0500 Message-ID: Thread-Topic: An NSIS requirement with backing scenario Thread-Index: AcHJ3jpp4i1qtkbjS4OlfK/8c85b+Q== To: X-OriginalArrivalTime: 12 Mar 2002 15:54:45.0401 (UTC) FILETIME=[3B118090:01C1C9DE] Subject: [NSIS] An NSIS requirement with backing scenario Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1C9DE.3A96CAD6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 I would like to place the following requirement on table for discussion = in WG. I have also provided a scenario below that motivates such = explicit requirement. I would like to know if WG deems this as an = important issue. =20 "QoS signaling protocol MUST interwork with AAA for QoS authorization = and accounting purposes". =20 Scenario: ----------- =20 A and B are connected to the Internet on the two sides of the globe. A = places call to B, and (say during SIP transactions) intimates to B that = A will pay for the call. Paying for the call also means paying for QoS = of the corresponding packet transport. B accepts A's proposal. The call = happens to be of bidirectional traffic type.=20 =20 A sends signal to its access network N_A asking it to give certain QoS = to packet stream from A -> B. A is a subscribed customer of N_A, so = there are no apparent difficulties for N_A in checking A's credentials = and in billing A. Also, network N_A may then take appropriate means to = guarantee end-to-end QoS, may be based on SLAs with other providers and = may be using some NSIS signaling. =20 For the packet path from B -> A, A does not know apriori as to how the = path looks like. So, the QoS establishment for this path needs to be = initiated from B's side. Now, B is not paying for QoS in its own access = network N_B. Since, A has agreed to pay, A needs to provide some = credentials to B which would be acceptable to N_B. There are two = problems encountered here: i) Though A has agreed to pay, A may not be = willing to provide credentials to end host B for security reasons, ii) = If A and N_B are in different jurisdiction, whatever credentials A has = to provide may not satisfy N_B. Note that N_B cannot bill A directly. =20 The following things need to happen to make this call through.=20 =20 (i) SIP has to convey "intent" of A to pay for the call to B. A may also = expect in return the B's cost of access at N_B. (This part has to be = addressed by SIP and SDPng). =20 (ii) NSIS signaling needs to interwork with AAA so that it can reserve = and bill for QoS resources in N_B. This is the requirement that needs to = be included in NSIS requirements document. =20 BR, Hemant ------_=_NextPart_001_01C1C9DE.3A96CAD6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi:
 
I = would like to=20 place the following requirement on table for discussion in WG. I have = also=20 provided a scenario below that motivates such=20 explicit requirement. I would like to know if WG deems this as an important=20 issue.
 
"QoS signaling protocol MUST = interwork with=20 AAA for QoS authorization and accounting = purposes".
 
Scenario:
-----------
 
A and = B are=20 connected to the Internet on the two sides of the globe. A places call = to B, and=20 (say during SIP transactions) intimates to B that A will pay for the = call.=20 Paying for the call also means paying for QoS of the corresponding = packet=20 transport. B accepts A's proposal. The call happens to be = of bidirectional=20 traffic type. 
 
A = sends signal to=20 its access network N_A asking it to give certain QoS to packet = stream from=20 A -> B. A is a subscribed customer of N_A, so there are no apparent=20 difficulties for N_A in checking A's credentials and in billing A. = Also,=20 network N_A may then take appropriate means to guarantee end-to-end = QoS,=20 may be based on SLAs with other providers and may be using some NSIS=20 signaling.
 
For = the packet path=20 from B -> A, A does not know apriori as to how the path looks like. = So, the=20 QoS establishment for this path needs to be initiated from B's side. = Now, B is=20 not paying for QoS in its own access network N_B. Since, A has agreed to = pay, A=20 needs to provide some credentials to B which would be acceptable to N_B. = There=20 are two problems encountered here: i) Though A has agreed to pay, A may = not be=20 willing to provide credentials to end host B for security reasons, ii) = If A and=20 N_B are in different jurisdiction, whatever credentials A has to provide = may not=20 satisfy N_B. Note that N_B cannot bill A directly.
 
The following things need to happen to = make this=20 call through.
 
(i) SIP has to convey "intent" of A = to pay for the=20 call to B. A may also expect in return the B's cost of access at N_B. = (This part=20 has to be addressed by SIP and SDPng).
 
(ii)  NSIS signaling needs to interwork = with AAA=20 so that it can reserve and bill for QoS resources in N_B. This is the=20 requirement that needs to be included in NSIS requirements=20 document.
 
BR,
Hemant
= ------_=_NextPart_001_01C1C9DE.3A96CAD6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 16:17:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07988 for ; Tue, 12 Mar 2002 16:17:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13114 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 16:17:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12877; Tue, 12 Mar 2002 16:12:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12845 for ; Tue, 12 Mar 2002 16:12:55 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07673 for ; Tue, 12 Mar 2002 16:12:52 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2CLFRN05655; Tue, 12 Mar 2002 15:15:27 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2CLCDW00539; Tue, 12 Mar 2002 15:12:13 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 15:12:51 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA27@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Georgios Karagiannis (ELN)'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Tue, 12 Mar 2002 15:12:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, The point of the example is that the network may want to limit the duration that it grants for a session and thus its corresponding resources (such as a QOS connection). So in this case the network needs to be able to revoke resources upon the expiration of some time period. In thinking about this example I was wondering whether it would be useful to make duration an explicit part of the reservation semantics. 1) A host requests from network a service of one hour duration. For example a video call to a friend. 2) Above is realized via session negotiation that results in token that is passed back to the host. The token permits a QOS connection of one hour duration at 5 Mbps 3) The host (QOS Initiator) includes the token in the NSIS setup message requesting a 5Mbps connection. 4) The QOS Controller uses the token to validate the reservation and allows the setup to go through. (See draft-ietf-sip-call-auth-0?.txt as well as draft-ietf-rap-session-auth-0?.txt) Now what happens when one hour is up? Ideally the host releases the resources but if the host does not the network will (otherwise the user gets more than they paid for). When the network releases the resources there should be a cause code that says your time was up or at the very least indicates that this was due to service policy. Now my question is: given that the reservation is intended to be of a precise duration should we make this explicit or is it better for this to be transparent? Is so why? Regarding Scalability, I do not understand your claim that this is very non-scalable. For every flow reservation the network presumably will need to store the amount reserved (at least one piece of information). A reservation duration requires one additional piece of information (at the edge) that does not propagate across the network. Best Regards, Marco > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Tuesday, March 12, 2002 3:54 AM > To: Schneider, Marco; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Marco > > I do not know if I understand your point. > You can achieve the same operation by just explicitly > releasing the resources after one hour! > Only the end host has to know that the resources > will be kept for one hour. > > In this case the network will not have to store for each flow > the reservation time. If the network would do that > then we will have a very non-scalable solution, i.e., > increasing number of users the number of reservation > lifetime states are increased. > > However, I think Steve Berson had a reasonable solution on this: > Emphasise in the requirement that advance reservations are not > required, but if you wanted advance reservations, then > reservation duration seems like a useful thing to have. > > Best regards, > Georgios > > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: maandag 11 maart 2002 19:30 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > I think the ability to control reservation life-times may be a useful > capability. Say for instance that I purchase a video call for one hour > duration. NSIS should support the ability of the network to end the > associated reservation after one hour. While this does not absolutely > necessitate making the reservation lifetime an explicit part of the > reservation request semantics, I think it would make sense to do so in > support of this situation. > > Marco > > > > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Friday, March 08, 2002 1:36 PM > > To: 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Steve > > > > The associated motivation given for this requirement > > in the NSIS WG draft is that "allows reducing the reservation > > update frequency in case of soft state based signaling." > (from draft) > > > > Therefore, I thought that it was related to the soft-state refresh > > timer. Do you have another motivation to keep this requirement. > > > > Best regards, > > Georgios > > > > > > -----Original Message----- > > From: Steven Berson [mailto:berson@isi.edu] > > Sent: vrijdag 8 maart 2002 20:30 > > To: Georgios Karagiannis (ELN) > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > > > > Georgios, > > > > I am not sure if it is a good idea to support reservation > life-times, > > but at this time, it does not seem like a good idea to > preclude it. > > Also, the reservation life-time is not necessarily related to the > > soft-state refresh timer. > > > > Steve > > > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > > > Hi Marcus > > > > > > Regarding requirement in Section 5.3.2: > > > > > > "Ability to signal life-time of a reservation": > > > > > > The problem that I have with this requirement is that it will > > > increase the complexity of the functionality related to the soft > > > state (refresh) principle in a node. > > > Please note that the soft state refresh principle is used > > > to somehow solve unexpected changes in the network, e.g., > > route changes > > > that are independent of the lifetime of a reservation. > > > Therefore, I do not think that the lifetime of the reservation > > > should affect the duration of the soft state refresh. > > > Please remove it! > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 12 16:39:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08841 for ; Tue, 12 Mar 2002 16:39:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14829 for nsis-archive@odin.ietf.org; Tue, 12 Mar 2002 16:39:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13425; Tue, 12 Mar 2002 16:22:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13393 for ; Tue, 12 Mar 2002 16:22:47 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08206 for ; Tue, 12 Mar 2002 16:22:43 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2CLPJN05743; Tue, 12 Mar 2002 15:25:19 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2CLM7C00960; Tue, 12 Mar 2002 15:22:07 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 15:22:45 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA28@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Juan-Carlos.Rojas@alcatel.fr'" , "Georgios Karagiannis (ELN)" Cc: "'Steven Berson'" , "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Tue, 12 Mar 2002 15:22:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Juan Carlos, Please see my reply to Georgios. I agree with what you wrote below, so perhaps my post was not interpreted as intended. (see one comment below as well). Marco > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr > [mailto:Juan-Carlos.Rojas@alcatel.fr] > Sent: Tuesday, March 12, 2002 7:03 AM > To: Georgios Karagiannis (ELN) > Cc: Schneider, Marco; 'Steven Berson'; 'brunner@ccrle.nec.de'; > nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > Hi all, > > I agree with Georgis reasoning. > If the NSIS protocol is focusing on bearers only, then it > should have no > knowledge on services like, e.g. "video calls", but only on > bearers having > some properties (bandwidth, delay, etc.), no matter what > those bearers are > carrying, no matter for which services they are being used. > If you "purchase a video call for one hour duration", then > the duration of > the *service* is one hour, and that's what you are paying for. The issue is what are the mechanisms to enforce that the corresponding resources last for one hour and how do the host, session controllers, and qos controllers participate in this. > Best regards > > Juan Carlos > > > > > > "Georgios Karagiannis (ELN)" > @ietf.org on 12/03/2002 10:54:02 > > Sent by: nsis-admin@ietf.org > > > To: "'Schneider, Marco'" , "'Steven Berson'" > > cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Marco > > I do not know if I understand your point. > You can achieve the same operation by just explicitly > releasing the resources after one hour! > Only the end host has to know that the resources > will be kept for one hour. > > In this case the network will not have to store for each flow > the reservation time. If the network would do that > then we will have a very non-scalable solution, i.e., > increasing number of users the number of reservation > lifetime states are increased. > > However, I think Steve Berson had a reasonable solution on this: > Emphasise in the requirement that advance reservations are not > required, but if you wanted advance reservations, then > reservation duration seems like a useful thing to have. > > Best regards, > Georgios > > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: maandag 11 maart 2002 19:30 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > I think the ability to control reservation life-times may be a useful > capability. Say for instance that I purchase a video call for one hour > duration. NSIS should support the ability of the network to end the > associated reservation after one hour. While this does not absolutely > necessitate making the reservation lifetime an explicit part of the > reservation request semantics, I think it would make sense to do so in > support of this situation. > > Marco > > > > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Friday, March 08, 2002 1:36 PM > > To: 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Steve > > > > The associated motivation given for this requirement > > in the NSIS WG draft is that "allows reducing the reservation > > update frequency in case of soft state based signaling." > (from draft) > > > > Therefore, I thought that it was related to the soft-state refresh > > timer. Do you have another motivation to keep this requirement. > > > > Best regards, > > Georgios > > > > > > -----Original Message----- > > From: Steven Berson [mailto:berson@isi.edu] > > Sent: vrijdag 8 maart 2002 20:30 > > To: Georgios Karagiannis (ELN) > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > > > > Georgios, > > > > I am not sure if it is a good idea to support reservation > life-times, > > but at this time, it does not seem like a good idea to preclude it. > > Also, the reservation life-time is not necessarily related to the > > soft-state refresh timer. > > > > Steve > > > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > > > Hi Marcus > > > > > > Regarding requirement in Section 5.3.2: > > > > > > "Ability to signal life-time of a reservation": > > > > > > The problem that I have with this requirement is that it will > > > increase the complexity of the functionality related to the soft > > > state (refresh) principle in a node. > > > Please note that the soft state refresh principle is used > > > to somehow solve unexpected changes in the network, e.g., > > route changes > > > that are independent of the lifetime of a reservation. > > > Therefore, I do not think that the lifetime of the reservation > > > should affect the duration of the soft state refresh. > > > Please remove it! > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Mar 13 05:10:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01710 for ; Wed, 13 Mar 2002 05:10:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05238 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 05:10:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04083; Wed, 13 Mar 2002 04:53:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04055 for ; Wed, 13 Mar 2002 04:53:39 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01547 for ; Wed, 13 Mar 2002 04:53:35 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g2D9rad28762; Wed, 13 Mar 2002 10:53:37 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g2D9rag20459; Wed, 13 Mar 2002 10:53:36 +0100 (MET) From: "Hannes Tschofenig" To: , Subject: RE: [NSIS] An NSIS requirement with backing scenario Date: Wed, 13 Mar 2002 10:56:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08BE_01C1CA7D.B62511D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_08BE_01C1CA7D.B62511D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi hemant! > Hi: > I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that > motivates such explicit requirement. I would like to know if WG deems this as an important issue. > "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". i like this requirement. it think that it is a good idea to have this requirement. but: i think it is already covered with: 5.8.2 The QoS protocol must provide means to authorize resource requests 5.10.5 The QoS protocol should provide hooks for AAA protocols appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging as indicated below. there have been a number of papers describing different solutions but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference next week. to your scenario below: just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for the reservation. if A is not willing to provide credentials then there is obvioulsy a problem but a could provide credentials without concerns about security. it only depends how these "credentials" look like. from my point of view this information should be exchanged before the actual qos reservation takes place since it is an application issue. hence the information should already be available at the qos-reservation start-up. > ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. > Note that N_B cannot bill A directly. there has to be some agreement between providers otherwise this exchange will not work. > (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. > (This part has to be addressed by SIP and SDPng). i agree with you. > (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. > This is the requirement that needs to be included in NSIS requirements document. this is true. first, the qos signaling messages must be authenticated, integrity and replay protected. second, the qos protocol should be able to transport information exchanged with protocols executed before the qos protocol is triggered. ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com Sent: Tuesday, March 12, 2002 4:55 PM To: nsis@ietf.org Subject: [NSIS] An NSIS requirement with backing scenario Hi: I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue. "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". Scenario: ----------- A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling. For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly. The following things need to happen to make this call through. (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng). (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document. BR, Hemant ------=_NextPart_000_08BE_01C1CA7D.B62511D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi hemant!

> Hi:

> I would like to = place the=20 following requirement on table for discussion in WG. I have also = provided a=20 scenario below that

> motivates such = explicit=20 requirement. I would like to know if WG deems this as an important=20 issue.

> "QoS signaling = protocol MUST=20 interwork with AAA for QoS authorization and accounting = purposes".

i like this requirement. = it think that=20 it is a good idea to have this requirement.

but: i think it is = already covered=20 with:

5.8.2 The QoS protocol = must provide=20 means to authorize resource requests

5.10.5 The QoS protocol = should provide=20 hooks for AAA protocols

appart from the = requirements for an=20 interaction with AAA there are still open issues regarding=20 billing/payment/charging

as indicated below. there = have been a=20 number of papers describing = different=20 solutions

but i do not know a = satisfiable one. maybe we can discuss some of the = issues at=20 the ietf conference

next week.

to your scenario below: =

just to make sure: the main problem = seems to be=20 that user B has to give "something" to network N_B telling that user A = is paying=20 for

the reservation. =

 

if A is not willing to = provide=20 credentials then there is obvioulsy a problem but

a could provide = credentials without=20 concerns about security. it only depends how these "credentials" look = like.=20

from my point of view = this information=20 should be exchanged before the actual qos reservation takes place since = it=20

is an application issue. = hence the=20 information should already be available at the qos-reservation start-up. =

> ii) If A and N_B are = in different=20 jurisdiction, whatever credentials A has to provide may not satisfy N_B. =

> Note that N_B cannot = bill A=20 directly.

there has to be some = agreement between=20 providers otherwise this exchange will not work.

 

> (i) SIP has to = convey "intent" of=20 A to pay for the call to B. A may also expect in return the B's cost of = access=20 at N_B.

> (This part has to be = addressed by=20 SIP and SDPng).

i agree with you. =

> (ii) NSIS signaling = needs to=20 interwork with AAA so that it can reserve and bill for QoS resources in = N_B.=20

> This is the = requirement that needs=20 to be included in NSIS requirements document.

this is true. =

first, the qos signaling = messages must=20 be authenticated, integrity and replay protected.

second, the qos protocol = should be able=20 to transport information exchanged with protocols executed before the=20

qos protocol is = triggered.

ciao

hannes

-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of=20 Hemant.Chaskar@nokia.com
Sent: Tuesday, March 12, 2002 = 4:55=20 PM
To: nsis@ietf.org
Subject: [NSIS] An NSIS = requirement=20 with backing scenario

Hi:
 
I = would like to=20 place the following requirement on table for discussion in WG. I have = also=20 provided a scenario below that motivates such=20 explicit requirement. I would like to know if WG deems this as an important=20 issue.
 
"QoS signaling protocol MUST = interwork=20 with AAA for QoS authorization and accounting=20 purposes".
 
Scenario:
-----------
 
A = and B are=20 connected to the Internet on the two sides of the globe. A places call = to B,=20 and (say during SIP transactions) intimates to B that A will pay for = the call.=20 Paying for the call also means paying for QoS of the corresponding = packet=20 transport. B accepts A's proposal. The call happens to be=20 of bidirectional traffic type. 
 
A = sends signal to=20 its access network N_A asking it to give certain QoS to packet = stream=20 from A -> B. A is a subscribed customer of N_A, so there are no = apparent=20 difficulties for N_A in checking A's credentials and in billing = A. Also,=20 network N_A may then take appropriate means to guarantee = end-to-end QoS,=20 may be based on SLAs with other providers and may be using some NSIS=20 signaling.
 
For = the packet=20 path from B -> A, A does not know apriori as to how the path looks = like.=20 So, the QoS establishment for this path needs to be initiated from B's = side.=20 Now, B is not paying for QoS in its own access network N_B. Since, A = has=20 agreed to pay, A needs to provide some credentials to B which would be = acceptable to N_B. There are two problems encountered here: i) Though = A has=20 agreed to pay, A may not be willing to provide credentials to end host = B for=20 security reasons, ii) If A and N_B are in different jurisdiction, = whatever=20 credentials A has to provide may not satisfy N_B. Note that N_B cannot = bill A=20 directly.
 
The following things need to happen to = make this=20 call through.
 
(i) SIP has to convey "intent" of A = to pay for=20 the call to B. A may also expect in return the B's cost of access at = N_B.=20 (This part has to be addressed by SIP and = SDPng).
 
(ii)  NSIS signaling needs to = interwork with AAA=20 so that it can reserve and bill for QoS resources in N_B. This is the=20 requirement that needs to be included in NSIS requirements=20 document.
 
BR,
Hemant
------=_NextPart_000_08BE_01C1CA7D.B62511D0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 13 05:17:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01762 for ; Wed, 13 Mar 2002 05:17:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05405 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 05:17:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05033; Wed, 13 Mar 2002 05:03:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04955 for ; Wed, 13 Mar 2002 05:03:44 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01638 for ; Wed, 13 Mar 2002 05:03:40 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g2DA3eR11857; Wed, 13 Mar 2002 11:03:41 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g2DA3eg27449; Wed, 13 Mar 2002 11:03:40 +0100 (MET) From: "Hannes Tschofenig" To: "Georgios Karagiannis \(ELN\)" , "'Hancock, Robert'" , Cc: Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Wed, 13 Mar 2002 11:06:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit hi > > Hi Hannes > > What about saying something like: > The initiator of the NSIS protocol can require > the support of the hop-by-hop security feature. because of the chain-of-trust assumption it is not possible for the initiator to require that all providers provide some sort of protection. every node can only decide whether it has to include a security protection or not. if the receiver requires the protection and no such protection is present then the request is not processed and an error message is returned. > However, an administrator of a QoS domain is able to > deactivate this feature, when the NSIS protocol > is used within its administrative QoS domain. true. an administrator of a qos domain may decide to require authenticated qos signaling messages at the borders and not within the nodes of the core network. how about this (modified) requirement? 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. Hop-by-hop security enables authentication, integrity, possibly confidentiality and replay protection of QoS signaling messages exchanged between two QoS aware network elements. The chain-of-trust principle then allows non-neighboring nodes to trust each other based on the existing trust of neighboring nodes. If, however, a network element along the path is not participating in the QoS signaling i.e. a QoS unaware or ignorant node (e.g. because the QoS signaling message are transmitted over a non-QoS signaling aware cloud) then neither QoS nor QoS protocol specific security mechanisms are executed by this node. Furthermore a network provider may also decide (independently of other involved parties) not to use hop-by-hop protection of the signaling messages between every QoS aware node within his own administrative domain (e.g. because other security mechanisms are in place or because of a strong trust assumption). In this case the hop-by-hop security is relaxed and hop-by-hop security is only used between QoS aware nodes which are also QoS security aware. Hop-by-hop security allows intermediate nodes that actively participate in the QoS protocol to modify the messages as required by the QoS processing. Note that this requirement does not exclude end-to-end or network-to-network security of a QoS reservation request. End-to- end security between the initiator and the responder may be used to provide protection of non-mutable data fields. Network-to-network security refers to the protection of messages over various hops but not in an end-to-end manner i.e. protected over a particular network. ciao hannes > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 13 05:59:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02174 for ; Wed, 13 Mar 2002 05:59:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07442 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 05:59:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06757; Wed, 13 Mar 2002 05:46:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06733 for ; Wed, 13 Mar 2002 05:46:27 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02002 for ; Wed, 13 Mar 2002 05:46:19 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2DAkLZc009866 for ; Wed, 13 Mar 2002 11:46:21 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Wed Mar 13 11:46:20 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 11:46:20 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Hannes Tschofenig'" , "'Hancock, Robert'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Wed, 13 Mar 2002 11:46:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Hannes What I mean is the following. If some QoS domain will use aggregated reservation states and if the lifetime requirement has to be supported by the domain, then new per flow reservation lifetime states have to be created in this domain. Best Regards, Georgios -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: woensdag 13 maart 2002 11:06 To: Georgios Karagiannis (ELN); 'Hancock, Robert'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) hi > > Hi Hannes > > What about saying something like: > The initiator of the NSIS protocol can require > the support of the hop-by-hop security feature. because of the chain-of-trust assumption it is not possible for the initiator to require that all providers provide some sort of protection. every node can only decide whether it has to include a security protection or not. if the receiver requires the protection and no such protection is present then the request is not processed and an error message is returned. > However, an administrator of a QoS domain is able to > deactivate this feature, when the NSIS protocol > is used within its administrative QoS domain. true. an administrator of a qos domain may decide to require authenticated qos signaling messages at the borders and not within the nodes of the core network. how about this (modified) requirement? 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. Hop-by-hop security enables authentication, integrity, possibly confidentiality and replay protection of QoS signaling messages exchanged between two QoS aware network elements. The chain-of-trust principle then allows non-neighboring nodes to trust each other based on the existing trust of neighboring nodes. If, however, a network element along the path is not participating in the QoS signaling i.e. a QoS unaware or ignorant node (e.g. because the QoS signaling message are transmitted over a non-QoS signaling aware cloud) then neither QoS nor QoS protocol specific security mechanisms are executed by this node. Furthermore a network provider may also decide (independently of other involved parties) not to use hop-by-hop protection of the signaling messages between every QoS aware node within his own administrative domain (e.g. because other security mechanisms are in place or because of a strong trust assumption). In this case the hop-by-hop security is relaxed and hop-by-hop security is only used between QoS aware nodes which are also QoS security aware. Hop-by-hop security allows intermediate nodes that actively participate in the QoS protocol to modify the messages as required by the QoS processing. Note that this requirement does not exclude end-to-end or network-to-network security of a QoS reservation request. End-to- end security between the initiator and the responder may be used to provide protection of non-mutable data fields. Network-to-network security refers to the protection of messages over various hops but not in an end-to-end manner i.e. protected over a particular network. ciao hannes > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 13 07:16:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02996 for ; Wed, 13 Mar 2002 07:16:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA10804 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 07:16:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10453; Wed, 13 Mar 2002 07:03:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10424 for ; Wed, 13 Mar 2002 07:03:13 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02865 for ; Wed, 13 Mar 2002 07:03:09 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g2DC39R08587; Wed, 13 Mar 2002 13:03:09 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g2DC39g18247; Wed, 13 Mar 2002 13:03:09 +0100 (MET) From: "Hannes Tschofenig" To: "Georgios Karagiannis \(ELN\)" , "'Hancock, Robert'" , Cc: Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Wed, 13 Mar 2002 13:05:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit hi georgios! > > Hi Hannes > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. but where do you see the problem for hop-by-hop security? ciao hannes > > Best Regards, > Georgios > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 13 maart 2002 11:06 > To: Georgios Karagiannis (ELN); 'Hancock, Robert'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) > > > hi > > > > Hi Hannes > > > > What about saying something like: > > The initiator of the NSIS protocol can require > > the support of the hop-by-hop security feature. > because of the chain-of-trust assumption it is not possible for the > initiator > to require that all providers provide some sort of protection. every node > can > only decide whether it has to include a security protection or not. if the > receiver requires the protection and no such protection is > present then the > request is not processed and an error message is returned. > > > However, an administrator of a QoS domain is able to > > deactivate this feature, when the NSIS protocol > > is used within its administrative QoS domain. > true. an administrator of a qos domain may decide to require authenticated > qos signaling messages at the borders and not within the nodes of the core > network. > > > > how about this (modified) requirement? > > 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. > > Hop-by-hop security enables authentication, integrity, possibly > confidentiality and replay protection of QoS signaling messages exchanged > between two QoS aware network elements. The chain-of-trust principle then > allows non-neighboring nodes to trust each other based on the > existing trust > of neighboring nodes. > > If, however, a network element along the path is not participating in the > QoS signaling i.e. a QoS unaware or ignorant node (e.g. because the QoS > signaling message are transmitted over a non-QoS signaling aware > cloud) then > neither QoS nor QoS protocol specific security mechanisms are executed by > this node. Furthermore a network provider may also decide > (independently of > other involved parties) not to use hop-by-hop protection of the signaling > messages between every QoS aware node within his own administrative domain > (e.g. because other security mechanisms are in place or because > of a strong > trust assumption). In this case the hop-by-hop security is relaxed and > hop-by-hop security is only used between QoS aware nodes which > are also QoS > security aware. > > Hop-by-hop security allows intermediate nodes that actively participate in > the QoS protocol to modify the messages as required by the QoS processing. > Note that this requirement does not exclude end-to-end or > network-to-network > security of a QoS reservation request. End-to- > end security between the initiator and the responder may be used > to provide > protection of non-mutable data fields. Network-to-network > security refers to > the protection of messages over various hops but not in an > end-to-end manner > i.e. protected over a particular network. > > ciao > hannes > > > > > Best Regards, > > Georgios > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 13 07:50:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03550 for ; Wed, 13 Mar 2002 07:50:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA12279 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 07:50:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11943; Wed, 13 Mar 2002 07:42:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11914 for ; Wed, 13 Mar 2002 07:42:44 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03374 for ; Wed, 13 Mar 2002 07:42:41 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2DCgcZc021373 for ; Wed, 13 Mar 2002 13:42:38 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 13 13:42:25 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 13:42:08 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Hannes Tschofenig'" , "'Hancock, Robert'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) Date: Wed, 13 Mar 2002 13:42:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Sorry Hannes, I think I mixed up the number of the requirement :-) This reply is a reply to the e-mail sent by Marco. Therefore, in a while I will re-send this reply to Marco. Regarding your proposal I think the description of the requirement is going into the right direction, but I will need some more time to think if I can understand all the possible implications. Best regards, Georgios -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: woensdag 13 maart 2002 13:06 To: Georgios Karagiannis (ELN); 'Hancock, Robert'; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) hi georgios! > > Hi Hannes > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. but where do you see the problem for hop-by-hop security? ciao hannes > > Best Regards, > Georgios > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 13 maart 2002 11:06 > To: Georgios Karagiannis (ELN); 'Hancock, Robert'; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5) > > > hi > > > > Hi Hannes > > > > What about saying something like: > > The initiator of the NSIS protocol can require > > the support of the hop-by-hop security feature. > because of the chain-of-trust assumption it is not possible for the > initiator > to require that all providers provide some sort of protection. every node > can > only decide whether it has to include a security protection or not. if the > receiver requires the protection and no such protection is > present then the > request is not processed and an error message is returned. > > > However, an administrator of a QoS domain is able to > > deactivate this feature, when the NSIS protocol > > is used within its administrative QoS domain. > true. an administrator of a qos domain may decide to require authenticated > qos signaling messages at the borders and not within the nodes of the core > network. > > > > how about this (modified) requirement? > > 5.8.5 The QoS signaling protocol must allow for hop-by-hop security. > > Hop-by-hop security enables authentication, integrity, possibly > confidentiality and replay protection of QoS signaling messages exchanged > between two QoS aware network elements. The chain-of-trust principle then > allows non-neighboring nodes to trust each other based on the > existing trust > of neighboring nodes. > > If, however, a network element along the path is not participating in the > QoS signaling i.e. a QoS unaware or ignorant node (e.g. because the QoS > signaling message are transmitted over a non-QoS signaling aware > cloud) then > neither QoS nor QoS protocol specific security mechanisms are executed by > this node. Furthermore a network provider may also decide > (independently of > other involved parties) not to use hop-by-hop protection of the signaling > messages between every QoS aware node within his own administrative domain > (e.g. because other security mechanisms are in place or because > of a strong > trust assumption). In this case the hop-by-hop security is relaxed and > hop-by-hop security is only used between QoS aware nodes which > are also QoS > security aware. > > Hop-by-hop security allows intermediate nodes that actively participate in > the QoS protocol to modify the messages as required by the QoS processing. > Note that this requirement does not exclude end-to-end or > network-to-network > security of a QoS reservation request. End-to- > end security between the initiator and the responder may be used > to provide > protection of non-mutable data fields. Network-to-network > security refers to > the protection of messages over various hops but not in an > end-to-end manner > i.e. protected over a particular network. > > ciao > hannes > > > > > Best Regards, > > Georgios > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 13 08:00:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03689 for ; Wed, 13 Mar 2002 08:00:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12794 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 08:00:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12003; Wed, 13 Mar 2002 07:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11974 for ; Wed, 13 Mar 2002 07:43:36 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03397 for ; Wed, 13 Mar 2002 07:43:34 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2DChZZc021989 for ; Wed, 13 Mar 2002 13:43:35 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Mar 13 13:43:32 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 13:43:32 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Wed, 13 Mar 2002 13:43:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marco What I mean is the following. If some QoS domain will use aggregated reservation states and if the lifetime requirement has to be supported by the domain, then new per flow reservation lifetime states have to be created in this domain. Best Regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: dinsdag 12 maart 2002 22:13 To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, The point of the example is that the network may want to limit the duration that it grants for a session and thus its corresponding resources (such as a QOS connection). So in this case the network needs to be able to revoke resources upon the expiration of some time period. In thinking about this example I was wondering whether it would be useful to make duration an explicit part of the reservation semantics. 1) A host requests from network a service of one hour duration. For example a video call to a friend. 2) Above is realized via session negotiation that results in token that is passed back to the host. The token permits a QOS connection of one hour duration at 5 Mbps 3) The host (QOS Initiator) includes the token in the NSIS setup message requesting a 5Mbps connection. 4) The QOS Controller uses the token to validate the reservation and allows the setup to go through. (See draft-ietf-sip-call-auth-0?.txt as well as draft-ietf-rap-session-auth-0?.txt) Now what happens when one hour is up? Ideally the host releases the resources but if the host does not the network will (otherwise the user gets more than they paid for). When the network releases the resources there should be a cause code that says your time was up or at the very least indicates that this was due to service policy. Now my question is: given that the reservation is intended to be of a precise duration should we make this explicit or is it better for this to be transparent? Is so why? Regarding Scalability, I do not understand your claim that this is very non-scalable. For every flow reservation the network presumably will need to store the amount reserved (at least one piece of information). A reservation duration requires one additional piece of information (at the edge) that does not propagate across the network. Best Regards, Marco > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Tuesday, March 12, 2002 3:54 AM > To: Schneider, Marco; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Marco > > I do not know if I understand your point. > You can achieve the same operation by just explicitly > releasing the resources after one hour! > Only the end host has to know that the resources > will be kept for one hour. > > In this case the network will not have to store for each flow > the reservation time. If the network would do that > then we will have a very non-scalable solution, i.e., > increasing number of users the number of reservation > lifetime states are increased. > > However, I think Steve Berson had a reasonable solution on this: > Emphasise in the requirement that advance reservations are not > required, but if you wanted advance reservations, then > reservation duration seems like a useful thing to have. > > Best regards, > Georgios > > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: maandag 11 maart 2002 19:30 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > I think the ability to control reservation life-times may be a useful > capability. Say for instance that I purchase a video call for one hour > duration. NSIS should support the ability of the network to end the > associated reservation after one hour. While this does not absolutely > necessitate making the reservation lifetime an explicit part of the > reservation request semantics, I think it would make sense to do so in > support of this situation. > > Marco > > > > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Friday, March 08, 2002 1:36 PM > > To: 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Steve > > > > The associated motivation given for this requirement > > in the NSIS WG draft is that "allows reducing the reservation > > update frequency in case of soft state based signaling." > (from draft) > > > > Therefore, I thought that it was related to the soft-state refresh > > timer. Do you have another motivation to keep this requirement. > > > > Best regards, > > Georgios > > > > > > -----Original Message----- > > From: Steven Berson [mailto:berson@isi.edu] > > Sent: vrijdag 8 maart 2002 20:30 > > To: Georgios Karagiannis (ELN) > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > > > > Georgios, > > > > I am not sure if it is a good idea to support reservation > life-times, > > but at this time, it does not seem like a good idea to > preclude it. > > Also, the reservation life-time is not necessarily related to the > > soft-state refresh timer. > > > > Steve > > > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > > > Hi Marcus > > > > > > Regarding requirement in Section 5.3.2: > > > > > > "Ability to signal life-time of a reservation": > > > > > > The problem that I have with this requirement is that it will > > > increase the complexity of the functionality related to the soft > > > state (refresh) principle in a node. > > > Please note that the soft state refresh principle is used > > > to somehow solve unexpected changes in the network, e.g., > > route changes > > > that are independent of the lifetime of a reservation. > > > Therefore, I do not think that the lifetime of the reservation > > > should affect the duration of the soft state refresh. > > > Please remove it! > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Mar 13 13:36:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14511 for ; Wed, 13 Mar 2002 13:36:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03926 for nsis-archive@odin.ietf.org; Wed, 13 Mar 2002 13:36:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02699; Wed, 13 Mar 2002 13:15:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02665 for ; Wed, 13 Mar 2002 13:15:00 -0500 (EST) Received: from fig.isi.edu (fig.isi.edu [128.9.160.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13664 for ; Wed, 13 Mar 2002 13:14:57 -0500 (EST) Received: from localhost (berson@localhost) by fig.isi.edu (8.11.6/8.11.6) with ESMTP id g2DIEkx25012; Wed, 13 Mar 2002 10:14:46 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs Date: Wed, 13 Mar 2002 10:14:46 -0800 (PST) From: Steven Berson To: "Georgios Karagiannis (ELN)" cc: "'Schneider, Marco'" , "'brunner@ccrle.nec.de'" , Subject: RE: [NSIS] Requirement Section 5.3.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Georgios, My understanding of what Marco wrote is that the lifetime information is stored only at the edge. The core would not need to store the lifetime information, and so aggregation (without lifetimes) can still be done in the core. Steve On Wed, 13 Mar 2002, Georgios Karagiannis (ELN) wrote: > Hi Marco > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. > > Best Regards, > Georgios > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: dinsdag 12 maart 2002 22:13 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > The point of the example is that the network may want to limit the duration > that it grants for a session and thus its corresponding resources (such as a > QOS connection). So in this case the network needs to be able to revoke > resources upon the expiration of some time period. In thinking about this > example I was wondering whether it would be useful to make duration an > explicit part of the reservation semantics. > > 1) A host requests from network a service of one hour duration. For example > a video call to a friend. > 2) Above is realized via session negotiation that results in token that is > passed back to the host. The token permits a QOS connection of one hour > duration at 5 Mbps > 3) The host (QOS Initiator) includes the token in the NSIS setup message > requesting a 5Mbps connection. > 4) The QOS Controller uses the token to validate the reservation and allows > the setup to go through. > (See draft-ietf-sip-call-auth-0?.txt as well as > draft-ietf-rap-session-auth-0?.txt) > > Now what happens when one hour is up? Ideally the host releases the > resources but if the host does not the network will (otherwise the user gets > more than they paid for). When the network releases the resources there > should be a cause code that says your time was up or at the very least > indicates that this was due to service policy. > > Now my question is: given that the reservation is intended to be of a > precise duration should we make this explicit or is it better for this to be > transparent? Is so why? > > Regarding Scalability, I do not understand your claim that this is very > non-scalable. For every flow reservation the network presumably will need to > store the amount reserved (at least one piece of information). A reservation > duration requires one additional piece of information (at the edge) that > does not propagate across the network. > > Best Regards, > Marco > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Tuesday, March 12, 2002 3:54 AM > > To: Schneider, Marco; 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Marco > > > > I do not know if I understand your point. > > You can achieve the same operation by just explicitly > > releasing the resources after one hour! > > Only the end host has to know that the resources > > will be kept for one hour. > > > > In this case the network will not have to store for each flow > > the reservation time. If the network would do that > > then we will have a very non-scalable solution, i.e., > > increasing number of users the number of reservation > > lifetime states are increased. > > > > However, I think Steve Berson had a reasonable solution on this: > > Emphasise in the requirement that advance reservations are not > > required, but if you wanted advance reservations, then > > reservation duration seems like a useful thing to have. > > > > Best regards, > > Georgios > > > > > > > > -----Original Message----- > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > Sent: maandag 11 maart 2002 19:30 > > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Georgios, > > > > I think the ability to control reservation life-times may be a useful > > capability. Say for instance that I purchase a video call for one hour > > duration. NSIS should support the ability of the network to end the > > associated reservation after one hour. While this does not absolutely > > necessitate making the reservation lifetime an explicit part of the > > reservation request semantics, I think it would make sense to do so in > > support of this situation. > > > > Marco > > > > > > > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: Friday, March 08, 2002 1:36 PM > > > To: 'Steven Berson' > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > > > > Hi Steve > > > > > > The associated motivation given for this requirement > > > in the NSIS WG draft is that "allows reducing the reservation > > > update frequency in case of soft state based signaling." > > (from draft) > > > > > > Therefore, I thought that it was related to the soft-state refresh > > > timer. Do you have another motivation to keep this requirement. > > > > > > Best regards, > > > Georgios > > > > > > > > > -----Original Message----- > > > From: Steven Berson [mailto:berson@isi.edu] > > > Sent: vrijdag 8 maart 2002 20:30 > > > To: Georgios Karagiannis (ELN) > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > > > > > > > Georgios, > > > > > > I am not sure if it is a good idea to support reservation > > life-times, > > > but at this time, it does not seem like a good idea to > > preclude it. > > > Also, the reservation life-time is not necessarily related to the > > > soft-state refresh timer. > > > > > > Steve > > > > > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > > > > > Hi Marcus > > > > > > > > Regarding requirement in Section 5.3.2: > > > > > > > > "Ability to signal life-time of a reservation": > > > > > > > > The problem that I have with this requirement is that it will > > > > increase the complexity of the functionality related to the soft > > > > state (refresh) principle in a node. > > > > Please note that the soft state refresh principle is used > > > > to somehow solve unexpected changes in the network, e.g., > > > route changes > > > > that are independent of the lifetime of a reservation. > > > > Therefore, I do not think that the lifetime of the reservation > > > > should affect the duration of the soft state refresh. > > > > Please remove it! > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Mar 14 08:28:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16785 for ; Thu, 14 Mar 2002 08:28:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26135 for nsis-archive@odin.ietf.org; Thu, 14 Mar 2002 08:28:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25847; Thu, 14 Mar 2002 08:22:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25814 for ; Thu, 14 Mar 2002 08:22:20 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16666 for ; Thu, 14 Mar 2002 08:22:16 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2EDMHUw016963 for ; Thu, 14 Mar 2002 14:22:17 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 14:21:50 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 14:20:36 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Steven Berson'" Cc: "'Schneider, Marco'" , "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Thu, 14 Mar 2002 14:21:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Steve But it will be still required to be stored on all edges. Some edges only need to maintain aggregated states. Best Regards, Georgios -----Original Message----- From: Steven Berson [mailto:berson@isi.edu] Sent: woensdag 13 maart 2002 19:15 To: Georgios Karagiannis (ELN) Cc: 'Schneider, Marco'; 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Georgios, My understanding of what Marco wrote is that the lifetime information is stored only at the edge. The core would not need to store the lifetime information, and so aggregation (without lifetimes) can still be done in the core. Steve On Wed, 13 Mar 2002, Georgios Karagiannis (ELN) wrote: > Hi Marco > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. > > Best Regards, > Georgios > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: dinsdag 12 maart 2002 22:13 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > The point of the example is that the network may want to limit the duration > that it grants for a session and thus its corresponding resources (such as a > QOS connection). So in this case the network needs to be able to revoke > resources upon the expiration of some time period. In thinking about this > example I was wondering whether it would be useful to make duration an > explicit part of the reservation semantics. > > 1) A host requests from network a service of one hour duration. For example > a video call to a friend. > 2) Above is realized via session negotiation that results in token that is > passed back to the host. The token permits a QOS connection of one hour > duration at 5 Mbps > 3) The host (QOS Initiator) includes the token in the NSIS setup message > requesting a 5Mbps connection. > 4) The QOS Controller uses the token to validate the reservation and allows > the setup to go through. > (See draft-ietf-sip-call-auth-0?.txt as well as > draft-ietf-rap-session-auth-0?.txt) > > Now what happens when one hour is up? Ideally the host releases the > resources but if the host does not the network will (otherwise the user gets > more than they paid for). When the network releases the resources there > should be a cause code that says your time was up or at the very least > indicates that this was due to service policy. > > Now my question is: given that the reservation is intended to be of a > precise duration should we make this explicit or is it better for this to be > transparent? Is so why? > > Regarding Scalability, I do not understand your claim that this is very > non-scalable. For every flow reservation the network presumably will need to > store the amount reserved (at least one piece of information). A reservation > duration requires one additional piece of information (at the edge) that > does not propagate across the network. > > Best Regards, > Marco > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Tuesday, March 12, 2002 3:54 AM > > To: Schneider, Marco; 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Marco > > > > I do not know if I understand your point. > > You can achieve the same operation by just explicitly > > releasing the resources after one hour! > > Only the end host has to know that the resources > > will be kept for one hour. > > > > In this case the network will not have to store for each flow > > the reservation time. If the network would do that > > then we will have a very non-scalable solution, i.e., > > increasing number of users the number of reservation > > lifetime states are increased. > > > > However, I think Steve Berson had a reasonable solution on this: > > Emphasise in the requirement that advance reservations are not > > required, but if you wanted advance reservations, then > > reservation duration seems like a useful thing to have. > > > > Best regards, > > Georgios > > > > > > > > -----Original Message----- > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > Sent: maandag 11 maart 2002 19:30 > > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Georgios, > > > > I think the ability to control reservation life-times may be a useful > > capability. Say for instance that I purchase a video call for one hour > > duration. NSIS should support the ability of the network to end the > > associated reservation after one hour. While this does not absolutely > > necessitate making the reservation lifetime an explicit part of the > > reservation request semantics, I think it would make sense to do so in > > support of this situation. > > > > Marco > > > > > > > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: Friday, March 08, 2002 1:36 PM > > > To: 'Steven Berson' > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > > > > Hi Steve > > > > > > The associated motivation given for this requirement > > > in the NSIS WG draft is that "allows reducing the reservation > > > update frequency in case of soft state based signaling." > > (from draft) > > > > > > Therefore, I thought that it was related to the soft-state refresh > > > timer. Do you have another motivation to keep this requirement. > > > > > > Best regards, > > > Georgios > > > > > > > > > -----Original Message----- > > > From: Steven Berson [mailto:berson@isi.edu] > > > Sent: vrijdag 8 maart 2002 20:30 > > > To: Georgios Karagiannis (ELN) > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > > > > > > > Georgios, > > > > > > I am not sure if it is a good idea to support reservation > > life-times, > > > but at this time, it does not seem like a good idea to > > preclude it. > > > Also, the reservation life-time is not necessarily related to the > > > soft-state refresh timer. > > > > > > Steve > > > > > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > > > > > Hi Marcus > > > > > > > > Regarding requirement in Section 5.3.2: > > > > > > > > "Ability to signal life-time of a reservation": > > > > > > > > The problem that I have with this requirement is that it will > > > > increase the complexity of the functionality related to the soft > > > > state (refresh) principle in a node. > > > > Please note that the soft state refresh principle is used > > > > to somehow solve unexpected changes in the network, e.g., > > > route changes > > > > that are independent of the lifetime of a reservation. > > > > Therefore, I do not think that the lifetime of the reservation > > > > should affect the duration of the soft state refresh. > > > > Please remove it! > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Mar 14 10:01:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18466 for ; Thu, 14 Mar 2002 10:01:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02983 for nsis-archive@odin.ietf.org; Thu, 14 Mar 2002 10:01:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02179; Thu, 14 Mar 2002 09:56:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02148 for ; Thu, 14 Mar 2002 09:56:17 -0500 (EST) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18338 for ; Thu, 14 Mar 2002 09:56:14 -0500 (EST) Received: from morgane.enst.fr (morgane.enst.fr [137.194.160.31]) by infres.enst.fr (Postfix) with ESMTP id 4D32018AD; Thu, 14 Mar 2002 15:56:15 +0100 (MET) Received: from morgane (localhost [127.0.0.1]) by morgane.enst.fr (8.9.3+Sun/8.9.3) with SMTP id PAA20629; Thu, 14 Mar 2002 15:56:14 +0100 (MET) Message-ID: <3C90BA0D.1A6@enst.fr> Date: Thu, 14 Mar 2002 15:56:13 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: Re: [NSIS] Requirement Section 5.3.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Georgos et al, IMHO, if the domain uses Policy-based networking concept where the centralized QoS control point (maybe the QC if I well understand) corresponds to the PDP, edge routers correspond to PEPs, the lifetime information may be maintained by the PDP, not on all edges. At the start-time and the end-time of the lifetime, the PDP will push neccessary information only to some edges concerning. Best regards, Mai Trang Georgios Karagiannis (ELN) wrote: > > Hi Steve > > But it will be still required to be stored on all edges. > Some edges only need to maintain aggregated states. > > Best Regards, > Georgios > > -----Original Message----- > From: Steven Berson [mailto:berson@isi.edu] > Sent: woensdag 13 maart 2002 19:15 > To: Georgios Karagiannis (ELN) > Cc: 'Schneider, Marco'; 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > Georgios, > > My understanding of what Marco wrote is that the lifetime information > is stored only at the edge. The core would not need to store the > lifetime information, and so aggregation (without lifetimes) can still > be done in the core. > > Steve > > On Wed, 13 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > Hi Marco > > > > What I mean is the following. > > If some QoS domain will use aggregated reservation states > > and if the lifetime requirement has to be supported by the domain, > > then new per flow reservation lifetime states have to be created > > in this domain. > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > Sent: dinsdag 12 maart 2002 22:13 > > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Georgios, > > > > The point of the example is that the network may want to limit the duration > > that it grants for a session and thus its corresponding resources (such as a > > QOS connection). So in this case the network needs to be able to revoke > > resources upon the expiration of some time period. In thinking about this > > example I was wondering whether it would be useful to make duration an > > explicit part of the reservation semantics. > > > > 1) A host requests from network a service of one hour duration. For example > > a video call to a friend. > > 2) Above is realized via session negotiation that results in token that is > > passed back to the host. The token permits a QOS connection of one hour > > duration at 5 Mbps > > 3) The host (QOS Initiator) includes the token in the NSIS setup message > > requesting a 5Mbps connection. > > 4) The QOS Controller uses the token to validate the reservation and allows > > the setup to go through. > > (See draft-ietf-sip-call-auth-0?.txt as well as > > draft-ietf-rap-session-auth-0?.txt) > > > > Now what happens when one hour is up? Ideally the host releases the > > resources but if the host does not the network will (otherwise the user gets > > more than they paid for). When the network releases the resources there > > should be a cause code that says your time was up or at the very least > > indicates that this was due to service policy. > > > > Now my question is: given that the reservation is intended to be of a > > precise duration should we make this explicit or is it better for this to be > > transparent? Is so why? > > > > Regarding Scalability, I do not understand your claim that this is very > > non-scalable. For every flow reservation the network presumably will need to > > store the amount reserved (at least one piece of information). A reservation > > duration requires one additional piece of information (at the edge) that > > does not propagate across the network. > > > > Best Regards, > > Marco > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: Tuesday, March 12, 2002 3:54 AM > > > To: Schneider, Marco; 'Steven Berson' > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > > > > Hi Marco > > > > > > I do not know if I understand your point. > > > You can achieve the same operation by just explicitly > > > releasing the resources after one hour! > > > Only the end host has to know that the resources > > > will be kept for one hour. > > > > > > In this case the network will not have to store for each flow > > > the reservation time. If the network would do that > > > then we will have a very non-scalable solution, i.e., > > > increasing number of users the number of reservation > > > lifetime states are increased. > > > > > > However, I think Steve Berson had a reasonable solution on this: > > > Emphasise in the requirement that advance reservations are not > > > required, but if you wanted advance reservations, then > > > reservation duration seems like a useful thing to have. > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > -----Original Message----- > > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > > Sent: maandag 11 maart 2002 19:30 > > > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > > > > Hi Georgios, > > > > > > I think the ability to control reservation life-times may be a useful > > > capability. Say for instance that I purchase a video call for one hour > > > duration. NSIS should support the ability of the network to end the > > > associated reservation after one hour. While this does not absolutely > > > necessitate making the reservation lifetime an explicit part of the > > > reservation request semantics, I think it would make sense to do so in > > > support of this situation. > > > > > > Marco > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis (ELN) > > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > > Sent: Friday, March 08, 2002 1:36 PM > > > > To: 'Steven Berson' > > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > > > > > > > Hi Steve > > > > > > > > The associated motivation given for this requirement > > > > in the NSIS WG draft is that "allows reducing the reservation > > > > update frequency in case of soft state based signaling." > > > (from draft) > > > > > > > > Therefore, I thought that it was related to the soft-state refresh > > > > timer. Do you have another motivation to keep this requirement. > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > -----Original Message----- > > > > From: Steven Berson [mailto:berson@isi.edu] > > > > Sent: vrijdag 8 maart 2002 20:30 > > > > To: Georgios Karagiannis (ELN) > > > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > > > Subject: Re: [NSIS] Requirement Section 5.3.2 > > > > > > > > > > > > Georgios, > > > > > > > > I am not sure if it is a good idea to support reservation > > > life-times, > > > > but at this time, it does not seem like a good idea to > > > preclude it. > > > > Also, the reservation life-time is not necessarily related to the > > > > soft-state refresh timer. > > > > > > > > Steve > > > > > > > > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote: > > > > > > > > > Hi Marcus > > > > > > > > > > Regarding requirement in Section 5.3.2: > > > > > > > > > > "Ability to signal life-time of a reservation": > > > > > > > > > > The problem that I have with this requirement is that it will > > > > > increase the complexity of the functionality related to the soft > > > > > state (refresh) principle in a node. > > > > > Please note that the soft state refresh principle is used > > > > > to somehow solve unexpected changes in the network, e.g., > > > > route changes > > > > > that are independent of the lifetime of a reservation. > > > > > Therefore, I do not think that the lifetime of the reservation > > > > > should affect the duration of the soft state refresh. > > > > > Please remove it! > > > > > > > > > > Best regards, > > > > > Georgios > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- --------------------------------------- NGUYEN Thi Mai Trang Ecole Nationale Superieure des Telecommunications Departement INFRES - Bureau C 234-4 46, rue Barrault - 75013 Paris Tel: (+33) (-0)1 45 81 74 61 - Fax : (+33) (-0)1 45 81 31 19 email : trnguyen@enst.fr --------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Mar 14 10:24:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19094 for ; Thu, 14 Mar 2002 10:24:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04426 for nsis-archive@odin.ietf.org; Thu, 14 Mar 2002 10:24:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03678; Thu, 14 Mar 2002 10:11:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03606 for ; Thu, 14 Mar 2002 10:11:15 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18813 for ; Thu, 14 Mar 2002 10:11:11 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EFBNZ00914 for ; Thu, 14 Mar 2002 17:11:23 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 14 Mar 2002 09:11:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 09:10:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB6A.5694D0A2" Subject: RE: [NSIS] An NSIS requirement with backing scenario Date: Thu, 14 Mar 2002 10:10:12 -0500 Message-ID: Thread-Topic: [NSIS] An NSIS requirement with backing scenario Thread-Index: AcHKdgzLshKRkswbTc68YMLy9mAscgAg+uRg To: X-OriginalArrivalTime: 14 Mar 2002 15:10:12.0925 (UTC) FILETIME=[56F986D0:01C1CB6A] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CB6A.5694D0A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hannes: =20 Please see some comments below. =20 =20 -----Original Message----- From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Wednesday, March 13, 2002 4:56 AM To: Chaskar Hemant (NRC/Boston); nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario hi hemant! > Hi: > I would like to place the following requirement on table for = discussion in WG. I have also provided a scenario below that=20 > motivates such explicit requirement. I would like to know if WG deems = this as an important issue. > "QoS signaling protocol MUST interwork with AAA for QoS authorization = and accounting purposes". i like this requirement. it think that it is a good idea to have this = requirement.=20 but: i think it is already covered with: 5.8.2 The QoS protocol must provide means to authorize resource requests 5.10.5 The QoS protocol should provide hooks for AAA protocols=20 =20 [HC] I think that only stating such requirements may not suffice. The = document should elaborate on them and also give some exemplary = scenarios. That helps to indicate where the deep waters are. =20 appart from the requirements for an interaction with AAA there are still = open issues regarding billing/payment/charging=20 as indicated below. there have been a number of papers describing = different solutions=20 but i do not know a satisfiable one. maybe we can discuss some of the = issues at the ietf conference=20 next week.=20 =20 [HC] Can you construct any more scenarios from those papers that may be = relevant for such requirement? It will be good to know as many scenarios = as possible before going into the solution phase. =20 to your scenario below:=20 just to make sure: the main problem seems to be that user B has to give = "something" to network N_B telling that user A is paying for the reservation. =20 =20 [HC] Yes, that is right.=20 =20 if A is not willing to provide credentials then there is obvioulsy a = problem but=20 a could provide credentials without concerns about security. it only = depends how these "credentials" look like.=20 from my point of view this information should be exchanged before the = actual qos reservation takes place since it=20 is an application issue. hence the information should already be = available at the qos-reservation start-up.=20 > ii) If A and N_B are in different jurisdiction, whatever credentials A = has to provide may not satisfy N_B.=20 > Note that N_B cannot bill A directly. there has to be some agreement between providers otherwise this exchange = will not work.=20 =20 > (i) SIP has to convey "intent" of A to pay for the call to B. A may = also expect in return the B's cost of access at N_B.=20 > (This part has to be addressed by SIP and SDPng). i agree with you.=20 > (ii) NSIS signaling needs to interwork with AAA so that it can reserve = and bill for QoS resources in N_B.=20 > This is the requirement that needs to be included in NSIS requirements = document. this is true.=20 first, the qos signaling messages must be authenticated, integrity and = replay protected.=20 second, the qos protocol should be able to transport information = exchanged with protocols executed before the=20 qos protocol is triggered.=20 =20 [HC] Issues such as these will affect NSIS protocol design. That is the = main message I would like to convey via this requirement/scenario. =20 Regards, Hemant =20 ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of = Hemant.Chaskar@nokia.com Sent: Tuesday, March 12, 2002 4:55 PM To: nsis@ietf.org Subject: [NSIS] An NSIS requirement with backing scenario Hi: =20 I would like to place the following requirement on table for discussion = in WG. I have also provided a scenario below that motivates such = explicit requirement. I would like to know if WG deems this as an = important issue. =20 "QoS signaling protocol MUST interwork with AAA for QoS authorization = and accounting purposes". =20 Scenario: ----------- =20 A and B are connected to the Internet on the two sides of the globe. A = places call to B, and (say during SIP transactions) intimates to B that = A will pay for the call. Paying for the call also means paying for QoS = of the corresponding packet transport. B accepts A's proposal. The call = happens to be of bidirectional traffic type.=20 =20 A sends signal to its access network N_A asking it to give certain QoS = to packet stream from A -> B. A is a subscribed customer of N_A, so = there are no apparent difficulties for N_A in checking A's credentials = and in billing A. Also, network N_A may then take appropriate means to = guarantee end-to-end QoS, may be based on SLAs with other providers and = may be using some NSIS signaling. =20 For the packet path from B -> A, A does not know apriori as to how the = path looks like. So, the QoS establishment for this path needs to be = initiated from B's side. Now, B is not paying for QoS in its own access = network N_B. Since, A has agreed to pay, A needs to provide some = credentials to B which would be acceptable to N_B. There are two = problems encountered here: i) Though A has agreed to pay, A may not be = willing to provide credentials to end host B for security reasons, ii) = If A and N_B are in different jurisdiction, whatever credentials A has = to provide may not satisfy N_B. Note that N_B cannot bill A directly. =20 The following things need to happen to make this call through.=20 =20 (i) SIP has to convey "intent" of A to pay for the call to B. A may also = expect in return the B's cost of access at N_B. (This part has to be = addressed by SIP and SDPng). =20 (ii) NSIS signaling needs to interwork with AAA so that it can reserve = and bill for QoS resources in N_B. This is the requirement that needs to = be included in NSIS requirements document. =20 BR, Hemant ------_=_NextPart_001_01C1CB6A.5694D0A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Hannes:
 
Please see some comments = below.
 
 
-----Original Message-----
From: ext Hannes = Tschofenig=20 [mailto:Hannes.Tschofenig@mchp.siemens.de]
Sent: Wednesday, = March 13,=20 2002 4:56 AM
To: Chaskar Hemant (NRC/Boston);=20 nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with = backing=20 scenario

hi hemant!

> Hi:

> I would like to = place the=20 following requirement on table for discussion in WG. I have also = provided a=20 scenario below that

> motivates such = explicit=20 requirement. I would like to know if WG deems this as an important=20 issue.

> "QoS signaling = protocol MUST=20 interwork with AAA for QoS authorization and accounting = purposes".

i like this requirement. = it think that=20 it is a good idea to have this requirement.

but: i think it is = already covered=20 with:

5.8.2 The QoS protocol = must provide=20 means to authorize resource requests

5.10.5 The = QoS protocol=20 should provide hooks for AAA protocols 

 

[HC] I think that only = stating such=20 requirements may not suffice. The document should elaborate on them and = also=20 give some exemplary scenarios. That helps to indicate where the deep = waters=20 are.

 

appart from the = requirements for an=20 interaction with AAA there are still open issues regarding=20 billing/payment/charging

as indicated below. there = have been a=20 number of papers describing = different=20 solutions

but i do not know a = satisfiable one. maybe we can discuss some of the = issues at=20 the ietf conference

next week. 

 

[HC] Can you construct any more scenarios from those = papers that may=20 be relevant for such requirement? It will be good to know as many = scenarios as=20 possible before going into the solution phase.

 

to your scenario below: =

just to make sure: the main problem = seems to be=20 that user B has to give "something" to network N_B telling that user A = is paying=20 for

the = reservation.  

 

[HC] Yes, that is=20 right. 

 

if A is not willing to = provide=20 credentials then there is obvioulsy a problem but

a could provide = credentials without=20 concerns about security. it only depends how these "credentials" look = like.=20

from my point of view = this information=20 should be exchanged before the actual qos reservation takes place since = it=20

is an application issue. = hence the=20 information should already be available at the qos-reservation start-up. =

> ii) If A and N_B are = in different=20 jurisdiction, whatever credentials A has to provide may not satisfy N_B. =

> Note that N_B cannot = bill A=20 directly.

there has to be some = agreement between=20 providers otherwise this exchange will not work.

 

> (i) SIP has to = convey "intent" of=20 A to pay for the call to B. A may also expect in return the B's cost of = access=20 at N_B.

> (This part has to be = addressed by=20 SIP and SDPng).

i agree with you. =

> (ii) NSIS signaling = needs to=20 interwork with AAA so that it can reserve and bill for QoS resources in = N_B.=20

> This is the = requirement that needs=20 to be included in NSIS requirements document.

this is true. =

first, the qos signaling = messages must=20 be authenticated, integrity and replay protected.

second, the qos protocol = should be able=20 to transport information exchanged with protocols executed before the=20

qos protocol is = triggered. 

 

[HC] Issues such as these will affect NSIS = protocol=20 design. That is the main message I would like to convey via this=20 requirement/scenario.

 

Regards, Hemant

 

ciao

hannes

-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of=20 Hemant.Chaskar@nokia.com
Sent: Tuesday, March 12, 2002 = 4:55=20 PM
To: nsis@ietf.org
Subject: [NSIS] An NSIS = requirement=20 with backing scenario

Hi:
 
I = would like to=20 place the following requirement on table for discussion in WG. I have = also=20 provided a scenario below that motivates such=20 explicit requirement. I would like to know if WG deems this as an important=20 issue.
 
"QoS signaling protocol MUST = interwork=20 with AAA for QoS authorization and accounting=20 purposes".
 
Scenario:
-----------
 
A = and B are=20 connected to the Internet on the two sides of the globe. A places call = to B,=20 and (say during SIP transactions) intimates to B that A will pay for = the call.=20 Paying for the call also means paying for QoS of the corresponding = packet=20 transport. B accepts A's proposal. The call happens to be=20 of bidirectional traffic type. 
 
A = sends signal to=20 its access network N_A asking it to give certain QoS to packet = stream=20 from A -> B. A is a subscribed customer of N_A, so there are no = apparent=20 difficulties for N_A in checking A's credentials and in billing = A. Also,=20 network N_A may then take appropriate means to guarantee = end-to-end QoS,=20 may be based on SLAs with other providers and may be using some NSIS=20 signaling.
 
For = the packet=20 path from B -> A, A does not know apriori as to how the path looks = like.=20 So, the QoS establishment for this path needs to be initiated from B's = side.=20 Now, B is not paying for QoS in its own access network N_B. Since, A = has=20 agreed to pay, A needs to provide some credentials to B which would be = acceptable to N_B. There are two problems encountered here: i) Though = A has=20 agreed to pay, A may not be willing to provide credentials to end host = B for=20 security reasons, ii) If A and N_B are in different jurisdiction, = whatever=20 credentials A has to provide may not satisfy N_B. Note that N_B cannot = bill A=20 directly.
 
The following things need to happen to = make this=20 call through.
 
(i) SIP has to convey "intent" of A = to pay for=20 the call to B. A may also expect in return the B's cost of access at = N_B.=20 (This part has to be addressed by SIP and = SDPng).
 
(ii)  NSIS signaling needs to = interwork with AAA=20 so that it can reserve and bill for QoS resources in N_B. This is the=20 requirement that needs to be included in NSIS requirements=20 document.
 
BR,
Hemant
------_=_NextPart_001_01C1CB6A.5694D0A2-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 14 23:23:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12254 for ; Thu, 14 Mar 2002 23:23:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA04961 for nsis-archive@odin.ietf.org; Thu, 14 Mar 2002 23:23:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03989; Thu, 14 Mar 2002 23:01:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03945 for ; Thu, 14 Mar 2002 23:01:13 -0500 (EST) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11988 for ; Thu, 14 Mar 2002 23:01:09 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <1GGAQM0W>; Thu, 14 Mar 2002 22:57:15 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE6633EDDB@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" , "'Georgios.Karagiannis@eln.ericsson.se'" , "'schneider@tri.sbc.com'" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Thu, 14 Mar 2002 22:57:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, Let me present another argument in support of this requirement: It is possible that the host that made a reservation dies "silently" without releasing network resources allocated for its flow. This requirement will provide protection from the possible waste of resources in this case. It is definitely different from refreshing the soft state of the reservation since it is driven by the application not the network specifics and applicable to the hard reservations as well (and maybe even more important for hard reservations). To make this arrangement more flexible I think that ability to signal life-time of a reservation (including permanent reservations) should be complemented by the ability to re-new the existing reservation. I envision the following scenario: The video endpoint (to stay on the same theme) is making a call. The endpoint or may be proxy makes reservation request with 30 min expected life-time. Three options exist 1. After 20 min the call is over and the endpoint (proxy) releases allocated resources. 2. After 25 min the participants realize that they need another 15 min to finish discussion - the re-new reservation request is issued with 15 min life-time 3. After 15 min the endpoints crashes. 15 min later the network realize that something is wrong and frees resources that were reserved for this video call. Does it make any sense? Ilya From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Wed, 13 Mar 2002 13:43:32 +0100 charset="iso-8859-1" Hi Marco What I mean is the following. If some QoS domain will use aggregated reservation states and if the lifetime requirement has to be supported by the domain, then new per flow reservation lifetime states have to be created in this domain. Best Regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: dinsdag 12 maart 2002 22:13 To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, The point of the example is that the network may want to limit the duration that it grants for a session and thus its corresponding resources (such as a QOS connection). So in this case the network needs to be able to revoke resources upon the expiration of some time period. In thinking about this example I was wondering whether it would be useful to make duration an explicit part of the reservation semantics. 1) A host requests from network a service of one hour duration. For example a video call to a friend. 2) Above is realized via session negotiation that results in token that is passed back to the host. The token permits a QOS connection of one hour duration at 5 Mbps 3) The host (QOS Initiator) includes the token in the NSIS setup message requesting a 5Mbps connection. 4) The QOS Controller uses the token to validate the reservation and allows the setup to go through. (See draft-ietf-sip-call-auth-0?.txt as well as draft-ietf-rap-session-auth-0?.txt) Now what happens when one hour is up? Ideally the host releases the resources but if the host does not the network will (otherwise the user gets more than they paid for). When the network releases the resources there should be a cause code that says your time was up or at the very least indicates that this was due to service policy. Now my question is: given that the reservation is intended to be of a precise duration should we make this explicit or is it better for this to be transparent? Is so why? Regarding Scalability, I do not understand your claim that this is very non-scalable. For every flow reservation the network presumably will need to store the amount reserved (at least one piece of information). A reservation duration requires one additional piece of information (at the edge) that does not propagate across the network. Best Regards, Marco _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 03:07:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23194 for ; Fri, 15 Mar 2002 03:07:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA25947 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 03:07:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24920; Fri, 15 Mar 2002 02:59:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24890 for ; Fri, 15 Mar 2002 02:59:35 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23041 for ; Fri, 15 Mar 2002 02:59:27 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id IAA13318; Fri, 15 Mar 2002 08:58:38 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, "'brunner@ccrle.nec.de'" Cc: nsis@ietf.org Date: Fri, 15 Mar 2002 08:58:36 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 08:58:37 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA24891 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Gabor et al,, As the general agreement seems that NSIS be limited to the bearer level only, and in order to avoid confusion in the future, I propose to add a new point to the section "4.3 Exclusions", that could be phrased as follows: "Specific methods, protocols, and ways to express QoS information in the Application/Session level are not considered (e.g., SDP, SIP, RTSP, etc.); therefore when the NSIS protocol is used to reserve resources with QoS constraints, it is assumed that the application/session level has already been able to determine/negotiate the QoS requirements between the end-users, for each requested bearer. The specification of any extensions needed to signal QoS information via application level protocols (e.g. SDP(ng)), and the mapping on NSIS information are considered outside of the scope of NSIS working group, as this work is in the direct scope of other IETF working groups (e.g. MMUSIC)." Comments ? Best regards Juan Carlos ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on 15/03/2002 08:38 --------------------------- Juan-Carlos ROJAS 12/03/2002 13:58 To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, "'brunner@ccrle.nec.de'" cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt (Document link: Listes Discussion) Hi Gabor, OK, if this is a general agreement in the NSIS wg, it is not my intention to go against the world. It would be preferable if this is clearly written in the requirements document: see e.g. section "4.3 Exclusions", the point 2 could be extended in this way. Best regards Juan Carlos Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Hi Juan-Carlos, my answer to your question : > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". would be "no", becuase in my understanding this WG focuses on IP level QoS signaling mechanisms. However, I agree with you when you say that : > ... what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most Therefore, it is important that we carefully select the bearer level paramaters ("define the bearer service(s)"), when we reach that discussion. To emphasize this, we could consider to add a requirement (at the level of those in Section 5.1) that NSIS signaling should support a wide range of media streams, or something more elaborated. /Gabor > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > Cc: nsis@ietf.org > Date: Mon, 11 Mar 2002 17:17:03 +0100 > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at > 03/11/2002 17:17:04 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27058 > X-Mailman-Version: 1.0 > List-Id: Next Steps in Signaling > X-BeenThere: nsis@ietf.org > > > Hi Gabor, > > No major problem with this. > You are right when saying that "There are already mechanisms that allow > coordination between the session layer and the bearer (IP) layer"; however, > there is no standardized way to exchange and negotiate QoS information at > session level (we are currently proposing SDP extensions for that). > I'm not asking to define "how parties make service agreements", but the > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". > The main purpose is that what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most > straight-forward will be the translation, the less error-prone will be the > implementation. > And for sure, at the end, the QoS information should allow a mapping on > different QoS technologies. > > Otherwise, I fully agree with you, we are currently specifying > requirements, the definition work will come later. > > Best regards > Juan Carlos > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Juan-Carlos, > > in this respect I fully support one view that was expressed > in a previous mail on this list, which formulated a requirement > that the [NSIS QoS signaling] architecture must be completely > agnostic as to how parties make service agreements. That is, > the service advertisement shoud be handled at the application > level. > > There are already mechanisms that allow coordination between the > session layer and the bearer (IP) layer, including the notion > of pre-conditions in SIP. > > However, I view it as an important requirement that > "the information exchanged over the signaling protocol > must be in such detail and quantity > that it is useful for various QoS technologies" > [draft-brunner-nsis..., Section 5.1]. > > Of course, this "level of detail and quantity" > should support various applications without requiring from > application programmers that complex and qualitative parameters > should be set. Therefore, we have a challange to define such > paramater set(s) at the IP level that help various underlying > QoS technologies to provide QoS and are "application programmer > friendly". Such sets allow parties to configure their QoS parameters > after negotiating a service at the application layer. > (This definition work is of course left after the requirements > discussion.) > > /Gabor > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > To: "Geib, Ruediger" > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > , > > nsis@ietf.org > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > |June 18, 2001) at > > 03/11/2002 15:50:51 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > id JAA21126 > > X-Mailman-Version: 1.0 > > List-Id: Next Steps in Signaling > > X-BeenThere: nsis@ietf.org > > > > > > Hi all, > > > > There is a general agreement that NSIS should not define services > > (applications); I fully support this view. > > However, a QoS signalling protocol should provide the necessary > mechanisms > > to allow applications to define, exchange, negotiate QoS characteristics. > > This seems to me a fondamental question: if we agree that in the NGN > > providers will sell services and not only some transport capacity, then > the > > QoS story cannot be considered anymore as only a matter of bearer > handling, > > you need to have a global view including the session layer (e.g. SIP/SDP) > > and the applications. > > Next, it should be up to the involved actors to define a common agreement > > on the service that is to be provided. > > My feeling is that this is fully inline with the IETF philosophy: define > > basic mechanisms, and next, allow the actors to build services on top of > > basic mechanisms. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > 11:40:03 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Hi John, > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). > The > > first requirement may be reworded to clarify that NSIS does not define > the > > service (I'm neither a native speaker nor a legal expert, so I'm not sure > > whether your suggestion does so). > > NSIS then MAY be the IETF WG to collect, check and administrate the > service > > description coded according to NSIS rules? If you don't know the answer > we > > could have a look on the RTP spec's. Also they support a mechanism > offering > > a signaling framework which may be (and is) filled by later individual > > specifications. > > > > Regards, Rüdiger > > > > > > > > NSIS must support a flexible service definition not > > > > restricting contents and meaning of individual service > > > > descriptions. Services may either be private or public. > > > > > > Would these requirements be OK? > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > NSIS MAY consider support for service descriptions developed > > > by other SDOs. > > > > > > This would mean that applications could do the service negotiations, > > > and pass this info to NSIS. > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > classes. > > > > > > John > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 03:26:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23421 for ; Fri, 15 Mar 2002 03:26:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26872 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 03:26:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26073; Fri, 15 Mar 2002 03:07:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26040 for ; Fri, 15 Mar 2002 03:07:54 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23228 for ; Fri, 15 Mar 2002 03:07:51 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA15110; Fri, 15 Mar 2002 09:07:20 +0100 (MET) Subject: RE: [NSIS] Requirement Section 5.3.2 To: "Freytsis, Ilya" Cc: "'nsis@ietf.org'" , "'Georgios.Karagiannis@eln.ericsson.se'" , "'schneider@tri.sbc.com'" Date: Fri, 15 Mar 2002 09:07:18 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 09:07:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya, That's sounds much better: It's up to the service to decide on durations, and when and how to release resources, mainly because these resources are there to provide a service. This does not preclude in anyway to foresee a "time to live" mechanism (with periodic refreshes, or one single duration indicated at the beginning, etc.), but only for *protection* reasons, and nothing else. Now, if the IP level is able to autonomously release resources, it must report that to the end-point (QoS initiator ?). Best regards, Juan Carlos "Freytsis, Ilya" @ietf.org on 15/03/2002 04:57:14 Sent by: nsis-admin@ietf.org To: "'nsis@ietf.org'" , "'Georgios.Karagiannis@eln.ericsson.se'" , "'schneider@tri.sbc.com'" cc: Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, Let me present another argument in support of this requirement: It is possible that the host that made a reservation dies "silently" without releasing network resources allocated for its flow. This requirement will provide protection from the possible waste of resources in this case. It is definitely different from refreshing the soft state of the reservation since it is driven by the application not the network specifics and applicable to the hard reservations as well (and maybe even more important for hard reservations). To make this arrangement more flexible I think that ability to signal life-time of a reservation (including permanent reservations) should be complemented by the ability to re-new the existing reservation. I envision the following scenario: The video endpoint (to stay on the same theme) is making a call. The endpoint or may be proxy makes reservation request with 30 min expected life-time. Three options exist 1. After 20 min the call is over and the endpoint (proxy) releases allocated resources. 2. After 25 min the participants realize that they need another 15 min to finish discussion - the re-new reservation request is issued with 15 min life-time 3. After 15 min the endpoints crashes. 15 min later the network realize that something is wrong and frees resources that were reserved for this video call. Does it make any sense? Ilya From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Wed, 13 Mar 2002 13:43:32 +0100 charset="iso-8859-1" Hi Marco What I mean is the following. If some QoS domain will use aggregated reservation states and if the lifetime requirement has to be supported by the domain, then new per flow reservation lifetime states have to be created in this domain. Best Regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: dinsdag 12 maart 2002 22:13 To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, The point of the example is that the network may want to limit the duration that it grants for a session and thus its corresponding resources (such as a QOS connection). So in this case the network needs to be able to revoke resources upon the expiration of some time period. In thinking about this example I was wondering whether it would be useful to make duration an explicit part of the reservation semantics. 1) A host requests from network a service of one hour duration. For example a video call to a friend. 2) Above is realized via session negotiation that results in token that is passed back to the host. The token permits a QOS connection of one hour duration at 5 Mbps 3) The host (QOS Initiator) includes the token in the NSIS setup message requesting a 5Mbps connection. 4) The QOS Controller uses the token to validate the reservation and allows the setup to go through. (See draft-ietf-sip-call-auth-0?.txt as well as draft-ietf-rap-session-auth-0?.txt) Now what happens when one hour is up? Ideally the host releases the resources but if the host does not the network will (otherwise the user gets more than they paid for). When the network releases the resources there should be a cause code that says your time was up or at the very least indicates that this was due to service policy. Now my question is: given that the reservation is intended to be of a precise duration should we make this explicit or is it better for this to be transparent? Is so why? Regarding Scalability, I do not understand your claim that this is very non-scalable. For every flow reservation the network presumably will need to store the amount reserved (at least one piece of information). A reservation duration requires one additional piece of information (at the edge) that does not propagate across the network. Best Regards, Marco _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 03:27:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23449 for ; Fri, 15 Mar 2002 03:27:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26918 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 03:27:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26510; Fri, 15 Mar 2002 03:18:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26481 for ; Fri, 15 Mar 2002 03:18:29 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23365 for ; Fri, 15 Mar 2002 03:18:27 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2F8ISR21762 for ; Fri, 15 Mar 2002 09:18:28 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 15 09:18:27 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 09:17:12 +0100 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Freytsis, Ilya'" , "'nsis@ietf.org'" , "'schneider@tri.sbc.com'" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Fri, 15 Mar 2002 09:18:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya I think that the issue that you are describing can be solved by the soft state principle. Anyway in my opinion the NSIS protocol MUST use the soft state principle, otherwise we will have to invent very complex functionalities that will solve all the problems that are solved by the soft state principle. Best Regards, Georgios -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: vrijdag 15 maart 2002 4:57 To: 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se'; 'schneider@tri.sbc.com' Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, Let me present another argument in support of this requirement: It is possible that the host that made a reservation dies "silently" without releasing network resources allocated for its flow. This requirement will provide protection from the possible waste of resources in this case. It is definitely different from refreshing the soft state of the reservation since it is driven by the application not the network specifics and applicable to the hard reservations as well (and maybe even more important for hard reservations). To make this arrangement more flexible I think that ability to signal life-time of a reservation (including permanent reservations) should be complemented by the ability to re-new the existing reservation. I envision the following scenario: The video endpoint (to stay on the same theme) is making a call. The endpoint or may be proxy makes reservation request with 30 min expected life-time. Three options exist 1. After 20 min the call is over and the endpoint (proxy) releases allocated resources. 2. After 25 min the participants realize that they need another 15 min to finish discussion - the re-new reservation request is issued with 15 min life-time 3. After 15 min the endpoints crashes. 15 min later the network realize that something is wrong and frees resources that were reserved for this video call. Does it make any sense? Ilya From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'Steven Berson'" Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Wed, 13 Mar 2002 13:43:32 +0100 charset="iso-8859-1" Hi Marco What I mean is the following. If some QoS domain will use aggregated reservation states and if the lifetime requirement has to be supported by the domain, then new per flow reservation lifetime states have to be created in this domain. Best Regards, Georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: dinsdag 12 maart 2002 22:13 To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Georgios, The point of the example is that the network may want to limit the duration that it grants for a session and thus its corresponding resources (such as a QOS connection). So in this case the network needs to be able to revoke resources upon the expiration of some time period. In thinking about this example I was wondering whether it would be useful to make duration an explicit part of the reservation semantics. 1) A host requests from network a service of one hour duration. For example a video call to a friend. 2) Above is realized via session negotiation that results in token that is passed back to the host. The token permits a QOS connection of one hour duration at 5 Mbps 3) The host (QOS Initiator) includes the token in the NSIS setup message requesting a 5Mbps connection. 4) The QOS Controller uses the token to validate the reservation and allows the setup to go through. (See draft-ietf-sip-call-auth-0?.txt as well as draft-ietf-rap-session-auth-0?.txt) Now what happens when one hour is up? Ideally the host releases the resources but if the host does not the network will (otherwise the user gets more than they paid for). When the network releases the resources there should be a cause code that says your time was up or at the very least indicates that this was due to service policy. Now my question is: given that the reservation is intended to be of a precise duration should we make this explicit or is it better for this to be transparent? Is so why? Regarding Scalability, I do not understand your claim that this is very non-scalable. For every flow reservation the network presumably will need to store the amount reserved (at least one piece of information). A reservation duration requires one additional piece of information (at the edge) that does not propagate across the network. Best Regards, Marco _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 04:31:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24408 for ; Fri, 15 Mar 2002 04:31:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02206 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 04:32:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00587; Fri, 15 Mar 2002 04:10:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00499 for ; Fri, 15 Mar 2002 04:10:37 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24102 for ; Fri, 15 Mar 2002 04:10:30 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2F9ATUw018824; Fri, 15 Mar 2002 10:10:29 +0100 (MET) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA17517; Fri, 15 Mar 2002 10:10:29 +0100 From: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Received: by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id KAA03608; Fri, 15 Mar 2002 10:10:28 +0100 (MET) Date: Fri, 15 Mar 2002 10:10:28 +0100 (MET) Message-Id: <200203150910.KAA03608@wrtw014.wrn.ki.sw.ericsson.se> To: Juan-Carlos.Rojas@alcatel.fr Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org X-Sun-Charset: ISO-8859-1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Juan-Carlos, I agree that some additional text in the Exclusion section can actually help to make the scope even more clear. Also, while I agree with the main point of your proposed text, we would probably need to iterate a bit more on excatly how this text could be best formulated. So please see my comments inline : > From Juan-Carlos.Rojas@alcatel.fr Fri Mar 15 08:58:45 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, > "'brunner@ccrle.nec.de'" > Cc: nsis@ietf.org > Date: Fri, 15 Mar 2002 08:58:36 +0100 > > Hello Gabor et al,, > > As the general agreement seems that NSIS be limited to the bearer level > only, and in order to avoid confusion in the future, I propose to add a new > point to the section "4.3 Exclusions", that could be phrased as follows: > > "Specific methods, protocols, and ways to express QoS information in the > Application/Session level are not considered (e.g., SDP, SIP, RTSP, etc.); OK > therefore when the NSIS protocol is used to reserve resources with QoS > constraints, it is assumed that the application/session level has already > been able to determine/negotiate the QoS requirements between the > end-users, for each requested bearer. This text actually assumes that the parties use application/session level signaling to negotiate QoS prior to NSIS signaling. While this is probably the typical case, NSIS should not be restricted to this model. > The specification of any extensions needed to signal QoS information via > application level protocols (e.g. SDP(ng)), and the mapping on NSIS > information are considered outside of the scope of NSIS working group, as > this work is in the direct scope of other IETF working groups (e.g. > MMUSIC)." Yes, I agree, but let me add the following. I agree that the mapping from e.g. the SDP parameters to NSIS bearer parameters are out of scope, but when determining the bearer classes and their associated paramaters, it seems necessary that we take into account what information is signalled at the SIP/SDP level. For instance, some SDP descriptors may contain explicit information about the voice codec (and its associated mime description) that is used in the session. This information can be useful to carry as a "local domain information" [Brunner draft 5.5, bullet 2)] in a wireless scenario, where the QI and the wireless link manager does not sit in the same node. There may be other such cases which we will need to discuss at a later stage (after the requirements doc). > > Comments ? > Best regards > Juan Carlos Regards /Gabor > > ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on > 15/03/2002 08:38 --------------------------- > > > Juan-Carlos ROJAS > 12/03/2002 13:58 > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, > "'brunner@ccrle.nec.de'" > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt (Document link: Listes > Discussion) > > Hi Gabor, > > OK, if this is a general agreement in the NSIS wg, it is not my intention > to go against the world. > It would be preferable if this is clearly written in the requirements > document: see e.g. section "4.3 Exclusions", the point 2 could be extended > in this way. > > Best regards > > Juan Carlos > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Hi Juan-Carlos, > > my answer to your question : > > > question I'm raising is more "Is in the context of NSIS to define ways of > > expressing QoS requirements also at the session level ?". > > would be "no", becuase in my understanding this WG focuses > on IP level QoS signaling mechanisms. > > However, I agree with you when you say that : > > > ... what will be agreed at the session/application > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > resource reservation complying with the QoS requirements. The most > > Therefore, it is important that we carefully select the bearer level > paramaters ("define the bearer service(s)"), when we reach that discussion. > To emphasize this, we could consider to add a requirement (at the > level of those in Section 5.1) that NSIS signaling should support > a wide range of media streams, or something more elaborated. > > /Gabor > > > > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > > Cc: nsis@ietf.org > > Date: Mon, 11 Mar 2002 17:17:03 +0100 > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > |June 18, 2001) at > > 03/11/2002 17:17:04 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > id LAA27058 > > X-Mailman-Version: 1.0 > > List-Id: Next Steps in Signaling > > X-BeenThere: nsis@ietf.org > > > > > > Hi Gabor, > > > > No major problem with this. > > You are right when saying that "There are already mechanisms that allow > > coordination between the session layer and the bearer (IP) layer"; > however, > > there is no standardized way to exchange and negotiate QoS information at > > session level (we are currently proposing SDP extensions for that). > > I'm not asking to define "how parties make service agreements", but the > > question I'm raising is more "Is in the context of NSIS to define ways of > > expressing QoS requirements also at the session level ?". > > The main purpose is that what will be agreed at the session/application > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > resource reservation complying with the QoS requirements. The most > > straight-forward will be the translation, the less error-prone will be > the > > implementation. > > And for sure, at the end, the QoS information should allow a mapping on > > different QoS technologies. > > > > Otherwise, I fully agree with you, we are currently specifying > > requirements, the definition work will come later. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Juan-Carlos, > > > > in this respect I fully support one view that was expressed > > in a previous mail on this list, which formulated a requirement > > that the [NSIS QoS signaling] architecture must be completely > > agnostic as to how parties make service agreements. That is, > > the service advertisement shoud be handled at the application > > level. > > > > There are already mechanisms that allow coordination between the > > session layer and the bearer (IP) layer, including the notion > > of pre-conditions in SIP. > > > > However, I view it as an important requirement that > > "the information exchanged over the signaling protocol > > must be in such detail and quantity > > that it is useful for various QoS technologies" > > [draft-brunner-nsis..., Section 5.1]. > > > > Of course, this "level of detail and quantity" > > should support various applications without requiring from > > application programmers that complex and qualitative parameters > > should be set. Therefore, we have a challange to define such > > paramater set(s) at the IP level that help various underlying > > QoS technologies to provide QoS and are "application programmer > > friendly". Such sets allow parties to configure their QoS parameters > > after negotiating a service at the application layer. > > (This definition work is of course left after the requirements > > discussion.) > > > > /Gabor > > > > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > > From: Juan-Carlos.Rojas@alcatel.fr > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > To: "Geib, Ruediger" > > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > > , > > > nsis@ietf.org > > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > |June 18, 2001) at > > > 03/11/2002 15:50:51 > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 8bit > > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > > id JAA21126 > > > X-Mailman-Version: 1.0 > > > List-Id: Next Steps in Signaling > > > X-BeenThere: nsis@ietf.org > > > > > > > > > Hi all, > > > > > > There is a general agreement that NSIS should not define services > > > (applications); I fully support this view. > > > However, a QoS signalling protocol should provide the necessary > > mechanisms > > > to allow applications to define, exchange, negotiate QoS > characteristics. > > > This seems to me a fondamental question: if we agree that in the NGN > > > providers will sell services and not only some transport capacity, then > > the > > > QoS story cannot be considered anymore as only a matter of bearer > > handling, > > > you need to have a global view including the session layer (e.g. > SIP/SDP) > > > and the applications. > > > Next, it should be up to the involved actors to define a common > agreement > > > on the service that is to be provided. > > > My feeling is that this is fully inline with the IETF philosophy: > define > > > basic mechanisms, and next, allow the actors to build services on top > of > > > basic mechanisms. > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > > 11:40:03 > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > Hi John, > > > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). > > The > > > first requirement may be reworded to clarify that NSIS does not define > > the > > > service (I'm neither a native speaker nor a legal expert, so I'm not > sure > > > whether your suggestion does so). > > > NSIS then MAY be the IETF WG to collect, check and administrate the > > service > > > description coded according to NSIS rules? If you don't know the answer > > we > > > could have a look on the RTP spec's. Also they support a mechanism > > offering > > > a signaling framework which may be (and is) filled by later individual > > > specifications. > > > > > > Regards, Rüdiger > > > > > > > > > > > NSIS must support a flexible service definition not > > > > > restricting contents and meaning of individual service > > > > > descriptions. Services may either be private or public. > > > > > > > > Would these requirements be OK? > > > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > > > NSIS MAY consider support for service descriptions developed > > > > by other SDOs. > > > > > > > > This would mean that applications could do the service negotiations, > > > > and pass this info to NSIS. > > > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > > classes. > > > > > > > > John > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 04:47:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24672 for ; Fri, 15 Mar 2002 04:47:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03643 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 04:47:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02285; Fri, 15 Mar 2002 04:32:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02252 for ; Fri, 15 Mar 2002 04:32:43 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24427 for ; Fri, 15 Mar 2002 04:32:38 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 09:30:44 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA1C7@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , "'Freytsis, Ilya'" , "'nsis@ietf.org'" , "'schneider@tri.sbc.com'" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Fri, 15 Mar 2002 09:30:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Georgios, Please, let's not mix together the requirements and the solution at this stage! Soft state might be a (or even the) solution, but that doesn't make it a requirement! In fact, we have at least three independent state-related requirements to consider: 1) the fact that the application wants a bearer of a limited duration (and only wants to pay for this duration) - the end user might want quite precise timing control over this (for accounting reasons) 2) the need to clean up after a node dies or becomes disconnected from the network (in which case explicit release isn't possible) 3) the need to re-install state after path (route) changes (which might be managed by something routing-aware) Soft-state *can* solve all these, but in some scenarios it might be *very* hard to find a good compromise soft-state timer value considering all the effects. Also, in some scenarios (e.g. mobile) it might be better to address some of the problems (e.g. 3) in a different, specialised way. But in that case, it's helpful to have explicitly the requirement that there are other reasons for needing refresh or timeout or explicit release or whatever. Personally, I like Ilya's description of the situation. But we could make things less judgemental by saying "it must be possible for an initiator to control reservation reservation end times without requiring continuous signalling with the network" (or something); we can think later whether relying always on soft state or allowing explicit lifetimes is a better solution. I certainly don't see why explicit lifetimes are so hard. Robert H. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 15 March 2002 08:18 > To: 'Freytsis, Ilya'; 'nsis@ietf.org'; 'schneider@tri.sbc.com' > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Ilya > > I think that the issue that you are describing can be solved by > the soft state principle. > Anyway in my opinion the NSIS protocol MUST use the soft state > principle, otherwise we will have to invent very complex > functionalities that will solve all the problems that are solved by > the soft state principle. > > Best Regards, > Georgios > > > > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > Sent: vrijdag 15 maart 2002 4:57 > To: 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se'; > 'schneider@tri.sbc.com' > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > Let me present another argument in support of this requirement: > > It is possible that the host that made a reservation dies > "silently" without > releasing network resources allocated for its flow. This > requirement will > provide protection from the possible waste of resources in > this case. It is > definitely different from refreshing the soft state of the > reservation since > it is driven by the application not the network specifics and > applicable to > the hard reservations as well (and maybe even more important for hard > reservations). > To make this arrangement more flexible I think that ability to signal > life-time of a reservation (including permanent reservations) > should be > complemented by the ability to re-new the existing reservation. > I envision the following scenario: > The video endpoint (to stay on the same theme) is making a call. The > endpoint or may be proxy makes reservation request with 30 > min expected > life-time. Three options exist > 1. After 20 min the call is over and the endpoint (proxy) > releases allocated > resources. > 2. After 25 min the participants realize that they need > another 15 min to > finish discussion - the re-new reservation request is issued > with 15 min > life-time > 3. After 15 min the endpoints crashes. 15 min later the > network realize that > something is wrong and frees resources that were reserved for > this video > call. > > Does it make any sense? > > Ilya > > From: "Georgios Karagiannis (ELN)" > > To: "'Schneider, Marco'" , > "'Steven Berson'" > > Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > Date: Wed, 13 Mar 2002 13:43:32 +0100 > charset="iso-8859-1" > > Hi Marco > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. > > Best Regards, > Georgios > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: dinsdag 12 maart 2002 22:13 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > The point of the example is that the network may want to > limit the duration > that it grants for a session and thus its corresponding > resources (such as a > QOS connection). So in this case the network needs to be able > to revoke > resources upon the expiration of some time period. In > thinking about this > example I was wondering whether it would be useful to make duration an > explicit part of the reservation semantics. > > 1) A host requests from network a service of one hour > duration. For example > a video call to a friend. > 2) Above is realized via session negotiation that results in > token that is > passed back to the host. The token permits a QOS connection > of one hour > duration at 5 Mbps > 3) The host (QOS Initiator) includes the token in the NSIS > setup message > requesting a 5Mbps connection. > 4) The QOS Controller uses the token to validate the > reservation and allows > the setup to go through. > (See draft-ietf-sip-call-auth-0?.txt as well as > draft-ietf-rap-session-auth-0?.txt) > > Now what happens when one hour is up? Ideally the host releases the > resources but if the host does not the network will > (otherwise the user gets > more than they paid for). When the network releases the > resources there > should be a cause code that says your time was up or at the very least > indicates that this was due to service policy. > > Now my question is: given that the reservation is intended to be of a > precise duration should we make this explicit or is it better > for this to be > transparent? Is so why? > > Regarding Scalability, I do not understand your claim that > this is very > non-scalable. For every flow reservation the network > presumably will need to > store the amount reserved (at least one piece of > information). A reservation > duration requires one additional piece of information (at the > edge) that > does not propagate across the network. > > Best Regards, > Marco > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 05:00:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24980 for ; Fri, 15 Mar 2002 05:00:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05012 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 05:00:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03468; Fri, 15 Mar 2002 04:46:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03437 for ; Fri, 15 Mar 2002 04:46:36 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24637 for ; Fri, 15 Mar 2002 04:46:28 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA10824; Fri, 15 Mar 2002 10:45:44 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org Date: Fri, 15 Mar 2002 10:45:42 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 10:45:43 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA03438 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gabor, Thank you for your comments. See my comments to your comments inline, between and brackets Best regards Juan Carlos Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 15/03/2002 10:10:28 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Hi Juan-Carlos, I agree that some additional text in the Exclusion section can actually help to make the scope even more clear. Also, while I agree with the main point of your proposed text, we would probably need to iterate a bit more on excatly how this text could be best formulated. So please see my comments inline : > From Juan-Carlos.Rojas@alcatel.fr Fri Mar 15 08:58:45 2002 > From: Juan-Carlos.Rojas@alcatel.fr > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, > "'brunner@ccrle.nec.de'" > Cc: nsis@ietf.org > Date: Fri, 15 Mar 2002 08:58:36 +0100 > > Hello Gabor et al,, > > As the general agreement seems that NSIS be limited to the bearer level > only, and in order to avoid confusion in the future, I propose to add a new > point to the section "4.3 Exclusions", that could be phrased as follows: > > "Specific methods, protocols, and ways to express QoS information in the > Application/Session level are not considered (e.g., SDP, SIP, RTSP, etc.); OK > therefore when the NSIS protocol is used to reserve resources with QoS > constraints, it is assumed that the application/session level has already > been able to determine/negotiate the QoS requirements between the > end-users, for each requested bearer. This text actually assumes that the parties use application/session level signaling to negotiate QoS prior to NSIS signaling. While this is probably the typical case, NSIS should not be restricted to this model. End-parties will always agree on what to do, before doing it; but "application/session level" shall not be restricted to SIP; the application can be contacted just using your web browser and http, or even using a telephone call in case of long duration pipes reservation for e.g. corporate networks. Maybe this can be re-phrased as follows "..., it is assumed that end parties previously determined/negotiated the QoS expectations using methods that are out of the scope of the NSIS WG" > The specification of any extensions needed to signal QoS information via > application level protocols (e.g. SDP(ng)), and the mapping on NSIS > information are considered outside of the scope of NSIS working group, as > this work is in the direct scope of other IETF working groups (e.g. > MMUSIC)." Yes, I agree, but let me add the following. I agree that the mapping from e.g. the SDP parameters to NSIS bearer parameters are out of scope, but when determining the bearer classes and their associated paramaters, it seems necessary that we take into account what information is signalled at the SIP/SDP level. For instance, some SDP descriptors may contain explicit information about the voice codec (and its associated mime description) that is used in the session. This information can be useful to carry as a "local domain information" [Brunner draft 5.5, bullet 2)] in a wireless scenario, where the QI and the wireless link manager does not sit in the same node. There may be other such cases which we will need to discuss at a later stage (after the requirements doc). First of all, any SDP information has a full end-to-end meaning, that is from end-user to end-user (or host). The referenced section in Brunner draft is dealing with local information with local meaning only. It is not stated how you get/determine/negotiate this information, and this is normal as the semantics scope is limited to the access network, or more exactly, just before entering a QoS domain. Possible sources to obtain this local information can be SDP, but also local policies stored in local databases, user profiles, etc. Moreover, the term "bearer class" should be used very carefully, in order to avoid any restriction or constraint to the session/application level. BTW, what's a "bearer class" ? is it defined somewhere ? > > Comments ? > Best regards > Juan Carlos Regards /Gabor > > ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on > 15/03/2002 08:38 --------------------------- > > > Juan-Carlos ROJAS > 12/03/2002 13:58 > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, > "'brunner@ccrle.nec.de'" > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt (Document link: Listes > Discussion) > > Hi Gabor, > > OK, if this is a general agreement in the NSIS wg, it is not my intention > to go against the world. > It would be preferable if this is clearly written in the requirements > document: see e.g. section "4.3 Exclusions", the point 2 could be extended > in this way. > > Best regards > > Juan Carlos > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Hi Juan-Carlos, > > my answer to your question : > > > question I'm raising is more "Is in the context of NSIS to define ways of > > expressing QoS requirements also at the session level ?". > > would be "no", becuase in my understanding this WG focuses > on IP level QoS signaling mechanisms. > > However, I agree with you when you say that : > > > ... what will be agreed at the session/application > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > resource reservation complying with the QoS requirements. The most > > Therefore, it is important that we carefully select the bearer level > paramaters ("define the bearer service(s)"), when we reach that discussion. > To emphasize this, we could consider to add a requirement (at the > level of those in Section 5.1) that NSIS signaling should support > a wide range of media streams, or something more elaborated. > > /Gabor > > > > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > > Cc: nsis@ietf.org > > Date: Mon, 11 Mar 2002 17:17:03 +0100 > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > |June 18, 2001) at > > 03/11/2002 17:17:04 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > id LAA27058 > > X-Mailman-Version: 1.0 > > List-Id: Next Steps in Signaling > > X-BeenThere: nsis@ietf.org > > > > > > Hi Gabor, > > > > No major problem with this. > > You are right when saying that "There are already mechanisms that allow > > coordination between the session layer and the bearer (IP) layer"; > however, > > there is no standardized way to exchange and negotiate QoS information at > > session level (we are currently proposing SDP extensions for that). > > I'm not asking to define "how parties make service agreements", but the > > question I'm raising is more "Is in the context of NSIS to define ways of > > expressing QoS requirements also at the session level ?". > > The main purpose is that what will be agreed at the session/application > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > resource reservation complying with the QoS requirements. The most > > straight-forward will be the translation, the less error-prone will be > the > > implementation. > > And for sure, at the end, the QoS information should allow a mapping on > > different QoS technologies. > > > > Otherwise, I fully agree with you, we are currently specifying > > requirements, the definition work will come later. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Juan-Carlos, > > > > in this respect I fully support one view that was expressed > > in a previous mail on this list, which formulated a requirement > > that the [NSIS QoS signaling] architecture must be completely > > agnostic as to how parties make service agreements. That is, > > the service advertisement shoud be handled at the application > > level. > > > > There are already mechanisms that allow coordination between the > > session layer and the bearer (IP) layer, including the notion > > of pre-conditions in SIP. > > > > However, I view it as an important requirement that > > "the information exchanged over the signaling protocol > > must be in such detail and quantity > > that it is useful for various QoS technologies" > > [draft-brunner-nsis..., Section 5.1]. > > > > Of course, this "level of detail and quantity" > > should support various applications without requiring from > > application programmers that complex and qualitative parameters > > should be set. Therefore, we have a challange to define such > > paramater set(s) at the IP level that help various underlying > > QoS technologies to provide QoS and are "application programmer > > friendly". Such sets allow parties to configure their QoS parameters > > after negotiating a service at the application layer. > > (This definition work is of course left after the requirements > > discussion.) > > > > /Gabor > > > > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > > From: Juan-Carlos.Rojas@alcatel.fr > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > To: "Geib, Ruediger" > > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > > , > > > nsis@ietf.org > > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > |June 18, 2001) at > > > 03/11/2002 15:50:51 > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 8bit > > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > > id JAA21126 > > > X-Mailman-Version: 1.0 > > > List-Id: Next Steps in Signaling > > > X-BeenThere: nsis@ietf.org > > > > > > > > > Hi all, > > > > > > There is a general agreement that NSIS should not define services > > > (applications); I fully support this view. > > > However, a QoS signalling protocol should provide the necessary > > mechanisms > > > to allow applications to define, exchange, negotiate QoS > characteristics. > > > This seems to me a fondamental question: if we agree that in the NGN > > > providers will sell services and not only some transport capacity, then > > the > > > QoS story cannot be considered anymore as only a matter of bearer > > handling, > > > you need to have a global view including the session layer (e.g. > SIP/SDP) > > > and the applications. > > > Next, it should be up to the involved actors to define a common > agreement > > > on the service that is to be provided. > > > My feeling is that this is fully inline with the IETF philosophy: > define > > > basic mechanisms, and next, allow the actors to build services on top > of > > > basic mechanisms. > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > > 11:40:03 > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > Hi John, > > > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now). > > The > > > first requirement may be reworded to clarify that NSIS does not define > > the > > > service (I'm neither a native speaker nor a legal expert, so I'm not > sure > > > whether your suggestion does so). > > > NSIS then MAY be the IETF WG to collect, check and administrate the > > service > > > description coded according to NSIS rules? If you don't know the answer > > we > > > could have a look on the RTP spec's. Also they support a mechanism > > offering > > > a signaling framework which may be (and is) filled by later individual > > > specifications. > > > > > > Regards, Rüdiger > > > > > > > > > > > NSIS must support a flexible service definition not > > > > > restricting contents and meaning of individual service > > > > > descriptions. Services may either be private or public. > > > > > > > > Would these requirements be OK? > > > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > > > NSIS MAY consider support for service descriptions developed > > > > by other SDOs. > > > > > > > > This would mean that applications could do the service negotiations, > > > > and pass this info to NSIS. > > > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > > classes. > > > > > > > > John > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 05:18:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25371 for ; Fri, 15 Mar 2002 05:18:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA06850 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 05:18:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05981; Fri, 15 Mar 2002 05:07:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05905 for ; Fri, 15 Mar 2002 05:07:54 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25127 for ; Fri, 15 Mar 2002 05:07:50 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2FA7cUw000646; Fri, 15 Mar 2002 11:07:39 +0100 (MET) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA19171; Fri, 15 Mar 2002 11:07:38 +0100 From: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Received: by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id LAA04326; Fri, 15 Mar 2002 11:07:37 +0100 (MET) Date: Fri, 15 Mar 2002 11:07:37 +0100 (MET) Message-Id: <200203151007.LAA04326@wrtw014.wrn.ki.sw.ericsson.se> To: Juan-Carlos.Rojas@alcatel.fr Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org X-Sun-Charset: ISO-8859-1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Juan-Carlos, > Maybe this can be re-phrased as follows "..., it is assumed that end > parties previously determined/negotiated the QoS expectations using methods > that are out of the scope of the NSIS WG" Yes, I agree with this formulation. > First of all, any SDP information has a full end-to-end meaning, that > is from end-user to end-user (or host). > The referenced section in Brunner draft is dealing with local information > with local meaning only. It is not stated how you get/determine/negotiate > this information, and this is normal as the semantics scope is limited to > the access network, or more exactly, just before entering a QoS domain. > Possible sources to obtain this local information can be SDP, but also > local policies stored in local databases, user profiles, etc. Yes, exactly. The SDP info may very well have end-to-end relevance at the session level, but that does not mean that any information that is mapped from it to some NSIS parameter set also needs to be carried end-to-end at the _bearer level_. But some pieces of information that is carried end-to-end at the session level (e.g. quite explicit information about a voice codec in form of mime) may be useful at the bearer level as well (as a local info). Outside of that domain this level of detail at the bearer level is not needed: in an edge-to-edge segment for instance, maybe a peak rate is quite enough. > Moreover, the term "bearer class" should be used very carefully, in order > to avoid any restriction or constraint to the session/application level. > BTW, what's a "bearer class" ? is it defined somewhere ? > Probably there is no formal definition, for the sake of this discussion I was using the terms "bearer (service)" and "bearer class" to designate a L3 service. In this sense, you can consider e.g. the controlled intergated service as a "bearer" service. I am happy to use other terminology as long as we agree on the meaning of it. /Gabor > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 15/03/2002 10:10:28 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > > Hi Juan-Carlos, > > I agree that some additional text in the Exclusion > section can actually help to make the scope even more clear. > Also, while I agree with the main point of your proposed text, > we would probably need to iterate a bit more on excatly how > this text could be best formulated. > > So please see my comments inline : > > > > From Juan-Carlos.Rojas@alcatel.fr Fri Mar 15 08:58:45 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, > > "'brunner@ccrle.nec.de'" > > Cc: nsis@ietf.org > > Date: Fri, 15 Mar 2002 08:58:36 +0100 > > > > Hello Gabor et al,, > > > > As the general agreement seems that NSIS be limited to the bearer level > > only, and in order to avoid confusion in the future, I propose to add a > new > > point to the section "4.3 Exclusions", that could be phrased as follows: > > > > "Specific methods, protocols, and ways to express QoS information in the > > Application/Session level are not considered (e.g., SDP, SIP, RTSP, > etc.); > OK > > > therefore when the NSIS protocol is used to reserve resources with QoS > > constraints, it is assumed that the application/session level has already > > been able to determine/negotiate the QoS requirements between the > > end-users, for each requested bearer. > This text actually assumes that the parties use application/session > level signaling to negotiate QoS prior to NSIS signaling. > While this is probably the typical case, > NSIS should not be restricted to this model. > > End-parties will always agree on what to do, before doing it; but > "application/session level" shall not be restricted to SIP; the application > can be contacted just using your web browser and http, or even using a > telephone call in case of long duration pipes reservation for e.g. > corporate networks. > Maybe this can be re-phrased as follows "..., it is assumed that end > parties previously determined/negotiated the QoS expectations using methods > that are out of the scope of the NSIS WG" > > > The specification of any extensions needed to signal QoS information via > > application level protocols (e.g. SDP(ng)), and the mapping on NSIS > > information are considered outside of the scope of NSIS working group, as > > this work is in the direct scope of other IETF working groups (e.g. > > MMUSIC)." > Yes, I agree, but let me add the following. > > I agree that the mapping from e.g. the SDP parameters to NSIS bearer > parameters > are out of scope, but when determining the bearer classes and their > associated > paramaters, it seems necessary that we take into account what information > is > signalled at the SIP/SDP level. > > For instance, some SDP descriptors may contain explicit information about > the voice codec (and its associated mime description) that is used > in the session. This information can be useful to carry as a "local domain > information" [Brunner draft 5.5, bullet 2)] in a wireless scenario, > where the QI and the wireless link manager does not sit in the same node. > There may be other such cases which we will need to discuss at a later > stage > (after the requirements doc). > > First of all, any SDP information has a full end-to-end meaning, that > is from end-user to end-user (or host). > The referenced section in Brunner draft is dealing with local information > with local meaning only. It is not stated how you get/determine/negotiate > this information, and this is normal as the semantics scope is limited to > the access network, or more exactly, just before entering a QoS domain. > Possible sources to obtain this local information can be SDP, but also > local policies stored in local databases, user profiles, etc. > Moreover, the term "bearer class" should be used very carefully, in order > to avoid any restriction or constraint to the session/application level. > BTW, what's a "bearer class" ? is it defined somewhere ? > > > > > > Comments ? > > Best regards > > Juan Carlos > > Regards /Gabor > > > > > ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on > > 15/03/2002 08:38 --------------------------- > > > > > > Juan-Carlos ROJAS > > 12/03/2002 13:58 > > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), > john.loughney@nokia.com, > > "'brunner@ccrle.nec.de'" > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt (Document link: > Listes > > Discussion) > > > > Hi Gabor, > > > > OK, if this is a general agreement in the NSIS wg, it is not my intention > > to go against the world. > > It would be preferable if this is clearly written in the requirements > > document: see e.g. section "4.3 Exclusions", the point 2 could be > extended > > in this way. > > > > Best regards > > > > Juan Carlos > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Hi Juan-Carlos, > > > > my answer to your question : > > > > > question I'm raising is more "Is in the context of NSIS to define ways > of > > > expressing QoS requirements also at the session level ?". > > > > would be "no", becuase in my understanding this WG focuses > > on IP level QoS signaling mechanisms. > > > > However, I agree with you when you say that : > > > > > ... what will be agreed at the session/application > > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > > resource reservation complying with the QoS requirements. The most > > > > Therefore, it is important that we carefully select the bearer level > > paramaters ("define the bearer service(s)"), when we reach that > discussion. > > To emphasize this, we could consider to add a requirement (at the > > level of those in Section 5.1) that NSIS signaling should support > > a wide range of media streams, or something more elaborated. > > > > /Gabor > > > > > > > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > > > From: Juan-Carlos.Rojas@alcatel.fr > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > > > Cc: nsis@ietf.org > > > Date: Mon, 11 Mar 2002 17:17:03 +0100 > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > |June 18, 2001) at > > > 03/11/2002 17:17:04 > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 8bit > > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > > id LAA27058 > > > X-Mailman-Version: 1.0 > > > List-Id: Next Steps in Signaling > > > X-BeenThere: nsis@ietf.org > > > > > > > > > Hi Gabor, > > > > > > No major problem with this. > > > You are right when saying that "There are already mechanisms that allow > > > coordination between the session layer and the bearer (IP) layer"; > > however, > > > there is no standardized way to exchange and negotiate QoS information > at > > > session level (we are currently proposing SDP extensions for that). > > > I'm not asking to define "how parties make service agreements", but the > > > question I'm raising is more "Is in the context of NSIS to define ways > of > > > expressing QoS requirements also at the session level ?". > > > The main purpose is that what will be agreed at the session/application > > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > > resource reservation complying with the QoS requirements. The most > > > straight-forward will be the translation, the less error-prone will be > > the > > > implementation. > > > And for sure, at the end, the QoS information should allow a mapping on > > > different QoS technologies. > > > > > > Otherwise, I fully agree with you, we are currently specifying > > > requirements, the definition work will come later. > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > Juan-Carlos, > > > > > > in this respect I fully support one view that was expressed > > > in a previous mail on this list, which formulated a requirement > > > that the [NSIS QoS signaling] architecture must be completely > > > agnostic as to how parties make service agreements. That is, > > > the service advertisement shoud be handled at the application > > > level. > > > > > > There are already mechanisms that allow coordination between the > > > session layer and the bearer (IP) layer, including the notion > > > of pre-conditions in SIP. > > > > > > However, I view it as an important requirement that > > > "the information exchanged over the signaling protocol > > > must be in such detail and quantity > > > that it is useful for various QoS technologies" > > > [draft-brunner-nsis..., Section 5.1]. > > > > > > Of course, this "level of detail and quantity" > > > should support various applications without requiring from > > > application programmers that complex and qualitative parameters > > > should be set. Therefore, we have a challange to define such > > > paramater set(s) at the IP level that help various underlying > > > QoS technologies to provide QoS and are "application programmer > > > friendly". Such sets allow parties to configure their QoS parameters > > > after negotiating a service at the application layer. > > > (This definition work is of course left after the requirements > > > discussion.) > > > > > > /Gabor > > > > > > > > > > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > To: "Geib, Ruediger" > > > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > > > , > > > > nsis@ietf.org > > > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > > |June 18, 2001) at > > > > 03/11/2002 15:50:51 > > > > MIME-Version: 1.0 > > > > Content-Transfer-Encoding: 8bit > > > > X-MIME-Autoconverted: from quoted-printable to 8bit by > optimus.ietf.org > > > id JAA21126 > > > > X-Mailman-Version: 1.0 > > > > List-Id: Next Steps in Signaling > > > > X-BeenThere: nsis@ietf.org > > > > > > > > > > > > Hi all, > > > > > > > > There is a general agreement that NSIS should not define services > > > > (applications); I fully support this view. > > > > However, a QoS signalling protocol should provide the necessary > > > mechanisms > > > > to allow applications to define, exchange, negotiate QoS > > characteristics. > > > > This seems to me a fondamental question: if we agree that in the NGN > > > > providers will sell services and not only some transport capacity, > then > > > the > > > > QoS story cannot be considered anymore as only a matter of bearer > > > handling, > > > > you need to have a global view including the session layer (e.g. > > SIP/SDP) > > > > and the applications. > > > > Next, it should be up to the involved actors to define a common > > agreement > > > > on the service that is to be provided. > > > > My feeling is that this is fully inline with the IETF philosophy: > > define > > > > basic mechanisms, and next, allow the actors to build services on top > > of > > > > basic mechanisms. > > > > > > > > Best regards > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > > > 11:40:03 > > > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > > > > > cc: nsis@ietf.org > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > > > > Hi John, > > > > > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for > now). > > > The > > > > first requirement may be reworded to clarify that NSIS does not > define > > > the > > > > service (I'm neither a native speaker nor a legal expert, so I'm not > > sure > > > > whether your suggestion does so). > > > > NSIS then MAY be the IETF WG to collect, check and administrate the > > > service > > > > description coded according to NSIS rules? If you don't know the > answer > > > we > > > > could have a look on the RTP spec's. Also they support a mechanism > > > offering > > > > a signaling framework which may be (and is) filled by later > individual > > > > specifications. > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > > NSIS must support a flexible service definition not > > > > > > restricting contents and meaning of individual service > > > > > > descriptions. Services may either be private or public. > > > > > > > > > > Would these requirements be OK? > > > > > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > > > > > NSIS MAY consider support for service descriptions developed > > > > > by other SDOs. > > > > > > > > > > This would mean that applications could do the service > negotiations, > > > > > and pass this info to NSIS. > > > > > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > > > classes. > > > > > > > > > > John > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 05:46:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25860 for ; Fri, 15 Mar 2002 05:46:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09466 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 05:46:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08438; Fri, 15 Mar 2002 05:33:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08376 for ; Fri, 15 Mar 2002 05:33:21 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25679 for ; Fri, 15 Mar 2002 05:33:16 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g2FAXId08424; Fri, 15 Mar 2002 11:33:18 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id g2FAXIg22533; Fri, 15 Mar 2002 11:33:18 +0100 (MET) From: "Hannes Tschofenig" To: , Subject: RE: [NSIS] An NSIS requirement with backing scenario Date: Fri, 15 Mar 2002 11:35:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09D5_01C1CC15.90C28050" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_09D5_01C1CC15.90C28050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi hemant! please see my comments below. -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com Sent: Thursday, March 14, 2002 4:10 PM To: nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario Hi Hannes: Please see some comments below. -----Original Message----- From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Wednesday, March 13, 2002 4:56 AM To: Chaskar Hemant (NRC/Boston); nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario hi hemant! > Hi: > I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that > motivates such explicit requirement. I would like to know if WG deems this as an important issue. > "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". i like this requirement. it think that it is a good idea to have this requirement. but: i think it is already covered with: 5.8.2 The QoS protocol must provide means to authorize resource requests 5.10.5 The QoS protocol should provide hooks for AAA protocols [HC] I think that only stating such requirements may not suffice. The document should elaborate on them and also give some exemplary scenarios. That helps to indicate where the deep waters are. [ht] i agree with you that sample scenarios are a helpful for avoiding traps and to get more insights. however consider that it is definitely difficult to cover all possible variations and ideas people have in mind for accounting. if you have some more ideas for scenarios please let me know and thank you for the scenario given in your previous mail. appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging as indicated below. there have been a number of papers describing different solutions but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference next week. [HC] Can you construct any more scenarios from those papers that may be relevant for such requirement? It will be good to know as many scenarios as possible before going into the solution phase. [ht] there will be future version of the requirements document. i will incorporate your suggestions into the next version. however it may also possible that these scenarios fit much better in a framework document. to your scenario below: just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for the reservation. [HC] Yes, that is right. if A is not willing to provide credentials then there is obvioulsy a problem but a could provide credentials without concerns about security. it only depends how these "credentials" look like. from my point of view this information should be exchanged before the actual qos reservation takes place since it is an application issue. hence the information should already be available at the qos-reservation start-up. > ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. > Note that N_B cannot bill A directly. there has to be some agreement between providers otherwise this exchange will not work. > (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. > (This part has to be addressed by SIP and SDPng). i agree with you. > (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. > This is the requirement that needs to be included in NSIS requirements document. this is true. first, the qos signaling messages must be authenticated, integrity and replay protected. second, the qos protocol should be able to transport information exchanged with protocols executed before the qos protocol is triggered. [HC] Issues such as these will affect NSIS protocol design. That is the main message I would like to convey via this requirement/scenario. [ht] i again agree with you. but i think that these issues are already covered with the current requirements for interaction with other protocols (for example aaa) and with the requirment for extensibility. This is true Regards, Hemant ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com Sent: Tuesday, March 12, 2002 4:55 PM To: nsis@ietf.org Subject: [NSIS] An NSIS requirement with backing scenario Hi: I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue. "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". Scenario: ----------- A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling. For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly. The following things need to happen to make this call through. (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng). (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document. BR, Hemant ------=_NextPart_000_09D5_01C1CC15.90C28050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi hemant!

please see my comments below.

-----Original Message-----  
From:=20 nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of=20 Hemant.Chaskar@nokia.com
Sent: Thursday, March 14, 2002 = 4:10=20 PM
To: nsis@ietf.org
Subject: RE: [NSIS] An NSIS=20 requirement with backing scenario
  
Hi=20 Hannes:
 
Please see some comments = below.
 
 
-----Original Message-----
From: ext Hannes = Tschofenig=20 [mailto:Hannes.Tschofenig@mchp.siemens.de]
Sent: Wednesday, = March=20 13, 2002 4:56 AM
To: Chaskar Hemant (NRC/Boston);=20 nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with = backing=20 scenario

hi hemant!

> Hi:

> I would like to = place the=20 following requirement on table for discussion in WG. I have also = provided a=20 scenario below that

> motivates such = explicit=20 requirement. I would like to know if WG deems this as an important=20 issue.

> "QoS signaling = protocol MUST=20 interwork with AAA for QoS authorization and accounting = purposes".

i like this = requirement. it think=20 that it is a good idea to have this requirement.

but: i think it is = already covered=20 with:

5.8.2 The QoS protocol = must provide=20 means to authorize resource requests

5.10.5 The = QoS protocol=20 should provide hooks for AAA protocols 

 

[HC] I think that only = stating such=20 requirements may not suffice. The document should elaborate on them = and also=20 give some exemplary scenarios. That helps to indicate where the deep = waters=20 are.

 

[ht] i agree with you that sample scenarios are a helpful for = avoiding=20 traps and to get more insights. however consider that it is definitely = difficult to cover all possible variations and ideas people have in = mind for=20 accounting. if you have some more ideas for scenarios please let me = know and=20 thank you for the scenario given in your previous mail.=20

 

appart from the = requirements for an=20 interaction with AAA there are still open issues regarding=20 billing/payment/charging

as indicated below. = there have been a=20 number of papers describing = different=20 solutions

but i do not know a = satisfiable one. maybe we can discuss some of = the issues=20 at the ietf conference

next week. 

 

[HC] Can you construct any more scenarios from those = papers that=20 may be relevant for such requirement? It will be good to know as many=20 scenarios as possible before going into the solution=20 phase.

   

[ht] there will be future version of the requirements document. i = will=20 incorporate your suggestions into the next version. however it may = also=20 possible that these scenarios fit much better in a framework document. =

 

to your scenario below: =

just to make sure: the main problem = seems to=20 be that user B has to give "something" to network N_B telling that = user A is=20 paying for

the=20 reservation.  

 

[HC] Yes, that is=20 right. 

 

if A is not willing to = provide=20 credentials then there is obvioulsy a problem but

a could provide = credentials without=20 concerns about security. it only depends how these "credentials" look = like.=20

from my point of view = this=20 information should be exchanged before the actual qos reservation = takes place=20 since it

is an application = issue. hence the=20 information should already be available at the qos-reservation = start-up.=20

> ii) If A and N_B = are in=20 different jurisdiction, whatever credentials A has to provide may not = satisfy=20 N_B.

> Note that N_B = cannot bill A=20 directly.

there has to be some = agreement=20 between providers otherwise this exchange will not work.

 

> (i) SIP has to = convey "intent"=20 of A to pay for the call to B. A may also expect in return the B's = cost of=20 access at N_B.

> (This part has to = be addressed=20 by SIP and SDPng).

i agree with you. =

> (ii) NSIS = signaling needs to=20 interwork with AAA so that it can reserve and bill for QoS resources = in N_B.=20

> This is the = requirement that=20 needs to be included in NSIS requirements document.

this is true. =

first, the qos = signaling messages=20 must be authenticated, integrity and replay protected.

second, the qos = protocol should be=20 able to transport information exchanged with protocols executed before = the=20

qos protocol is = triggered. 

 

[HC] Issues such as these will = affect NSIS=20 protocol design. That is the main message I would like to convey via = this=20 requirement/scenario. 

&nbs= p;

[ht] i  again agree with you. but i think = that these=20 issues are already covered with the current requirements for = interaction with=20 other protocols (for example aaa) and with the requirment for = extensibility.=20

This=20 is true 

Regards, Hemant

 

ciao

hannes

-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of=20 Hemant.Chaskar@nokia.com
Sent: Tuesday, March 12, 2002 = 4:55=20 PM
To: nsis@ietf.org
Subject: [NSIS] An NSIS = requirement=20 with backing scenario

Hi:
 
I = would like to=20 place the following requirement on table for discussion in WG. I = have also=20 provided a scenario below that motivates such=20 explicit requirement. I would like to know if WG = deems this as an important=20 issue.
 
"QoS signaling protocol MUST = interwork=20 with AAA for QoS authorization and accounting=20 purposes".
 
Scenario:
-----------
 
A = and B are=20 connected to the Internet on the two sides of the globe. A places = call to B,=20 and (say during SIP transactions) intimates to B that A will pay for = the=20 call. Paying for the call also means paying for QoS of the = corresponding=20 packet transport. B accepts A's proposal. The call happens to be=20 of bidirectional traffic type. 
 
A = sends signal=20 to its access network N_A asking it to give certain QoS to = packet=20 stream from A -> B. A is a subscribed customer of N_A, so there = are no=20 apparent difficulties for N_A in checking A's credentials and = in=20 billing A. Also, network N_A may then take appropriate means to = guarantee end-to-end QoS, may be based on SLAs with other providers = and may=20 be using some NSIS signaling.
 
For the packet=20 path from B -> A, A does not know apriori as to how the path = looks like.=20 So, the QoS establishment for this path needs to be initiated from = B's side.=20 Now, B is not paying for QoS in its own access network N_B. Since, A = has=20 agreed to pay, A needs to provide some credentials to B which would = be=20 acceptable to N_B. There are two problems encountered here: i) = Though A has=20 agreed to pay, A may not be willing to provide credentials to end = host B for=20 security reasons, ii) If A and N_B are in different jurisdiction, = whatever=20 credentials A has to provide may not satisfy N_B. Note that N_B = cannot bill=20 A directly.
 
The following things need to = happen to make=20 this call through.
 
(i) SIP has to convey "intent" of A = to pay for=20 the call to B. A may also expect in return the B's cost of access at = N_B.=20 (This part has to be addressed by SIP and = SDPng).
 
(ii)  NSIS signaling needs to = interwork with=20 AAA so that it can reserve and bill for QoS resources in N_B. This = is the=20 requirement that needs to be included in NSIS requirements=20 document.
 
BR,
Hemant
------=_NextPart_000_09D5_01C1CC15.90C28050-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 05:53:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25965 for ; Fri, 15 Mar 2002 05:53:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09785 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 05:53:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09047; Fri, 15 Mar 2002 05:40:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08969 for ; Fri, 15 Mar 2002 05:40:34 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25774 for ; Fri, 15 Mar 2002 05:40:30 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA27561; Fri, 15 Mar 2002 11:39:25 +0100 (MET) Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org Date: Fri, 15 Mar 2002 11:37:43 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 11:39:25 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA08970 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gabor, Concerning the SDP story, I agree with you that not all the SDP information will be mapped to NSIS information, but surely all or almost all the SDP information *will be used by the application level* to derive the needed NSIS information. My understanding is that this is fully inline with my original proposal, that is "the mapping on NSIS information ... is out of the scope of the NSIS WG" Concerning the term "bearer class", I agree that maybe the term itself does not matter, providing that there is a clear agreed definition. Now I know what you were referring to; I don't love the usage of the word "class" in this context, because generally this means a group of things, entities, etc. having common characteristics, which is not the actual case. This is surely an issue in Brunner draft, where the expression "QoS Service Class" is defined as "specify the QoS requirements of a traffic flow or aggregate"; I fear that the word "class" is also very confusing here. As an example, this definition does not match the 3GPP definition of "QoS Class" (conversational, streaming, interactive and background). Best regards Juan Carlos Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 15/03/2002 11:07:37 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Hi Juan-Carlos, > Maybe this can be re-phrased as follows "..., it is assumed that end > parties previously determined/negotiated the QoS expectations using methods > that are out of the scope of the NSIS WG" Yes, I agree with this formulation. > First of all, any SDP information has a full end-to-end meaning, that > is from end-user to end-user (or host). > The referenced section in Brunner draft is dealing with local information > with local meaning only. It is not stated how you get/determine/negotiate > this information, and this is normal as the semantics scope is limited to > the access network, or more exactly, just before entering a QoS domain. > Possible sources to obtain this local information can be SDP, but also > local policies stored in local databases, user profiles, etc. Yes, exactly. The SDP info may very well have end-to-end relevance at the session level, but that does not mean that any information that is mapped from it to some NSIS parameter set also needs to be carried end-to-end at the _bearer level_. But some pieces of information that is carried end-to-end at the session level (e.g. quite explicit information about a voice codec in form of mime) may be useful at the bearer level as well (as a local info). Outside of that domain this level of detail at the bearer level is not needed: in an edge-to-edge segment for instance, maybe a peak rate is quite enough. > Moreover, the term "bearer class" should be used very carefully, in order > to avoid any restriction or constraint to the session/application level. > BTW, what's a "bearer class" ? is it defined somewhere ? > Probably there is no formal definition, for the sake of this discussion I was using the terms "bearer (service)" and "bearer class" to designate a L3 service. In this sense, you can consider e.g. the controlled intergated service as a "bearer" service. I am happy to use other terminology as long as we agree on the meaning of it. /Gabor > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 15/03/2002 10:10:28 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > > Hi Juan-Carlos, > > I agree that some additional text in the Exclusion > section can actually help to make the scope even more clear. > Also, while I agree with the main point of your proposed text, > we would probably need to iterate a bit more on excatly how > this text could be best formulated. > > So please see my comments inline : > > > > From Juan-Carlos.Rojas@alcatel.fr Fri Mar 15 08:58:45 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), john.loughney@nokia.com, > > "'brunner@ccrle.nec.de'" > > Cc: nsis@ietf.org > > Date: Fri, 15 Mar 2002 08:58:36 +0100 > > > > Hello Gabor et al,, > > > > As the general agreement seems that NSIS be limited to the bearer level > > only, and in order to avoid confusion in the future, I propose to add a > new > > point to the section "4.3 Exclusions", that could be phrased as follows: > > > > "Specific methods, protocols, and ways to express QoS information in the > > Application/Session level are not considered (e.g., SDP, SIP, RTSP, > etc.); > OK > > > therefore when the NSIS protocol is used to reserve resources with QoS > > constraints, it is assumed that the application/session level has already > > been able to determine/negotiate the QoS requirements between the > > end-users, for each requested bearer. > This text actually assumes that the parties use application/session > level signaling to negotiate QoS prior to NSIS signaling. > While this is probably the typical case, > NSIS should not be restricted to this model. > > End-parties will always agree on what to do, before doing it; but > "application/session level" shall not be restricted to SIP; the application > can be contacted just using your web browser and http, or even using a > telephone call in case of long duration pipes reservation for e.g. > corporate networks. > Maybe this can be re-phrased as follows "..., it is assumed that end > parties previously determined/negotiated the QoS expectations using methods > that are out of the scope of the NSIS WG" > > > The specification of any extensions needed to signal QoS information via > > application level protocols (e.g. SDP(ng)), and the mapping on NSIS > > information are considered outside of the scope of NSIS working group, as > > this work is in the direct scope of other IETF working groups (e.g. > > MMUSIC)." > Yes, I agree, but let me add the following. > > I agree that the mapping from e.g. the SDP parameters to NSIS bearer > parameters > are out of scope, but when determining the bearer classes and their > associated > paramaters, it seems necessary that we take into account what information > is > signalled at the SIP/SDP level. > > For instance, some SDP descriptors may contain explicit information about > the voice codec (and its associated mime description) that is used > in the session. This information can be useful to carry as a "local domain > information" [Brunner draft 5.5, bullet 2)] in a wireless scenario, > where the QI and the wireless link manager does not sit in the same node. > There may be other such cases which we will need to discuss at a later > stage > (after the requirements doc). > > First of all, any SDP information has a full end-to-end meaning, that > is from end-user to end-user (or host). > The referenced section in Brunner draft is dealing with local information > with local meaning only. It is not stated how you get/determine/negotiate > this information, and this is normal as the semantics scope is limited to > the access network, or more exactly, just before entering a QoS domain. > Possible sources to obtain this local information can be SDP, but also > local policies stored in local databases, user profiles, etc. > Moreover, the term "bearer class" should be used very carefully, in order > to avoid any restriction or constraint to the session/application level. > BTW, what's a "bearer class" ? is it defined somewhere ? > > > > > > Comments ? > > Best regards > > Juan Carlos > > Regards /Gabor > > > > > ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on > > 15/03/2002 08:38 --------------------------- > > > > > > Juan-Carlos ROJAS > > 12/03/2002 13:58 > > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), > john.loughney@nokia.com, > > "'brunner@ccrle.nec.de'" > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt (Document link: > Listes > > Discussion) > > > > Hi Gabor, > > > > OK, if this is a general agreement in the NSIS wg, it is not my intention > > to go against the world. > > It would be preferable if this is clearly written in the requirements > > document: see e.g. section "4.3 Exclusions", the point 2 could be > extended > > in this way. > > > > Best regards > > > > Juan Carlos > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Hi Juan-Carlos, > > > > my answer to your question : > > > > > question I'm raising is more "Is in the context of NSIS to define ways > of > > > expressing QoS requirements also at the session level ?". > > > > would be "no", becuase in my understanding this WG focuses > > on IP level QoS signaling mechanisms. > > > > However, I agree with you when you say that : > > > > > ... what will be agreed at the session/application > > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > > resource reservation complying with the QoS requirements. The most > > > > Therefore, it is important that we carefully select the bearer level > > paramaters ("define the bearer service(s)"), when we reach that > discussion. > > To emphasize this, we could consider to add a requirement (at the > > level of those in Section 5.1) that NSIS signaling should support > > a wide range of media streams, or something more elaborated. > > > > /Gabor > > > > > > > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > > > From: Juan-Carlos.Rojas@alcatel.fr > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > > > Cc: nsis@ietf.org > > > Date: Mon, 11 Mar 2002 17:17:03 +0100 > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > |June 18, 2001) at > > > 03/11/2002 17:17:04 > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 8bit > > > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org > > id LAA27058 > > > X-Mailman-Version: 1.0 > > > List-Id: Next Steps in Signaling > > > X-BeenThere: nsis@ietf.org > > > > > > > > > Hi Gabor, > > > > > > No major problem with this. > > > You are right when saying that "There are already mechanisms that allow > > > coordination between the session layer and the bearer (IP) layer"; > > however, > > > there is no standardized way to exchange and negotiate QoS information > at > > > session level (we are currently proposing SDP extensions for that). > > > I'm not asking to define "how parties make service agreements", but the > > > question I'm raising is more "Is in the context of NSIS to define ways > of > > > expressing QoS requirements also at the session level ?". > > > The main purpose is that what will be agreed at the session/application > > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > > resource reservation complying with the QoS requirements. The most > > > straight-forward will be the translation, the less error-prone will be > > the > > > implementation. > > > And for sure, at the end, the QoS information should allow a mapping on > > > different QoS technologies. > > > > > > Otherwise, I fully agree with you, we are currently specifying > > > requirements, the definition work will come later. > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > Juan-Carlos, > > > > > > in this respect I fully support one view that was expressed > > > in a previous mail on this list, which formulated a requirement > > > that the [NSIS QoS signaling] architecture must be completely > > > agnostic as to how parties make service agreements. That is, > > > the service advertisement shoud be handled at the application > > > level. > > > > > > There are already mechanisms that allow coordination between the > > > session layer and the bearer (IP) layer, including the notion > > > of pre-conditions in SIP. > > > > > > However, I view it as an important requirement that > > > "the information exchanged over the signaling protocol > > > must be in such detail and quantity > > > that it is useful for various QoS technologies" > > > [draft-brunner-nsis..., Section 5.1]. > > > > > > Of course, this "level of detail and quantity" > > > should support various applications without requiring from > > > application programmers that complex and qualitative parameters > > > should be set. Therefore, we have a challange to define such > > > paramater set(s) at the IP level that help various underlying > > > QoS technologies to provide QoS and are "application programmer > > > friendly". Such sets allow parties to configure their QoS parameters > > > after negotiating a service at the application layer. > > > (This definition work is of course left after the requirements > > > discussion.) > > > > > > /Gabor > > > > > > > > > > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > To: "Geib, Ruediger" > > > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > > > , > > > > nsis@ietf.org > > > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > > |June 18, 2001) at > > > > 03/11/2002 15:50:51 > > > > MIME-Version: 1.0 > > > > Content-Transfer-Encoding: 8bit > > > > X-MIME-Autoconverted: from quoted-printable to 8bit by > optimus.ietf.org > > > id JAA21126 > > > > X-Mailman-Version: 1.0 > > > > List-Id: Next Steps in Signaling > > > > X-BeenThere: nsis@ietf.org > > > > > > > > > > > > Hi all, > > > > > > > > There is a general agreement that NSIS should not define services > > > > (applications); I fully support this view. > > > > However, a QoS signalling protocol should provide the necessary > > > mechanisms > > > > to allow applications to define, exchange, negotiate QoS > > characteristics. > > > > This seems to me a fondamental question: if we agree that in the NGN > > > > providers will sell services and not only some transport capacity, > then > > > the > > > > QoS story cannot be considered anymore as only a matter of bearer > > > handling, > > > > you need to have a global view including the session layer (e.g. > > SIP/SDP) > > > > and the applications. > > > > Next, it should be up to the involved actors to define a common > > agreement > > > > on the service that is to be provided. > > > > My feeling is that this is fully inline with the IETF philosophy: > > define > > > > basic mechanisms, and next, allow the actors to build services on top > > of > > > > basic mechanisms. > > > > > > > > Best regards > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on 08/03/2002 > > > > 11:40:03 > > > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > > > > > cc: nsis@ietf.org > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > > > > Hi John, > > > > > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for > now). > > > The > > > > first requirement may be reworded to clarify that NSIS does not > define > > > the > > > > service (I'm neither a native speaker nor a legal expert, so I'm not > > sure > > > > whether your suggestion does so). > > > > NSIS then MAY be the IETF WG to collect, check and administrate the > > > service > > > > description coded according to NSIS rules? If you don't know the > answer > > > we > > > > could have a look on the RTP spec's. Also they support a mechanism > > > offering > > > > a signaling framework which may be (and is) filled by later > individual > > > > specifications. > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > > NSIS must support a flexible service definition not > > > > > > restricting contents and meaning of individual service > > > > > > descriptions. Services may either be private or public. > > > > > > > > > > Would these requirements be OK? > > > > > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > > > > > NSIS MAY consider support for service descriptions developed > > > > > by other SDOs. > > > > > > > > > > This would mean that applications could do the service > negotiations, > > > > > and pass this info to NSIS. > > > > > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > > > classes. > > > > > > > > > > John > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 06:20:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26400 for ; Fri, 15 Mar 2002 06:20:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11739 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 06:20:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10933; Fri, 15 Mar 2002 06:02:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10890 for ; Fri, 15 Mar 2002 06:02:13 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26158 for ; Fri, 15 Mar 2002 06:02:09 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2FB1GR02932; Fri, 15 Mar 2002 12:01:16 +0100 (MET) Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id MAA20735; Fri, 15 Mar 2002 12:01:16 +0100 From: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) Received: by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3) id MAA04989; Fri, 15 Mar 2002 12:01:15 +0100 (MET) Date: Fri, 15 Mar 2002 12:01:15 +0100 (MET) Message-Id: <200203151101.MAA04989@wrtw014.wrn.ki.sw.ericsson.se> To: Juan-Carlos.Rojas@alcatel.fr Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org X-Sun-Charset: ISO-8859-1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Juan-Carlos, > > Hi Gabor, > > Concerning the SDP story, I agree with you that not all the SDP information > will be mapped to NSIS information, but surely all or almost all the SDP > information *will be used by the application level* to derive the needed > NSIS information. Yes, I was discussing more the issue what info needs to be carried at the bearer level (which is a separate issue from what info is used to do the session-bearer mapping). > My understanding is that this is fully inline with my original proposal, > that is "the mapping on NSIS information ... is out of the scope of the > NSIS WG" Yes, that is fine. > > Concerning the term "bearer class", I agree that maybe the term itself does > not matter, providing that there is a clear agreed definition. Now I know > what you were referring to; I don't love the usage of the word "class" in > this context, because generally this means a group of things, entities, > etc. having common characteristics, which is not the actual case. > > This is surely an issue in Brunner draft, where the expression "QoS Service > Class" is defined as "specify the QoS requirements of a traffic flow or > aggregate"; I fear that the word "class" is also very confusing here. As an > example, this definition does not match the 3GPP definition of "QoS Class" > (conversational, streaming, interactive and background). > I am certainly open to use other terminologies as long as we agree to a common definition. > Best regards > Juan Carlos > Regards /Gabor > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 15/03/2002 11:07:37 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > > Hi Juan-Carlos, > > > Maybe this can be re-phrased as follows "..., it is assumed that end > > parties previously determined/negotiated the QoS expectations using > methods > > that are out of the scope of the NSIS WG" > Yes, I agree with this formulation. > > > First of all, any SDP information has a full end-to-end meaning, that > > is from end-user to end-user (or host). > > The referenced section in Brunner draft is dealing with local information > > with local meaning only. It is not stated how you get/determine/negotiate > > this information, and this is normal as the semantics scope is limited to > > the access network, or more exactly, just before entering a QoS domain. > > Possible sources to obtain this local information can be SDP, but also > > local policies stored in local databases, user profiles, etc. > Yes, exactly. The SDP info may very well have end-to-end relevance > at the session level, but that does not mean that any information that > is mapped from it to some NSIS parameter set also needs to be carried > end-to-end > at the _bearer level_. But some pieces of information that is carried > end-to-end at the session level (e.g. quite explicit information > about a voice codec in form of mime) may be useful at the bearer level as > well > (as a local info). Outside of that domain this level of detail > at the bearer level is not needed: in an edge-to-edge segment for instance, > maybe a peak rate is quite enough. > > > Moreover, the term "bearer class" should be used very carefully, in order > > to avoid any restriction or constraint to the session/application level. > > BTW, what's a "bearer class" ? is it defined somewhere ? > > > Probably there is no formal definition, for the sake of this discussion > I was using the terms "bearer (service)" and "bearer class" > to designate a L3 service. > In this sense, you can consider e.g. the controlled intergated service > as a "bearer" service. I am happy to use other terminology as long as > we agree on the meaning of it. > > /Gabor > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 15/03/2002 10:10:28 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > > > > > Hi Juan-Carlos, > > > > I agree that some additional text in the Exclusion > > section can actually help to make the scope even more clear. > > Also, while I agree with the main point of your proposed text, > > we would probably need to iterate a bit more on excatly how > > this text could be best formulated. > > > > So please see my comments inline : > > > > > > > From Juan-Carlos.Rojas@alcatel.fr Fri Mar 15 08:58:45 2002 > > > From: Juan-Carlos.Rojas@alcatel.fr > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), > john.loughney@nokia.com, > > > "'brunner@ccrle.nec.de'" > > > Cc: nsis@ietf.org > > > Date: Fri, 15 Mar 2002 08:58:36 +0100 > > > > > > Hello Gabor et al,, > > > > > > As the general agreement seems that NSIS be limited to the bearer level > > > only, and in order to avoid confusion in the future, I propose to add a > > new > > > point to the section "4.3 Exclusions", that could be phrased as > follows: > > > > > > "Specific methods, protocols, and ways to express QoS information in > the > > > Application/Session level are not considered (e.g., SDP, SIP, RTSP, > > etc.); > > OK > > > > > therefore when the NSIS protocol is used to reserve resources with QoS > > > constraints, it is assumed that the application/session level has > already > > > been able to determine/negotiate the QoS requirements between the > > > end-users, for each requested bearer. > > This text actually assumes that the parties use application/session > > level signaling to negotiate QoS prior to NSIS signaling. > > While this is probably the typical case, > > NSIS should not be restricted to this model. > > > > End-parties will always agree on what to do, before doing it; but > > "application/session level" shall not be restricted to SIP; the > application > > can be contacted just using your web browser and http, or even using a > > telephone call in case of long duration pipes reservation for e.g. > > corporate networks. > > Maybe this can be re-phrased as follows "..., it is assumed that end > > parties previously determined/negotiated the QoS expectations using > methods > > that are out of the scope of the NSIS WG" > > > > > The specification of any extensions needed to signal QoS information > via > > > application level protocols (e.g. SDP(ng)), and the mapping on NSIS > > > information are considered outside of the scope of NSIS working group, > as > > > this work is in the direct scope of other IETF working groups (e.g. > > > MMUSIC)." > > Yes, I agree, but let me add the following. > > > > I agree that the mapping from e.g. the SDP parameters to NSIS bearer > > parameters > > are out of scope, but when determining the bearer classes and their > > associated > > paramaters, it seems necessary that we take into account what information > > is > > signalled at the SIP/SDP level. > > > > For instance, some SDP descriptors may contain explicit information about > > the voice codec (and its associated mime description) that is used > > in the session. This information can be useful to carry as a "local > domain > > information" [Brunner draft 5.5, bullet 2)] in a wireless scenario, > > where the QI and the wireless link manager does not sit in the same node. > > There may be other such cases which we will need to discuss at a later > > stage > > (after the requirements doc). > > > > First of all, any SDP information has a full end-to-end meaning, that > > is from end-user to end-user (or host). > > The referenced section in Brunner draft is dealing with local information > > with local meaning only. It is not stated how you get/determine/negotiate > > this information, and this is normal as the semantics scope is limited to > > the access network, or more exactly, just before entering a QoS domain. > > Possible sources to obtain this local information can be SDP, but also > > local policies stored in local databases, user profiles, etc. > > Moreover, the term "bearer class" should be used very carefully, in order > > to avoid any restriction or constraint to the session/application level. > > BTW, what's a "bearer class" ? is it defined somewhere ? > > > > > > > > > > Comments ? > > > Best regards > > > Juan Carlos > > > > Regards /Gabor > > > > > > > > ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on > > > 15/03/2002 08:38 --------------------------- > > > > > > > > > Juan-Carlos ROJAS > > > 12/03/2002 13:58 > > > > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), > > john.loughney@nokia.com, > > > "'brunner@ccrle.nec.de'" > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt (Document link: > > Listes > > > Discussion) > > > > > > Hi Gabor, > > > > > > OK, if this is a general agreement in the NSIS wg, it is not my > intention > > > to go against the world. > > > It would be preferable if this is clearly written in the requirements > > > document: see e.g. section "4.3 Exclusions", the point 2 could be > > extended > > > in this way. > > > > > > Best regards > > > > > > Juan Carlos > > > > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 > > > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > Hi Juan-Carlos, > > > > > > my answer to your question : > > > > > > > question I'm raising is more "Is in the context of NSIS to define > ways > > of > > > > expressing QoS requirements also at the session level ?". > > > > > > would be "no", becuase in my understanding this WG focuses > > > on IP level QoS signaling mechanisms. > > > > > > However, I agree with you when you say that : > > > > > > > ... what will be agreed at the session/application > > > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > > > resource reservation complying with the QoS requirements. The most > > > > > > Therefore, it is important that we carefully select the bearer level > > > paramaters ("define the bearer service(s)"), when we reach that > > discussion. > > > To emphasize this, we could consider to add a requirement (at the > > > level of those in Section 5.1) that NSIS signaling should support > > > a wide range of media streams, or something more elaborated. > > > > > > /Gabor > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > > > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > > > > Cc: nsis@ietf.org > > > > Date: Mon, 11 Mar 2002 17:17:03 +0100 > > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 > > > |June 18, 2001) at > > > > 03/11/2002 17:17:04 > > > > MIME-Version: 1.0 > > > > Content-Transfer-Encoding: 8bit > > > > X-MIME-Autoconverted: from quoted-printable to 8bit by > optimus.ietf.org > > > id LAA27058 > > > > X-Mailman-Version: 1.0 > > > > List-Id: Next Steps in Signaling > > > > X-BeenThere: nsis@ietf.org > > > > > > > > > > > > Hi Gabor, > > > > > > > > No major problem with this. > > > > You are right when saying that "There are already mechanisms that > allow > > > > coordination between the session layer and the bearer (IP) layer"; > > > however, > > > > there is no standardized way to exchange and negotiate QoS > information > > at > > > > session level (we are currently proposing SDP extensions for that). > > > > I'm not asking to define "how parties make service agreements", but > the > > > > question I'm raising is more "Is in the context of NSIS to define > ways > > of > > > > expressing QoS requirements also at the session level ?". > > > > The main purpose is that what will be agreed at the > session/application > > > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > > > > resource reservation complying with the QoS requirements. The most > > > > straight-forward will be the translation, the less error-prone will > be > > > the > > > > implementation. > > > > And for sure, at the end, the QoS information should allow a mapping > on > > > > different QoS technologies. > > > > > > > > Otherwise, I fully agree with you, we are currently specifying > > > > requirements, the definition work will come later. > > > > > > > > Best regards > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > > > > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > > > cc: nsis@ietf.org > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > > > > Juan-Carlos, > > > > > > > > in this respect I fully support one view that was expressed > > > > in a previous mail on this list, which formulated a requirement > > > > that the [NSIS QoS signaling] architecture must be completely > > > > agnostic as to how parties make service agreements. That is, > > > > the service advertisement shoud be handled at the application > > > > level. > > > > > > > > There are already mechanisms that allow coordination between the > > > > session layer and the bearer (IP) layer, including the notion > > > > of pre-conditions in SIP. > > > > > > > > However, I view it as an important requirement that > > > > "the information exchanged over the signaling protocol > > > > must be in such detail and quantity > > > > that it is useful for various QoS technologies" > > > > [draft-brunner-nsis..., Section 5.1]. > > > > > > > > Of course, this "level of detail and quantity" > > > > should support various applications without requiring from > > > > application programmers that complex and qualitative parameters > > > > should be set. Therefore, we have a challange to define such > > > > paramater set(s) at the IP level that help various underlying > > > > QoS technologies to provide QoS and are "application programmer > > > > friendly". Such sets allow parties to configure their QoS parameters > > > > after negotiating a service at the application layer. > > > > (This definition work is of course left after the requirements > > > > discussion.) > > > > > > > > /Gabor > > > > > > > > > > > > > > > > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > > > > From: Juan-Carlos.Rojas@alcatel.fr > > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > To: "Geib, Ruediger" > > > > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > > > > , > > > > > nsis@ietf.org > > > > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > > > > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release > 5.0.8 > > > > |June 18, 2001) at > > > > > 03/11/2002 15:50:51 > > > > > MIME-Version: 1.0 > > > > > Content-Transfer-Encoding: 8bit > > > > > X-MIME-Autoconverted: from quoted-printable to 8bit by > > optimus.ietf.org > > > > id JAA21126 > > > > > X-Mailman-Version: 1.0 > > > > > List-Id: Next Steps in Signaling > > > > > X-BeenThere: nsis@ietf.org > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > There is a general agreement that NSIS should not define services > > > > > (applications); I fully support this view. > > > > > However, a QoS signalling protocol should provide the necessary > > > > mechanisms > > > > > to allow applications to define, exchange, negotiate QoS > > > characteristics. > > > > > This seems to me a fondamental question: if we agree that in the > NGN > > > > > providers will sell services and not only some transport capacity, > > then > > > > the > > > > > QoS story cannot be considered anymore as only a matter of bearer > > > > handling, > > > > > you need to have a global view including the session layer (e.g. > > > SIP/SDP) > > > > > and the applications. > > > > > Next, it should be up to the involved actors to define a common > > > agreement > > > > > on the service that is to be provided. > > > > > My feeling is that this is fully inline with the IETF philosophy: > > > define > > > > > basic mechanisms, and next, allow the actors to build services on > top > > > of > > > > > basic mechanisms. > > > > > > > > > > Best regards > > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Geib, Ruediger" @ietf.org on > 08/03/2002 > > > > > 11:40:03 > > > > > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > > > > > > > cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > > > > > > > Hi John, > > > > > > > > > > I'd appreciate if NSIS takes care of the issue (a MAY is fine for > > now). > > > > The > > > > > first requirement may be reworded to clarify that NSIS does not > > define > > > > the > > > > > service (I'm neither a native speaker nor a legal expert, so I'm > not > > > sure > > > > > whether your suggestion does so). > > > > > NSIS then MAY be the IETF WG to collect, check and administrate the > > > > service > > > > > description coded according to NSIS rules? If you don't know the > > answer > > > > we > > > > > could have a look on the RTP spec's. Also they support a mechanism > > > > offering > > > > > a signaling framework which may be (and is) filled by later > > individual > > > > > specifications. > > > > > > > > > > Regards, Rüdiger > > > > > > > > > > > > > > > > > NSIS must support a flexible service definition not > > > > > > > restricting contents and meaning of individual service > > > > > > > descriptions. Services may either be private or public. > > > > > > > > > > > > Would these requirements be OK? > > > > > > > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > > > > > > > NSIS MAY consider support for service descriptions developed > > > > > > by other SDOs. > > > > > > > > > > > > This would mean that applications could do the service > > negotiations, > > > > > > and pass this info to NSIS. > > > > > > > > > > > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS > > > > > > classes. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 06:25:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26479 for ; Fri, 15 Mar 2002 06:25:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11858 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 06:25:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11184; Fri, 15 Mar 2002 06:08:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11149 for ; Fri, 15 Mar 2002 06:08:49 -0500 (EST) Received: from vs.informatik.uni-ulm.de (vs.informatik.uni-ulm.de [134.60.77.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26255 for ; Fri, 15 Mar 2002 06:08:45 -0500 (EST) Received: from lamagra (lamagra.informatik.uni-ulm.de [134.60.77.31]) by vs.informatik.uni-ulm.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id g2FBBK028214; Fri, 15 Mar 2002 12:11:20 +0100 X-Authentication-Warning: vs.informatik.uni-ulm.de: Host lamagra.informatik.uni-ulm.de [134.60.77.31] claimed to be lamagra Message-ID: <001501c1cc1c$5371ebd0$1f4d3c86@informatik.uniulm.de> From: "Andreas Kassler" To: , "Gabor Fodor" Cc: , , References: Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Date: Fri, 15 Mar 2002 13:24:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Juan, > > Concerning the SDP story, I agree with you that not all the SDP information > will be mapped to NSIS information, but surely all or almost all the SDP > information *will be used by the application level* to derive the needed > NSIS information. I completely agree on this issue. It may be of interest for NSIS, that there is a draft related to SDPng that exactly describes requirements for that. It is draft-guenkova-mmusic-e2enp-sdpng-00.txt, that is available from: http://www-vs.informatik.uni-ulm.de/ietf/mmusic/sdp-ng/drafts/draft-guenkova -mmusic-e2enp-sdpng-00.txt The idea is to negotiate application level QoS parameters like frame rate, size, quality,.. and capabilties like codecs using SDPng and provide a set of potential QoS contracts at application/session level that can be used to describe alternative QoS parameters for a multimedia session. It is then the responsibility of a terminal to proceed with network ressource reservation (if it likes to do so) using e.g. NSIS. But the mapping from application level QoS to network related QoS parameters (like bandwidth, loss rate) should be out of the scope for NSIS. > My understanding is that this is fully inline with my original proposal, > that is "the mapping on NSIS information ... is out of the scope of the > NSIS WG" > > Concerning the term "bearer class", I agree that maybe the term itself does > not matter, providing that there is a clear agreed definition. Now I know > what you were referring to; I don't love the usage of the word "class" in > this context, because generally this means a group of things, entities, > etc. having common characteristics, which is not the actual case. > > This is surely an issue in Brunner draft, where the expression "QoS Service > Class" is defined as "specify the QoS requirements of a traffic flow or > aggregate"; I fear that the word "class" is also very confusing here. As an > example, this definition does not match the 3GPP definition of "QoS Class" > (conversational, streaming, interactive and background). > > Best regards > Juan Carlos > > > > Kind regards, Andreas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 07:40:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27514 for ; Fri, 15 Mar 2002 07:40:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16877 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 07:40:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16573; Fri, 15 Mar 2002 07:32:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16541 for ; Fri, 15 Mar 2002 07:32:24 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27395 for ; Fri, 15 Mar 2002 07:32:21 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA17751; Fri, 15 Mar 2002 13:30:59 +0100 (MET) Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions To: "Andreas Kassler" Cc: "Gabor Fodor" , , , Date: Fri, 15 Mar 2002 13:30:58 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 13:30:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Andreas, Yes, it is clear now that the session/application level negotiation of QoS related information is out of the scope of NSIS. I know the draft you are talking about, and there are also some other drafts concerning this subject in MMUSIC. So, in order to avoid to mix all debates, I propose to continue de discusion on the QoS question in the application level on the MMUSIC mailing list. Best regards Juan Carlos "Andreas Kassler" on 15/03/2002 13:24:17 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, "Gabor Fodor" cc: , , Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Hi Juan, > > Concerning the SDP story, I agree with you that not all the SDP information > will be mapped to NSIS information, but surely all or almost all the SDP > information *will be used by the application level* to derive the needed > NSIS information. I completely agree on this issue. It may be of interest for NSIS, that there is a draft related to SDPng that exactly describes requirements for that. It is draft-guenkova-mmusic-e2enp-sdpng-00.txt, that is available from: http://www-vs.informatik.uni-ulm.de/ietf/mmusic/sdp-ng/drafts/draft-guenkova -mmusic-e2enp-sdpng-00.txt The idea is to negotiate application level QoS parameters like frame rate, size, quality,.. and capabilties like codecs using SDPng and provide a set of potential QoS contracts at application/session level that can be used to describe alternative QoS parameters for a multimedia session. It is then the responsibility of a terminal to proceed with network ressource reservation (if it likes to do so) using e.g. NSIS. But the mapping from application level QoS to network related QoS parameters (like bandwidth, loss rate) should be out of the scope for NSIS. > My understanding is that this is fully inline with my original proposal, > that is "the mapping on NSIS information ... is out of the scope of the > NSIS WG" > > Concerning the term "bearer class", I agree that maybe the term itself does > not matter, providing that there is a clear agreed definition. Now I know > what you were referring to; I don't love the usage of the word "class" in > this context, because generally this means a group of things, entities, > etc. having common characteristics, which is not the actual case. > > This is surely an issue in Brunner draft, where the expression "QoS Service > Class" is defined as "specify the QoS requirements of a traffic flow or > aggregate"; I fear that the word "class" is also very confusing here. As an > example, this definition does not match the 3GPP definition of "QoS Class" > (conversational, streaming, interactive and background). > > Best regards > Juan Carlos > > > > Kind regards, Andreas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 09:28:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29710 for ; Fri, 15 Mar 2002 09:27:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25128 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 09:28:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24445; Fri, 15 Mar 2002 09:20:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24372 for ; Fri, 15 Mar 2002 09:20:42 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29401 for ; Fri, 15 Mar 2002 09:20:37 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA05333; Fri, 15 Mar 2002 15:17:01 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA10830; Fri, 15 Mar 2002 15:16:53 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 15:17:22 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A0126568F@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" , Kappler Cornelia Cc: nsis@ietf.org, maarten.buchli@alcatel.be, danny.goderis@alcatel.be, Hancock Robert Date: Fri, 15 Mar 2002 15:17:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] RE: section on QI/QC and QI/QC terminology Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven, what I dont understand yet is whether your QI/QC relationship Figure (describing basically a NSIS framework) is supposed to cover all scenarios in which NSIS signaling is applicable, or just is applicable to a subset, such as those described in your Req draft. I think you have in mind a general framework. In this case I have a different views of the NSIS scope / I find your framework too restrictive. Before embarking on a discussion on this though I'd like to doublecheck your intention? Cornelia > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, March 12, 2002 4:59 PM > To: Kappler Cornelia > Cc: nsis@ietf.org; maarten.buchli@alcatel.be; danny.goderis@alcatel.be; Hancock Robert > Subject: RE: section on QI/QC and QI/QC terminology > > Hi Cornelia, > > Thanks for your reply. I have some comments inline. > > Bye, > Sven. > > > > > > Kappler Cornelia on 12/03/2002 16:23:06 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, > nsis@ietf.org > > cc: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Danny > GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert > > > > > Subject RE: section on QI/QC and QI/QC terminology > : > > > > > > > Hi Sven, > > thank you for your detailed analysis. > > I agree with you the current definition of QI ("receives trigger from > _higher_ layer to start signaling") does run into problems for some > scenarios, such as in UMTS, where PDP context signaling (from a _lower_ > layer) is being translated into normal IP QoS signaling at the GGSN > (possibly via the P-CSCF). > > Your suggestion points a way for solving this problem (by offering an > alternative Def of QI, and also of QC and QR). However I have the following > comments (inline). Generally I'd like to modify your definitions somewhat > to lift unnecessary restrictions on protocol design and network structure > they seem to imply. I am not sure though whether my modifications dont run > into other problems :-) > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > [SMTP:sven.van_den_bosch@alcatel.be] > > Sent: Tuesday, March 05, 2002 2:31 PM > > To: nsis@ietf.org > > Cc: maarten.buchli@alcatel.be; danny.goderis@alcatel.be; > robert.hancock@roke.co.uk; cornelia.kappler@icn.siemens.de > > Subject: section on QI/QC and QI/QC terminology > > > > Hi, > > > > We have been thinking about the QI/QC definitions and we have tried to > > arrange the QC/QI functional entities in a logical relation that covers > the > > use case scenarios that have been proposed so far. From this, we hope to > > derive clearer definitions. > > > > The general logical relationships are depicted below (for simplicity, > only > > signaling relations are drawn) > > > > +--+ (a) +--+ (a) +--+ (a) +---+ > > +->|QI|---->|QC|---------------->|QC|---->| QR|--+ > > QI,QC,QR roles for e2e QoS protocol > > | +--+ /+--+\ /+--+\ +---+ | > > | / \ / \ v > > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+> > > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > > QI,QC,QR roles for local QoS protocol > > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > > > In this pictures we clearly distinguish two applications for the NSIS > > protocol: > > (a) NSIS as end-to-end QoS signaling protocol > > (b) NSIS as local QoS signaling protocol > > > The term "end2end QoS signaling protocol" I dont find entirely > fitting, since it seems to imply participation of end hosts. However, a > typical scenario we discuss is edge2edge signaling. What about "global QoS > signaling protocol"? > > Sven>> The picture has two layers of NSIS signaling: > - end-to-end NSIS signaling (where the QI and the QR are located at the > edge of the network). I don't think it completely maps to your edge-to-edge > scenario because that specifically talks about edges of domains. Here it is > really the edge of the network from the end-hosts point of view. > - NSIS as a local QoS signaling protocol. Note that between the end host > and the edge of the network, there is only NSIS signaling at this level. > This means that NSIS end-to-end does not require participation of the end > host. Even if the end host is an NSIS speaker, it will use NSIS as a local > QoS signaling protocol to get to the (top-level) QI where mapping will take > place and end-to-end signaling is initiated. > > Would e2e per-flow signaling - tunnelled through most of the network - > which might be necessary when no SIP-type e2e exchange of QoS took place, > be "local" NSIS signaling? Probably not. However when regarded as "global", > what about another signaling on top, signaling for aggregates? This is one > of the unnecessary restrictions / assumptions I see with your approach. > > Sven>> Setting up the aggregates is a local matter for each of the QCs. A > QC may choose to modify its aggregate based on incoming micro-flows but > this process will not be triggered by microflow arrivals. > > Your figure seems to imply global NSIS QoS signaling is always > triggered by end host signaling. However e.g. signaling for aggregates deep > in the backbone might only loosly be coupled to end host signaling. (You > may not have intended your figure as covering all possible scenarios) > > Sven>> Signaling for aggregates in the backbone is not triggered by the > NSIS end-to-end signaling. In fact, for this a local QoS technology is used > under the authority of the QC (via network management). This local > technology may exist or it may be another application of the local NSIS > signaling. > > > > Local, in this case, is defined as local to a QoS domain. A QoS domain is > > defined as a contiguous part of the network supporting the same QoS > > technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), > NSIS > > actually competes with other technologies offering local QoS, such as > PDP, > > RSVP, ... > > > ok. This maps my view. > > > The above picture seems to suggest an out-of-band approach but this is > not > > the case. The QCs can be implemented in a distributed way and redrawing > the > > picture then gives a different view. > > > > +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ > > |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| > > QI,QC,QR roles for e2e QoS protocol > > +--+ +--+ +--+ +--+ +--+ +--+> > > ^ v ^ v ^ v > > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ > > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > > QI,QC,QR roles for local QoS protocol > > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > > > In this case, it is clear that an in-band solution is also supported. The > > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on> > a > > r> outer. Note that in this picture, the signaling in the access is done > with > > a local QoS protocol. This can be either an existing protocol, or the > NSIS > > protocol in its role of local QoS signaling mechanism. This leads to the > > following requirements: > > > > (a) If an NSIS protocol is only used end-to-end, then mobility need not > be > > supported > > > This seems to already imply a design choice. Why would the "e2e" / > global NSIS protocol not also support mobility? In this case local > signaling support is not needed. > > ...In fact I dont have any particular oppinion on this subject. > However in my view some detailed analysis is necessary to decide whether > mobility support by a local protocol is always sufficient!? > > Sven>> I think mobility definitely needs to be supported in the local > protocol. When the (top-level) QI is a fixed point (joint point of > reservation) then the end-to-end (or top-level) signaling does not need to > support mobility. This relaxes some of the requirements which is a good > thing. I think that without loss of generality we can have this situation. > The only design impact this may have is when we want to use the same > protocol for local and global NSIS signaling. In this case we need to make > it modular so that a global QC only has to look at the information relevant > to him. This requirement was already identified. > > > (b) If an NSIS protocol is used as a local QoS signaling mechanism then > > mobility must be supported, both on the QI-QC and QC-QC interface > > > > (c) If the same protocol is desired in (a) and (b), the protocol should > be > > modular and the mobility aspects need to be separable from the rest > > > OK. > > > Both of the above scenarios assume that the host is not NSIS-aware. This > is > > a reasonable assumption in a first phase. In a later stage, when hosts > are > > NSIS-aware, the host speaks the NSIS protocol, but as a local QoS > signaling > > technology! This allows this case to be backwards compatible with the > above > > scenarios. It means that (b) in the access is an NSIS protocol. It also > > means that the host will always trigger the local QoS signaling > mechanism. > > > Why would the host never trigger the global NSIS protocol? > > Sven>> It doesn't need to. When he is an NSIS speaker he can initiate the > local NSIS protocol. At the global QI his requirement will then be mapped > into the e2e NSIS protocol. If he didn't have any requirements that can't > be offered be the global NSIS protocol he could theoretically initiate e2e > signaling. I don't think it is needed however. > > > This suggests the following definitions for the QI, QC, QR > > > > - QoS Initiator: Network entity, located at the boundary of a QoS domain, > > responsible for initiating a (local or end-to-end) QoS mechanism. If it > is > > the QI of a local protocol, it can be triggered by higher layers > > (applications or end-to-end QoS Controller). If it is the QI of an > > end-to-end protocol, it can be triggered by applications or by the QoS > > Receiver of a local QoS signaling mechanism. > > > These triggers make sense to me (although a QC isn't a higher layer, > is it?). However what about the following problem with this definition: In > an RSVP-like scenario, per-flow signaling is tunnelled through an > aggregation area (may be this is how the NSIS protocol is going to work, > too). The aggregating router initiating the tunnelling, would it be a QR > for the per-flow signaling? Not really, because the signalling is not > terminated.So it is a QC. But then the QI initiating the aggregation is > triggered by a QC. > > Sven>> In the definition, I mentioned application or end-to-end/global QC > as possible triggers. So maybe we should say that a QC on the client NSIS > layer (global) can trigger a QI on the server NSIS layer (local). Would > this solve the issue in you opinion?> > > May be we have to become very broad with the QI Def by sa> ying "network > entity initiating NSIS signaling, including an entity initiating one type > of NSIS signaling after terminating another type of NSIS signaling.In which > case it would also be a QR." > > Note I restrict QI to NSIS signaling because we dont need to worry > about other kinds of signaling except by providing hooks for integrating > it. With this Def the GGSN (P-CSCF) classifies as QI as well as an > aggregating entity. The "including" sentence I put in to provide for > interworking of local and global NSIS signaling e.g. at an NSIS proxy. > > Sven>> I fully agree: QI/QC only have a meaning in NSIS signaling. > > Another point: I'd rather not restrict the QI to be located on the > boundary of a QoS Domain: It may be a bandwidth broker, located anywhere in > a domain, it may be a end host (is the end host always located "at the > boundary" of a QoS domain?). What if there is a address boundary inside a > QoS domain? Would address translation involve re-initiating QoS signaling? > Plus there may be a number of reasons for not locating the QI at the > boundary. Locating the QI at the boundary or a QoS domain includes too many > asumption about the network structure. So my suggestion is dropping this > restriction. > > Sven>> OK. Maybe we should say: located at the boundary of an NSIS > signaling domain. > > > - QoS Controller: Network entity responsible for interpreting and > > implementing the signalled QoS in the network. Failure to do so implies > an > > admission control decision. It can only be triggered by a QI or another > QC. > > > > -QoS Receiver: Network entity, located at the boundary of a QoS domain, > > responsible for terminating a (local or end-to-end) QoS mechanism. It has > > the additional functionality that it may initiate an acknowledgment > towards > > the QI and that it may trigger a QI or QC in the NSIS end-to-end > protocol. > > > Again I have an issue with "located at the boundary..:". > > Looking forward to your comments > > Cornelia > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 16:35:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11117 for ; Fri, 15 Mar 2002 16:35:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27781 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 16:35:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27018; Fri, 15 Mar 2002 16:25:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26986 for ; Fri, 15 Mar 2002 16:25:29 -0500 (EST) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10810 for ; Fri, 15 Mar 2002 16:25:24 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <1GGAQ3RZ>; Fri, 15 Mar 2002 16:21:29 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE6633EDDE@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" Date: Fri, 15 Mar 2002 16:21:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comment on draft-nsis-req-00 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, all. While catching up with discussions on the list I've got impression the requirements to NSIS sometimes got mixed up with requirements to the entities that have to implement it. This mix-up can make our discussions at the IETF 53 less productive than it can be. One thing is to say that NSIS must allow to do X and the other - to say that the entity A must implement X. I think that the modality MUST is the only meaningful modality for the protocol requirements (what protocol will allow you to achieve). On the other hand requirements for the protocol implementation (what is supported and in what scenarios) by the various enteritis the difference between modalities MUST, SHOULD, MAY becomes very important and meaningful. I think that section 6 of the document should be re-worked from this perspective. Here are some comments to the requirement section (and discussions on the list): 5.1.7 - I have a hard time to understand this requirement and how it is derived from the motivation paragraph. I think it has to be re-worded and explained or removed. 5.1.8 - I think this requirement should be removed or completed with the list of technologies. Requirement 5.1.1 and 5.1.10 looks the same to me. What am I missing here? 5.5.4 - I agree with those who are saying that QoS requestor should not be concerned with the actions taken by the network if the "contract" between requestor and the network is not affected. 5.5.7 - I believe that existence of the separate (from the flow identifier) reservation identifier is very important not just for mobility but for the ease of integration with the different local QoS technologies as well. 5.5.10 is very similar to 5.5.6. Do we need both? I see very strong correlation between 5.6.1 and 5.6.3. Do we need both? I support requirement (Hemant Chaskar) that NSIS must support various billing/charging scenarios beyond simply providing hooks for record collection. Ilya. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 18:12:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13359 for ; Fri, 15 Mar 2002 18:12:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03404 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 18:12:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02953; Fri, 15 Mar 2002 18:04:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02926 for ; Fri, 15 Mar 2002 18:04:37 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13154 for ; Fri, 15 Mar 2002 18:04:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FN5Ji27598 for ; Sat, 16 Mar 2002 01:05:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 16 Mar 2002 01:04:35 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 16 Mar 2002 01:04:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Sat, 16 Mar 2002 01:04:35 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C5F@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHJGFe9gacwoXv/TDaSe5a9xzC1NwDXSQtw To: , Cc: X-OriginalArrivalTime: 15 Mar 2002 23:04:35.0887 (UTC) FILETIME=[C6A29BF0:01C1CC75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA02927 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Juan-Carlos, > I'm not asking to define "how parties make service agreements", but the > question I'm raising is more "Is in the context of NSIS to define ways of > expressing QoS requirements also at the session level ?". > The main purpose is that what will be agreed at the session/application > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for > resource reservation complying with the QoS requirements. The most > straight-forward will be the translation, the less error-prone will be the > implementation. > And for sure, at the end, the QoS information should allow a > mapping on different QoS technologies. Some folks have wondered if we should create 'NSIS QoS Classes' (pick a better term, if you like) and create an IANA registry. These could then be used. Somehow, I favor this approach as opposed to allowing n x m parameters to be used. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 18:16:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13474 for ; Fri, 15 Mar 2002 18:16:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03561 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 18:16:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02350; Fri, 15 Mar 2002 17:58:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02317 for ; Fri, 15 Mar 2002 17:58:49 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12969 for ; Fri, 15 Mar 2002 17:58:45 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FMxVi26676 for ; Sat, 16 Mar 2002 00:59:31 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 16 Mar 2002 00:58:47 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 16 Mar 2002 00:58:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt Date: Sat, 16 Mar 2002 00:58:47 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C5E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Comment on draft-ietf-nsis-req-00.txt Thread-Index: AcHI4FQPg99uJWR8SyOZjy7b8zUj3wDlFA4Q To: , Cc: , , X-OriginalArrivalTime: 15 Mar 2002 22:58:47.0842 (UTC) FILETIME=[F72F2820:01C1CC74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA02318 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Robert, I still don't really see this a requirement. It could be a nice feature, in some environments, but I'm not completely convinced that it is really useful. Additionally, it will create state in the network and I'm not sure that is so good, especially in the case when there are not enough resources. John > > in this particular case, i think the requirement came from > the context of not wanting to have a frustrated QI polling an > access network (e.g. a cellular one) at some ridiculous rate > to find out if resources have become available. (note in > particular that it is quite hard in some cellular > architectures to bill for this sort of polling, so far as i know.) > > > > in some environments, this will be worth doing, and in some > it won't. i guess that makes it a SHOULD (which is what the > draft says), and there are a number of different modularity > approaches which would minimise the pain caused by providing > it as an option. (existence argument: QI says 'I want QoS for > flow labelled by reference R', QC responds in the event of > failure with either 'sorry, try later, in the meantime i've > forgotten about R' or 'sorry, i'll tell you later, in the > meantime don't ask again for flow R'. related tricks are > needed in mobile scenarios. if QI doesn't want notification > it omits R. the overhead in the protocol is some optional > fields, which either end can ignore. i'm not saying that this > is the right way to do it, but i don't see that allowing this > as a should causes too much pain for people who don't > actually want to implement the functionality.) > > In that case the requirement should probably be: > > "The QI MAY (or SHOULD) support being automatically notified > from QCs for resources not previously available" _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 18:19:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13559 for ; Fri, 15 Mar 2002 18:19:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03694 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 18:19:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03259; Fri, 15 Mar 2002 18:10:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03228 for ; Fri, 15 Mar 2002 18:10:23 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13263 for ; Fri, 15 Mar 2002 18:10:19 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FN9g316262 for ; Sat, 16 Mar 2002 01:09:42 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 16 Mar 2002 01:10:21 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 16 Mar 2002 01:10:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Sat, 16 Mar 2002 01:10:21 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C61@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Requirement Section 5.3.2 Thread-Index: AcHMBHVmKs3iFH+sRpKzm7mmAU9vGwAcfFUw To: , , , , X-OriginalArrivalTime: 15 Mar 2002 23:10:21.0405 (UTC) FILETIME=[949478D0:01C1CC76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA03229 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi All, Looking at this requirement from another direction, it seems that the requirement is really about supporting time-based reservations. Is this the real requirement? If so, do we support this? John > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 15 March, 2002 11:31 > To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; 'nsis@ietf.org'; > 'schneider@tri.sbc.com' > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Georgios, > > Please, let's not mix together the requirements and the > solution at this stage! Soft state might be a (or even the) > solution, but that doesn't make it a requirement! > > In fact, we have at least three independent state-related > requirements to consider: > 1) the fact that the application wants a bearer of a limited > duration (and only wants to pay for this duration) - the end > user might want quite precise timing control over this (for > accounting reasons) > 2) the need to clean up after a node dies or becomes > disconnected from the network (in which case explicit release > isn't possible) > 3) the need to re-install state after path (route) changes > (which might be managed by something routing-aware) > > Soft-state *can* solve all these, but in some scenarios it > might be *very* hard to find a good compromise soft-state > timer value considering all the effects. Also, in some > scenarios (e.g. mobile) it might be better to address some of > the problems (e.g. 3) in a different, specialised way. But in > that case, it's helpful to have explicitly the requirement > that there are other reasons for needing refresh or timeout > or explicit release or whatever. > > Personally, I like Ilya's description of the situation. But > we could make things less judgemental by saying "it must be > possible for an initiator to control reservation reservation > end times without requiring continuous signalling with the > network" (or something); we can think later whether relying > always on soft state or allowing explicit lifetimes is a > better solution. I certainly don't see why explicit lifetimes > are so hard. > > Robert H. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 15 March 2002 08:18 > > To: 'Freytsis, Ilya'; 'nsis@ietf.org'; 'schneider@tri.sbc.com' > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Ilya > > > > I think that the issue that you are describing can be solved by > > the soft state principle. > > Anyway in my opinion the NSIS protocol MUST use the soft state > > principle, otherwise we will have to invent very complex > > functionalities that will solve all the problems that are solved by > > the soft state principle. > > > > Best Regards, > > Georgios > > > > > > > > -----Original Message----- > > From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] > > Sent: vrijdag 15 maart 2002 4:57 > > To: 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se'; > > 'schneider@tri.sbc.com' > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Georgios, > > > > Let me present another argument in support of this requirement: > > > > It is possible that the host that made a reservation dies > > "silently" without > > releasing network resources allocated for its flow. This > > requirement will > > provide protection from the possible waste of resources in > > this case. It is > > definitely different from refreshing the soft state of the > > reservation since > > it is driven by the application not the network specifics and > > applicable to > > the hard reservations as well (and maybe even more > important for hard > > reservations). > > To make this arrangement more flexible I think that ability > to signal > > life-time of a reservation (including permanent reservations) > > should be > > complemented by the ability to re-new the existing reservation. > > I envision the following scenario: > > The video endpoint (to stay on the same theme) is making a call. The > > endpoint or may be proxy makes reservation request with 30 > > min expected > > life-time. Three options exist > > 1. After 20 min the call is over and the endpoint (proxy) > > releases allocated > > resources. > > 2. After 25 min the participants realize that they need > > another 15 min to > > finish discussion - the re-new reservation request is issued > > with 15 min > > life-time > > 3. After 15 min the endpoints crashes. 15 min later the > > network realize that > > something is wrong and frees resources that were reserved for > > this video > > call. > > > > Does it make any sense? > > > > Ilya > > > > From: "Georgios Karagiannis (ELN)" > > > > To: "'Schneider, Marco'" , > > "'Steven Berson'" > > > > Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > Date: Wed, 13 Mar 2002 13:43:32 +0100 > > charset="iso-8859-1" > > > > Hi Marco > > > > What I mean is the following. > > If some QoS domain will use aggregated reservation states > > and if the lifetime requirement has to be supported by the domain, > > then new per flow reservation lifetime states have to be created > > in this domain. > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > > Sent: dinsdag 12 maart 2002 22:13 > > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > > > > Hi Georgios, > > > > The point of the example is that the network may want to > > limit the duration > > that it grants for a session and thus its corresponding > > resources (such as a > > QOS connection). So in this case the network needs to be able > > to revoke > > resources upon the expiration of some time period. In > > thinking about this > > example I was wondering whether it would be useful to make > duration an > > explicit part of the reservation semantics. > > > > 1) A host requests from network a service of one hour > > duration. For example > > a video call to a friend. > > 2) Above is realized via session negotiation that results in > > token that is > > passed back to the host. The token permits a QOS connection > > of one hour > > duration at 5 Mbps > > 3) The host (QOS Initiator) includes the token in the NSIS > > setup message > > requesting a 5Mbps connection. > > 4) The QOS Controller uses the token to validate the > > reservation and allows > > the setup to go through. > > (See draft-ietf-sip-call-auth-0?.txt as well as > > draft-ietf-rap-session-auth-0?.txt) > > > > Now what happens when one hour is up? Ideally the host releases the > > resources but if the host does not the network will > > (otherwise the user gets > > more than they paid for). When the network releases the > > resources there > > should be a cause code that says your time was up or at the > very least > > indicates that this was due to service policy. > > > > Now my question is: given that the reservation is intended > to be of a > > precise duration should we make this explicit or is it better > > for this to be > > transparent? Is so why? > > > > Regarding Scalability, I do not understand your claim that > > this is very > > non-scalable. For every flow reservation the network > > presumably will need to > > store the amount reserved (at least one piece of > > information). A reservation > > duration requires one additional piece of information (at the > > edge) that > > does not propagate across the network. > > > > Best Regards, > > Marco > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 18:23:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13607 for ; Fri, 15 Mar 2002 18:23:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03894 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 18:23:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03089; Fri, 15 Mar 2002 18:07:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03060 for ; Fri, 15 Mar 2002 18:07:40 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13216 for ; Fri, 15 Mar 2002 18:07:36 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FN6x315795 for ; Sat, 16 Mar 2002 01:06:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 16 Mar 2002 01:07:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 16 Mar 2002 01:07:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Sat, 16 Mar 2002 01:07:37 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C60@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Requirement Section 5.3.2 Thread-Index: AcHJxn08pdbijkQOQFq67jz215Ws6ACr5OkQ To: , Cc: , , , X-OriginalArrivalTime: 15 Mar 2002 23:07:37.0987 (UTC) FILETIME=[332CDD30:01C1CC76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA03061 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > I agree with Georgis reasoning. > If the NSIS protocol is focusing on bearers only, then it > should have no > knowledge on services like, e.g. "video calls", but only on > bearers having > some properties (bandwidth, delay, etc.), no matter what > those bearers are > carrying, no matter for which services they are being used. > If you "purchase a video call for one hour duration", then > the duration of > the *service* is one hour, and that's what you are paying for. I agree - for example TCP connections are not time based .... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 15 18:47:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14132 for ; Fri, 15 Mar 2002 18:47:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05364 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 18:47:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04518; Fri, 15 Mar 2002 18:30:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04483 for ; Fri, 15 Mar 2002 18:30:40 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13806 for ; Fri, 15 Mar 2002 18:30:36 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g2FNUct06974; Fri, 15 Mar 2002 15:30:39 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA07457; Fri, 15 Mar 2002 23:30:38 GMT Date: Fri, 15 Mar 2002 23:30:38 GMT Message-Id: <200203152330.XAA07457@gra.isi.edu> To: john.loughney@nokia.com Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org *> *> > I'm not asking to define "how parties make service agreements", but the *> > question I'm raising is more "Is in the context of NSIS to define ways of *> > expressing QoS requirements also at the session level ?". *> > The main purpose is that what will be agreed at the session/application *> > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for *> > resource reservation complying with the QoS requirements. The most *> > straight-forward will be the translation, the less error-prone will be the *> > implementation. *> > And for sure, at the end, the QoS information should allow a *> > mapping on different QoS technologies. *> *> Some folks have wondered if we should create 'NSIS QoS Classes' (pick *> a better term, if you like) and create an IANA registry. These could *> then be used. Somehow, I favor this approach as opposed to allowing *> n x m parameters to be used. *> *> John *> John, Just a historical data point: when we designed the int-serv architecture, beginning in 1991 and culminating in RFC 1633, we considered the idea of QoS classes and rejected them in favor of the "flow spec" idea. The reason we rejected the QoS class idea was that it seemed to be an invitation to massive non-interoperability. The fear was that such classes would proliferate, with each application that needed QoS defining its own QoS class. Which ones of the perhaps 50 such classes would a router vendor support? These would often be minor variations on each other, but they would have to be registered, defined, documented, implemented, maintained, ... individually. Unless you have some standardization mechanism that keeps the number of such classes down to a few dozen or so, it seemed like a recipe for QoS chaos. However, isn't this question outside the scope of a WG on signaling? Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Mar 15 19:38:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14778 for ; Fri, 15 Mar 2002 19:38:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07608 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 19:38:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07283; Fri, 15 Mar 2002 19:31:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07254 for ; Fri, 15 Mar 2002 19:31:10 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14692 for ; Fri, 15 Mar 2002 19:31:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2G0UT326200 for ; Sat, 16 Mar 2002 02:30:29 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 16 Mar 2002 02:31:08 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 16 Mar 2002 02:31:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Sat, 16 Mar 2002 02:31:08 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D69@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHMeXEJN3d3wCy0QwCIUD9ZKgXjHgAAF/PA To: Cc: X-OriginalArrivalTime: 16 Mar 2002 00:31:08.0690 (UTC) FILETIME=[DDC97720:01C1CC81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA07255 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Bob, > Just a historical data point: when we designed the int-serv > architecture, beginning in 1991 and culminating in RFC 1633, we > considered the idea of QoS classes and rejected them in favor of the > "flow spec" idea. The reason we rejected the QoS class idea was that > it seemed to be an invitation to massive non-interoperability. The > fear was that such classes would proliferate, with each application > that needed QoS defining its own QoS class. Which ones of the perhaps > 50 such classes would a router vendor support? These would often be > minor variations on each other, but they would have to be registered, > defined, documented, implemented, maintained, ... > individually. Unless > you have some standardization mechanism that keeps the number of such > classes down to a few dozen or so, it seemed like a recipe for QoS > chaos. Agreed. Additionally, I do think that offering many levels of QoS can be a problem for a service provider as well. Some models have shown that a service provider cannot support offering more than 4 levels of QoS reliably. > However, isn't this question outside the scope of a WG on signaling? Well, I perhaps chose the wrong term, but I think we do have to decide what to signaling. Do we signal absolutely or relatively, or do we do a little of both. Actually, with respect to this, I'd be very interested in see real-world data on service providers who have provided or are providing different levels of QoS & their experiences. As an aside, someone to me suggested that NSIS should have a model where there are 5 different QoS profiles (best effort, interactive, voice, video and VPN), each profile have a level from 1 to 10 specifying the level of service, and optionally carrying specific parameters ... thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sat Mar 16 20:02:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12550 for ; Sat, 16 Mar 2002 20:02:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14811 for nsis-archive@odin.ietf.org; Sat, 16 Mar 2002 20:02:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13368; Sat, 16 Mar 2002 19:32:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13339 for ; Sat, 16 Mar 2002 19:32:43 -0500 (EST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11884 for ; Sat, 16 Mar 2002 19:32:40 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2H0WC114362 for ; Sat, 16 Mar 2002 18:32:12 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3C838620000B0276; Sat, 16 Mar 2002 19:32:01 -0500 content-class: urn:content-classes:message Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Sat, 16 Mar 2002 19:32:01 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170167AF52@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcHMdkihZpzhO8MZSlyjdvz1FdqBZAA0miiw From: "Ash, Gerald R (Jerry), ALASO" To: Cc: "Ash, Gerald R (Jerry), ALASO" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA13340 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, > Some folks have wondered if we should create 'NSIS QoS Classes' (pick > a better term, if you like) and create an IANA registry. These could > then be used. Somehow, I favor this approach as opposed to allowing > n x m parameters to be used. I agree that we should consider creating standardized 'QoS classes'. Work along this line was done in http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-class-types-00.txt, which proposes a small number of standardized QoS classes (called 'class types' in the draft). Also note that ITU-T has recently approved 6 standardized QoS classes in Y.1541 (this is discussed in the draft). Jerry Ash _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Mar 17 09:40:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01827 for ; Sun, 17 Mar 2002 09:40:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22725 for nsis-archive@odin.ietf.org; Sun, 17 Mar 2002 09:41:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21799; Sun, 17 Mar 2002 09:16:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21768 for ; Sun, 17 Mar 2002 09:16:01 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01592 for ; Sun, 17 Mar 2002 09:15:55 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2HEGhi08151 for ; Sun, 17 Mar 2002 16:16:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 17 Mar 2002 16:15:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sun, 17 Mar 2002 16:15:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Sun, 17 Mar 2002 16:15:56 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C6F@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] section 3.5 in nsis-req-00.txt Thread-Index: AcHMeXEJN3d3wCy0QwCIUD9ZKgXjHgAAF/PAAFETxSA= To: Cc: X-OriginalArrivalTime: 17 Mar 2002 14:15:57.0370 (UTC) FILETIME=[41C081A0:01C1CDBE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA21769 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Just in case it wasn't clear: > As an aside, someone to me suggested that NSIS should have a model > where there are 5 different QoS profiles (best effort, interactive, > voice, video and VPN), each profile have a level from 1 to 10 > specifying the level of service, and optionally carrying specific > parameters ... I was NOT suggesting this as our model, as this would be far to complex, in my opinion, to administer, etc. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Mar 17 11:54:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05828 for ; Sun, 17 Mar 2002 11:54:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28277 for nsis-archive@odin.ietf.org; Sun, 17 Mar 2002 11:54:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27569; Sun, 17 Mar 2002 11:33:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27542 for ; Sun, 17 Mar 2002 11:33:29 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04856 for ; Sun, 17 Mar 2002 11:33:25 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Mar 2002 16:30:07 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804594C67@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, sarantis@cnl.di.uoa.gr Cc: Georgios.Karagiannis@eln.ericsson.se, Anders.P.Bergsten@telia.se, nsis@ietf.org Subject: what is an NSIS requirement? [was: RE: [NSIS] Comment on draft-ie tf-nsis-req-00.txt] Date: Sun, 17 Mar 2002 16:29:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" John & Sarantis, I agree with your reasoning, but maybe it exposes my confusion about something more fundamental. (It's similar to the subject of Ilya's latest email, which I have not yet fully analysed.) When we say "x.y.z is a requirement for NSIS" or "NSIS shall/must/may" or whatever, it seems we could be saying any of a large number of different things, like a) there is a single ubiquitous NSIS protocol, and we are writing requirements for the core functionality that must be implemented in every node using it [one extreme], or b) there are several components to a QoS signalling framework (e.g. in the same way that there are several components to the Internet routing framework), and some features may be useful, possibly optional parts of one component [the other extreme - essentially, the NSIS requirements are a formalised statement of NSIS scope] I'm 100% behind the view that 5.3.7 must not be a requirement under view (a), but <<100% under view (b). In particular, I don't like assuming a single protocol; in any case, if NSIS 'happens' one can be sure that people will try to hack these 'nice to have' features into it in some localised way in the future (look what has happened with RSVP after all). If we could sort this out before more agonising over any particular requirements, I think progress would be faster. Easier said than done, though... Robert H. PS. To draw an extremely tortuous analogy with the 'toolbox' phrases in the charter: not everyone has to have the same set of tools in their own toolbox. and not everyone has to use all the tools in their toolbox. but if a capability is useful, it's useful to have a standard tool for it. is NSIS a set of possible tools or a standardised toolbox? > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 15 March 2002 22:59 > To: sarantis@cnl.di.uoa.gr; Hancock, Robert > Cc: Georgios.Karagiannis@eln.ericsson.se; Anders.P.Bergsten@telia.se; > nsis@ietf.org > Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt > > > Robert, > > I still don't really see this a requirement. It could > be a nice feature, in some environments, but I'm > not completely convinced that it is really useful. > Additionally, it will create state in the network > and I'm not sure that is so good, especially in the > case when there are not enough resources. > > John > > > > in this particular case, i think the requirement came from > > the context of not wanting to have a frustrated QI polling an > > access network (e.g. a cellular one) at some ridiculous rate > > to find out if resources have become available. (note in > > particular that it is quite hard in some cellular > > architectures to bill for this sort of polling, so far as i know.) > > > > > > in some environments, this will be worth doing, and in some > > it won't. i guess that makes it a SHOULD (which is what the > > draft says), and there are a number of different modularity > > approaches which would minimise the pain caused by providing > > it as an option. (existence argument: QI says 'I want QoS for > > flow labelled by reference R', QC responds in the event of > > failure with either 'sorry, try later, in the meantime i've > > forgotten about R' or 'sorry, i'll tell you later, in the > > meantime don't ask again for flow R'. related tricks are > > needed in mobile scenarios. if QI doesn't want notification > > it omits R. the overhead in the protocol is some optional > > fields, which either end can ignore. i'm not saying that this > > is the right way to do it, but i don't see that allowing this > > as a should causes too much pain for people who don't > > actually want to implement the functionality.) > > > > In that case the requirement should probably be: > > > > "The QI MAY (or SHOULD) support being automatically notified > > from QCs for resources not previously available" > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 18 05:37:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02608 for ; Mon, 18 Mar 2002 05:37:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25245 for nsis-archive@odin.ietf.org; Mon, 18 Mar 2002 05:37:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24368; Mon, 18 Mar 2002 05:19:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24334 for ; Mon, 18 Mar 2002 05:19:26 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02332 for ; Mon, 18 Mar 2002 05:19:21 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA18122; Mon, 18 Mar 2002 11:19:12 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA27530; Mon, 18 Mar 2002 11:19:02 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 11:19:35 +0100 Message-ID: <0D9B5CCF4BBCD211B7560008C70DBE8E01CDB23E@MCHH241E> From: Winter Martin To: "'Ash, Gerald R (Jerry), ALASO'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt Date: Mon, 18 Mar 2002 11:19:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Jerry, I also agree, that 'QoS classes' are a good thing. In our project (see link below) we discussed this intensively. Network operators always tried to keep the number of such classes low (as others already stated on this mailing list). We finally came up with 4+1 classes. There are similarities to those proposed in the draft you mentioned. This strengenths my hopes, that it is possible to cover a broad range of QoS requirements with a small set of classes. I do not have hard arguments, but I think it is easier - to define (probably outside of NSIS) - and especially to use (inside of NSIS) such a set of classes, than to leave a larger set of parameters open for negotioation on each QoS request. -- Martin Winter AQUILA Project http://www.ist-aquila.org ------------------------------------------------------ Siemens AG Voice: +49 89 722-63718 ICN WN CC NA A19 Fax: +49 89 722-41920 Hofmannstr. 51 Mail: Martin.Winter@icn.siemens.de 81359 Muenchen Germany > -----Original Message----- > From: Ash, Gerald R (Jerry), ALASO [mailto:gash@att.com] > Sent: Sunday, March 17, 2002 1:32 AM > To: john.loughney@nokia.com > Cc: Ash, Gerald R (Jerry), ALASO; nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > John, > > > Some folks have wondered if we should create 'NSIS QoS > Classes' (pick > > a better term, if you like) and create an IANA registry. > These could > > then be used. Somehow, I favor this approach as opposed to allowing > > n x m parameters to be used. > > I agree that we should consider creating standardized 'QoS > classes'. Work along this line was done in > http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv -te-class-types-00.txt, which proposes a small number of standardized QoS classes (called 'class types' in the draft). Also note that ITU-T has recently approved 6 standardized QoS classes in Y.1541 (this is discussed in the draft). Jerry Ash _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 18 05:56:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02810 for ; Mon, 18 Mar 2002 05:56:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25893 for nsis-archive@odin.ietf.org; Mon, 18 Mar 2002 05:56:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25580; Mon, 18 Mar 2002 05:48:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25549 for ; Mon, 18 Mar 2002 05:48:43 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02732 for ; Mon, 18 Mar 2002 05:48:38 -0500 (EST) Received: from hzsgp68.nl.lucent.com (h135-85-117-188.lucent.com [135.85.117.188]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2IAmAl26531; Mon, 18 Mar 2002 05:48:10 -0500 (EST) Received: from lucent.com (hzsgp04.nl.lucent.com [135.85.117.104]) by hzsgp68.nl.lucent.com (8.11.0/8.11.0) with ESMTP id g2IBlf028907; Mon, 18 Mar 2002 12:47:41 +0100 Message-ID: <3C95C616.AFD4CAD4@lucent.com> Date: Mon, 18 Mar 2002 11:48:54 +0100 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: braden@ISI.EDU, nsis@ietf.org Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D69@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Bob, John, in my experience an application-level QoS class is (only) useful between the user at the edge and the (first) application aware server. At the user interface a set of classes is a useful shorthand to ask for what you want. This application specific thing should be converted to something that provides a parameterized (sp?) description of the transport service you need. Subsequently you need to consider what the scope of these parameters are. In general the scope of the parameters is from here (for a suitable definition of here) to the destiation. So the parameters will change at each hop. So John, the parameters are absolutely relative. (excuse the pun) Paul john.loughney@nokia.com wrote: > > Hi Bob, > > > Just a historical data point: when we designed the int-serv > > architecture, beginning in 1991 and culminating in RFC 1633, we > > considered the idea of QoS classes and rejected them in favor of the > > "flow spec" idea. The reason we rejected the QoS class idea was that > > it seemed to be an invitation to massive non-interoperability. The > > fear was that such classes would proliferate, with each application > > that needed QoS defining its own QoS class. Which ones of the perhaps > > 50 such classes would a router vendor support? These would often be > > minor variations on each other, but they would have to be registered, > > defined, documented, implemented, maintained, ... > > individually. Unless > > you have some standardization mechanism that keeps the number of such > > classes down to a few dozen or so, it seemed like a recipe for QoS > > chaos. > > Agreed. Additionally, I do think that offering many levels of QoS > can be a problem for a service provider as well. Some models > have shown that a service provider cannot support offering > more than 4 levels of QoS reliably. > > > However, isn't this question outside the scope of a WG on signaling? > > Well, I perhaps chose the wrong term, but I think we do have to decide > what to signaling. Do we signal absolutely or relatively, or do > we do a little of both. > > Actually, with respect to this, I'd be very interested in see > real-world data on service providers who have provided or are > providing different levels of QoS & their experiences. > > As an aside, someone to me suggested that NSIS should have a model > where there are 5 different QoS profiles (best effort, interactive, > voice, video and VPN), each profile have a level from 1 to 10 > specifying the level of service, and optionally carrying specific > parameters ... > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Paul Sijben Tel:+31 356874774 Bell Labs - Advanced Technologies Fax:+31 356875954 Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben Huizen, The Netherlands _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 18 06:45:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03422 for ; Mon, 18 Mar 2002 06:45:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27921 for nsis-archive@odin.ietf.org; Mon, 18 Mar 2002 06:45:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26838; Mon, 18 Mar 2002 06:24:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26805 for ; Mon, 18 Mar 2002 06:24:10 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03166 for ; Mon, 18 Mar 2002 06:24:07 -0500 (EST) From: maarten.buchli@alcatel.be Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2IBNNM25441; Mon, 18 Mar 2002 12:23:23 +0100 (MET) Subject: Re: [NSIS] RE: section on QI/QC and QI/QC terminology To: Kappler Cornelia Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, danny.goderis@alcatel.be, Hancock Robert Date: Mon, 18 Mar 2002 12:22:51 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/18/2002 12:23:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cornelia, The figure describing NSIS used as a local and as a global protocol was intended as a general framework and not specifically towards a certain scenario. Why do you consider it too restrictive? Regards, Maarten Kappler Cornelia on 15/03/2002 15:17:19 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Kappler Cornelia cc: nsis@ietf.org, Maarten BUCHLI/BE/ALCATEL@ALCATEL, Danny GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert Subject: [NSIS] RE: section on QI/QC and QI/QC terminology Hi Sven, what I dont understand yet is whether your QI/QC relationship Figure (describing basically a NSIS framework) is supposed to cover all scenarios in which NSIS signaling is applicable, or just is applicable to a subset, such as those described in your Req draft. I think you have in mind a general framework. In this case I have a different views of the NSIS scope / I find your framework too restrictive. Before embarking on a discussion on this though I'd like to doublecheck your intention? Cornelia > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Tuesday, March 12, 2002 4:59 PM > To: Kappler Cornelia > Cc: nsis@ietf.org; maarten.buchli@alcatel.be; danny.goderis@alcatel.be; Hancock Robert > Subject: RE: section on QI/QC and QI/QC terminology > > Hi Cornelia, > > Thanks for your reply. I have some comments inline. > > Bye, > Sven. > > > > > > Kappler Cornelia on 12/03/2002 16:23:06 > > > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, > nsis@ietf.org > > cc: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Danny > GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert > > > > > Subject RE: section on QI/QC and QI/QC terminology > : > > > > > > > Hi Sven, > > thank you for your detailed analysis. > > I agree with you the current definition of QI ("receives trigger from > _higher_ layer to start signaling") does run into problems for some > scenarios, such as in UMTS, where PDP context signaling (from a _lower_ > layer) is being translated into normal IP QoS signaling at the GGSN > (possibly via the P-CSCF). > > Your suggestion points a way for solving this problem (by offering an > alternative Def of QI, and also of QC and QR). However I have the following > comments (inline). Generally I'd like to modify your definitions somewhat > to lift unnecessary restrictions on protocol design and network structure > they seem to imply. I am not sure though whether my modifications dont run > into other problems :-) > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > [SMTP:sven.van_den_bosch@alcatel.be] > > Sent: Tuesday, March 05, 2002 2:31 PM > > To: nsis@ietf.org > > Cc: maarten.buchli@alcatel.be; danny.goderis@alcatel.be; > robert.hancock@roke.co.uk; cornelia.kappler@icn.siemens.de > > Subject: section on QI/QC and QI/QC terminology > > > > Hi, > > > > We have been thinking about the QI/QC definitions and we have tried to > > arrange the QC/QI functional entities in a logical relation that covers > the > > use case scenarios that have been proposed so far. From this, we hope to > > derive clearer definitions. > > > > The general logical relationships are depicted below (for simplicity, > only > > signaling relations are drawn) > > > > +--+ (a) +--+ (a) +--+ (a) +---+ > > +->|QI|---->|QC|---------------->|QC|---->| QR|--+ > > QI,QC,QR roles for e2e QoS protocol > > | +--+ /+--+\ /+--+\ +---+ | > > | / \ / \ v > > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+> > > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > > QI,QC,QR roles for local QoS protocol > > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > > > In this pictures we clearly distinguish two applications for the NSIS > > protocol: > > (a) NSIS as end-to-end QoS signaling protocol > > (b) NSIS as local QoS signaling protocol > > > The term "end2end QoS signaling protocol" I dont find entirely > fitting, since it seems to imply participation of end hosts. However, a > typical scenario we discuss is edge2edge signaling. What about "global QoS > signaling protocol"? > > Sven>> The picture has two layers of NSIS signaling: > - end-to-end NSIS signaling (where the QI and the QR are located at the > edge of the network). I don't think it completely maps to your edge-to-edge > scenario because that specifically talks about edges of domains. Here it is > really the edge of the network from the end-hosts point of view. > - NSIS as a local QoS signaling protocol. Note that between the end host > and the edge of the network, there is only NSIS signaling at this level. > This means that NSIS end-to-end does not require participation of the end > host. Even if the end host is an NSIS speaker, it will use NSIS as a local > QoS signaling protocol to get to the (top-level) QI where mapping will take > place and end-to-end signaling is initiated. > > Would e2e per-flow signaling - tunnelled through most of the network - > which might be necessary when no SIP-type e2e exchange of QoS took place, > be "local" NSIS signaling? Probably not. However when regarded as "global", > what about another signaling on top, signaling for aggregates? This is one > of the unnecessary restrictions / assumptions I see with your approach. > > Sven>> Setting up the aggregates is a local matter for each of the QCs. A > QC may choose to modify its aggregate based on incoming micro-flows but > this process will not be triggered by microflow arrivals. > > Your figure seems to imply global NSIS QoS signaling is always > triggered by end host signaling. However e.g. signaling for aggregates deep > in the backbone might only loosly be coupled to end host signaling. (You > may not have intended your figure as covering all possible scenarios) > > Sven>> Signaling for aggregates in the backbone is not triggered by the > NSIS end-to-end signaling. In fact, for this a local QoS technology is used > under the authority of the QC (via network management). This local > technology may exist or it may be another application of the local NSIS > signaling. > > > > Local, in this case, is defined as local to a QoS domain. A QoS domain is > > defined as a contiguous part of the network supporting the same QoS > > technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), > NSIS > > actually competes with other technologies offering local QoS, such as > PDP, > > RSVP, ... > > > ok. This maps my view. > > > The above picture seems to suggest an out-of-band approach but this is > not > > the case. The QCs can be implemented in a distributed way and redrawing > the > > picture then gives a different view. > > > > +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ > > |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| > > QI,QC,QR roles for e2e QoS protocol > > +--+ +--+ +--+ +--+ +--+ +--+> > > ^ v ^ v ^ v > > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ > > |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > > QI,QC,QR roles for local QoS protocol > > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > > > In this case, it is clear that an in-band solution is also supported. The > > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on> > a > > r> outer. Note that in this picture, the signaling in the access is done > with > > a local QoS protocol. This can be either an existing protocol, or the > NSIS > > protocol in its role of local QoS signaling mechanism. This leads to the > > following requirements: > > > > (a) If an NSIS protocol is only used end-to-end, then mobility need not > be > > supported > > > This seems to already imply a design choice. Why would the "e2e" / > global NSIS protocol not also support mobility? In this case local > signaling support is not needed. > > ...In fact I dont have any particular oppinion on this subject. > However in my view some detailed analysis is necessary to decide whether > mobility support by a local protocol is always sufficient!? > > Sven>> I think mobility definitely needs to be supported in the local > protocol. When the (top-level) QI is a fixed point (joint point of > reservation) then the end-to-end (or top-level) signaling does not need to > support mobility. This relaxes some of the requirements which is a good > thing. I think that without loss of generality we can have this situation. > The only design impact this may have is when we want to use the same > protocol for local and global NSIS signaling. In this case we need to make > it modular so that a global QC only has to look at the information relevant > to him. This requirement was already identified. > > > (b) If an NSIS protocol is used as a local QoS signaling mechanism then > > mobility must be supported, both on the QI-QC and QC-QC interface > > > > (c) If the same protocol is desired in (a) and (b), the protocol should > be > > modular and the mobility aspects need to be separable from the rest > > > OK. > > > Both of the above scenarios assume that the host is not NSIS-aware. This > is > > a reasonable assumption in a first phase. In a later stage, when hosts > are > > NSIS-aware, the host speaks the NSIS protocol, but as a local QoS > signaling > > technology! This allows this case to be backwards compatible with the > above > > scenarios. It means that (b) in the access is an NSIS protocol. It also > > means that the host will always trigger the local QoS signaling > mechanism. > > > Why would the host never trigger the global NSIS protocol? > > Sven>> It doesn't need to. When he is an NSIS speaker he can initiate the > local NSIS protocol. At the global QI his requirement will then be mapped > into the e2e NSIS protocol. If he didn't have any requirements that can't > be offered be the global NSIS protocol he could theoretically initiate e2e > signaling. I don't think it is needed however. > > > This suggests the following definitions for the QI, QC, QR > > > > - QoS Initiator: Network entity, located at the boundary of a QoS domain, > > responsible for initiating a (local or end-to-end) QoS mechanism. If it > is > > the QI of a local protocol, it can be triggered by higher layers > > (applications or end-to-end QoS Controller). If it is the QI of an > > end-to-end protocol, it can be triggered by applications or by the QoS > > Receiver of a local QoS signaling mechanism. > > > These triggers make sense to me (although a QC isn't a higher layer, > is it?). However what about the following problem with this definition: In > an RSVP-like scenario, per-flow signaling is tunnelled through an > aggregation area (may be this is how the NSIS protocol is going to work, > too). The aggregating router initiating the tunnelling, would it be a QR > for the per-flow signaling? Not really, because the signalling is not > terminated.So it is a QC. But then the QI initiating the aggregation is > triggered by a QC. > > Sven>> In the definition, I mentioned application or end-to-end/global QC > as possible triggers. So maybe we should say that a QC on the client NSIS > layer (global) can trigger a QI on the server NSIS layer (local). Would > this solve the issue in you opinion?> > > May be we have to become very broad with the QI Def by sa> ying "network > entity initiating NSIS signaling, including an entity initiating one type > of NSIS signaling after terminating another type of NSIS signaling.In which > case it would also be a QR." > > Note I restrict QI to NSIS signaling because we dont need to worry > about other kinds of signaling except by providing hooks for integrating > it. With this Def the GGSN (P-CSCF) classifies as QI as well as an > aggregating entity. The "including" sentence I put in to provide for > interworking of local and global NSIS signaling e.g. at an NSIS proxy. > > Sven>> I fully agree: QI/QC only have a meaning in NSIS signaling. > > Another point: I'd rather not restrict the QI to be located on the > boundary of a QoS Domain: It may be a bandwidth broker, located anywhere in > a domain, it may be a end host (is the end host always located "at the > boundary" of a QoS domain?). What if there is a address boundary inside a > QoS domain? Would address translation involve re-initiating QoS signaling? > Plus there may be a number of reasons for not locating the QI at the > boundary. Locating the QI at the boundary or a QoS domain includes too many > asumption about the network structure. So my suggestion is dropping this > restriction. > > Sven>> OK. Maybe we should say: located at the boundary of an NSIS > signaling domain. > > > - QoS Controller: Network entity responsible for interpreting and > > implementing the signalled QoS in the network. Failure to do so implies > an > > admission control decision. It can only be triggered by a QI or another > QC. > > > > -QoS Receiver: Network entity, located at the boundary of a QoS domain, > > responsible for terminating a (local or end-to-end) QoS mechanism. It has > > the additional functionality that it may initiate an acknowledgment > towards > > the QI and that it may trigger a QI or QC in the NSIS end-to-end > protocol. > > > Again I have an issue with "located at the boundary..:". > > Looking forward to your comments > > Cornelia > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 18 08:51:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05369 for ; Mon, 18 Mar 2002 08:51:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03972 for nsis-archive@odin.ietf.org; Mon, 18 Mar 2002 08:51:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03047; Mon, 18 Mar 2002 08:37:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03018 for ; Mon, 18 Mar 2002 08:37:21 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04937 for ; Mon, 18 Mar 2002 08:37:16 -0500 (EST) From: gratta@lucent.com Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g2IDb5G14122; Mon, 18 Mar 2002 08:37:05 -0500 (EST) Received: from nj7460gratta by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA15496; Mon, 18 Mar 2002 08:37:04 -0500 To: nsis@ietf.org Date: Mon, 18 Mar 2002 08:37:03 -0500 MIME-Version: 1.0 Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Reply-to: gratta@lucent.com CC: y.hiramatsu@hco.ntt.co.jp, Arshey.Odedra@itu.int, Randy Bush , Bert Wijnen , tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch Message-ID: <3C95A72F.18733.8D160@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Content-Transfer-Encoding: Quoted-printable Subject: [NSIS] Progress of the discussion on generic end-to-end QoS service requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: Quoted-printable 0100,0100,0100Times New RomanOn behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11, I am forwarding= the following Communication that was approved by Study Group 11 at its March 1, 2002 meeting. It describes progress of the discussion on g0100,0100,0100eneric end-to- end QoS service requirements within that body. Please respond to y.hiramatsu@hco.ntt.co.jp __________ Within ITU-T SG11, discussion has progressed on requirements for a generic= protocol mechanism for end-to-end QoS service control. A fundamental topic of discussion was raised whether the protocol mechanism for end-to-end QoS service control should be based on QoS classes and/or QoS parameters. We would like to acknowledge the view of favouring the use of a limited number of QoS classes rather than QoS parameter values, based on the considerations provided in the different inputs. outBased on the approach in ITU-T Recommendatio= n G.1010 for defining realistic QoS classes for underlying transport networks, and associated QoS control mechanisms. outFollowing the extensive guidance provided by= SG13 on our questions to prefer the use of QoS classes based on the work in progress on ITU-T Recommendation Y.1541 for the IP classes and previously the definition of the QoS classes for ATM in ITU-T Recommendation I.356. outThe response of SG16 that as part of their s= tudies on H.mmclass the ETSI TIPHON defined speech QoS service classes for VoIP will be taken and the plan to extend this classification system to multimedia. Also from a BICC protocol perspective we are considering solutions for end= - to-end QoS support for the interworking between BICC networks and other networks like SIP and H.323. We see major advantages to use the QoS class approach for end-to-end QoS service control rather than the use of QoS parameters. This based on the following considerations. outA limited set of QoS classes would ease proc= essing in the network. It is noted that operators and service providers may use non-standardised QoS classes (flavours) like Gold, Silver, Bronze, etc. in their subscripti= on offers to end-users. These non-standardised QoS classes (flavours) would easily be mapped to standardised QoS classes for the internal handling in the network of the operator and particularly for the interworking with other operator domains. Far more complexity would be involved if the end-to-end QoS control mechanism is based on QoS parameters. outWe foresee major problems to settle service = level agreements (SLA=92s) between operators if the end-to-end QoS handling would be based on QoS parameters rather than on QoS classes. The obvious advantages of the QoS class approach are the limited set of QoS classes to be agreed and since each QoS class represents standardised bounds on the typical end-to-end QoS factors excluding the need for further negotiation on the individual QoS parameters. outFrom a practical viewpoint it may be questio= ned whether the use of QoS parameters would lead to an accurate end-to-end QoS control mechanism. Firstly, it would require that operators have to provision accurate values= of the individual QoS factors allocated to the routes in the transport networks. Secondly, it may be questioned whether in packet networks like IP without dedicated bearer paths it will be possible to have precise values of the QoS factors for individual calls. outFor the existing PSTN/ISDN/PLMN services a s= imilar approach is followed based on an implicit QoS arrangement without a distinction in different QoS levels. We agree with the view of SG13 that for the existing= PSTN/ISDN/PLMN services there is no need to introduce QoS service levels. The studies in SG11 for end-to-end QoS service control are focussed on the seamless interworking with other call control protocols like SIP and the appropriate mapping to QoS mechanism in the underlying transport networks (e.g. IP and ATM). Consequently the studies in SG11 on protocol support for end-to-end QoS service control in BICC will proceed based on the transfer of a limited se= t of QoS classes. This applies for the horizontal call control that would inter= work with solutions in SIP and H.323 when solutions in these protocols also become available. In addition, the QoS classes may be transferred on the vertical CBC interface between call control level and bearer control level= and subsequently to be mapped to the technology specific QoS classes in the transport network (i.e. the QoS classes in e.g. IP or ATM). On the following issues we would asked SG12 and SG13 for some guidance on the following points.. outWe would like to receive guidance from SG12 = what set of QoS service classes should be used. Based on ITU-T Recommendation G.1010 and the intentions of SG16 for H.mmclass we assume the ETSI TIPHON defined speech QoS service classes for VoIP. outWe would like to receive guidance from SG13 = to which specific QoS classes in IP and ATM the QoS services classes in BICC networks (and potentially other networks like SIP and H.323) need to be mapped for the existing PSTN/ISDN/PLMN services. We also noted that similar solutions are being discussed in the IETF in th= e NSIS working group that may evolve in an end-to-end QoS control mechanism to be supported by the SIP protocol. We also noted that similar solutions = are being discussed in the IETF in the NSIS working group that may evolve in a= n end-to-end QoS control mechanism to be supported by the SIP protocol. SG11= would like to receive information from IETF as your studies evolve and loo= k forward to some cooperation. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Mar 18 17:32:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23266 for ; Mon, 18 Mar 2002 17:32:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14295 for nsis-archive@odin.ietf.org; Mon, 18 Mar 2002 17:32:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12546; Mon, 18 Mar 2002 17:18:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12518 for ; Mon, 18 Mar 2002 17:18:43 -0500 (EST) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22578 for ; Mon, 18 Mar 2002 17:18:37 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 17:14:39 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE6633EDE3@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" Date: Mon, 18 Mar 2002 17:14:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] FW: comment on draft-nsis-req-00 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This posting has never showed up in the digests (I am receiving only digests). I'm resending it for this reason. Ilya -----Original Message----- From: Freytsis, Ilya Sent: Friday, March 15, 2002 4:21 PM To: 'nsis@ietf.org' Subject: comment on draft-nsis-req-00 Hi, all. While catching up with discussions on the list I've got impression the requirements to NSIS sometimes got mixed up with requirements to the entities that have to implement it. This mix-up can make our discussions at the IETF 53 less productive than it can be. One thing is to say that NSIS must allow to do X and the other - to say that the entity A must implement X. I think that the modality MUST is the only meaningful modality for the protocol requirements (what protocol will allow you to achieve). On the other hand requirements for the protocol implementation (what is supported and in what scenarios) by the various enteritis the difference between modalities MUST, SHOULD, MAY becomes very important and meaningful. I think that section 6 of the document should be re-worked from this perspective. Here are some comments to the requirement section (and discussions on the list): 5.1.7 - I have a hard time to understand this requirement and how it is derived from the motivation paragraph. I think it has to be re-worded and explained or removed. 5.1.8 - I think this requirement should be removed or completed with the list of technologies. Requirement 5.1.1 and 5.1.10 looks the same to me. What am I missing here? 5.5.4 - I agree with those who are saying that QoS requestor should not be concerned with the actions taken by the network if the "contract" between requestor and the network is not affected. 5.5.7 - I believe that existence of the separate (from the flow identifier) reservation identifier is very important not just for mobility but for the ease of integration with the different local QoS technologies as well. 5.5.10 is very similar to 5.5.6. Do we need both? I see very strong correlation between 5.6.1 and 5.6.3. Do we need both? I support requirement (Hemant Chaskar) that NSIS must support various billing/charging scenarios beyond simply providing hooks for record collection. Ilya. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue Mar 19 17:13:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05890 for ; Tue, 19 Mar 2002 17:13:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21430 for nsis-archive@odin.ietf.org; Tue, 19 Mar 2002 17:13:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20594; Tue, 19 Mar 2002 17:01:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20548 for ; Tue, 19 Mar 2002 17:01:07 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05504 for ; Tue, 19 Mar 2002 17:01:03 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16nRfF-0004td-00 for ; Tue, 19 Mar 2002 23:01:05 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16nRfE-00035q-00 for ; Tue, 19 Mar 2002 23:01:04 +0100 Received: from tpce10.ipv6.tm.uka.de ([127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2JM14f30961 for ; Tue, 19 Mar 2002 23:01:04 +0100 Message-Id: <200203192201.g2JM14f30961@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 19 Mar 2002 23:01:04 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit Subject: [NSIS] NSIS Service Definition (not!) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, to catch up the issue that Marcus had on one of his slides, and, that caused much discussion, but for which there is IMO broad consensus in the WG: => service definition is out of scope. (just as others and I have stated before) The NSIS protocol should be service-"agnostic" as much as possible: - Which service or service parameter values are actually signalled by the protocol should be transparent for the protocol carrying the information. (or as John said: not "what" but how is it signaled) - One possible implementation is to carry a service object transparently. Later on, it might be required to identify objects of globally defined services by IANA assigned numbers. What may be in the WG scope: - How different services may influence the protocol requirements (any suggestions?). Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Tue Mar 19 17:52:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07061 for ; Tue, 19 Mar 2002 17:52:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23707 for nsis-archive@odin.ietf.org; Tue, 19 Mar 2002 17:52:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23147; Tue, 19 Mar 2002 17:44:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23114 for ; Tue, 19 Mar 2002 17:44:03 -0500 (EST) Received: from hotmail.com (f95.pav2.hotmail.com [64.4.37.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06693 for ; Tue, 19 Mar 2002 17:44:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Mar 2002 14:43:32 -0800 Received: from 166.63.186.251 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 19 Mar 2002 22:43:32 GMT X-Originating-IP: [166.63.186.251] From: "Sven Van den Bosch" To: nsis@ietf.org Date: Tue, 19 Mar 2002 23:43:32 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 19 Mar 2002 22:43:32.0887 (UTC) FILETIME=[7F7B1A70:01C1CF97] Subject: [NSIS] proposals related to NSIS WG draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi all, As an outcome of this morning's NSIS meeting, we propose the following detailed additions to the WG draft. 1. Terminology - QoS Controller: Network entity responsible for interpreting and implementing the signaled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by another NSIS entity of the same instance (a QoS Initiator or another QoS Controller). - QoS Receiver: Network entity, located at the edge of or inside a QoS domain, responsible for terminating an instance of an NSIS protocol. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger another NSIS entity (QoS Initiator or QoS Controller of another instance of the NSIS protocol) - QoS Initiator: Network entity, located at the edge of or inside a QoS domain, responsible for initiating an instance of an NSIS QoS signaling protocol. It may be triggered by the application layer, by the termination of a local QoS signaling mechanism (possibly another instance of NSIS signaling) or by a QoS Controller of another of a client instance of an NSIS protocol. It provides a mapping between the QoS parameters contained in the trigger and the QoS parameters in the instance of the NSIS protocol for which is serves as QoS Initiator. 2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 and 4.2) 3. Requirements * New requirements - in section MUST support priority The priority of a flow is essentially decoupled from its QoS requirements. Therefore the protocol MUST support priority. As a consequence, it MUST support preemption of traffic flows in case of congestion or failure. A preemption action MAY trigger an attempt to resetup the request by means of another instance of an NSIS signaling protocol. - in section 5.3: MAY support grouping of microflows (possibly only for feedback) As a consequence of the optimization for the interactive multimedia services, the signaling should allow one unique request for several micro flows having the same origination and destination IP addresses. This is usually the case for multimedia SIP calls where the voice and video micro flows follow the same path. This grouping of requests allows optimization of the QoS processing. Note that this may be detrimental for the call setup time. The use of grouping for microflows may be restricted to teardown and/or notification messages when call setup time is a concern. - in section 5.5: Protocol content The per-flow QoS requests are mapped onto the bandwidth pipe, which is specified by an SLS. These pipes may provide statistical guarantees such as delay and packet loss bounds (depending on the QoS class). In order to invoke per-flow QoS services the only parameter needed is a required rate, a means to identify the data path (mapping on SLS) and eventually a reservation identifier. 1) Microflow/reservation description The signaling should allow the request to describe the microflow whose QoS would be guaranteed by giving at least the source and destination IP addresses of the media flow. In case the QC is stateful (per microflow) there may be a need to include a unique reservation identifier (e.g. QI identifier+counter) such that in case of e.g. a tear down message the reservation can be easily identified in the QC. 2) Traffic descriptor The required peak rate must be signaled. Optionally the traffic parameters may be expressed in terms of token bucket parameters (similar to the TSpec in RSVP). - in section 5.10: Interworking with provisioning * Requirements for which to change priority or formulation - MUST support signalling to entities outside the data path (reformulation) - MUST NOT be adversely impacted by mobility aspects (applicable for end-to-end) A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be adversely affected by mobility issues. Any mobility scenario should be tackled by other uses of an NSIS protocol and is outside the realm of an end-to-end application of the NSIS protocol. _________________________________________________________________ Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 20 13:02:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08165 for ; Wed, 20 Mar 2002 13:02:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01454 for nsis-archive@odin.ietf.org; Wed, 20 Mar 2002 13:02:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00780; Wed, 20 Mar 2002 12:57:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00753 for ; Wed, 20 Mar 2002 12:57:27 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07992 for ; Wed, 20 Mar 2002 12:57:24 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA07238; Wed, 20 Mar 2002 18:57:18 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA29946; Wed, 20 Mar 2002 18:57:10 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 18:57:45 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656A1@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Sven Van den Bosch'" , nsis@ietf.org Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Wed, 20 Mar 2002 18:57:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven, some inline comments on the new definitions / Reqs (which in general I like) Cornelia > -----Original Message----- > From: Sven Van den Bosch [SMTP:svenvandenbosch@hotmail.com] > Sent: Tuesday, March 19, 2002 11:44 PM > To: nsis@ietf.org > Subject: [NSIS] proposals related to NSIS WG draft > > Hi all, > > As an outcome of this morning's NSIS meeting, we propose the following > detailed additions to the WG draft. > > 1. Terminology > > - QoS Controller: Network entity responsible for interpreting and > implementing the signaled QoS in the network. Failure to do so implies an > admission control decision. It can only be triggered by another NSIS entity > of the same instance (a QoS Initiator or another QoS Controller). > "instance": NSIS protocol instance? One should probably also provide the definition of NSIS protocol instance. > - QoS Receiver: Network entity, located at the edge of or inside a QoS > domain, responsible for terminating an instance of an NSIS protocol. It has > the additional functionality that it may initiate an acknowledgment towards > the QI and that it may trigger another NSIS entity (QoS Initiator or QoS > Controller of another instance of the NSIS protocol) > why would it trigger a QC? > - QoS Initiator: Network entity, located at the edge of or inside a QoS > domain, responsible for initiating an instance of an NSIS QoS signaling > protocol. It may be triggered by the application layer, by the termination > of a local QoS signaling mechanism (possibly another instance of NSIS > signaling) or by a QoS Controller of another of a client instance of an NSIS > protocol. It provides a mapping between the QoS parameters contained in the > trigger and the QoS parameters in the instance of the NSIS protocol for > which is serves as QoS Initiator. > what is a "client instance of an NSIS protocol"? > 2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 > and 4.2) > > 3. Requirements > > * New requirements > - in section MUST support priority > The priority of a flow is essentially decoupled from its QoS requirements. > Therefore the protocol MUST support priority. As a consequence, it MUST > support preemption of traffic flows in case of congestion or failure. A > preemption action MAY trigger an attempt to resetup the request by means of > another instance of an NSIS signaling protocol. > > - in section 5.3: MAY support grouping of microflows (possibly only for > feedback) > As a consequence of the optimization for the interactive multimedia > services, the signaling should allow one unique request for several micro > flows having the same origination and destination IP addresses. This is > usually the case for multimedia SIP calls where the voice and video micro > flows follow the same path. This grouping of requests allows optimization of > the QoS processing. Note that this may be detrimental for the call setup > time. The use of grouping for microflows may be restricted to teardown > and/or notification messages when call setup time is a concern. > > - in section 5.5: Protocol content > The per-flow QoS requests are mapped onto the bandwidth pipe, which is > specified by an SLS. These pipes may provide statistical guarantees such as > delay and packet loss bounds (depending on the QoS class). In order to > invoke per-flow QoS services the only parameter needed is a required rate, a > means to identify the data path (mapping on SLS) and eventually a > reservation identifier. > - "per-flow QoS requests _may be_ mapped onto ..."? - "rate" = bandwidth? > 1) Microflow/reservation description > The signaling should allow the request to describe the microflow whose QoS > would be guaranteed by giving at least the source and destination IP > > addresses of the media flow. In case the QC is stateful (per microflow) > > there may be a need to include a unique reservation identifier (e.g. QI > identifier+counter) such that in case of e.g. a tear down message the > reservation can be easily identified in the QC. > > 2) Traffic descriptor > The required peak rate must be signaled. Optionally the traffic parameters > may be expressed in terms of token bucket parameters (similar to the TSpec > in RSVP). > > - in section 5.10: Interworking with provisioning > > * Requirements for which to change priority or formulation > - MUST support signalling to entities outside the data path (reformulation) > > - MUST NOT be adversely impacted by mobility aspects (applicable for > end-to-end) > A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be > adversely affected by mobility issues. Any mobility scenario should be > tackled by other uses of an NSIS protocol and is outside the realm of an > end-to-end application of the NSIS protocol. > what is "other uses of an NSIS protocol"? What is an "e2e app of the NSIS protocol" (I understand this looking at the figures you provided in a recent email, however they are not part of the Req doc)Does this imply NSIS is not supporting mobility? Or: it MUST be possible to support mobility locally, without invoking e2e NSIS signaling? > _________________________________________________________________ > Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 20 13:12:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08763 for ; Wed, 20 Mar 2002 13:12:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01946 for nsis-archive@odin.ietf.org; Wed, 20 Mar 2002 13:12:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01536; Wed, 20 Mar 2002 13:03:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01503 for ; Wed, 20 Mar 2002 13:03:16 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08208 for ; Wed, 20 Mar 2002 13:03:12 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA27864; Wed, 20 Mar 2002 18:59:44 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA26230; Wed, 20 Mar 2002 18:59:26 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 19:00:04 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656A2@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'maarten.buchli@alcatel.be'" Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, danny.goderis@alcatel.be, Hancock Robert Subject: RE: [NSIS] RE: section on QI/QC and QI/QC terminology Date: Wed, 20 Mar 2002 19:00:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Maarten and Sven, may be this discussion is outdated by what you've been discussing at the NSIS WG meeting which unfortunately I was not able to attend. Anyways Maarten wrote: > Hi Cornelia, > > The figure describing NSIS used as a local and as a global protocol was > intended as a general framework > and not specifically towards a certain scenario. > > Why do you consider it too restrictive? > > Regards, > Maarten > Cornelia: Let me summarize your framework as I understand it: You fix a two-level signaling hierarchy for any kind of signaling scenario (e.g. mobile and fixed): end-to-end (global) and local. In a first step, NSIS is only global, and interworks with local signaling mechanisms. I.e. it is nowhere "stand-alone". In a second step, we would also have a local NSIS signaling protocol, which may replace the "legacy" local signaling. Global and local signaling must always work together, i.e. with just one of them QoS cannot be set up e2e. The end host never initiates global / end-to-end signaling, but just does local signaling to some access router (gateway), which acts as a proxy and QI, and translates the reservation into NSIS e2e/global signaling Now why do I consider this as too restrictive: - why is it necessary to always involve a proxy? Why would the end host never initiate e2e signaling? - it fixes a two-level hierarchy. However, more deeply nested hierarchies are also possible. E.g. when some edge router pipes a per-flow aggregation into a (possibly previously set-up) aggregate reservation. Note this idea can even be extended by the next edge router piping the aggregates it receives into "super- aggregates". "Sven>> Setting up the aggregates is a local matter for each of the QCs. A QC may choose to modify its aggregate based on incoming micro-flows but this process will not be triggered by microflow arrivals." Cornelia: When a QC initiates an aggregate reservation it is a QI! (or rather: the logical QC instance on a particular node receives per flow signaling and triggers (based on incoming micro-flows, but not because of a particular microflow arrival, I agree) the logical QI instance on the same node to initiate or modify an aggregate reservation.) This is also consistent with the terminology definition you sent out after the NSIS meeting, where the QC may trigger a QI to initiate another instance of the NSIS protocol Another example of a more-than-two-level hierarchy: a QC initiates per-flow e2e signaling. At the edge of some administrative domain a QC tunnels it to the other edge of the domain and initiates local (domain-specific) NSIS signaling, may be because a mapping of QoS parameters to local scope parameters is necessary. Now this administrative domain consists of more than one QoS domain, i.e. different QoS mechanisms are supported. At the edge of each of these domains, local (non-NSIS) signaling mechanisms are therefore initiated (e.g. RSVP, or no signaling, and instead DSCPs). This last example may be a bitfar fetched... however I think we should allow the protocol to be arbitrarily deeply nested, if only because it is more general and we dont know what the future is going to bring. Besides I dont see having an arbitrary number of levels would make the protocol more complicated - what about a scenario where no end host is involved, but a BB triggers an edge router to set-up an aggregate reservation through a domain? The BB would send this trigger because of some SLA agreement process rather than because of the interpretation of per-flow reservations. I dont think this would map to your framework either, because there is no reason for starting with a local NSIS signaling that later is translated into global NSIS signaling. Best regards, Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 20 19:41:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20262 for ; Wed, 20 Mar 2002 19:41:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25246 for nsis-archive@odin.ietf.org; Wed, 20 Mar 2002 19:41:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25031; Wed, 20 Mar 2002 19:31:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25004 for ; Wed, 20 Mar 2002 19:31:15 -0500 (EST) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20165 for ; Wed, 20 Mar 2002 19:31:12 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 19:24:47 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE6633EDF8@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'nsis@ietf.org'" Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Wed, 20 Mar 2002 19:24:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org My comments inline. Ilya From: "Sven Van den Bosch" To: nsis@ietf.org Date: Tue, 19 Mar 2002 23:43:32 +0100 Subject: [NSIS] proposals related to NSIS WG draft Hi all, As an outcome of this morning's NSIS meeting, we propose the following detailed additions to the WG draft. 1. Terminology - QoS Controller: Network entity responsible for interpreting and implementing the signaled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by another NSIS entity of the same instance (a QoS Initiator or another QoS Controller). - QoS Receiver: Network entity, located at the edge of or inside a QoS domain, responsible for terminating an instance of an NSIS protocol. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger another NSIS entity (QoS Initiator or QoS Controller of another instance of the NSIS protocol) - QoS Initiator: Network entity, located at the edge of or inside a QoS domain, responsible for initiating an instance of an NSIS QoS signaling protocol. It may be triggered by the application layer, by the termination of a local QoS signaling mechanism (possibly another instance of NSIS signaling) or by a QoS Controller of another of a client instance of an NSIS protocol. It provides a mapping between the QoS parameters contained in the trigger and the QoS parameters in the instance of the NSIS protocol for which is serves as QoS Initiator. [IF>>] The following statement should be added to this set of definitions: QI, QC and QR can be located within the same or different QoS [sub]domains. Otherwise the case of two QoS [sub]domains (different QoS technology) with centralized Bandwidth Brokers communicating directly to each other is not covered. 2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 and 4.2) 3. Requirements * New requirements - in section MUST support priority The priority of a flow is essentially decoupled from its QoS requirements. Therefore the protocol MUST support priority. As a consequence, it MUST support preemption of traffic flows in case of congestion or failure. A preemption action MAY trigger an attempt to resetup the request by means of another instance of an NSIS signaling protocol. - in section 5.3: MAY support grouping of microflows (possibly only for feedback) As a consequence of the optimization for the interactive multimedia services, the signaling should allow one unique request for several micro flows having the same origination and destination IP addresses. This is usually the case for multimedia SIP calls where the voice and video micro flows follow the same path. This grouping of requests allows optimization of the QoS processing. Note that this may be detrimental for the call setup time. The use of grouping for microflows may be restricted to teardown and/or notification messages when call setup time is a concern. - in section 5.5: Protocol content The per-flow QoS requests are mapped onto the bandwidth pipe, which is specified by an SLS. These pipes may provide statistical guarantees such as delay and packet loss bounds (depending on the QoS class). In order to invoke per-flow QoS services the only parameter needed is a required rate, a means to identify the data path (mapping on SLS) and eventually a reservation identifier. [IF>>] It seems to me that max packet size can be as important criteria for decision to accept or reject a microflow into the pipe as rate. 1) Microflow/reservation description The signaling should allow the request to describe the microflow whose QoS would be guaranteed by giving at least the source and destination IP addresses of the media flow. In case the QC is stateful (per microflow) there may be a need to include a unique reservation identifier (e.g. QI identifier+counter) such that in case of e.g. a tear down message the reservation can be easily identified in the QC. 2) Traffic descriptor The required peak rate must be signaled. Optionally the traffic parameters may be expressed in terms of token bucket parameters (similar to the TSpec in RSVP). - in section 5.10: Interworking with provisioning * Requirements for which to change priority or formulation - MUST support signalling to entities outside the data path (reformulation) [IF>>] I strongly support it! - MUST NOT be adversely impacted by mobility aspects (applicable for end-to-end) A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be adversely affected by mobility issues. Any mobility scenario should be tackled by other uses of an NSIS protocol and is outside the realm of an end-to-end application of the NSIS protocol. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 20 21:56:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23250 for ; Wed, 20 Mar 2002 21:56:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA01083 for nsis-archive@odin.ietf.org; Wed, 20 Mar 2002 21:56:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00831; Wed, 20 Mar 2002 21:49:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00802 for ; Wed, 20 Mar 2002 21:49:39 -0500 (EST) Received: from hotmail.com (f79.pav2.hotmail.com [64.4.37.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23206 for ; Wed, 20 Mar 2002 21:49:35 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Mar 2002 18:49:07 -0800 Received: from 166.63.186.251 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 21 Mar 2002 02:49:07 GMT X-Originating-IP: [166.63.186.251] From: "Sven Van den Bosch" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Date: Thu, 21 Mar 2002 03:49:07 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2002 02:49:07.0629 (UTC) FILETIME=[F87C0DD0:01C1D082] Subject: [NSIS] text on layering - original mail Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, We have been thinking about the QI/QC definitions and we have tried to arrange the QC/QI functional entities in a logical relation that covers the use case scenarios that have been proposed so far. From this, we hope to derive clearer definitions. The general logical relationships are depicted below (for simplicity, only signaling relations are drawn) +--+ (a) +--+ (a) +--+ (a) +---+ +->|QI|---->|QC|---------------->|QC|---->| QR|--+ QI,QC,QR roles for e2e QoS protocol | +--+ /+--+\ /+--+\ +---+ | | / \ / \ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this pictures we clearly distinguish two applications for the NSIS protocol: (a) NSIS as end-to-end QoS signaling protocol (b) NSIS as local QoS signaling protocol Local, in this case, is defined as local to a QoS domain. A QoS domain is defined as a contiguous part of the network supporting the same QoS technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS actually competes with other technologies offering local QoS, such as PDP, RSVP, ... The above picture seems to suggest an out-of-band approach but this is not the case. The QCs can be implemented in a distributed way and redrawing the picture then gives a different view. +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| QI,QC,QR roles for e2e QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ ^ v ^ v ^ v +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ |QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| QI,QC,QR roles for local QoS protocol +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ In this case, it is clear that an in-band solution is also supported. The end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on a router. Note that in this picture, the signaling in the access is done with a local QoS protocol. This can be either an existing protocol, or the NSIS protocol in its role of local QoS signaling mechanism. This leads to the following requirements: (a) If an NSIS protocol is only used end-to-end, then mobility need not be supported (b) If an NSIS protocol is used as a local QoS signaling mechanism then mobility must be supported, both on the QI-QC and QC-QC interface (c) If the same protocol is desired in (a) and (b), the protocol should be modular and the mobility aspects need to be separable from the rest Both of the above scenarios assume that the host is not NSIS-aware. This is a reasonable assumption in a first phase. In a later stage, when hosts are NSIS-aware, the host speaks the NSIS protocol, but as a local QoS signaling technology! This allows this case to be backwards compatible with the above scenarios. It means that (b) in the access is an NSIS protocol. It also means that the host will always trigger the local QoS signaling mechanism. This suggests the following definitions for the QI, QC, QR - QoS Initiator: Network entity, located at the boundary of a QoS domain, responsible for initiating a (local or end-to-end) QoS mechanism. If it is the QI of a local protocol, it can be triggered by higher layers (applications or end-to-end QoS Controller). If it is the QI of an end-to-end protocol, it can be triggered by applications or by the QoS Receiver of a local QoS signaling mechanism. - QoS Controller: Network entity responsible for interpreting and implementing the signalled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by a QI or another QC. -QoS Receiver: Network entity, located at the boundary of a QoS domain, responsible for terminating a (local or end-to-end) QoS mechanism. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger a QI or QC in the NSIS end-to-end protocol. If this can be accepted by the NSIS community, we propose to add this text to the requirements document as a clarification of the QI/QC model that is used there. _________________________________________________________________ Chat on line met vrienden en probeer MSN Messenger uit: http://messenger.msn.nl _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 10:38:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13998 for ; Thu, 21 Mar 2002 10:38:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16603 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 10:38:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15612; Thu, 21 Mar 2002 10:27:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15580 for ; Thu, 21 Mar 2002 10:27:05 -0500 (EST) Received: from hotmail.com (f72.pav2.hotmail.com [64.4.37.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13683 for ; Thu, 21 Mar 2002 10:26:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Mar 2002 07:26:32 -0800 Received: from 166.63.186.251 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 21 Mar 2002 15:26:32 GMT X-Originating-IP: [166.63.186.251] From: "Sven Van den Bosch" To: Cornelia.Kappler@icn.siemens.de, nsis@ietf.org Cc: maarten.buchli@alcatel.be Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Thu, 21 Mar 2002 16:26:32 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2002 15:26:32.0097 (UTC) FILETIME=[C77F9110:01C1D0EC] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Cornelia, I have some comments inline. >From: Kappler Cornelia >To: "'Sven Van den Bosch'" , nsis@ietf.org >Subject: RE: [NSIS] proposals related to NSIS WG draft >Date: Wed, 20 Mar 2002 18:57:43 +0100 > >Hi Sven, > >some inline comments on the new definitions / Reqs (which in general I >like) > >Cornelia > > > -----Original Message----- > > From: Sven Van den Bosch [SMTP:svenvandenbosch@hotmail.com] > > Sent: Tuesday, March 19, 2002 11:44 PM > > To: nsis@ietf.org > > Subject: [NSIS] proposals related to NSIS WG draft > > > > Hi all, > > > > As an outcome of this morning's NSIS meeting, we propose the following > > detailed additions to the WG draft. > > > > 1. Terminology > > > > - QoS Controller: Network entity responsible for interpreting and > > implementing the signaled QoS in the network. Failure to do so implies >an > > admission control decision. It can only be triggered by another NSIS >entity > > of the same instance (a QoS Initiator or another QoS Controller). > > > "instance": NSIS protocol instance? One should probably also provide the >definition of NSIS protocol instance. I see an NSIS protocol instance as a flow of NSIS messages staring at a QI and ending at a QR while passing through zero or more QCs. > > > - QoS Receiver: Network entity, located at the edge of or inside a QoS > > domain, responsible for terminating an instance of an NSIS protocol. It >has > > the additional functionality that it may initiate an acknowledgment >towards > > the QI and that it may trigger another NSIS entity (QoS Initiator or QoS > > Controller of another instance of the NSIS protocol) > > > why would it trigger a QC? The scenario here would be: the QC triggers, upon receiving an NSIS message, an instance of NSIS at a QI. Signalling then propagates at the lower NSIS layer to a QR which would hand over control back to the QC. In that case there would be a client-server relationship between the two instances of NSIS. > > > - QoS Initiator: Network entity, located at the edge of or inside a QoS > > domain, responsible for initiating an instance of an NSIS QoS signaling > > protocol. It may be triggered by the application layer, by the >termination > > of a local QoS signaling mechanism (possibly another instance of NSIS > > signaling) or by a QoS Controller of another of a client instance of an >NSIS > > protocol. It provides a mapping between the QoS parameters contained in >the > > trigger and the QoS parameters in the instance of the NSIS protocol for > > which is serves as QoS Initiator. > > > what is a "client instance of an NSIS protocol"? See the scenario above. > > > 2. Use cases/scenarios: 2 are available from the draft-buchli (sections >4.1 > > and 4.2) > > > > 3. Requirements > > > > * New requirements > > - in section MUST support priority > > The priority of a flow is essentially decoupled from its QoS >requirements. > > Therefore the protocol MUST support priority. As a consequence, it MUST > > support preemption of traffic flows in case of congestion or failure. A > > preemption action MAY trigger an attempt to resetup the request by means >of > > another instance of an NSIS signaling protocol. > > > > - in section 5.3: MAY support grouping of microflows (possibly only for > > feedback) > > As a consequence of the optimization for the interactive multimedia > > services, the signaling should allow one unique request for several >micro > > flows having the same origination and destination IP addresses. This is > > usually the case for multimedia SIP calls where the voice and video >micro > > flows follow the same path. This grouping of requests allows >optimization of > > the QoS processing. Note that this may be detrimental for the call setup > > time. The use of grouping for microflows may be restricted to teardown > > and/or notification messages when call setup time is a concern. > > > > - in section 5.5: Protocol content > > The per-flow QoS requests are mapped onto the bandwidth pipe, which is > > specified by an SLS. These pipes may provide statistical guarantees such >as > > delay and packet loss bounds (depending on the QoS class). In order to > > invoke per-flow QoS services the only parameter needed is a required >rate, a > > means to identify the data path (mapping on SLS) and eventually a > > reservation identifier. > > > - "per-flow QoS requests _may be_ mapped onto ..."? > - "rate" = bandwidth? OK, I agree on this one. It is possible that they do not need to be mapped. Rate indeed equals BW. > > > 1) Microflow/reservation description > > The signaling should allow the request to describe the microflow whose >QoS > > would be guaranteed by giving at least the source and destination IP > > > addresses of the media flow. In case the QC is stateful (per microflow) > > > > there may be a need to include a unique reservation identifier (e.g. QI > > identifier+counter) such that in case of e.g. a tear down message the > > reservation can be easily identified in the QC. > > > > 2) Traffic descriptor > > The required peak rate must be signaled. Optionally the traffic >parameters > > may be expressed in terms of token bucket parameters (similar to the >TSpec > > in RSVP). > > > > - in section 5.10: Interworking with provisioning > > > > * Requirements for which to change priority or formulation > > - MUST support signalling to entities outside the data path >(reformulation) > > > > - MUST NOT be adversely impacted by mobility aspects (applicable for > > end-to-end) > > A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT >be > > adversely affected by mobility issues. Any mobility scenario should be > > tackled by other uses of an NSIS protocol and is outside the realm of an > > end-to-end application of the NSIS protocol. > > > what is "other uses of an NSIS protocol"? What is an "e2e app of the NSIS >protocol" (I understand this looking at the figures you provided in a >recent email, however they are not part of the Req doc)Does this imply NSIS >is not supporting mobility? Or: it MUST be possible to support mobility >locally, without invoking e2e NSIS signaling? There may be some confusion here. We have identified three potential network parts where NSIS may be applicable: the host-to-first-hop, the access and edge-to-edge (covering core, interdomain). Clearly there are different requirements in each part. In the access and first-hop mobility will have to be supported. Edge-to-edge it must not be supported. We are going to try to put this in the requirements by providing the MUST, SHOULD, MAY tables per network part where they apply. We don't exclude that there will be one NSIS protocol (in which case it needs to be modular) but it is likely that there can be more. Hence, other uses of an NSIS protocol. The question about layering has come up in our discussions too and I think we ahve agreed to put the picture in my mail into the requirements document for some clarification on this. Do you think this is a good idea? Thanks for your comments, Sven. > > > > > _________________________________________________________________ > > Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp. > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis _________________________________________________________________ Chat on line met vrienden en probeer MSN Messenger uit: http://messenger.msn.nl _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 12:05:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17682 for ; Thu, 21 Mar 2002 12:05:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23319 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 12:05:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21439; Thu, 21 Mar 2002 11:57:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21365 for ; Thu, 21 Mar 2002 11:57:46 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17304 for ; Thu, 21 Mar 2002 11:57:42 -0500 (EST) From: maarten.buchli@alcatel.be Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2LGv2Z19090; Thu, 21 Mar 2002 17:57:02 +0100 (MET) Subject: RE: [NSIS] RE: section on QI/QC and QI/QC terminology To: Kappler Cornelia Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, danny.goderis@alcatel.be, Hancock Robert Date: Thu, 21 Mar 2002 17:34:31 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/21/2002 17:57:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cornelia, I have written some comments in-line with [MB]. Regards, Maarten Kappler Cornelia on 20/03/2002 19:00:03 To: Maarten BUCHLI/BE/ALCATEL@ALCATEL cc: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, nsis@ietf.org, Danny GODERIS/BE/ALCATEL@ALCATEL, Hancock Robert Subject: RE: [NSIS] RE: section on QI/QC and QI/QC terminology Hi Maarten and Sven, may be this discussion is outdated by what you've been discussing at the NSIS WG meeting which unfortunately I was not able to attend. Anyways Maarten wrote: > Hi Cornelia, > > The figure describing NSIS used as a local and as a global protocol was > intended as a general framework > and not specifically towards a certain scenario. > > Why do you consider it too restrictive? > > Regards, > Maarten > Cornelia: Let me summarize your framework as I understand it: You fix a two-level signaling hierarchy for any kind of signaling scenario (e.g. mobile and fixed): end-to-end (global) and local. In a first step, NSIS is only global, and interworks with local signaling mechanisms. I.e. it is nowhere "stand-alone". In a second step, we would also have a local NSIS signaling protocol, which may replace the "legacy" local signaling. Global and local signaling must always work together, i.e. with just one of them QoS cannot be set up e2e. The end host never initiates global / end-to-end signaling, but just does local signaling to some access router (gateway), which acts as a proxy and QI, and translates the reservation into NSIS e2e/global signaling Now why do I consider this as too restrictive: - why is it necessary to always involve a proxy? Why would the end host never initiate e2e signaling? [MB] First option is that access networks will still use their technology specific QoS protocol. In this case there is a clear need to have an entity (proxy) that translated the access QoS signaling to the global NSIS signaling. Another (more future oriented) option is that the access network speaks NSIS. However, such a (local) NSIS access protocol requires much more functionality, e.g. mobility support. Therefore, the local NSIS protocol in the access will be much more specific while the QoS signaling in the core can be kept as simple as possible. Also, a proxy allows for smooth migration from access specific QoS protocols to an NSIS protocol. But indeed, there may be cases where a host initiates the global NSIS signaling. - it fixes a two-level hierarchy. However, more deeply nested hierarchies are also possible. E.g. when some edge router pipes a per-flow aggregation into a (possibly previously set-up) aggregate reservation. Note this idea can even be extended by the next edge router piping the aggregates it receives into "super- aggregates". [MB] Agree, the number of hierarchy may be arbitrary although in most cases two levels of hierarchy should be sufficient. "Sven>> Setting up the aggregates is a local matter for each of the QCs. A QC may choose to modify its aggregate based on incoming micro-flows but this process will not be triggered by microflow arrivals." Cornelia: When a QC initiates an aggregate reservation it is a QI! (or rather: the logical QC instance on a particular node receives per flow signaling and triggers (based on incoming micro-flows, but not because of a particular microflow arrival, I agree) the logical QI instance on the same node to initiate or modify an aggregate reservation.) This is also consistent with the terminology definition you sent out after the NSIS meeting, where the QC may trigger a QI to initiate another instance of the NSIS protocol Another example of a more-than-two-level hierarchy: a QC initiates per-flow e2e signaling. At the edge of some administrative domain a QC tunnels it to the other edge of the domain and initiates local (domain-specific) NSIS signaling, may be because a mapping of QoS parameters to local scope parameters is necessary. Now this administrative domain consists of more than one QoS domain, i.e. different QoS mechanisms are supported. At the edge of each of these domains, local (non-NSIS) signaling mechanisms are therefore initiated (e.g. RSVP, or no signaling, and instead DSCPs). This last example may be a bitfar fetched... however I think we should allow the protocol to be arbitrarily deeply nested, if only because it is more general and we dont know what the future is going to bring. Besides I dont see having an arbitrary number of levels would make the protocol more complicated - what about a scenario where no end host is involved, but a BB triggers an edge router to set-up an aggregate reservation through a domain? The BB would send this trigger because of some SLA agreement process rather than because of the interpretation of per-flow reservations. I dont think this would map to your framework either, because there is no reason for starting with a local NSIS signaling that later is translated into global NSIS signaling. [MB] Indeed, the BB will trigger the setup of traffic trunks (i.e.bandwidth pipes) due to the establishment of an SLA. How a BB provisions SLSs is outside the scope of NSIS in my opinion. Some local NSIS protocol may be involved but for sure this won't be translated into a global NSIS protocol. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 14:41:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23051 for ; Thu, 21 Mar 2002 14:41:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06401 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 14:41:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06223; Thu, 21 Mar 2002 14:38:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06176 for ; Thu, 21 Mar 2002 14:38:11 -0500 (EST) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22955 for ; Thu, 21 Mar 2002 14:38:07 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1XV9CL2L>; Thu, 21 Mar 2002 19:37:32 -0000 Received: from roke.co.uk (percy.roke.co.uk [193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GZCWHSWF; Thu, 21 Mar 2002 19:37:24 -0000 From: "Hancock, Robert" To: nsis@ietf.org Message-ID: <3C9A3700.8090709@roke.co.uk> Date: Thu, 21 Mar 2002 19:39:44 +0000 User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] interim meeting location? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear All, It has been suggested that the NSIS work could benefit from an interim face to face meeting, sometime in May. We (the Siemens lot) enjoyed our time so much here this week that we'd like to offer to host such a meeting; the location would be Berlin. We'd prefer the second half of May for this. Obviously, we still have to work out what the subject(s) of the interim meeting would be, and then whether it is definitely needed. We need to start that discussion anyway (in a separate thread!), but it seems sensible to check out the administrative/organisational aspects of the meeting in parallel, to be prepared. All the best, Robert H. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 14:45:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23218 for ; Thu, 21 Mar 2002 14:45:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06658 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 14:45:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06604; Thu, 21 Mar 2002 14:44:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06573 for ; Thu, 21 Mar 2002 14:44:18 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23174 for ; Thu, 21 Mar 2002 14:44:14 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2LJhki00122 for ; Thu, 21 Mar 2002 13:43:46 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g2LJhkW13077 for ; Thu, 21 Mar 2002 13:43:46 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 21 13:43:45 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 13:43:45 -0600 Message-ID: From: "Jonas Wiorek (EWU)" To: "'nsis@ietf.org'" Date: Thu, 21 Mar 2002 13:43:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D110.B5CD5820" Subject: [NSIS] (no subject) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D110.B5CD5820 Content-Type: text/plain; charset="iso-8859-1" subscribe ------_=_NextPart_001_01C1D110.B5CD5820 Content-Type: text/html; charset="iso-8859-1"
subscribe
------_=_NextPart_001_01C1D110.B5CD5820-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 15:09:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23859 for ; Thu, 21 Mar 2002 15:09:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08338 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 15:09:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07386; Thu, 21 Mar 2002 15:01:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07316 for ; Thu, 21 Mar 2002 15:00:59 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23534 for ; Thu, 21 Mar 2002 14:59:57 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2LJxHF10100 for ; Thu, 21 Mar 2002 21:59:17 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Mar 2002 21:59:58 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Mar 2002 21:59:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] interim meeting location? Date: Thu, 21 Mar 2002 21:59:58 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64CAA@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] interim meeting location? Thread-Index: AcHRENZgHmNr1x6LRD+kPWnyq81FIgAABNzg To: X-OriginalArrivalTime: 21 Mar 2002 19:59:58.0503 (UTC) FILETIME=[FA7A7370:01C1D112] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA07325 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi All, Robert, thanks for the offer. I've been talking to many folks & still working out some issues. One strong possibility may be the Bay Area in California. If this would be impossible for some folks, please let me know. The timeframe is mid-May, 2 or 3 days would be sufficient. Topics will be Requirements document, Protocol Comparison document & Signaling Framework document. Additionally, some guest speakers are being considered. John > It has been suggested that the NSIS work could benefit from an interim > face to face meeting, sometime in May. We (the Siemens lot) enjoyed our time so > much here this week that we'd like to offer to host such a meeting; the location would > be Berlin. We'd prefer the second half of May for this. > > Obviously, we still have to work out what the subject(s) of the interim > meeting would be, and then whether it is definitely needed. > We need to start that discussion anyway (in a separate thread!), but it seems > sensible to check out the administrative/organisational > aspects of the meeting in parallel, to be prepared. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 16:12:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25697 for ; Thu, 21 Mar 2002 16:12:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12648 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 16:12:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11820; Thu, 21 Mar 2002 16:00:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11772 for ; Thu, 21 Mar 2002 16:00:04 -0500 (EST) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25366 for ; Thu, 21 Mar 2002 15:59:59 -0500 (EST) Received: from melkki.cs.Helsinki.FI (IDENT:jmanner@melkki.cs.Helsinki.FI [128.214.48.122]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g2LKvHr17702; Thu, 21 Mar 2002 22:59:59 +0200 Date: Thu, 21 Mar 2002 22:57:11 +0200 (EET) From: Jukka MJ Manner To: john.loughney@nokia.com cc: nsis@ietf.org Subject: RE: [NSIS] interim meeting location? In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64CAA@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, I would like to see the meeting held in Europe, and not in the exact middle of May. I believe Robert agrees. If the meeting is held in the bay area the last week of May, I would be able to take part. Cheers, Jukka On Thu, 21 Mar 2002 john.loughney@nokia.com wrote: > Hi All, > > Robert, thanks for the offer. > > I've been talking to many folks & still working out some issues. > One strong possibility may be the Bay Area in California. If > this would be impossible for some folks, please let me know. > > The timeframe is mid-May, 2 or 3 days would be sufficient. > > Topics will be Requirements document, Protocol Comparison document > & Signaling Framework document. Additionally, some guest speakers > are being considered. > > John > > > > It has been suggested that the NSIS work could benefit from an interim > > face to face meeting, sometime in May. We (the Siemens lot) enjoyed our time so > > much here this week that we'd like to offer to host such a meeting; the location would > > be Berlin. We'd prefer the second half of May for this. > > > > Obviously, we still have to work out what the subject(s) of the interim > > meeting would be, and then whether it is definitely needed. > > We need to start that discussion anyway (in a separate thread!), but it seems > > sensible to check out the administrative/organisational > > aspects of the meeting in parallel, to be prepared. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 16:52:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26769 for ; Thu, 21 Mar 2002 16:52:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15231 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 16:52:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14469; Thu, 21 Mar 2002 16:37:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14438 for ; Thu, 21 Mar 2002 16:37:56 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26360 for ; Thu, 21 Mar 2002 16:37:51 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 22:37:56 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: SV: [NSIS] interim meeting location? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 21 Mar 2002 22:37:55 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBE1@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] interim meeting location? Thread-Index: AcHRG26DXoKEqoANR4SfjpJ9hncDYQABGR7C To: , Cc: X-OriginalArrivalTime: 21 Mar 2002 21:37:56.0312 (UTC) FILETIME=[A9ECED80:01C1D120] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA14439 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, as most parties that have been involved in the discussions about the requirements document is located in Europe, I am in (strong) favour of the suggestion from Siemens about holding the interim-meeting in Berlin in May. best regards, Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 16:56:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26835 for ; Thu, 21 Mar 2002 16:56:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15444 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 16:56:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14833; Thu, 21 Mar 2002 16:46:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14735 for ; Thu, 21 Mar 2002 16:45:56 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26501 for ; Thu, 21 Mar 2002 16:45:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2LLjct00193 for ; Thu, 21 Mar 2002 23:45:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Mar 2002 23:45:26 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Mar 2002 23:45:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [NSIS] interim meeting location? Date: Thu, 21 Mar 2002 23:45:24 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64CB0@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] interim meeting location? Thread-Index: AcHRG26DXoKEqoANR4SfjpJ9hncDYQABGR7CAABk19A= To: , Cc: X-OriginalArrivalTime: 21 Mar 2002 21:45:25.0229 (UTC) FILETIME=[B58039D0:01C1D121] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA14754 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, > as most parties that have been involved in the discussions > about the requirements document is located in Europe, I am in > (strong) favour of the suggestion from Siemens about holding > the interim-meeting in Berlin in May. This is actually not true, there are a fair number of folks in the US and elsewhere. I already have gotten an indication of a number of US folks who cannot make it to Europe, so I will have to balance it. However, if someone cannot make the interim meeting, we will try to find a location that is easiest. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 17:57:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28661 for ; Thu, 21 Mar 2002 17:57:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20069 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 17:57:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19873; Thu, 21 Mar 2002 17:52:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19842 for ; Thu, 21 Mar 2002 17:52:22 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28523 for ; Thu, 21 Mar 2002 17:52:16 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 23:52:21 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 21 Mar 2002 23:52:21 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBE3@TMS041MB.tcad.telia.se> Thread-Topic: proposal to add requirement text Thread-Index: AcHRKw9zJhjH5667QG6caMIFiFLapw== To: Cc: X-OriginalArrivalTime: 21 Mar 2002 22:52:21.0967 (UTC) FILETIME=[0FA9CDF0:01C1D12B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA19843 Subject: [NSIS] proposal to add requirement text Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit All, off line discussions revealed that the scalability sections (5.6) could be slightly updated. I suggest wording along these lines: The nsis architecture should give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. This can be achieved by many different methods, for example message aggregation, by ignoring signaling message, header compression or minimizing functionality. The architecture may choose any of these methods as long as the requirement is met. (the reasoning behind the words are the following, if I have the ability to control the load the protocol(s) generate in a singel device, the protocol will "scale". And the words does not mandate any particular solution) A related requirement that was discussed was transport quality for the signaling protocol where I propose the following text. The nsis architecture should allow the network operator to assign the nsis protocol messages a certain transport quality. As signaling opens up for possible denial-of-service attacks, this requirement gives the network operator a mean, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within his/her network. From protocol design this requirement states that the protocol messages should be detectable, at least where the control and assignment of the messages priority is done. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 18:21:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29570 for ; Thu, 21 Mar 2002 18:21:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21965 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 18:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21374; Thu, 21 Mar 2002 18:12:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21338 for ; Thu, 21 Mar 2002 18:12:30 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29243 for ; Thu, 21 Mar 2002 18:12:26 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Mar 2002 00:12:28 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 22 Mar 2002 00:12:28 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBE7@TMS041MB.tcad.telia.se> Thread-Topic: req. section 5.1.9 Thread-Index: AcHRLd5ftwDU9QN3SkKeA//4CnTNcA== To: Cc: X-OriginalArrivalTime: 21 Mar 2002 23:12:28.0536 (UTC) FILETIME=[DED59F80:01C1D12D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA21339 Subject: [NSIS] req. section 5.1.9 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit All, I believe section 5.1.9 needs a small update. The proposed changes have been discussed with, but not agreed to by the draft editor. Current text: The QoS signaling should be independent of the paradigm and mechanism of QoS provisioning. The independence allows for using the NSIS protocol together with various QoS technologies. Proposed text: The architecture should support independence between signaling, what is being signaled and how a device chooses to use the information that is being signaled. This allows for different information being signaled as well as devices behaving differently to what is being signaled. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 18:33:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29892 for ; Thu, 21 Mar 2002 18:33:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23146 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 18:33:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21875; Thu, 21 Mar 2002 18:20:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21846 for ; Thu, 21 Mar 2002 18:20:23 -0500 (EST) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29544 for ; Thu, 21 Mar 2002 18:20:19 -0500 (EST) Received: from melkki.cs.Helsinki.FI (IDENT:jmanner@melkki.cs.Helsinki.FI [128.214.48.122]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g2LNHdr06615; Fri, 22 Mar 2002 01:20:21 +0200 Date: Fri, 22 Mar 2002 01:17:32 +0200 (EET) From: Jukka MJ Manner To: Anders.P.Bergsten@telia.se cc: nsis@ietf.org, Subject: Re: [NSIS] proposal to add requirement text In-Reply-To: <1BF8A5964E4EFA41A094B835FCA7129110CBE3@TMS041MB.tcad.telia.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, the first req sounds good, but the second, IMO, is written the wrong way: "The signalling messages must be identifiable in an efficient way (with some definition of "efficient":)." This then allows a network operator to assign priorities etc. to those signalling packets. So, don't mandate what to do with the packets, but make it (easily) possible to handle these packets in a specific way. Cheers, JiM On Thu, 21 Mar 2002 Anders.P.Bergsten@telia.se wrote: > All, > off line discussions revealed that the scalability sections (5.6) could > be slightly updated. > > I suggest wording along these lines: > The nsis architecture should give the ability to constrain the load > (CPU load, memory space, signaling bandwidth consumption and signaling > intensity) on devices where it is needed. This can be achieved by many > different methods, for example message aggregation, by ignoring > signaling message, header compression or minimizing functionality. The > architecture may choose any of these methods as long as the requirement > is met. > (the reasoning behind the words are the following, if I have the > ability to control the load the protocol(s) generate in a singel device, > the protocol will "scale". And the words does not mandate any particular > solution) > A related requirement that was discussed was transport quality for the > signaling protocol where I propose the following text. > The nsis architecture should allow the network operator to assign the > nsis protocol messages a certain transport quality. As signaling opens > up for possible denial-of-service attacks, this requirement gives the > network operator a mean, but also the obligation, to trade-off between > signaling latency and the impact (from the signaling messages) on > devices within his/her network. From protocol design this requirement > states that the protocol messages should be detectable, at least where > the control and assignment of the messages priority is done. > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 18:45:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00298 for ; Thu, 21 Mar 2002 18:45:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23489 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 18:46:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23229; Thu, 21 Mar 2002 18:36:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23198 for ; Thu, 21 Mar 2002 18:36:51 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29956 for ; Thu, 21 Mar 2002 18:36:46 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Mar 2002 00:36:50 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: SV: [NSIS] proposal to add requirement text X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 22 Mar 2002 00:36:50 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBEC@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] proposal to add requirement text Thread-Index: AcHRLvuulMZna8qGSiSIsJHHP53YVwAAjdit To: Cc: , X-OriginalArrivalTime: 21 Mar 2002 23:36:50.0467 (UTC) FILETIME=[46369730:01C1D131] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA23199 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Jukka, I guess our difference is just what the requirement should be used for. The architectural requirement is to be able to control the message intensity (for denial of service reasons) and control the signaling delay (for express forwarding). The protocol requirement is exactly what you state. So this depends only on what kind of requirements we want to state. I tried to capture the architectural requirement, and also write some words about what the impact this will have on the protocol design. If you and others want to state it the other way around, I have no major objections to it - just as long as everything is stated. Anders ps, resent because I missed to send it to the list. -----Ursprungligt meddelande----- Från: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Skickat: to 2002-03-21 11:17 Till: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98 Kopia: nsis@ietf.org; brunner@ccrle.nec.de Ämne: Re: [NSIS] proposal to add requirement text Hi, the first req sounds good, but the second, IMO, is written the wrong way: "The signalling messages must be identifiable in an efficient way (with some definition of "efficient":)." This then allows a network operator to assign priorities etc. to those signalling packets. So, don't mandate what to do with the packets, but make it (easily) possible to handle these packets in a specific way. Cheers, JiM On Thu, 21 Mar 2002 Anders.P.Bergsten@telia.se wrote: > All, > off line discussions revealed that the scalability sections (5.6) could > be slightly updated. > > I suggest wording along these lines: > The nsis architecture should give the ability to constrain the load > (CPU load, memory space, signaling bandwidth consumption and signaling > intensity) on devices where it is needed. This can be achieved by many > different methods, for example message aggregation, by ignoring > signaling message, header compression or minimizing functionality. The > architecture may choose any of these methods as long as the requirement > is met. > (the reasoning behind the words are the following, if I have the > ability to control the load the protocol(s) generate in a singel device, > the protocol will "scale". And the words does not mandate any particular > solution) > A related requirement that was discussed was transport quality for the > signaling protocol where I propose the following text. > The nsis architecture should allow the network operator to assign the > nsis protocol messages a certain transport quality. As signaling opens > up for possible denial-of-service attacks, this requirement gives the > network operator a mean, but also the obligation, to trade-off between > signaling latency and the impact (from the signaling messages) on > devices within his/her network. From protocol design this requirement > states that the protocol messages should be detectable, at least where > the control and assignment of the messages priority is done. > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 19:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00790 for ; Thu, 21 Mar 2002 19:03:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24693 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 19:03:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23928; Thu, 21 Mar 2002 18:55:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23894 for ; Thu, 21 Mar 2002 18:55:52 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00581 for ; Thu, 21 Mar 2002 18:55:50 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2LNtEB10334; Fri, 22 Mar 2002 00:55:19 +0100 (MET) Subject: Re: [NSIS] req. section 5.1.9 To: Anders.P.Bergsten@telia.se Cc: nsis@ietf.org, brunner@ccrle.nec.de X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 22 Mar 2002 00:55:11 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 00:55:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, I have the impression that the text you propose mixes two requirements we have already in the draft. 5.1.4 Decoupling of protocol and information it is carrying 5.1.9 Independence of signaling and provisioning paradigm If you agree, I would propose to leave it as it is, unless there is a specific reason for combining the requirements. CU, Sven. Anders.P.Bergsten@telia.se on 22/03/2002 00:12:28 To: nsis@ietf.org cc: brunner@ccrle.nec.de(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject [NSIS] req. section 5.1.9 : All, I believe section 5.1.9 needs a small update. The proposed changes have been discussed with, but not agreed to by the draft editor. Current text: The QoS signaling should be independent of the paradigm and mechanism of QoS provisioning. The independence allows for using the NSIS protocol together with various QoS technologies. Proposed text: The architecture should support independence between signaling, what is being signaled and how a device chooses to use the information that is being signaled. This allows for different information being signaled as well as devices behaving differently to what is being signaled. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 19:29:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01098 for ; Thu, 21 Mar 2002 19:29:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25741 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 19:30:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25159; Thu, 21 Mar 2002 19:15:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25125 for ; Thu, 21 Mar 2002 19:15:46 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00978 for ; Thu, 21 Mar 2002 19:15:43 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16oCiZ-0006pM-00; Fri, 22 Mar 2002 01:15:39 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16oCiZ-0000Qo-00; Fri, 22 Mar 2002 01:15:39 +0100 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2M0Fcf03307; Fri, 22 Mar 2002 01:15:38 +0100 Message-Id: <200203220015.g2M0Fcf03307@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Anders.P.Bergsten@telia.se cc: nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] proposal to add requirement text In-Reply-To: Your message of "Thu, 21 Mar 2002 23:52:21 +0100." <1BF8A5964E4EFA41A094B835FCA7129110CBE3@TMS041MB.tcad.telia.se> References: <1BF8A5964E4EFA41A094B835FCA7129110CBE3@TMS041MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Mar 2002 01:15:38 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, I don't think that it really replaces the scalability statement, but maybe a good addition to it. Scalability is usually about considering the effects on system performance when scaling some system parameters in the order of magnitudes (different scales). This is somehow different from the statement of minimizing/constraining things. The second suggested paragraph on transport quality for the signaling protocol is IMO a non-requirement (i.e. not really a requirement): 1. every protocol has some identifier in the lower layer (thus they are always "detectable") 2. although it is sensible and really desirable to have a faster/better/isolated transport for signaling messages, it should be left to the provider to do so and if so by what means. [BTW: please, can you break the lines into a reasonable length, because quoting is awkward otherwise?] Regards, Roland > off line discussions revealed that the scalability sections (5.6) could be slightly updated. > > I suggest wording along these lines: > > The nsis architecture should give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. This can be achieved by many different methods, for example message aggregation, by ignoring signaling message, header compression or minimizing functionality. The architecture may choose any of these methods as long as the requirement is met. > > (the reasoning behind the words are the following, if I have the ability to control the load the protocol(s) generate in a singel device, the protocol will "scale". And the words does not mandate any particular solution) > > A related requirement that was discussed was transport quality for the signaling protocol where I propose the following text. > > The nsis architecture should allow the network operator to assign the nsis protocol messages a certain transport quality. As signaling opens up for possible denial-of-service attacks, this requirement gives the network operator a mean, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within his/her network. From protocol design this requirement states that the protocol messages should be detectable, at least where the control and assignment of the messages priority is done. > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 19:32:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01182 for ; Thu, 21 Mar 2002 19:32:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26285 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 19:33:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25501; Thu, 21 Mar 2002 19:24:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25476 for ; Thu, 21 Mar 2002 19:24:14 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01036 for ; Thu, 21 Mar 2002 19:24:12 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16oCqr-0006vc-00; Fri, 22 Mar 2002 01:24:13 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16oCqr-0000Y7-00; Fri, 22 Mar 2002 01:24:13 +0100 Received: from tpce10.ipv6.tm.uka.de ([127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2M0OCf03357; Fri, 22 Mar 2002 01:24:12 +0100 Message-Id: <200203220024.g2M0OCf03357@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Anders.P.Bergsten@telia.se cc: nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] req. section 5.1.9 In-Reply-To: Your message of "Fri, 22 Mar 2002 00:12:28 +0100." <1BF8A5964E4EFA41A094B835FCA7129110CBE7@TMS041MB.tcad.telia.se> References: <1BF8A5964E4EFA41A094B835FCA7129110CBE7@TMS041MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Mar 2002 01:24:12 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, I think you misinterpreted this section a little bit. It merely says that you can use an arbitrary QoS architecture (e.g. IntServ/DiffServ, whatever else) within your administered domain and the signaling protocol should not depend on a particular QoS architecture or its mechanisms (which is an important requirement). Or am I wrong here? Regards, Roland > I believe section 5.1.9 needs a small update. The proposed changes have been discussed with, but not agreed to by the draft editor. > > Current text: > The QoS signaling should be independent of the paradigm and mechanism of QoS provisioning. The independence allows for using the NSIS protocol together with various QoS technologies. > > Proposed text: > The architecture should support independence between signaling, what is being signaled and how a device chooses to use the information that is being signaled. This allows for different information being signaled as well as devices behaving differently to what is being signaled. > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 19:59:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01621 for ; Thu, 21 Mar 2002 19:59:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27188 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 19:59:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26938; Thu, 21 Mar 2002 19:51:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26904 for ; Thu, 21 Mar 2002 19:51:31 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01509 for ; Thu, 21 Mar 2002 19:51:28 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16oDHF-0007ET-00; Fri, 22 Mar 2002 01:51:29 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16oDHF-0000yZ-00; Fri, 22 Mar 2002 01:51:29 +0100 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2M0pTf03465; Fri, 22 Mar 2002 01:51:29 +0100 Message-Id: <200203220051.g2M0pTf03465@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: "Sven Van den Bosch" cc: brunner@ccrle.nec.de, nsis@ietf.org Subject: Re: [NSIS] text on layering - original mail In-Reply-To: Your message of "Thu, 21 Mar 2002 03:49:07 +0100." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Mar 2002 01:51:29 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven, Why do you make restrictions on triggering? I would remove that. For instance, you state that a QC can only be triggered by a QI and a QC. However, there are cases when a QC may decide to create an aggregate out of existing reservations, so it may start a new protocol (trans)action to other QCs in (a) without being triggered by other entities. Regards, Roland svenvandenbosch@hotmail.com said: > This suggests the following definitions for the QI, QC, QR > - QoS Initiator: Network entity, located at the boundary of a QoS > domain, responsible for initiating a (local or end-to-end) QoS > mechanism. If it is the QI of a local protocol, it can be triggered by > higher layers (applications or end-to-end QoS Controller). If it is > the QI of an end-to-end protocol, it can be triggered by applications > or by the QoS Receiver of a local QoS signaling mechanism. > - QoS Controller: Network entity responsible for interpreting and > implementing the signalled QoS in the network. Failure to do so > implies an admission control decision. It can only be triggered by a > QI or another QC. > -QoS Receiver: Network entity, located at the boundary of a QoS > domain, responsible for terminating a (local or end-to-end) QoS > mechanism. It has the additional functionality that it may initiate an > acknowledgment towards the QI and that it may trigger a QI or QC in > the NSIS end-to-end protocol. > If this can be accepted by the NSIS community, we propose to add this > text to the requirements document as a clarification of the QI/QC > model that is used there. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 20:20:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02018 for ; Thu, 21 Mar 2002 20:20:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28371 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 20:20:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28094; Thu, 21 Mar 2002 20:11:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28017 for ; Thu, 21 Mar 2002 20:11:10 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01827 for ; Thu, 21 Mar 2002 20:09:28 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2M18JA17499; Fri, 22 Mar 2002 02:08:19 +0100 (MET) Subject: Re: [NSIS] text on layering - original mail To: Roland Bless Cc: "Sven Van den Bosch" , brunner@ccrle.nec.de, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 22 Mar 2002 02:08:14 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 02:08:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Roland, I agree, although you could say that even in this case it is first triggered by a QC or QI. What I meant was that it couldn't be triggered by a QR or by applications. Of course it can sometimes act on its own initiative. To make this more clear, I propose to modify the text to: ... It can trigger another instance of NSIS signaling or be triggered by a QC or a QI. Thanks, Sven. Roland Bless on 22/03/2002 01:51:29 To: "Sven Van den Bosch" cc: brunner@ccrle.nec.de, nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject Re: [NSIS] text on layering - original mail : Hi Sven, Why do you make restrictions on triggering? I would remove that. For instance, you state that a QC can only be triggered by a QI and a QC. However, there are cases when a QC may decide to create an aggregate out of existing reservations, so it may start a new protocol (trans)action to other QCs in (a) without being triggered by other entities. Regards, Roland svenvandenbosch@hotmail.com said: > This suggests the following definitions for the QI, QC, QR > - QoS Initiator: Network entity, located at the boundary of a QoS > domain, responsible for initiating a (local or end-to-end) QoS > mechanism. If it is the QI of a local protocol, it can be triggered by > higher layers (applications or end-to-end QoS Controller). If it is > the QI of an end-to-end protocol, it can be triggered by applications > or by the QoS Receiver of a local QoS signaling mechanism. > - QoS Controller: Network entity responsible for interpreting and > implementing the signalled QoS in the network. Failure to do so > implies an admission control decision. It can only be triggered by a > QI or another QC. > -QoS Receiver: Network entity, located at the boundary of a QoS > domain, responsible for terminating a (local or end-to-end) QoS > mechanism. It has the additional functionality that it may initiate an > acknowledgment towards the QI and that it may trigger a QI or QC in > the NSIS end-to-end protocol. > If this can be accepted by the NSIS community, we propose to add this > text to the requirements document as a clarification of the QI/QC > model that is used there. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 21:12:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02966 for ; Thu, 21 Mar 2002 21:12:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00649 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 21:12:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00547; Thu, 21 Mar 2002 21:09:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00516 for ; Thu, 21 Mar 2002 21:09:00 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02918 for ; Thu, 21 Mar 2002 21:08:56 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2M29At02849 for ; Fri, 22 Mar 2002 04:09:10 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 22 Mar 2002 04:08:58 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Mar 2002 04:08:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 22 Mar 2002 04:08:56 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64CC4@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] text on layering - original mail Thread-Index: AcHRPpfaRqBx1+NbTP2GXdFqJ/Ut2gAB6IRA To: X-OriginalArrivalTime: 22 Mar 2002 02:08:57.0061 (UTC) FILETIME=[86165150:01C1D146] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA00517 Subject: [NSIS] NSIS Interim Meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I'm trying to find out a good time & place for an interim meeting. There are a lot of scheduling conflicts, but I will try my best to find something that works. Can everyone who is fairly certain that they would attend send me a PERSONAL & DIRECT mail. Time Frame: May Place: Europe / East Coast US / West Coast US Please tell me what you CAN NOT do. Thanks, JOhn _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 21 21:48:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04925 for ; Thu, 21 Mar 2002 21:48:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02647 for nsis-archive@odin.ietf.org; Thu, 21 Mar 2002 21:48:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02105; Thu, 21 Mar 2002 21:36:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02074 for ; Thu, 21 Mar 2002 21:36:13 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03573 for ; Thu, 21 Mar 2002 21:36:09 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Mar 2002 03:36:13 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: SV: [NSIS] req. section 5.1.9 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 22 Mar 2002 03:36:13 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CBED@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] req. section 5.1.9 Thread-Index: AcHRM9+NgG19IF7YSJudTnCQK+FFFQAFdTYt To: Cc: , X-OriginalArrivalTime: 22 Mar 2002 02:36:14.0014 (UTC) FILETIME=[55C985E0:01C1D14A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA02075 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Yes I agree. I didn't intend to mix them. However, what I set out to do was to remove the term provisioning, because it implies different things for different people. > If you agree, I would propose to leave it as it is, unless there is a > specific reason for combining the requirements. agreed for the time being. I'd try to come up with a better term than "provisioning" however I cannot come up with one during the IESG planery... Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 09:20:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22008 for ; Fri, 22 Mar 2002 09:20:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06468 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 09:20:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05626; Fri, 22 Mar 2002 09:17:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05437 for ; Fri, 22 Mar 2002 09:17:10 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20574 for ; Fri, 22 Mar 2002 08:15:53 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2MC2m628513; Fri, 22 Mar 2002 13:02:48 +0100 (MET) Subject: Re: SV: [NSIS] req. section 5.1.9 To: Anders.P.Bergsten@telia.se Cc: nsis@ietf.org, brunner@ccrle.nec.de X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 22 Mar 2002 13:02:44 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 13:02:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, I see two possibilities: 1. define the term provisioning so it is clear to everyone what is meant in this case 2. say something like: "NSIS signaling is independent of the (QoS) technology that is used for the local implementation of the requested QoS." The idea is to leave it open whether you have over-provisioning, diffserv, ... right? What do you think? Sven. Anders.P.Bergsten@telia.se on 22/03/2002 03:36:13 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org, brunner@ccrle.nec.de Subject SV: [NSIS] req. section 5.1.9 : Yes I agree. I didn't intend to mix them. However, what I set out to do was to remove the term provisioning, because it implies different things for different people. > If you agree, I would propose to leave it as it is, unless there is a > specific reason for combining the requirements. agreed for the time being. I'd try to come up with a better term than "provisioning" however I cannot come up with one during the IESG planery... Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 09:20:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22027 for ; Fri, 22 Mar 2002 09:20:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06483 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 09:20:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05583; Fri, 22 Mar 2002 09:17:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05431 for ; Fri, 22 Mar 2002 09:17:10 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20280 for ; Fri, 22 Mar 2002 08:06:01 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA14332 for ; Fri, 22 Mar 2002 10:46:37 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA28515 for ; Fri, 22 Mar 2002 10:46:23 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 10:47:01 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656A9@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: nsis@ietf.org Subject: FW: [NSIS] interim meeting location? Date: Fri, 22 Mar 2002 10:46:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > -----Original Message----- > From: Kappler Cornelia > Sent: Friday, March 22, 2002 10:46 AM > To: 'john.loughney@nokia.com' > Subject: RE: [NSIS] interim meeting location? > > Hi all, > > as the potential host I'd like to support the Berlin idea :-) > > The last two NSIS (IETF) meetings where held in the US, the one after the interim meeting will take place in Japan. So the interim meeting in Europe seems like a fair idea? (Besides, Berlin is a very interesting place to visit!) > > Cornelia > > PS.: I couldn't travel to the US. > > > > -----Original Message----- > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > Sent: Thursday, March 21, 2002 10:45 PM > To: Anders.P.Bergsten@telia.se; jmanner@cs.helsinki.fi > Cc: nsis@ietf.org > Subject: RE: [NSIS] interim meeting location? > > Hi all, > > > as most parties that have been involved in the discussions > > about the requirements document is located in Europe, I am in > > (strong) favour of the suggestion from Siemens about holding > > the interim-meeting in Berlin in May. > > This is actually not true, there are a fair number of folks in > the US and elsewhere. I already have gotten an indication of > a number of US folks who cannot make it to Europe, so I will > have to balance it. > > However, if someone cannot make the interim meeting, we will > try to find a location that is easiest. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 13:24:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28037 for ; Fri, 22 Mar 2002 13:24:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08344 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 13:24:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07979; Fri, 22 Mar 2002 13:18:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07951 for ; Fri, 22 Mar 2002 13:18:29 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27879 for ; Fri, 22 Mar 2002 13:18:27 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA16887; Fri, 22 Mar 2002 19:18:26 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA10532; Fri, 22 Mar 2002 19:18:11 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 19:18:50 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656B0@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" , Roland Bless Cc: brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] text on layering - original mail Date: Fri, 22 Mar 2002 19:18:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I think the simplest way to include "starting of an aggregate reservation" is viewing the (logical) entity starting this aggregate as a QI. Note the "logical". I'm not proposing additional functionality in an aggregating router. Cornelia > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Friday, March 22, 2002 2:08 AM > To: Roland Bless > Cc: Sven Van den Bosch; brunner@ccrle.nec.de; nsis@ietf.org > Subject: Re: [NSIS] text on layering - original mail > > Hi Roland, > > I agree, although you could say that even in this case it is first > triggered by a QC or QI. What I meant was that it couldn't be triggered by > a QR or by applications. Of course it can sometimes act on its own > initiative. To make this more clear, I propose to modify the text to: > ... It can trigger another instance of NSIS signaling or be triggered by a > QC or a QI. > > Thanks, > Sven. > > > > > > Roland Bless on 22/03/2002 01:51:29 > > > > To: "Sven Van den Bosch" > > > cc: brunner@ccrle.nec.de, nsis@ietf.org(bcc: Sven > VAN DEN BOSCH/BE/ALCATEL) > > > > Subject Re: [NSIS] text on layering - original mail > : > > > > > > > Hi Sven, > > Why do you make restrictions on triggering? I would remove > that. For instance, you state that a QC can only be triggered by > a QI and a QC. However, there are cases when a QC may decide > to create an aggregate out of existing reservations, so it > may start a new protocol (trans)action to other QCs in (a) > without being triggered by other entities. > > Regards, > Roland > > svenvandenbosch@hotmail.com said: > > This suggests the following definitions for the QI, QC, QR > > - QoS Initiator: Network entity, located at the boundary of a QoS > > domain, responsible for initiating a (local or end-to-end) QoS > > mechanism. If it is the QI of a local protocol, it can be triggered by > > higher layers (applications or end-to-end QoS Controller). If it is > > the QI of an end-to-end protocol, it can be triggered by applications > > or by the QoS Receiver of a local QoS signaling mechanism. > > > - QoS Controller: Network entity responsible for interpreting and > > implementing the signalled QoS in the network. Failure to do so > > implies an admission control decision. It can only be triggered by a > > QI or another QC. > > > -QoS Receiver: Network entity, located at the boundary of a QoS > > domain, responsible for terminating a (local or end-to-end) QoS > > mechanism. It has the additional functionality that it may initiate an > > acknowledgment towards the QI and that it may trigger a QI or QC in > > the NSIS end-to-end protocol. > > > If this can be accepted by the NSIS community, we propose to add this > > text to the requirements document as a clarification of the QI/QC > > model that is used there. > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:00:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28908 for ; Fri, 22 Mar 2002 14:00:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11338 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:00:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10909; Fri, 22 Mar 2002 13:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10878 for ; Fri, 22 Mar 2002 13:58:59 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28858 for ; Fri, 22 Mar 2002 13:58:56 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA17604; Fri, 22 Mar 2002 19:55:32 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA26046; Fri, 22 Mar 2002 19:55:13 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 19:55:54 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656B2@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Sven Van den Bosch'" , nsis@ietf.org Cc: maarten.buchli@alcatel.be Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Fri, 22 Mar 2002 19:55:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven, Comments inline > > > 1. Terminology > > > > > > - QoS Controller: Network entity responsible for interpreting and > > > implementing the signaled QoS in the network. Failure to do so implies > >an > > > admission control decision. It can only be triggered by another NSIS > >entity > > > of the same instance (a QoS Initiator or another QoS Controller). > > > > > "instance": NSIS protocol instance? One should probably also provide the > >definition of NSIS protocol instance. > > I see an NSIS protocol instance as a flow of NSIS messages staring at a QI > and ending at a QR while passing through zero or more QCs. > Is this definition unique? Is it always possible to identify "a flow of NSIS messages"? I.e. are there no bifurcations or aggregations of NSIS messages? What about multicast reservations? What about when a message is altered by addition or deletion of objects (e.g. domain specific information) - is this still the same protocol instance? May be we should add: "...which all carry the same reservation identifier"? (I am not up to date on the current terminology regarding reservation identifiers) Does everybody agree such a definition should be added to the terminology section? > > > > > - QoS Receiver: Network entity, located at the edge of or inside a QoS > > > domain, responsible for terminating an instance of an NSIS protocol. It > >has > > > the additional functionality that it may initiate an acknowledgment > >towards > > > the QI and that it may trigger another NSIS entity (QoS Initiator or QoS > > > Controller of another instance of the NSIS protocol) > > > > > why would it trigger a QC? > The scenario here would be: the QC triggers, upon receiving an NSIS message, > an instance of NSIS at a QI. Signalling then propagates at the lower NSIS > layer to a QR which would hand over control back to the QC. In that case > there would be a client-server relationship between the two instances of > NSIS. > Lets call the triggering QC "QC1" and the QC being handed control from the QR "QC2". Is there any relation at all between the QR and QC2? Wouldnt the "triggering instance" of NSIS just tunnel between QC1 and QC2 (i.e. QC1 addresses QC2 directly)? A scenario in which such a triggering takes place would be e.g. per-flow NSIS signaling being tunneled through an aggregation region, or "generic NSIS signaling" being replaced inside one (QoS) domain by another instance of NSIS signaling (another NSIS protocol, or same protocol with different QoS information), particulary suited to the needs of this domain. In both cases I see the original NSIS protocol instance being tunneled rather than "switched back on" by the QR trigger (there may also be a timing problem unless the "triggering instance" is piggybacked on the "triggered instance"). Well, the my reasoning above implies QC1 knows QC2. In RSVP for Aggregates this is the case. I dont know about the general case? > > > - QoS Initiator: Network entity, located at the edge of or inside a QoS > > > domain, responsible for initiating an instance of an NSIS QoS signaling > > > protocol. It may be triggered by the application layer, by the > >termination > > > of a local QoS signaling mechanism (possibly another instance of NSIS > > > signaling) or by a QoS Controller of another of a client instance of an > >NSIS > > > protocol. It provides a mapping between the QoS parameters contained in > >the > > > trigger and the QoS parameters in the instance of the NSIS protocol for > > > which is serves as QoS Initiator. > > > > > what is a "client instance of an NSIS protocol"? > See the scenario above. > I'm not sure about the implications of defining client / server instances? Doesnt this map to a two-level-hierarchy-only signaling model? In any event, if we stick to this, the term should be defined, too. > > > - MUST NOT be adversely impacted by mobility aspects (applicable for> > > > end-to-end) > > > A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT > >be > > > adversely affected by mobility issues. Any mobility scenario should be > > > tackled by other uses of an NSIS protocol and is outside the realm of an > > > end-to-end application of the NSIS protocol. > > > > > what is "other uses of an NSIS protocol"? What is an "e2e app of the NSIS > >protocol" (I understand this looking at the figures you provided in a > >recent email, however they are not part of the Req doc)Does this imply NSIS > >is not supporting mobility? Or: it MUST be possible to support mobility > >locally, without invoking e2e NSIS signaling? > > There may be some confusion here. We have identified three potential network > parts where NSIS may be applicable: the host-to-first-hop, the access and > edge-to-edge (covering core, interdomain). Clearly there are different > requirements in each part. In the access and first-hop mobility will have to > be supported. Edge-to-edge it must not be supported. We are going to try to > put this in the requirements by providing the MUST, SHOULD, MAY tables per > network part where they apply. We don't exclude that there will be one NSIS > protocol (in which case it needs to be modular) but it is likely that there > can be more. Hence, other uses of an NSIS protocol. > The question about layering has come up in our discussions too and I think > we ahve agreed to put the picture in my mail into the requirements document > for some clarification on this. > > Do you think this is a good idea? > A table with MUST / SHOULD / MAY per network part is a good idea, including the figure, too (as long as it is clear we dont exclude a more-than-two-level signaling hierarchy ;-). However, I unfortunately still dont get the meaning of "other uses". May be you could reformulate the requirement using another term? Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28974 for ; Fri, 22 Mar 2002 14:04:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11811 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:04:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11668; Fri, 22 Mar 2002 14:03:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11634 for ; Fri, 22 Mar 2002 14:03:18 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28959 for ; Fri, 22 Mar 2002 14:03:15 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA13449; Fri, 22 Mar 2002 19:59:35 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA17701; Fri, 22 Mar 2002 19:59:27 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 20:00:05 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656B3@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'maarten.buchli@alcatel.be'" , Kappler Cornelia Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org, danny.goderis@alcatel.be, Hancock Robert Subject: RE: [NSIS] RE: section on QI/QC and QI/QC terminology Date: Fri, 22 Mar 2002 20:00:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Maarten, So you agree our scenario is not general, because it assumes usage of a signaling proxy and fixes a two-level-only hierarchy?? Best regards, Cornelia > -----Original Message----- > From: maarten.buchli@alcatel.be [SMTP:maarten.buchli@alcatel.be] > Sent: Thursday, March 21, 2002 5:35 PM > To: Kappler Cornelia > Cc: sven.van_den_bosch@alcatel.be; nsis@ietf.org; danny.goderis@alcatel.be; Hancock Robert > Subject: RE: [NSIS] RE: section on QI/QC and QI/QC terminology > > Hi Cornelia, > > I have written some comments in-line with [MB]. > > Regards, > Maarten > > > > > > Kappler Cornelia on 20/03/2002 19:00:03 > > > > To: Maarten BUCHLI/BE/ALCATEL@ALCATEL > > cc: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, > nsis@ietf.org, Danny GODERIS/BE/ALCATEL@ALCATEL, > Hancock Robert > > > > Subject: RE: [NSIS] RE: section on QI/QC and QI/QC > terminology > > > > > > > Hi Maarten and Sven, > > may be this discussion is outdated by what you've been discussing at the > NSIS WG meeting which unfortunately I was not able to attend. > > Anyways > > Maarten wrote: > > > Hi Cornelia, > > > > The figure describing NSIS used as a local and as a global protocol was > > intended as a general framework > > and not specifically towards a certain scenario. > > > > Why do you consider it too restrictive? > > > > Regards, > > Maarten > > > Cornelia: > > Let me summarize your framework as I understand it: > > You fix a two-level signaling hierarchy for any kind of signaling scenario > (e.g. mobile and fixed): end-to-end (global) and local. In a first step, > NSIS is only global, and interworks with local signaling mechanisms. I.e. > it is nowhere "stand-alone". In a second step, we would also have a local > NSIS signaling protocol, which may replace the "legacy" local signaling. > Global and local signaling must always work together, i.e. with just one of > them QoS cannot be set up e2e. > > The end host never initiates global / end-to-end signaling, but just does > local signaling to some access router (gateway), which acts as a proxy and > QI, and translates the reservation into NSIS e2e/global signaling > > Now why do I consider this as too restrictive: > > - why is it necessary to always involve a proxy? Why would the end host > never initiate e2e signaling? > > [MB] First option is that access networks will still use their technology > specific QoS protocol. In this case there is a clear need to have an entity > (proxy) that translated the access QoS signaling to the global NSIS > signaling. > Another (more future oriented) option is that the access network speaks > NSIS. > However, such a (local) NSIS access protocol requires much more > functionality, > e.g. mobility support. Therefore, the local NSIS protocol in the access > will > be much more specific while the QoS signaling in the core can be kept as > simple > as possible. Also, a proxy allows for smooth migration from access specific > QoS protocols to an NSIS protocol. > > But indeed, there may be cases where a host initiates the global NSIS > signaling. > > > - it fixes a two-level hierarchy. However, more deeply nested hierarchies > are also possible. E.g. when some edge router pipes a per-flow aggregation> > into a (possibly previously set-up) aggregate reservation. Note this idea > can even be extended by the next edge router piping the aggregates it > receives into "super- aggregates". > > [MB] Agree, the number of hierarchy may be arbitrary although in most cases > two levels of hierarchy should be sufficient. > > "Sven>> Setting up the aggregates is a local matter for each of the QCs. A > QC may choose to modify its aggregate based on incoming micro-flows but > this process will not be triggered by microflow arrivals." > > Cornelia: > When a QC initiates an aggregate reservation it is a QI! (or rather: the > logical QC instance on a particular node receives per flow signaling and > triggers (based on incoming micro-flows, but not because of a particular > microflow arrival, I agree) the logical QI instance on the same node to > initiate or modify an aggregate reservation.) This is also consistent with > the terminology definition you sent out after the NSIS meeting, where the > QC may trigger a QI to initiate another instance of the NSIS protocol > > Another example of a more-than-two-level hierarchy: a QC initiates per-flow > e2e signaling. At the edge of some administrative domain a QC tunnels it to > the other edge of the domain and initiates local (domain-specific) NSIS > signaling, may be because a mapping of QoS parameters to local scope > parameters is necessary. Now this administrative domain consists of more > than one QoS domain, i.e. different QoS mechanisms are supported. At the > edge of each of these domains, local (non-NSIS) signaling mechanisms are > therefore initiated (e.g. RSVP, or no signaling, and instead DSCPs). > > This last example may be a bitfar fetched... however I think we should > allow the protocol to be arbitrarily deeply nested, if only because it is > more general and we dont know what the future is going to bring. Besides I > dont see having an arbitrary number of levels would make the protocol more > complicated > > - what about a scenario where no end host is involved, but a BB triggers an > edge router to set-up an aggregate reservation through a domain? The BB > would send this trigger because of some SLA agreement process rather than > because of the interpretation of per-flow reservations. I dont think this > would map to your framework either, because there is no reason for starting > with a local NSIS signaling that later is translated into global NSIS > signaling. > > [MB] Indeed, the BB will trigger the setup of traffic trunks > (i.e.bandwidth pipes) due to the establishment of an SLA. How a BB > provisions SLSs is outside the scope of NSIS in my opinion. Some > local NSIS protocol may be involved but for sure this won't be > translated into a global NSIS protocol. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:12:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29112 for ; Fri, 22 Mar 2002 14:12:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12204 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:12:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12151; Fri, 22 Mar 2002 14:11:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12062 for ; Fri, 22 Mar 2002 14:11:24 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29039 for ; Fri, 22 Mar 2002 14:11:22 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2MJE1N14857; Fri, 22 Mar 2002 13:14:01 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2MJAfl26815; Fri, 22 Mar 2002 13:10:41 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 13:11:21 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA30@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Hannes Tschofenig'" , Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario Date: Fri, 22 Mar 2002 13:11:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1D5.57EC55B0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D1D5.57EC55B0 Content-Type: text/plain; charset="iso-8859-1" Hannes, Hemant I agree with your comments below. Note that another possible way for B to receive credentials is via an opaque field in the signaling protocol used to setup the reservation in the A to B direction. B could then use the credentials for its setup. Marco -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Wednesday, March 13, 2002 3:56 AM To: Hemant.Chaskar@nokia.com; nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario hi hemant! > Hi: > I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that > motivates such explicit requirement. I would like to know if WG deems this as an important issue. > "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". i like this requirement. it think that it is a good idea to have this requirement. but: i think it is already covered with: 5.8.2 The QoS protocol must provide means to authorize resource requests 5.10.5 The QoS protocol should provide hooks for AAA protocols appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging as indicated below. there have been a number of papers describing different solutions but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference next week. to your scenario below: just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for the reservation. if A is not willing to provide credentials then there is obvioulsy a problem but a could provide credentials without concerns about security. it only depends how these "credentials" look like. from my point of view this information should be exchanged before the actual qos reservation takes place since it is an application issue. hence the information should already be available at the qos-reservation start-up. > ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. > Note that N_B cannot bill A directly. there has to be some agreement between providers otherwise this exchange will not work. > (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. > (This part has to be addressed by SIP and SDPng). i agree with you. > (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. > This is the requirement that needs to be included in NSIS requirements document. this is true. first, the qos signaling messages must be authenticated, integrity and replay protected. second, the qos protocol should be able to transport information exchanged with protocols executed before the qos protocol is triggered. ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com Sent: Tuesday, March 12, 2002 4:55 PM To: nsis@ietf.org Subject: [NSIS] An NSIS requirement with backing scenario Hi: I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue. "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". Scenario: ----------- A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling. For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly. The following things need to happen to make this call through. (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng). (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document. BR, Hemant ------_=_NextPart_001_01C1D1D5.57EC55B0 Content-Type: text/html; charset="iso-8859-1"
Hannes, Hemant
 
I agree with your comments below.
 
Note that another possible way for B to receive  credentials is via an opaque field in the signaling protocol used to setup the reservation in the A to B direction. B could then use the credentials for its setup.
 
Marco
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de]
Sent: Wednesday, March 13, 2002 3:56 AM
To: Hemant.Chaskar@nokia.com; nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with backing scenario

hi hemant!

> Hi:

> I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that

> motivates such explicit requirement. I would like to know if WG deems this as an important issue.

> "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes".

i like this requirement. it think that it is a good idea to have this requirement.

but: i think it is already covered with:

5.8.2 The QoS protocol must provide means to authorize resource requests

5.10.5 The QoS protocol should provide hooks for AAA protocols

appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging

as indicated below. there have been a number of papers describing different solutions

but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference

next week.

to your scenario below:

just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for

the reservation.

 

if A is not willing to provide credentials then there is obvioulsy a problem but

a could provide credentials without concerns about security. it only depends how these "credentials" look like.

from my point of view this information should be exchanged before the actual qos reservation takes place since it

is an application issue. hence the information should already be available at the qos-reservation start-up.

> ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B.

> Note that N_B cannot bill A directly.

there has to be some agreement between providers otherwise this exchange will not work.

 

> (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B.

> (This part has to be addressed by SIP and SDPng).

i agree with you.

> (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B.

> This is the requirement that needs to be included in NSIS requirements document.

this is true.

first, the qos signaling messages must be authenticated, integrity and replay protected.

second, the qos protocol should be able to transport information exchanged with protocols executed before the

qos protocol is triggered.

ciao

hannes

-----Original Message-----
From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com
Sent: Tuesday, March 12, 2002 4:55 PM
To: nsis@ietf.org
Subject: [NSIS] An NSIS requirement with backing scenario

Hi:
 
I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue.
 
"QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes".
 
Scenario:
-----------
 
A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. 
 
A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling.
 
For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly.
 
The following things need to happen to make this call through.
 
(i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng).
 
(ii)  NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document.
 
BR,
Hemant
------_=_NextPart_001_01C1D1D5.57EC55B0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:27:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29478 for ; Fri, 22 Mar 2002 14:27:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13101 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:27:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12864; Fri, 22 Mar 2002 14:25:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12833 for ; Fri, 22 Mar 2002 14:25:09 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29448 for ; Fri, 22 Mar 2002 14:25:06 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2MJPuA03509 for ; Fri, 22 Mar 2002 21:25:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Mar 2002 21:25:07 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Mar 2002 21:25:06 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Mar 2002 13:25:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1D7.441AEEB0" Subject: RE: [NSIS] An NSIS requirement with backing scenario Date: Fri, 22 Mar 2002 14:25:03 -0500 Message-ID: Thread-Topic: [NSIS] An NSIS requirement with backing scenario Thread-Index: AcHR1YjwlUrydvCjRdqxOWg0Mzy+RQAAYM+A To: , , X-OriginalArrivalTime: 22 Mar 2002 19:25:04.0462 (UTC) FILETIME=[44BEE6E0:01C1D1D7] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D1D7.441AEEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marco: =20 But the problem here is that A does not want to disclose credentials to = B. So, N_B has to get it from some network AAA entity that has record = for A's credentials that are acceptable to N_B. =20 Hemant =20 -----Original Message----- From: ext Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: Friday, March 22, 2002 2:11 PM To: 'Hannes Tschofenig'; Chaskar Hemant (NRC/Boston); nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario Hannes, Hemant =20 I agree with your comments below.=20 =20 Note that another possible way for B to receive credentials is via an = opaque field in the signaling protocol used to setup the reservation in = the A to B direction. B could then use the credentials for its setup.=20 =20 Marco -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Wednesday, March 13, 2002 3:56 AM To: Hemant.Chaskar@nokia.com; nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario hi hemant! > Hi: > I would like to place the following requirement on table for = discussion in WG. I have also provided a scenario below that=20 > motivates such explicit requirement. I would like to know if WG deems = this as an important issue. > "QoS signaling protocol MUST interwork with AAA for QoS authorization = and accounting purposes". i like this requirement. it think that it is a good idea to have this = requirement.=20 but: i think it is already covered with: 5.8.2 The QoS protocol must provide means to authorize resource requests 5.10.5 The QoS protocol should provide hooks for AAA protocols appart from the requirements for an interaction with AAA there are still = open issues regarding billing/payment/charging=20 as indicated below. there have been a number of papers describing = different solutions=20 but i do not know a satisfiable one. maybe we can discuss some of the = issues at the ietf conference=20 next week.=20 to your scenario below:=20 just to make sure: the main problem seems to be that user B has to give = "something" to network N_B telling that user A is paying for the reservation.=20 =20 if A is not willing to provide credentials then there is obvioulsy a = problem but=20 a could provide credentials without concerns about security. it only = depends how these "credentials" look like.=20 from my point of view this information should be exchanged before the = actual qos reservation takes place since it=20 is an application issue. hence the information should already be = available at the qos-reservation start-up.=20 > ii) If A and N_B are in different jurisdiction, whatever credentials A = has to provide may not satisfy N_B.=20 > Note that N_B cannot bill A directly. there has to be some agreement between providers otherwise this exchange = will not work.=20 =20 > (i) SIP has to convey "intent" of A to pay for the call to B. A may = also expect in return the B's cost of access at N_B.=20 > (This part has to be addressed by SIP and SDPng). i agree with you.=20 > (ii) NSIS signaling needs to interwork with AAA so that it can reserve = and bill for QoS resources in N_B.=20 > This is the requirement that needs to be included in NSIS requirements = document. this is true.=20 first, the qos signaling messages must be authenticated, integrity and = replay protected.=20 second, the qos protocol should be able to transport information = exchanged with protocols executed before the=20 qos protocol is triggered.=20 ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of = Hemant.Chaskar@nokia.com Sent: Tuesday, March 12, 2002 4:55 PM To: nsis@ietf.org Subject: [NSIS] An NSIS requirement with backing scenario Hi: =20 I would like to place the following requirement on table for discussion = in WG. I have also provided a scenario below that motivates such = explicit requirement. I would like to know if WG deems this as an = important issue. =20 "QoS signaling protocol MUST interwork with AAA for QoS authorization = and accounting purposes". =20 Scenario: ----------- =20 A and B are connected to the Internet on the two sides of the globe. A = places call to B, and (say during SIP transactions) intimates to B that = A will pay for the call. Paying for the call also means paying for QoS = of the corresponding packet transport. B accepts A's proposal. The call = happens to be of bidirectional traffic type.=20 =20 A sends signal to its access network N_A asking it to give certain QoS = to packet stream from A -> B. A is a subscribed customer of N_A, so = there are no apparent difficulties for N_A in checking A's credentials = and in billing A. Also, network N_A may then take appropriate means to = guarantee end-to-end QoS, may be based on SLAs with other providers and = may be using some NSIS signaling. =20 For the packet path from B -> A, A does not know apriori as to how the = path looks like. So, the QoS establishment for this path needs to be = initiated from B's side. Now, B is not paying for QoS in its own access = network N_B. Since, A has agreed to pay, A needs to provide some = credentials to B which would be acceptable to N_B. There are two = problems encountered here: i) Though A has agreed to pay, A may not be = willing to provide credentials to end host B for security reasons, ii) = If A and N_B are in different jurisdiction, whatever credentials A has = to provide may not satisfy N_B. Note that N_B cannot bill A directly. =20 The following things need to happen to make this call through.=20 =20 (i) SIP has to convey "intent" of A to pay for the call to B. A may also = expect in return the B's cost of access at N_B. (This part has to be = addressed by SIP and SDPng). =20 (ii) NSIS signaling needs to interwork with AAA so that it can reserve = and bill for QoS resources in N_B. This is the requirement that needs to = be included in NSIS requirements document. =20 BR, Hemant ------_=_NextPart_001_01C1D1D7.441AEEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Marco:
 
But=20 the problem here is that A does not want to disclose credentials to = B. So,=20 N_B has to get it from some network AAA entity that has record for A's=20 credentials that are acceptable to N_B.
 
Hemant
 
-----Original Message-----
From: ext Schneider, Marco = [mailto:schneider@tri.sbc.com]
Sent: Friday, March 22, 2002 = 2:11=20 PM
To: 'Hannes Tschofenig'; Chaskar Hemant (NRC/Boston);=20 nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with = backing=20 scenario

Hannes, Hemant
 
I=20 agree with your comments below.
 
Note=20 that another possible way for B to receive  credentials is via an = opaque=20 field in the signaling protocol used to setup the reservation in = the A to B=20 direction. B could then use the credentials for its setup. =
 
Marco
-----Original Message-----
From: Hannes Tschofenig=20 [mailto:Hannes.Tschofenig@mchp.siemens.de]
Sent: Wednesday, = March=20 13, 2002 3:56 AM
To: Hemant.Chaskar@nokia.com;=20 nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with = backing=20 scenario

hi hemant!

> Hi:

> I would like to = place the=20 following requirement on table for discussion in WG. I have also = provided a=20 scenario below that

> motivates such = explicit=20 requirement. I would like to know if WG deems this as an important=20 issue.

> "QoS signaling = protocol MUST=20 interwork with AAA for QoS authorization and accounting = purposes".

i like this = requirement. it think=20 that it is a good idea to have this requirement.

but: i think it is = already covered=20 with:

5.8.2 The QoS protocol = must provide=20 means to authorize resource requests

5.10.5 The QoS protocol = should=20 provide hooks for AAA protocols

appart from the = requirements for an=20 interaction with AAA there are still open issues regarding=20 billing/payment/charging

as indicated below. = there have been a=20 number of papers describing = different=20 solutions

but i do not know a = satisfiable one. maybe we can discuss some of = the issues=20 at the ietf conference

next week.

to your scenario below: =

just to make sure: the main problem = seems to=20 be that user B has to give "something" to network N_B telling that = user A is=20 paying for

the reservation. =

 

if A is not willing to = provide=20 credentials then there is obvioulsy a problem but

a could provide = credentials without=20 concerns about security. it only depends how these "credentials" look = like.=20

from my point of view = this=20 information should be exchanged before the actual qos reservation = takes place=20 since it

is an application = issue. hence the=20 information should already be available at the qos-reservation = start-up.=20

> ii) If A and N_B = are in=20 different jurisdiction, whatever credentials A has to provide may not = satisfy=20 N_B.

> Note that N_B = cannot bill A=20 directly.

there has to be some = agreement=20 between providers otherwise this exchange will not work.

 

> (i) SIP has to = convey "intent"=20 of A to pay for the call to B. A may also expect in return the B's = cost of=20 access at N_B.

> (This part has to = be addressed=20 by SIP and SDPng).

i agree with you. =

> (ii) NSIS = signaling needs to=20 interwork with AAA so that it can reserve and bill for QoS resources = in N_B.=20

> This is the = requirement that=20 needs to be included in NSIS requirements document.

this is true. =

first, the qos = signaling messages=20 must be authenticated, integrity and replay protected.

second, the qos = protocol should be=20 able to transport information exchanged with protocols executed before = the=20

qos protocol is = triggered.=20

ciao

hannes

-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of=20 Hemant.Chaskar@nokia.com
Sent: Tuesday, March 12, 2002 = 4:55=20 PM
To: nsis@ietf.org
Subject: [NSIS] An NSIS = requirement=20 with backing scenario

Hi:
 
I = would like to=20 place the following requirement on table for discussion in WG. I = have also=20 provided a scenario below that motivates such=20 explicit requirement. I would like to know if WG = deems this as an important=20 issue.
 
"QoS signaling protocol MUST = interwork=20 with AAA for QoS authorization and accounting=20 purposes".
 
Scenario:
-----------
 
A = and B are=20 connected to the Internet on the two sides of the globe. A places = call to B,=20 and (say during SIP transactions) intimates to B that A will pay for = the=20 call. Paying for the call also means paying for QoS of the = corresponding=20 packet transport. B accepts A's proposal. The call happens to be=20 of bidirectional traffic type. 
 
A = sends signal=20 to its access network N_A asking it to give certain QoS to = packet=20 stream from A -> B. A is a subscribed customer of N_A, so there = are no=20 apparent difficulties for N_A in checking A's credentials and = in=20 billing A. Also, network N_A may then take appropriate means to = guarantee end-to-end QoS, may be based on SLAs with other providers = and may=20 be using some NSIS signaling.
 
For the packet=20 path from B -> A, A does not know apriori as to how the path = looks like.=20 So, the QoS establishment for this path needs to be initiated from = B's side.=20 Now, B is not paying for QoS in its own access network N_B. Since, A = has=20 agreed to pay, A needs to provide some credentials to B which would = be=20 acceptable to N_B. There are two problems encountered here: i) = Though A has=20 agreed to pay, A may not be willing to provide credentials to end = host B for=20 security reasons, ii) If A and N_B are in different jurisdiction, = whatever=20 credentials A has to provide may not satisfy N_B. Note that N_B = cannot bill=20 A directly.
 
The following things need to = happen to make=20 this call through.
 
(i) SIP has to convey "intent" of A = to pay for=20 the call to B. A may also expect in return the B's cost of access at = N_B.=20 (This part has to be addressed by SIP and = SDPng).
 
(ii)  NSIS signaling needs to = interwork with=20 AAA so that it can reserve and bill for QoS resources in N_B. This = is the=20 requirement that needs to be included in NSIS requirements=20 document.
 
BR,
Hemant
------_=_NextPart_001_01C1D1D7.441AEEB0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:29:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29524 for ; Fri, 22 Mar 2002 14:29:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13174 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:29:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13087; Fri, 22 Mar 2002 14:26:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13008 for ; Fri, 22 Mar 2002 14:26:54 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29473 for ; Fri, 22 Mar 2002 14:26:51 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2MJTVN14919; Fri, 22 Mar 2002 13:29:31 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2MJQAP27325; Fri, 22 Mar 2002 13:26:10 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 13:26:51 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA32@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario Date: Fri, 22 Mar 2002 13:26:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1D7.80113630" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D1D7.80113630 Content-Type: text/plain; charset="iso-8859-1" Hi Hemmant, I strongly agree that we need to give exemplary scenarios showing how we believe the protocol will be used. Should these be part of the framework document? Marco -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Thursday, March 14, 2002 9:10 AM To: nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario Hi Hannes: Please see some comments below. -----Original Message----- From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de] Sent: Wednesday, March 13, 2002 4:56 AM To: Chaskar Hemant (NRC/Boston); nsis@ietf.org Subject: RE: [NSIS] An NSIS requirement with backing scenario hi hemant! > Hi: > I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that > motivates such explicit requirement. I would like to know if WG deems this as an important issue. > "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". i like this requirement. it think that it is a good idea to have this requirement. but: i think it is already covered with: 5.8.2 The QoS protocol must provide means to authorize resource requests 5.10.5 The QoS protocol should provide hooks for AAA protocols [HC] I think that only stating such requirements may not suffice. The document should elaborate on them and also give some exemplary scenarios. That helps to indicate where the deep waters are. appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging as indicated below. there have been a number of papers describing different solutions but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference next week. [HC] Can you construct any more scenarios from those papers that may be relevant for such requirement? It will be good to know as many scenarios as possible before going into the solution phase. to your scenario below: just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for the reservation. [HC] Yes, that is right. if A is not willing to provide credentials then there is obvioulsy a problem but a could provide credentials without concerns about security. it only depends how these "credentials" look like. from my point of view this information should be exchanged before the actual qos reservation takes place since it is an application issue. hence the information should already be available at the qos-reservation start-up. > ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. > Note that N_B cannot bill A directly. there has to be some agreement between providers otherwise this exchange will not work. > (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. > (This part has to be addressed by SIP and SDPng). i agree with you. > (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. > This is the requirement that needs to be included in NSIS requirements document. this is true. first, the qos signaling messages must be authenticated, integrity and replay protected. second, the qos protocol should be able to transport information exchanged with protocols executed before the qos protocol is triggered. [HC] Issues such as these will affect NSIS protocol design. That is the main message I would like to convey via this requirement/scenario. Regards, Hemant ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com Sent: Tuesday, March 12, 2002 4:55 PM To: nsis@ietf.org Subject: [NSIS] An NSIS requirement with backing scenario Hi: I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue. "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes". Scenario: ----------- A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling. For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly. The following things need to happen to make this call through. (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng). (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document. BR, Hemant ------_=_NextPart_001_01C1D1D7.80113630 Content-Type: text/html; charset="iso-8859-1"
Hi Hemmant,
 
I strongly agree that we need to give exemplary scenarios showing how we believe the protocol will be used. Should these be part of the framework document?
 
Marco
-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
Sent: Thursday, March 14, 2002 9:10 AM
To: nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with backing scenario

Hi Hannes:
 
Please see some comments below.
 
 
-----Original Message-----
From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@mchp.siemens.de]
Sent: Wednesday, March 13, 2002 4:56 AM
To: Chaskar Hemant (NRC/Boston); nsis@ietf.org
Subject: RE: [NSIS] An NSIS requirement with backing scenario

hi hemant!

> Hi:

> I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that

> motivates such explicit requirement. I would like to know if WG deems this as an important issue.

> "QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes".

i like this requirement. it think that it is a good idea to have this requirement.

but: i think it is already covered with:

5.8.2 The QoS protocol must provide means to authorize resource requests

5.10.5 The QoS protocol should provide hooks for AAA protocols 

 

[HC] I think that only stating such requirements may not suffice. The document should elaborate on them and also give some exemplary scenarios. That helps to indicate where the deep waters are.

 

appart from the requirements for an interaction with AAA there are still open issues regarding billing/payment/charging

as indicated below. there have been a number of papers describing different solutions

but i do not know a satisfiable one. maybe we can discuss some of the issues at the ietf conference

next week. 

 

[HC] Can you construct any more scenarios from those papers that may be relevant for such requirement? It will be good to know as many scenarios as possible before going into the solution phase.

 

to your scenario below:

just to make sure: the main problem seems to be that user B has to give "something" to network N_B telling that user A is paying for

the reservation.  

 

[HC] Yes, that is right. 

 

if A is not willing to provide credentials then there is obvioulsy a problem but

a could provide credentials without concerns about security. it only depends how these "credentials" look like.

from my point of view this information should be exchanged before the actual qos reservation takes place since it

is an application issue. hence the information should already be available at the qos-reservation start-up.

> ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B.

> Note that N_B cannot bill A directly.

there has to be some agreement between providers otherwise this exchange will not work.

 

> (i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B.

> (This part has to be addressed by SIP and SDPng).

i agree with you.

> (ii) NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B.

> This is the requirement that needs to be included in NSIS requirements document.

this is true.

first, the qos signaling messages must be authenticated, integrity and replay protected.

second, the qos protocol should be able to transport information exchanged with protocols executed before the

qos protocol is triggered. 

 

[HC] Issues such as these will affect NSIS protocol design. That is the main message I would like to convey via this requirement/scenario.

 

Regards, Hemant

 

ciao

hannes

-----Original Message-----
From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Hemant.Chaskar@nokia.com
Sent: Tuesday, March 12, 2002 4:55 PM
To: nsis@ietf.org
Subject: [NSIS] An NSIS requirement with backing scenario

Hi:
 
I would like to place the following requirement on table for discussion in WG. I have also provided a scenario below that motivates such explicit requirement. I would like to know if WG deems this as an important issue.
 
"QoS signaling protocol MUST interwork with AAA for QoS authorization and accounting purposes".
 
Scenario:
-----------
 
A and B are connected to the Internet on the two sides of the globe. A places call to B, and (say during SIP transactions) intimates to B that A will pay for the call. Paying for the call also means paying for QoS of the corresponding packet transport. B accepts A's proposal. The call happens to be of bidirectional traffic type. 
 
A sends signal to its access network N_A asking it to give certain QoS to packet stream from A -> B. A is a subscribed customer of N_A, so there are no apparent difficulties for N_A in checking A's credentials and in billing A. Also, network N_A may then take appropriate means to guarantee end-to-end QoS, may be based on SLAs with other providers and may be using some NSIS signaling.
 
For the packet path from B -> A, A does not know apriori as to how the path looks like. So, the QoS establishment for this path needs to be initiated from B's side. Now, B is not paying for QoS in its own access network N_B. Since, A has agreed to pay, A needs to provide some credentials to B which would be acceptable to N_B. There are two problems encountered here: i) Though A has agreed to pay, A may not be willing to provide credentials to end host B for security reasons, ii) If A and N_B are in different jurisdiction, whatever credentials A has to provide may not satisfy N_B. Note that N_B cannot bill A directly.
 
The following things need to happen to make this call through.
 
(i) SIP has to convey "intent" of A to pay for the call to B. A may also expect in return the B's cost of access at N_B. (This part has to be addressed by SIP and SDPng).
 
(ii)  NSIS signaling needs to interwork with AAA so that it can reserve and bill for QoS resources in N_B. This is the requirement that needs to be included in NSIS requirements document.
 
BR,
Hemant
------_=_NextPart_001_01C1D1D7.80113630-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:44:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29970 for ; Fri, 22 Mar 2002 14:44:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14373 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:44:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14046; Fri, 22 Mar 2002 14:38:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14015 for ; Fri, 22 Mar 2002 14:38:49 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29808 for ; Fri, 22 Mar 2002 14:38:46 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2MJfLN14976; Fri, 22 Mar 2002 13:41:21 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2MJc0d27704; Fri, 22 Mar 2002 13:38:01 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 13:38:41 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA33@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Freytsis, Ilya'" , "'nsis@ietf.org'" , "'Georgios.Karagiannis@eln.ericsson.se'" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Fri, 22 Mar 2002 13:38:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Ilya, You have provided some interesting scenarios. This really points out the danger of having a solution in mind while deciding requirements. In a soft state solution the death of the host would be less important since the reservation would time out. I think the requirement for this first part is that the protocol must support the ability to release resources in the case of initiator failure. Not that in some cases such as a proxy controller in the network that signals on behalf of many hosts, we must be able to support the behaviour that the resources are not released. With respect to the ability to signal reservation lifetime, I would propose that we could make this part of service specific semantics. Thus the designer of a service type could include a parameter to indicate the lifetime. If a controller released a reservation due to the end of lifetime the cause could be expressed in the service specific semantics and opaque to the signaling protocol. Marco > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] > Sent: Thursday, March 14, 2002 9:57 PM > To: 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se'; > Schneider, > Marco > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > Let me present another argument in support of this requirement: > > It is possible that the host that made a reservation dies > "silently" without > releasing network resources allocated for its flow. This > requirement will > provide protection from the possible waste of resources in > this case. It is > definitely different from refreshing the soft state of the > reservation since > it is driven by the application not the network specifics and > applicable to > the hard reservations as well (and maybe even more important for hard > reservations). > To make this arrangement more flexible I think that ability to signal > life-time of a reservation (including permanent reservations) > should be > complemented by the ability to re-new the existing reservation. > I envision the following scenario: > The video endpoint (to stay on the same theme) is making a call. The > endpoint or may be proxy makes reservation request with 30 > min expected > life-time. Three options exist > 1. After 20 min the call is over and the endpoint (proxy) > releases allocated > resources. > 2. After 25 min the participants realize that they need > another 15 min to > finish discussion - the re-new reservation request is issued > with 15 min > life-time > 3. After 15 min the endpoints crashes. 15 min later the > network realize that > something is wrong and frees resources that were reserved for > this video > call. > > Does it make any sense? > > Ilya > > From: "Georgios Karagiannis (ELN)" > > To: "'Schneider, Marco'" , > "'Steven Berson'" > > Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > Date: Wed, 13 Mar 2002 13:43:32 +0100 > charset="iso-8859-1" > > Hi Marco > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. > > Best Regards, > Georgios > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: dinsdag 12 maart 2002 22:13 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > The point of the example is that the network may want to > limit the duration > that it grants for a session and thus its corresponding > resources (such as a > QOS connection). So in this case the network needs to be able > to revoke > resources upon the expiration of some time period. In > thinking about this > example I was wondering whether it would be useful to make duration an > explicit part of the reservation semantics. > > 1) A host requests from network a service of one hour > duration. For example > a video call to a friend. > 2) Above is realized via session negotiation that results in > token that is > passed back to the host. The token permits a QOS connection > of one hour > duration at 5 Mbps > 3) The host (QOS Initiator) includes the token in the NSIS > setup message > requesting a 5Mbps connection. > 4) The QOS Controller uses the token to validate the > reservation and allows > the setup to go through. > (See draft-ietf-sip-call-auth-0?.txt as well as > draft-ietf-rap-session-auth-0?.txt) > > Now what happens when one hour is up? Ideally the host releases the > resources but if the host does not the network will > (otherwise the user gets > more than they paid for). When the network releases the > resources there > should be a cause code that says your time was up or at the very least > indicates that this was due to service policy. > > Now my question is: given that the reservation is intended to be of a > precise duration should we make this explicit or is it better > for this to be > transparent? Is so why? > > Regarding Scalability, I do not understand your claim that > this is very > non-scalable. For every flow reservation the network > presumably will need to > store the amount reserved (at least one piece of > information). A reservation > duration requires one additional piece of information (at the > edge) that > does not propagate across the network. > > Best Regards, > Marco > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 14:47:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00012 for ; Fri, 22 Mar 2002 14:47:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14460 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 14:47:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14349; Fri, 22 Mar 2002 14:44:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14318 for ; Fri, 22 Mar 2002 14:44:39 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29956 for ; Fri, 22 Mar 2002 14:44:35 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2MJlFN14988; Fri, 22 Mar 2002 13:47:15 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2MJhp827853; Fri, 22 Mar 2002 13:43:51 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 13:44:32 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA34@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Juan-Carlos.Rojas@alcatel.fr'" , Gabor.Fodor@era-t.ericsson.se, john.loughney@nokia.com, "'brunner@ccrle.nec.de'" Cc: nsis@ietf.org Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions Date: Fri, 22 Mar 2002 13:44:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Well said, Marco > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr > [mailto:Juan-Carlos.Rojas@alcatel.fr] > Sent: Friday, March 15, 2002 1:59 AM > To: Gabor.Fodor@era-t.ericsson.se; john.loughney@nokia.com; > 'brunner@ccrle.nec.de' > Cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions > > > Hello Gabor et al,, > > As the general agreement seems that NSIS be limited to the > bearer level > only, and in order to avoid confusion in the future, I > propose to add a new > point to the section "4.3 Exclusions", that could be phrased > as follows: > > "Specific methods, protocols, and ways to express QoS > information in the > Application/Session level are not considered (e.g., SDP, SIP, > RTSP, etc.); > therefore when the NSIS protocol is used to reserve resources with QoS > constraints, it is assumed that the application/session level > has already > been able to determine/negotiate the QoS requirements between the > end-users, for each requested bearer. > The specification of any extensions needed to signal QoS > information via > application level protocols (e.g. SDP(ng)), and the mapping on NSIS > information are considered outside of the scope of NSIS > working group, as > this work is in the direct scope of other IETF working groups (e.g. > MMUSIC)." > > Comments ? > Best regards > Juan Carlos > > ---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on > 15/03/2002 08:38 --------------------------- > > > Juan-Carlos ROJAS > 12/03/2002 13:58 > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor), > john.loughney@nokia.com, > "'brunner@ccrle.nec.de'" > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > (Document link: Listes > Discussion) > > Hi Gabor, > > OK, if this is a general agreement in the NSIS wg, it is not > my intention > to go against the world. > It would be preferable if this is clearly written in the requirements > document: see e.g. section "4.3 Exclusions", the point 2 > could be extended > in this way. > > Best regards > > Juan Carlos > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 18:08:23 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: nsis@ietf.org > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > Hi Juan-Carlos, > > my answer to your question : > > > question I'm raising is more "Is in the context of NSIS to > define ways of > > expressing QoS requirements also at the session level ?". > > would be "no", becuase in my understanding this WG focuses > on IP level QoS signaling mechanisms. > > However, I agree with you when you say that : > > > ... what will be agreed at the session/application > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer > level for > > resource reservation complying with the QoS requirements. The most > > Therefore, it is important that we carefully select the bearer level > paramaters ("define the bearer service(s)"), when we reach > that discussion. > To emphasize this, we could consider to add a requirement (at the > level of those in Section 5.1) that NSIS signaling should support > a wide range of media streams, or something more elaborated. > > /Gabor > > > > From nsis-admin@ietf.org Mon Mar 11 17:17:52 2002 > > From: Juan-Carlos.Rojas@alcatel.fr > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > To: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) > > Cc: nsis@ietf.org > > Date: Mon, 11 Mar 2002 17:17:03 +0100 > > X-MIMETrack: Serialize by Router on > FRMAIL25/FR/ALCATEL(Release 5.0.8 > |June 18, 2001) at > > 03/11/2002 17:17:04 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-MIME-Autoconverted: from quoted-printable to 8bit by > optimus.ietf.org > id LAA27058 > > X-Mailman-Version: 1.0 > > List-Id: Next Steps in Signaling > > X-BeenThere: nsis@ietf.org > > > > > > Hi Gabor, > > > > No major problem with this. > > You are right when saying that "There are already > mechanisms that allow > > coordination between the session layer and the bearer (IP) layer"; > however, > > there is no standardized way to exchange and negotiate QoS > information at > > session level (we are currently proposing SDP extensions for that). > > I'm not asking to define "how parties make service > agreements", but the > > question I'm raising is more "Is in the context of NSIS to > define ways of > > expressing QoS requirements also at the session level ?". > > The main purpose is that what will be agreed at the > session/application > > layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer > level for > > resource reservation complying with the QoS requirements. The most > > straight-forward will be the translation, the less > error-prone will be > the > > implementation. > > And for sure, at the end, the QoS information should allow > a mapping on > > different QoS technologies. > > > > Otherwise, I fully agree with you, we are currently specifying > > requirements, the definition work will come later. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > Gabor.Fodor@era-t.ericsson.se (Gabor Fodor) on 11/03/2002 16:28:09 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: nsis@ietf.org > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > Juan-Carlos, > > > > in this respect I fully support one view that was expressed > > in a previous mail on this list, which formulated a requirement > > that the [NSIS QoS signaling] architecture must be completely > > agnostic as to how parties make service agreements. That is, > > the service advertisement shoud be handled at the application > > level. > > > > There are already mechanisms that allow coordination between the > > session layer and the bearer (IP) layer, including the notion > > of pre-conditions in SIP. > > > > However, I view it as an important requirement that > > "the information exchanged over the signaling protocol > > must be in such detail and quantity > > that it is useful for various QoS technologies" > > [draft-brunner-nsis..., Section 5.1]. > > > > Of course, this "level of detail and quantity" > > should support various applications without requiring from > > application programmers that complex and qualitative parameters > > should be set. Therefore, we have a challange to define such > > paramater set(s) at the IP level that help various underlying > > QoS technologies to provide QoS and are "application programmer > > friendly". Such sets allow parties to configure their QoS parameters > > after negotiating a service at the application layer. > > (This definition work is of course left after the requirements > > discussion.) > > > > /Gabor > > > > > > > > > > > > > From nsis-admin@ietf.org Mon Mar 11 15:51:42 2002 > > > From: Juan-Carlos.Rojas@alcatel.fr > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > To: "Geib, Ruediger" > > > Cc: john.loughney@nokia.com, "Geib, Ruediger" > > , > > > nsis@ietf.org > > > Date: Mon, 11 Mar 2002 15:50:50 +0100 > > > X-MIMETrack: Serialize by Router on > FRMAIL25/FR/ALCATEL(Release 5.0.8 > > |June 18, 2001) at > > > 03/11/2002 15:50:51 > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 8bit > > > X-MIME-Autoconverted: from quoted-printable to 8bit by > optimus.ietf.org > > id JAA21126 > > > X-Mailman-Version: 1.0 > > > List-Id: Next Steps in Signaling > > > X-BeenThere: nsis@ietf.org > > > > > > > > > Hi all, > > > > > > There is a general agreement that NSIS should not define services > > > (applications); I fully support this view. > > > However, a QoS signalling protocol should provide the necessary > > mechanisms > > > to allow applications to define, exchange, negotiate QoS > characteristics. > > > This seems to me a fondamental question: if we agree that > in the NGN > > > providers will sell services and not only some transport > capacity, then > > the > > > QoS story cannot be considered anymore as only a matter of bearer > > handling, > > > you need to have a global view including the session layer (e.g. > SIP/SDP) > > > and the applications. > > > Next, it should be up to the involved actors to define a common > agreement > > > on the service that is to be provided. > > > My feeling is that this is fully inline with the IETF philosophy: > define > > > basic mechanisms, and next, allow the actors to build > services on top > of > > > basic mechanisms. > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > > > > > > > "Geib, Ruediger" @ietf.org > on 08/03/2002 > > > 11:40:03 > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > To: john.loughney@nokia.com, "Geib, Ruediger" > > > > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt > > > > > > > > > Hi John, > > > > > > I'd appreciate if NSIS takes care of the issue (a MAY is > fine for now). > > The > > > first requirement may be reworded to clarify that NSIS > does not define > > the > > > service (I'm neither a native speaker nor a legal expert, > so I'm not > sure > > > whether your suggestion does so). > > > NSIS then MAY be the IETF WG to collect, check and > administrate the > > service > > > description coded according to NSIS rules? If you don't > know the answer > > we > > > could have a look on the RTP spec's. Also they support a mechanism > > offering > > > a signaling framework which may be (and is) filled by > later individual > > > specifications. > > > > > > Regards, Rüdiger > > > > > > > > > > > NSIS must support a flexible service definition not > > > > > restricting contents and meaning of individual service > > > > > descriptions. Services may either be private or public. > > > > > > > > Would these requirements be OK? > > > > > > > > NSIS SHOULD support application level service descriptions. > > > > > > > > NSIS MAY consider support for service descriptions developed > > > > by other SDOs. > > > > > > > > This would mean that applications could do the service > negotiations, > > > > and pass this info to NSIS. > > > > > > > > It also means that NSIS could support ITU-T Y.1541, or > 3GPP's QoS > > > > classes. > > > > > > > > John > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 18:36:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04272 for ; Fri, 22 Mar 2002 18:36:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29232 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 18:36:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28508; Fri, 22 Mar 2002 18:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28477 for ; Fri, 22 Mar 2002 18:27:43 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04112 for ; Fri, 22 Mar 2002 18:27:40 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2MNUJN16141; Fri, 22 Mar 2002 17:30:19 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g2MNQxG06753; Fri, 22 Mar 2002 17:26:59 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 17:27:39 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA37@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Jukka MJ Manner'" , Anders.P.Bergsten@telia.se Cc: nsis@ietf.org, brunner@ccrle.nec.de Subject: RE: [NSIS] proposal to add requirement text Date: Fri, 22 Mar 2002 17:27:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Jukka, I agree with your wording. It is up to the operator as to how to handle the signaling packets in whatever matter we see fit. What is required is that we be able to identify them as such and also that we be able to distinguish between the different types of signaling messages (for possibly different handling). Finally of course this must be achieveable in an efficient manner. Marco > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > Sent: Thursday, March 21, 2002 5:18 PM > To: Anders.P.Bergsten@telia.se > Cc: nsis@ietf.org; brunner@ccrle.nec.de > Subject: Re: [NSIS] proposal to add requirement text > > > > Hi, > > the first req sounds good, but the second, IMO, is written the > wrong way: > > "The signalling messages must be identifiable in an efficient > way (with some definition of "efficient":)." > > This then allows a network operator to assign > priorities etc. to > those signalling packets. So, don't mandate what to do with > the packets, > but make it (easily) possible to handle these packets in a > specific way. > > Cheers, > > JiM > > > On Thu, 21 Mar 2002 Anders.P.Bergsten@telia.se wrote: > > > All, > > off line discussions revealed that the scalability > sections (5.6) could > > be slightly updated. > > > > I suggest wording along these lines: > > The nsis architecture should give the ability to constrain the load > > (CPU load, memory space, signaling bandwidth consumption > and signaling > > intensity) on devices where it is needed. This can be > achieved by many > > different methods, for example message aggregation, by ignoring > > signaling message, header compression or minimizing > functionality. The > > architecture may choose any of these methods as long as the > requirement > > is met. > > > (the reasoning behind the words are the following, if I have the > > ability to control the load the protocol(s) generate in a > singel device, > > the protocol will "scale". And the words does not mandate > any particular > > solution) > > > A related requirement that was discussed was transport > quality for the > > signaling protocol where I propose the following text. > > > The nsis architecture should allow the network operator to > assign the > > nsis protocol messages a certain transport quality. As > signaling opens > > up for possible denial-of-service attacks, this requirement > gives the > > network operator a mean, but also the obligation, to > trade-off between > > signaling latency and the impact (from the signaling messages) on > > devices within his/her network. From protocol design this > requirement > > states that the protocol messages should be detectable, at > least where > > the control and assignment of the messages priority is done. > > > > Anders > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Mar 22 19:02:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04580 for ; Fri, 22 Mar 2002 19:02:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01016 for nsis-archive@odin.ietf.org; Fri, 22 Mar 2002 19:02:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00927; Fri, 22 Mar 2002 19:01:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00895 for ; Fri, 22 Mar 2002 19:01:54 -0500 (EST) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04549 for ; Fri, 22 Mar 2002 19:01:53 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 18:57:46 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE6633EE0B@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Schneider, Marco'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Requirement Section 5.3.2 Date: Fri, 22 Mar 2002 18:57:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marco, I like the way you stated this requirement. Ilya -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: Friday, March 22, 2002 2:39 PM To: 'Freytsis, Ilya'; 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se' Subject: RE: [NSIS] Requirement Section 5.3.2 Hi Ilya, You have provided some interesting scenarios. This really points out the danger of having a solution in mind while deciding requirements. In a soft state solution the death of the host would be less important since the reservation would time out. I think the requirement for this first part is that the protocol must support the ability to release resources in the case of initiator failure. Not that in some cases such as a proxy controller in the network that signals on behalf of many hosts, we must be able to support the behaviour that the resources are not released. With respect to the ability to signal reservation lifetime, I would propose that we could make this part of service specific semantics. Thus the designer of a service type could include a parameter to indicate the lifetime. If a controller released a reservation due to the end of lifetime the cause could be expressed in the service specific semantics and opaque to the signaling protocol. Marco > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] > Sent: Thursday, March 14, 2002 9:57 PM > To: 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se'; > Schneider, > Marco > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > Let me present another argument in support of this requirement: > > It is possible that the host that made a reservation dies > "silently" without > releasing network resources allocated for its flow. This > requirement will > provide protection from the possible waste of resources in > this case. It is > definitely different from refreshing the soft state of the > reservation since > it is driven by the application not the network specifics and > applicable to > the hard reservations as well (and maybe even more important for hard > reservations). > To make this arrangement more flexible I think that ability to signal > life-time of a reservation (including permanent reservations) > should be > complemented by the ability to re-new the existing reservation. > I envision the following scenario: > The video endpoint (to stay on the same theme) is making a call. The > endpoint or may be proxy makes reservation request with 30 > min expected > life-time. Three options exist > 1. After 20 min the call is over and the endpoint (proxy) > releases allocated > resources. > 2. After 25 min the participants realize that they need > another 15 min to > finish discussion - the re-new reservation request is issued > with 15 min > life-time > 3. After 15 min the endpoints crashes. 15 min later the > network realize that > something is wrong and frees resources that were reserved for > this video > call. > > Does it make any sense? > > Ilya > > From: "Georgios Karagiannis (ELN)" > > To: "'Schneider, Marco'" , > "'Steven Berson'" > > Cc: "'brunner@ccrle.nec.de'" , nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > Date: Wed, 13 Mar 2002 13:43:32 +0100 > charset="iso-8859-1" > > Hi Marco > > What I mean is the following. > If some QoS domain will use aggregated reservation states > and if the lifetime requirement has to be supported by the domain, > then new per flow reservation lifetime states have to be created > in this domain. > > Best Regards, > Georgios > > > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: dinsdag 12 maart 2002 22:13 > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson' > Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org > Subject: RE: [NSIS] Requirement Section 5.3.2 > > > Hi Georgios, > > The point of the example is that the network may want to > limit the duration > that it grants for a session and thus its corresponding > resources (such as a > QOS connection). So in this case the network needs to be able > to revoke > resources upon the expiration of some time period. In > thinking about this > example I was wondering whether it would be useful to make duration an > explicit part of the reservation semantics. > > 1) A host requests from network a service of one hour > duration. For example > a video call to a friend. > 2) Above is realized via session negotiation that results in > token that is > passed back to the host. The token permits a QOS connection > of one hour > duration at 5 Mbps > 3) The host (QOS Initiator) includes the token in the NSIS > setup message > requesting a 5Mbps connection. > 4) The QOS Controller uses the token to validate the > reservation and allows > the setup to go through. > (See draft-ietf-sip-call-auth-0?.txt as well as > draft-ietf-rap-session-auth-0?.txt) > > Now what happens when one hour is up? Ideally the host releases the > resources but if the host does not the network will > (otherwise the user gets > more than they paid for). When the network releases the > resources there > should be a cause code that says your time was up or at the very least > indicates that this was due to service policy. > > Now my question is: given that the reservation is intended to be of a > precise duration should we make this explicit or is it better > for this to be > transparent? Is so why? > > Regarding Scalability, I do not understand your claim that > this is very > non-scalable. For every flow reservation the network > presumably will need to > store the amount reserved (at least one piece of > information). A reservation > duration requires one additional piece of information (at the > edge) that > does not propagate across the network. > > Best Regards, > Marco > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 25 11:08:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16917 for ; Mon, 25 Mar 2002 11:08:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06701 for nsis-archive@odin.ietf.org; Mon, 25 Mar 2002 11:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05790; Mon, 25 Mar 2002 11:05:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05752 for ; Mon, 25 Mar 2002 11:05:04 -0500 (EST) Received: from ommo.com ([63.227.234.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16644 for ; Mon, 25 Mar 2002 11:04:48 -0500 (EST) Message-Id: <200203251604.LAA16644@ietf.org> From: "sameez1@dubaimail.com" To: nsis@ietf.org Date: Mon, 25 Mar 2002 17:33:41 -0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6800 DM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05753 Subject: [NSIS] ASSISTANCE NEEDED. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit DR. SOLOMON AZEEZ. Director, Project Implementation, Nigerian National Petroleum Corporation, Falomo Office Complex, Ikoyi - Lagos. SIR, BUSINESS PROPOSAL It is my great pleasure in writing you this letter on behalf of myself and my colleagues. Your particulars were given to me by a member of the Nigerian Export Promotion Council (NEPC) who was at the Federal Government Delegation to your country during a trade exhibition. I have decided to seek a confidentialcooperation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as top secret because of the nature of this business. Within the Ministry of Petroleum Resources where I work as a Director, Project Implementation and with the cooperation of four other top officials we have in our possession as overdue payment bills totalling Fourteen Million, Five Hundred Thousand U. S. Dollars (US$14,500,000.00) which we want to transfer abroad with assistance and cooperation of a foreign company/individual toreceive the said fund on our behalf or a reliable foreign non-company account to receive such funds. Moreso, we are handicapped in the circumstances as the Nigerian Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. The amount represents the balance of the total contract value executed on behalf of my Ministry by a foreign contracting firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the tune of the said amount which we have in principles gotten approval to remit byTelegraphic Transfer (T.T) to foreign bank account you will provide by filing in an application through the Federal Ministry of Justice for the transfer of rights and privileges of the formercontractor to you. Since the new civilian government of my country is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign government and non-government financial agencies, thereforewe have decided to include our bills for approvals with the cooperation of some officials from the FederalMinistry of Finance and the Central Bank ofNigeria (CBN) We are seeking your assistance in providing a vital account or any virgin bank account into which we can remit this money by acting as our main partner and trustee. This we can do by swapping of account and changing of beneficiary and other forms of documentation upon application for claim to reflect the payment and approvals to be secured on behalf of you. This processes being pre-arranged with the principal trustee of the original contractor and with the consent of the original contractor. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction your share of the sum will be 30% of the US$14.5 million, 60% for us and 10% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to e-mail ON;sameez1@dubaimail.com me toknow your position and include your confidential telephoneand fax numbers. Thanks for your cooperation. Yours faithfully, DR. SOLOMON AZEEZ. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 25 11:11:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17287 for ; Mon, 25 Mar 2002 11:11:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07476 for nsis-archive@odin.ietf.org; Mon, 25 Mar 2002 11:11:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06414; Mon, 25 Mar 2002 11:07:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06364 for ; Mon, 25 Mar 2002 11:06:58 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16857 for ; Mon, 25 Mar 2002 11:06:54 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16pWzm-00073v-00; Mon, 25 Mar 2002 17:06:54 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16pWzf-0000Ea-00; Mon, 25 Mar 2002 17:06:54 +0100 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2PG6ff10060; Mon, 25 Mar 2002 17:06:41 +0100 Message-Id: <200203251606.g2PG6ff10060@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Kappler Cornelia cc: "'sven.van_den_bosch@alcatel.be'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: Re: [NSIS] text on layering - original mail In-Reply-To: Message from Kappler Cornelia of "Fri, 22 Mar 2002 19:18:46 +0100." <4D486782CA36D4118A530000D11EA42A012656B0@blns204e.bln.icn.siemens.de> References: <4D486782CA36D4118A530000D11EA42A012656B0@blns204e.bln.icn.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Mar 2002 17:06:40 +0100 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Cornelia, > I think the simplest way to include "starting of an aggregate > reservation" is viewing the (logical) entity starting this aggregate as > a QI. Note the "logical". I'm not proposing additional functionality in Surely, one can see it as a logical QI, but this is although generally true for QC <-> QC dialogues. I think we need a clearer definition here (what if the QoS receiver QR is the initiator?), etc. I see an nsis protocol as a two-party protocol between two entities. The QI,QC,QR terminology tries to catch the different roles of the parties for concatenated dialogues between those entities. I'm not sure whether we currently catch all possible cases here. > an aggregating router. ^^^^^^ Who says that a QC must be a router? Regards, Roland > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > > Sent: Friday, March 22, 2002 2:08 AM > > To: Roland Bless > > Cc: Sven Van den Bosch; brunner@ccrle.nec.de; nsis@ietf.org > > Subject: Re: [NSIS] text on layering - original mail > > > > Hi Roland, > > > > I agree, although you could say that even in this case it is first > > triggered by a QC or QI. What I meant was that it couldn't be triggered by > > a QR or by applications. Of course it can sometimes act on its own > > initiative. To make this more clear, I propose to modify the text to: > > ... It can trigger another instance of NSIS signaling or be triggered by a > > QC or a QI. > > > > Thanks, > > Sven. > > > > > > > > > > > > Roland Bless on 22/03/2002 01:51:29 > > > > > > > > To: "Sven Van den Bosch" > > > > > > cc: brunner@ccrle.nec.de, nsis@ietf.org(bcc: Sven > > VAN DEN BOSCH/BE/ALCATEL) > > > > > > > > Subject Re: [NSIS] text on layering - original mail > > : > > > > > > > > > > > > > > Hi Sven, > > > > Why do you make restrictions on triggering? I would remove > > that. For instance, you state that a QC can only be triggered by > > a QI and a QC. However, there are cases when a QC may decide > > to create an aggregate out of existing reservations, so it > > may start a new protocol (trans)action to other QCs in (a) > > without being triggered by other entities. > > > > Regards, > > Roland > > > > svenvandenbosch@hotmail.com said: > > > This suggests the following definitions for the QI, QC, QR > > > - QoS Initiator: Network entity, located at the boundary of a QoS > > > domain, responsible for initiating a (local or end-to-end) QoS > > > mechanism. If it is the QI of a local protocol, it can be triggered by > > > higher layers (applications or end-to-end QoS Controller). If it is > > > the QI of an end-to-end protocol, it can be triggered by applications > > > or by the QoS Receiver of a local QoS signaling mechanism. > > > > > - QoS Controller: Network entity responsible for interpreting and > > > implementing the signalled QoS in the network. Failure to do so > > > implies an admission control decision. It can only be triggered by a > > > QI or another QC. > > > > > -QoS Receiver: Network entity, located at the boundary of a QoS > > > domain, responsible for terminating a (local or end-to-end) QoS > > > mechanism. It has the additional functionality that it may initiate an > > > acknowledgment towards the QI and that it may trigger a QI or QC in > > > the NSIS end-to-end protocol. > > > > > If this can be accepted by the NSIS community, we propose to add this > > > text to the requirements document as a clarification of the QI/QC > > > model that is used there. -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Mar 25 11:44:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19171 for ; Mon, 25 Mar 2002 11:44:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15780 for nsis-archive@odin.ietf.org; Mon, 25 Mar 2002 11:44:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12070; Mon, 25 Mar 2002 11:30:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12033 for ; Mon, 25 Mar 2002 11:30:10 -0500 (EST) Received: from ommo.com ([63.227.234.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18167 for ; Mon, 25 Mar 2002 11:30:01 -0500 (EST) Message-Id: <200203251630.LAA18167@ietf.org> From: "sameez1@dubaimail.com" To: nsis@ietf.org Date: Mon, 25 Mar 2002 17:58:54 -0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6800 DM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12036 Subject: [NSIS] ASSISTANCE NEEDED. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit DR. SOLOMON AZEEZ. Director, Project Implementation, Nigerian National Petroleum Corporation, Falomo Office Complex, Ikoyi - Lagos. SIR, BUSINESS PROPOSAL It is my great pleasure in writing you this letter on behalf of myself and my colleagues. Your particulars were given to me by a member of the Nigerian Export Promotion Council (NEPC) who was at the Federal Government Delegation to your country during a trade exhibition. I have decided to seek a confidentialcooperation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as top secret because of the nature of this business. Within the Ministry of Petroleum Resources where I work as a Director, Project Implementation and with the cooperation of four other top officials we have in our possession as overdue payment bills totalling Fourteen Million, Five Hundred Thousand U. S. Dollars (US$14,500,000.00) which we want to transfer abroad with assistance and cooperation of a foreign company/individual toreceive the said fund on our behalf or a reliable foreign non-company account to receive such funds. Moreso, we are handicapped in the circumstances as the Nigerian Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. The amount represents the balance of the total contract value executed on behalf of my Ministry by a foreign contracting firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the tune of the said amount which we have in principles gotten approval to remit byTelegraphic Transfer (T.T) to foreign bank account you will provide by filing in an application through the Federal Ministry of Justice for the transfer of rights and privileges of the formercontractor to you. Since the new civilian government of my country is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign government and non-government financial agencies, thereforewe have decided to include our bills for approvals with the cooperation of some officials from the FederalMinistry of Finance and the Central Bank ofNigeria (CBN) We are seeking your assistance in providing a vital account or any virgin bank account into which we can remit this money by acting as our main partner and trustee. This we can do by swapping of account and changing of beneficiary and other forms of documentation upon application for claim to reflect the payment and approvals to be secured on behalf of you. This processes being pre-arranged with the principal trustee of the original contractor and with the consent of the original contractor. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction your share of the sum will be 30% of the US$14.5 million, 60% for us and 10% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to e-mail ON;sameez1@dubaimail.com me toknow your position and include your confidential telephoneand fax numbers. Thanks for your cooperation. Yours faithfully, DR. SOLOMON AZEEZ. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 26 08:30:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01709 for ; Tue, 26 Mar 2002 08:30:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA14627 for nsis-archive@odin.ietf.org; Tue, 26 Mar 2002 08:30:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13278; Tue, 26 Mar 2002 08:25:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13238 for ; Tue, 26 Mar 2002 08:25:05 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01586 for ; Tue, 26 Mar 2002 08:25:03 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA22403; Tue, 26 Mar 2002 14:24:56 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA09679; Tue, 26 Mar 2002 14:24:41 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 14:25:23 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656CF@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'sven.van_den_bosch@alcatel.be'" Cc: nsis@ietf.org Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Tue, 26 Mar 2002 14:25:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > > > > - QoS Receiver: Network entity, located at the edge of or inside a QoS > > > > domain, responsible for terminating an instance of an NSIS protocol. Ithas > > > > the additional functionality that it may initiate an acknowledgment towards > > > > the QI and that it may trigger another NSIS entity (QoS Initiator or QoS > > > > Controller of another instance of the NSIS protocol) > > > > > > > why would it trigger a QC? > > The scenario here would be: the QC triggers, upon receiving an NSIS message, > > an instance of NSIS at a QI. Signalling then propagates at the lower NSIS > > layer to a QR which would hand over control back to the QC. In that case > > there would be a client-server relationship between the two instances of > > NSIS. > > > Lets call the triggering QC "QC1" and the QC being handed control from > the QR "QC2". > Is there any relation at all between the QR and QC2? Wouldnt the > "triggering instance" of NSIS just tunnel between QC1 and QC2 (i.e. QC1 > addresses QC2 directly)? > > A scenario in which such a triggering takes place would be e.g. > per-flow NSIS signaling being tunneled through an aggregation region, or > "generic NSIS signaling" being replaced inside one (QoS) domain by another > instance of NSIS signaling (another NSIS protocol, or same protocol with > different QoS information), particulary suited to the needs of this domain. > In both cases I see the original NSIS protocol instance being tunneled > rather than "switched back on" by the QR trigger (there may also be a > timing problem unless the "triggering instance" is piggybacked on the > "triggered instance"). > > Well, the my reasoning above implies QC1 knows QC2. In RSVP for > Aggregates this is the case. I dont know about the general case? > > Sven>> Q1 could be the same as Q2 (potentially even outside the data path) > and it could wait for confirmation that a pipe has been set up before > proceeding with the setup. > Cornelia: I see your point. > > > > - MUST NOT be adversely impacted by mobility aspects (applicable for> > > > > end-to-end) > > > > A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT > > >be adversely affected by mobility issues. Any mobility scenario should be > > > > tackled by other uses of an NSIS protocol and is outside the realm of an > > > > end-to-end application of the NSIS protocol. > > > > > > > what is "other uses of an NSIS protocol"? What is an "e2e app of the NSIS > > >protocol" (I understand this looking at the figures you provided in a > > >recent email, however they are not part of the Req doc)Does this imply NSIS > > >is not supporting mobility? Or: it MUST be possible to support mobility > > >locally, without invoking e2e NSIS signaling? > > > > There may be some confusion here. We have identified three potential network > > parts where NSIS may be applicable: the host-to-first-hop, the access and > > edge-to-edge (covering core, interdomain). Clearly there are different > > requirements in each part. In the access and first-hop mobility will have to > > be supported. Edge-to-edge it must not be supported. We are going to try to > > put this in the requirements by providing the MUST, SHOULD, MAY tables per > > network part where they apply. We don't exclude that there will be one NSIS > > protocol (in which case it needs to be modular) but it is likely that there > > can be more. Hence, other uses of an NSIS protocol. > > The question about layering has come up in our discussions too and I think > > we ahve agreed to put the picture in my mail into the requirements document > > for some clarification on this. > > > > Do you think this is a good idea? > > > A table with MUST / SHOULD / MAY per network part is a good idea, > including the figure, too (as long as it is clear we dont exclude a> > more-than-two-level signaling hierarchy ;-). However, I unfortunately still > dont get the meaning of "other uses". May be you could reformulate the > requirement using another term? > > Sven>> Assuming that the NSIS protocol is edge-to-edge, the other uses are > local applications of an NSIS protocol, e.g. in the access or locally in > the core (as opposed to edge-to-edge). > > Cornelia: OK. While I think in principle this makes sense, in practice this might run into problems because it seems to assume a particular network structure: Wouldnt it be difficult to define exactly what is edge-to-edge? Obviously it excludes an access network. What about a mobile network without an access network (may not exist but this is conceivable, isnt it?) Or: what about the mobile node uses a proxy (probably located in the access network, but not necessarily). At handoff, the proxy might change, so the signaling originating from the proxy would have to deal with mobility. Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 26 08:47:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02513 for ; Tue, 26 Mar 2002 08:47:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA19651 for nsis-archive@odin.ietf.org; Tue, 26 Mar 2002 08:47:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16696; Tue, 26 Mar 2002 08:37:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16639 for ; Tue, 26 Mar 2002 08:37:24 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02109 for ; Tue, 26 Mar 2002 08:37:22 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA23508; Tue, 26 Mar 2002 14:37:20 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA29888; Tue, 26 Mar 2002 14:36:55 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 14:37:42 +0100 Message-ID: <4D486782CA36D4118A530000D11EA42A012656D0@blns204e.bln.icn.siemens.de> From: Kappler Cornelia To: "'Roland Bless'" Cc: "'sven.van_den_bosch@alcatel.be'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: RE: [NSIS] text on layering - original mail Date: Tue, 26 Mar 2002 14:37:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Roland, > -----Original Message----- > From: Roland Bless [SMTP:bless@tm.uka.de] > Sent: Monday, March 25, 2002 5:07 PM > To: Kappler Cornelia > Cc: 'sven.van_den_bosch@alcatel.be'; brunner@ccrle.nec.de; nsis@ietf.org > Subject: Re: [NSIS] text on layering - original mail > > Hi Cornelia, > > > I think the simplest way to include "starting of an aggregate > > reservation" is viewing the (logical) entity starting this aggregate as > > a QI. Note the "logical". I'm not proposing additional functionality in > > Surely, one can see it as a logical QI, but this is although > generally true for QC <-> QC dialogues. I think we need a > clearer definition here (what if the QoS receiver QR is the initiator?), > etc. I see an nsis protocol as a two-party protocol between two > entities. The QI,QC,QR terminology tries to catch the different roles > of the parties for concatenated dialogues between those entities. > I'm not sure whether we currently catch all possible cases here. > I'm not quite sure what you're getting at. Do you view one instance of NSIS signaling as always only between two parties, i.e. at each QC one instance is terminated, and a new instance is originated to talk to the next-hop QC? This is not how I (and I would assume most other people) see it. Rather an NSIS instance is always originated a QI, and always terminated at a QR. If a node terminates a NSIS instance (acting as a QR) there are no problems for the same node to also intitiate an NSIS instance (acting as a QI). For example - ... (thinking...) - when this node is located at the edge of a mobile access network, and it wishes to employ a different NSIS protocol in the access e.g. to cover mobility. I think the definitions Sven sent out the other day are rather clear. Could you send concrete examples of cases that are not covered? > > an aggregating router. > ^^^^^^ > Who says that a QC must be a router? > Of course not, you're right. (but this doesnt change my point) Cornelia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Mar 26 09:00:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03144 for ; Tue, 26 Mar 2002 09:00:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23215 for nsis-archive@odin.ietf.org; Tue, 26 Mar 2002 09:00:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21820; Tue, 26 Mar 2002 08:56:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21783 for ; Tue, 26 Mar 2002 08:55:56 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02966 for ; Tue, 26 Mar 2002 08:55:54 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QDu2s03843 for ; Tue, 26 Mar 2002 15:56:02 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Mar 2002 15:55:48 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 15:55:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 26 Mar 2002 15:55:48 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D06@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] text on layering - original mail Thread-Index: AcHUFy9TdaxA2bBDRVCmA3AE4ne9IgAtqCPQ To: X-OriginalArrivalTime: 26 Mar 2002 13:55:48.0180 (UTC) FILETIME=[EEBC8140:01C1D4CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21785 Subject: [NSIS] Summary of IETF 53 NSIS meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, Here are some rough minutes. They need to be edited. Comments appreciated. John IETF#53 meeting in Minneapolis: 17.03.2002 - 22.03.2002 NEXT STEP IN SIGNALLING WG Draft-ietf-nsis-req-00.txt: Requirements for QoS Signaling Protocols - Markus Brunner 45 min Marcus Brunner went through the requirements based on the discussions in the mailing and the outcome of a 'brainstorming' with authors of some of the drafts. The biggest problem of the draft currently is that scope is very wide. Also we should get rid of application level QoS and low level QoS in order to have more focused target for the NSIS work. Risks in the current situation are that discussion is unproductive and there is a risk of over specifying. In general, it was proposed to select use cases and then create list of requirements and eventually relates them to "parts of the network" part. Also it was proposed that scenarios section and structure of requirements section remain in addition to adding description of "parts of the network" to section 6. Change the tables with MUST's, SHOULD's and MAY's to relate to parts of the network instead of relate them to scenarios. Parts of the network will not be 1) host to first hop (also first hop to host), 2) access network or 3) core to core. It was commented that it is important to differentiate the directions. It was criticized that dividing issue into sections might not be good idea. However there will be different requirements in different contents. It was pointed out in the presentation that some use cases like Voice over IP scenario (from the draft-partain-nsis-requirements-00.txt), the case when host request QoS from the network without mobility, wireless etc. and using s! ignaling to set up the pipes. Regarding to the mobile IP, the hand of decision and trigger sources should be out of the scope of the NSIS. Thus the WG should rather focus only on "establishing" QoS after hand off. Marcus presented also some concerns and pros related to Framework and it was proposed remove the figures, since they are seen as bit misleading. The changes to the text are needed in such a way that we do not want to impose any architecture or constrains. Also the intention is to try to phrase the requirements without relaying too much on the framework. In the issue, who will initiate signaling, accounting was one key issue mentioned, thus it was commented that we should not link signaling protocol solution to accounting. Also it was proposed that we don't assume that requirements are being considered to be for bi-directional reservations. The biggest discussion arose on the globally defined services and especially creating NSIS QoS classes. The question was who should define those QoS classes, since NSIS was not seen as an appropriate group to define them. NSIS could rather collect them, although something need to be done in NSIS WG as well. Massive non-interoperability problems were foreseen as well. Actually this part of the presentation raised many concerns among the DiffServ, RSVP and Intserv pioneers and it was commented that there is not technical problem at all, thus this discussion is purely political. At this point it was mentioned again that the scope and charter is definitely too wide. Also it was clarified that intention of the WG is not to define any new QoS reservation mechanism, thus we are focusing to signaling mechanism only in NSIS. Previously IP fragmentation was proposed to be one requirement, but eventually it was proposed to remove it since it may increase complexity. Some text needs to be added to avoiding duplication, ability to signal lifetime of reservation and independence of reservation identifier sections. The security requirement for the NSIS was also discussed. It was commented that more analysis about the threads are needed and current draft needs more text for security section. The next step of this work is that next version of the draft will be submitted by the end of the may. Draft-fodor-reqts-cellular-netwks-00.txt: NSIS QoS Signaling Requirements from a Multi-access Wireless Perspective - Gabor Fudor - 10 min The presenter liked to emphasize the importance of multi-access wireless networks. The requirements presented in the drafts are 1) host to edge signaling must be per flow, 2) QoS information, 3) bi-directional and asymmetric reservation, 4) local reservation must be supported, 5) multicast, 6) local control, Dos, 7) support for adaptivity. No comments were provided in the meeting. Draft-buchli-nsis-req-00.txt: QoS signaling requirements, interfaces and architecture - Sven Van Den Bosch - 10 min Main goal of the draft is to enable hard guaranteed per-flow end-to-end QoS. Relation to NSIS WG draft was elaborated in the presentation. Basically the terminology and requirement section are inherently covered currently. QoS signaling and QC must not constrained to be in the data path and 2 level QoS granularities are emphasized. Mobility, modularity, universality of signaled parameters, communication between QI/QC and local administration are de-emphasized or not even applicable. Some requirements are new: priority, grouping of micro-flows. The authors of the draft support proposal to split work into three areas and propose to add use cases, terminology and requirements to WG draft. Also it was proposed to move some use cases to framework document. Some kind of document that is describing the use of NSIS would be good to have. Draft-hancock-nsis-framework-00.txt: NSIS Framework Issues - Robert Handcock 10 min It was stated especially in the presentation that AAA/policy capability is needed. Anyway the level of Security needs more discussion. Presentation covered issues like receiver-initiated reservations, bi-directional reservations and end-to-end signaling. Correlation between application level signaling was mentioned in the discussions. Eventually the conclusion was that the authors do not see any showstoppers, although AAA needs to be investigated more. Next Steps - all - 20 min · Re-publish requirement document · Start working on analyses of existing signaling protocols document · Start work on framework signaling document · Possible interim meeting: target date would be in May, Location open (possibly in Helsinki, Dallas, Boston, ...) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 27 05:38:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21958 for ; Wed, 27 Mar 2002 05:38:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18155 for nsis-archive@odin.ietf.org; Wed, 27 Mar 2002 05:38:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16474; Wed, 27 Mar 2002 05:31:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16385 for ; Wed, 27 Mar 2002 05:31:11 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21889 for ; Wed, 27 Mar 2002 05:31:08 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2RAUdm03074 for ; Wed, 27 Mar 2002 11:30:39 +0100 (MET) Subject: RE: [NSIS] text on layering - original mail To: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 27 Mar 2002 11:30:38 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/27/2002 11:30:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This mail was accidentily not copied to the nsis list.. Sven. ---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on 27/03/2002 11:29 --------------------------- Sven VAN DEN BOSCH 25/03/2002 12:22 To: Kappler Cornelia cc: Subject: RE: [NSIS] text on layering - original mail (Document link: Sven VAN DEN BOSCH) I agree. Sven. Kappler Cornelia on 22/03/2002 19:18:46 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, Roland Bless cc: brunner@ccrle.nec.de, nsis@ietf.org Subject RE: [NSIS] text on layering - original mail : I think the simplest way to include "starting of an aggregate reservation" is viewing the (logical) entity starting this aggregate as a QI. Note the "logical". I'm not proposing additional functionality in an aggregating router. Cornelia > -----Original Message----- > From: sven.van_den_bosch@alcatel.be [SMTP:sven.van_den_bosch@alcatel.be] > Sent: Friday, March 22, 2002 2:08 AM > To: Roland Bless > Cc: Sven Van den Bosch; brunner@ccrle.nec.de; nsis@ietf.org > Subject: Re: [NSIS] text on layering - original mail > > Hi Roland, > > I agree, although you could say that even in this case it is first > triggered by a QC or QI. What I meant was that it couldn't be triggered by > a QR or by applications. Of course it can sometimes act on its own > initiative. To make this more clear, I propose to modify the text to: > ... It can trigger another instance of NSIS signaling or be triggered by a > QC or a QI. > > Thanks, > Sven. > > > > > > Roland Bless on 22/03/2002 01:51:29 > > > > To: "Sven Van den Bosch" > > > cc: brunner@ccrle.nec.de, nsis@ietf.org(bcc: Sven > VAN DEN BOSCH/BE/ALCATEL) > > > > Subject Re: [NSIS] text on layering - original mail > : > > > > > > > Hi Sven, > > Why do you make restrictions on triggering? I would remove > that. For instance, you state that a QC can only be triggered by > a QI and a QC. However, there are cases when a QC may decide > to create an aggregate out of existing reservations, so it > may start a new protocol (trans)action to other QCs in (a) > without being triggered by other entities. > > Regards, > Roland > > svenvandenbosch@hotmail.com said: > > This suggests the following definitions for the QI, QC, QR > > - QoS Initiator: Network entity, located at the boundary of a QoS > > domain, responsible for initiating a (local or end-to-end) QoS > > mechanism. If it is the QI of a local protocol, it can be triggered by > > higher layers (applications or end-to-end QoS Controller). If it is > > the QI of an end-to-end protocol, it can be triggered by applications > > or by the QoS Receiver of a local QoS signaling mechanism. > > > - QoS Controller: Network entity responsible for interpreting and > > implementing the signalled QoS in the network. Failure to do so > > implies an admission control decision. It can only be triggered by a > > QI or another QC. > > > -QoS Receiver: Network entity, located at the boundary of a QoS > > domain, responsible for terminating a (local or end-to-end) QoS > > mechanism. It has the additional functionality that it may initiate an > > acknowledgment towards the QI and that it may trigger a QI or QC in > > the NSIS end-to-end protocol. > > > If this can be accepted by the NSIS community, we propose to add this > > text to the requirements document as a clarification of the QI/QC > > model that is used there. > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 27 07:11:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23380 for ; Wed, 27 Mar 2002 07:11:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09869 for nsis-archive@odin.ietf.org; Wed, 27 Mar 2002 07:11:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07779; Wed, 27 Mar 2002 07:02:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07734 for ; Wed, 27 Mar 2002 07:02:20 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22819 for ; Wed, 27 Mar 2002 07:02:19 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16qC88-0001N2-00; Wed, 27 Mar 2002 13:02:17 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16qC88-0003PN-00; Wed, 27 Mar 2002 13:02:16 +0100 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g2RC2Ff18950; Wed, 27 Mar 2002 13:02:16 +0100 Message-Id: <200203271202.g2RC2Ff18950@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Kappler Cornelia cc: "'sven.van_den_bosch@alcatel.be'" , brunner@ccrle.nec.de, nsis@ietf.org Subject: Re: [NSIS] text on layering - original mail In-Reply-To: Message from Kappler Cornelia of "Tue, 26 Mar 2002 14:37:39 +0100." <4D486782CA36D4118A530000D11EA42A012656D0@blns204e.bln.icn.siemens.de> References: <4D486782CA36D4118A530000D11EA42A012656D0@blns204e.bln.icn.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 27 Mar 2002 13:02:15 +0100 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Cornelia, > I'm not quite sure what you're getting at. Do you view one instance > of NSIS signaling as always only between two parties, i.e. at each QC > one instance is terminated, and a new instance is originated to talk to I fear we run in terminology trouble here: I'm not sure what you mean by "instance" and "terminate". Maybe we mean the same, so let me explain my view (although we want to get rid of the QI/QC model in the requirements): - A QI requests a reservation from its QC and it will get (later on) a response to this request from the same QC. I call this a "signaling transaction" because the request and the response relate to the same reservation. An nsis protocol will define exact rules for this dialogue between QI and QC (thus two-party protocol). - When a QC receives a request from a QI, various things can happen, among which are: a) it can start a domain-internal signaling for local QoS provisioning, this may involve edge-to-edge signaling where other QCs are involved. In this case another QC (egress edge) may continue the signaling. b) it signals another QC in the next domain along the path (note, that this may be the adjacent QC or an aggregate endpoint, thus a "logically" adjacent QC). The original request is usually modified by the QC. - A QC receives a request from a QC (also an nsis protocol). This QC may forward the request further if the QR is not "the next hop". If the QR is the next entity to be asked, the QC send a request towards the QR, or, the QC acts on behalf of the QR as a proxy, and, e.g. performs admission control for the QR according to a predefined policy. - Due to asymmetric paths it may be required that a QR signals the sender to act as a QI. Thus, it will get also the response from the sender. To summarize: - A QI just requests a reservation from its QC. How the QC manages to allocate resources along the path to the QR (within its own domain and along other domains) is usually not of interest for the QI and should be transparent. - We have a hop-by-hop (logical hops) signaling protocol which is in some sense "terminated" at each hop, because usually new request messages are created at each nsis hop. Surely, these request messages are logically related to each other, because they are related to the same reservation. - nsis should allow logical end-to-end signaling in the sense that a QR is usually also involved in the overall signaling procedure (except when a proxy is used instead). > the next-hop QC? This is not how I (and I would assume most other > people) see it. Rather an NSIS instance is always originated a QI, and > always terminated at a QR. If a node terminates a NSIS instance (acting > as a QR) there are no problems for the same node to also intitiate an > NSIS instance (acting as a QI). For example - ... (thinking...) - when > this node is located at the edge of a mobile access network, and it > wishes to employ a different NSIS protocol in the access e.g. to cover > mobility. I don't get your point here. I find the above described model rather flexible and fitting well into the nsis charter. > I think the definitions Sven sent out the other day are rather clear. > Could you send concrete examples of cases that are not covered? Consider receiver initiated unicast resource reservations: a "QR" acts as a QI to contact the sender which then acts as a QI. This is possible, but currently a little bit confusing, when we say that a QI may be triggered by a QR etc. In this case we may have: Receiver (QI) -> Sender (QR) Sender (QI) -> QC ... -> Receiver (QR) > > > an aggregating router. > > ^^^^^^ > > Who says that a QC must be a router? > > > Of course not, you're right. (but this doesnt change my point) Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 27 07:18:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24311 for ; Wed, 27 Mar 2002 07:18:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA12214 for nsis-archive@odin.ietf.org; Wed, 27 Mar 2002 07:18:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10908; Wed, 27 Mar 2002 07:14:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10847 for ; Wed, 27 Mar 2002 07:14:11 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23610; Wed, 27 Mar 2002 07:14:10 -0500 (EST) Message-Id: <200203271214.HAA23610@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 27 Mar 2002 07:14:09 -0500 Subject: [NSIS] I-D ACTION:draft-weijing-rsvp-sqn-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to RSVP for RSVP over Signaled QoS Network Author(s) : W. Chen, K. Allen Filename : draft-weijing-rsvp-sqn-00.txt Pages : 11 Date : 26-Mar-02 This document describes the use of RSVP, including all the necessary extensions, to establish guaranteed QoS IP sessions over a signaled QoS network. The examples of signaled QoS network are ATM SVC network and MPLS network with proper UNI signaling. The specified approach is very scalable with large number of service subscribers and incurs minimum administrative and operation overhead of service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weijing-rsvp-sqn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weijing-rsvp-sqn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-weijing-rsvp-sqn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020326114148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-weijing-rsvp-sqn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-weijing-rsvp-sqn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020326114148.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 27 13:32:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14737 for ; Wed, 27 Mar 2002 13:32:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28977 for nsis-archive@odin.ietf.org; Wed, 27 Mar 2002 13:32:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27199; Wed, 27 Mar 2002 13:24:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27056 for ; Wed, 27 Mar 2002 13:24:49 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10169 for ; Wed, 27 Mar 2002 12:31:49 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g2RHVJN09580 for ; Wed, 27 Mar 2002 12:31:19 -0500 (EST) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA23922; Wed, 27 Mar 2002 12:31:18 -0500 Message-ID: <3CA201E4.E040A3C9@bell-labs.com> Date: Wed, 27 Mar 2002 12:31:16 -0500 From: Igor Faynberg Reply-To: faynberg@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Flow Definition? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Ladies and Gentlemen: Reading with great interest 'draft-ietf-nsis-req-00.txt', I became puzzled by the new definition of a flow: "Flow: a traffic stream (sequence of IP packets between two end systems) for which a specific level of QoS is to be provided. The flow can be unicast (uni- or bi-directional) or multicast." It looks to me like a significant departure from, say RFC 1633, which describes a flow as "... a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS. For example, a flow might consist of one transport connection or one video stream between a given host pair..." and further says: "A flow might consist of one transport connection or one video stream between a given host pair." So, with the new definition, two such transport connections, both between a given pair of hosts, would still form the same flow. Is that what was intended? If so, why? With best regards, Igor Does it mean that if I have two _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Mar 27 14:07:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16847 for ; Wed, 27 Mar 2002 14:07:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02224 for nsis-archive@odin.ietf.org; Wed, 27 Mar 2002 14:07:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00981; Wed, 27 Mar 2002 13:59:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00948 for ; Wed, 27 Mar 2002 13:59:17 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16334 for ; Wed, 27 Mar 2002 13:59:16 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g2RJ1vN01331 for ; Wed, 27 Mar 2002 13:01:57 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g2RIwZV09730 for ; Wed, 27 Mar 2002 12:58:35 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:59:16 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632253A@TRIMAIL2.ad.tri.sbc.com> From: "Chen, Weijing" To: nsis@ietf.org Date: Wed, 27 Mar 2002 12:59:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [NSIS] Internet Draft for QoS IP Service through RSVP/SQN Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org An Internet Draft was uploaded in IETF Internet Draft Directory. Title "Extensions to RSVP for QoS IP Services over Signaled QoS Network" Abstract: This document describes the use of RSVP, including all the necessary extensions, to establish guaranteed QoS IP sessions over a signaled QoS network. The examples of signaled QoS network are ATM SVC network and MPLS network with proper UNI signaling. The specified approach is very scalable with large number of service subscribers and incurs minimum administrative and operation overhead of service providers http://www.ietf.org/internet-drafts/draft-weijing-rsvp-sqn-00.txt -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Mar 28 04:09:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19427 for ; Thu, 28 Mar 2002 04:09:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02444 for nsis-archive@odin.ietf.org; Thu, 28 Mar 2002 04:09:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01887; Thu, 28 Mar 2002 04:01:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01858 for ; Thu, 28 Mar 2002 04:01:13 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19292 for ; Thu, 28 Mar 2002 04:01:10 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g2S90dQ74498 for ; Thu, 28 Mar 2002 10:00:39 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA17837 for ; Thu, 28 Mar 2002 10:00:38 +0100 Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 0FD3D33026; Thu, 28 Mar 2002 10:00:38 +0100 (CET) X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen References: <3CA201E4.E040A3C9@bell-labs.com> From: Marcus Brunner MIME-Version: 1.0 Subject: Re: [NSIS] Flow Definition? To: Content-type: text/plain; charset= "iso-8859-1" Date: Thu, 28 Mar 2002 10:00:37 +0100 Content-transfer-encoding: 7bit Message-Id: <20020328090038.0FD3D33026@imap.heidelberg.ccrle.nec.de> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Reading our flow definition, I currently would be not even specific about end-systems. The intention was not to prescribe, what a flow is, but say that the flow is the traffic getting s specific quality. So e.g. an (behaviour) aggregate might be signaled for as well. Marcus > Ladies and Gentlemen: > > Reading with great interest 'draft-ietf-nsis-req-00.txt', I became > puzzled by the new definition of a flow: > > "Flow: a traffic stream (sequence of IP packets between two end > systems) for which a specific level of QoS is to be provided. The > flow can be unicast (uni- or bi-directional) or multicast." > > It looks to me like a significant departure from, say RFC 1633, which > describes a flow as > > "... a > distinguishable stream of related datagrams that results from a > single user activity and requires the same QoS. For example, a > flow might consist of one transport connection or one video stream > between a given host pair..." > > and further says: > > "A flow might consist of one transport connection or one video stream > between a given host pair." > > So, with the new definition, two such transport connections, both > between a given pair of hosts, would still form the same flow. Is that > what was intended? If so, why? > > With best regards, > > Igor > Does it mean that if I have two > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Mar 31 21:03:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01708 for ; Sun, 31 Mar 2002 21:03:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA22289 for nsis-archive@odin.ietf.org; Sun, 31 Mar 2002 21:03:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21587; Sun, 31 Mar 2002 20:54:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21549 for ; Sun, 31 Mar 2002 20:54:12 -0500 (EST) Received: from servernodo.eurowin.it ([151.99.143.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01570; Sun, 31 Mar 2002 20:54:09 -0500 (EST) Received: from mx.arshia.net=0 (1Cust7.tnt1.bloomington.il.da.uu.net [63.27.139.7]) by servernodo.eurowin.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H44GFGK0; Mon, 1 Apr 2002 03:51:48 +0200 Message-ID: <00001b311f96$000079a7$00000cd3@elissa.destination.com.lb=1> To: , , , , , , , Cc: , , , , , , <100644.2116@compuserve.com>, From: "ricardo" Date: Sun, 31 Mar 2002 19:47:54 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [NSIS] I n t e r n e t D e t e c t i v e 21831 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: quoted-printable
Interne= t Detective 5.0
 
The Internet's BEST Sel= ling Spy Software Is Now Better Than Ever!
 
Track, Locate, Or Conduct = A Complete Background Check On Anyone, At Anytime!  Protect Your Family From Imp= ostors Or People With Criminal Records.
 
Investigate Anyone Or Everyone = From The Privacy Of Your Home.  This Program Allows You To Tap Into The Very S= ame Information Sources That Are Used By Professional Private Investigators!!
 
ONLY $29.95
 
Click Here And Get It Now      http://netdet.direct2you.bz/?chck
 
 
To Be Removed From Further Mailings, Clic= k Here http://remove.direct2you.bz/
_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis