Subject: [NSIS] section 3.5 in nsis-req-00.txt

From: [email-masked]
Date: Wed, 6 Mar 2002 17:46:25 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 7 Mar 2002 08:42:15 +0100

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

---

From: [email-masked]
Date: Thu, 7 Mar 2002 09:31:17 +0100

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 7 Mar 2002 11:21:46 -0000

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: [email-masked] [mailto:[email-masked]]
> Sent: 07 March 2002 08:31
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt
> 
> 
> Ruediger, 
> 
> 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
> 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
> - 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). 
> - 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)
> 
> 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.
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 7 Mar 2002 13:27:27 +0100

Anders,

thanks for your clarification. I largely agree with your postions. Some comments in line.

Regards, Rüdiger

>   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 

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.

>   'service') to be mapped. This should be under the
>   control of the carrier.
>   to be passed between two carriers. nsis must also use
>   this value when doing CAC. 
>   (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!

> understand what you want to do)

Switching here means automated negotiation of service specific resources between domains.

---

From: [email-masked]
Date: Thu, 7 Mar 2002 14:15:20 +0100

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. 
 
> [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).

> *) 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

---

From: [email-masked]
Date: Thu, 7 Mar 2002 14:17:56 +0100

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

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: den 7 mars 2002 13:27
> To: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98
> Cc: [email-masked]
> 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.
> 
> > 
> Agreed too. And I really appreciate that you restrict the 
> only service parameter to be communicated by signaling to 
> bandwidth. Keep things simple!
>  
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 7 Mar 2002 17:20:30 -0000

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.

> Sent: 07 March 2002 13:15
> To: Hancock, Robert; [email-masked]
> Cc: [email-masked]
> I would assume that all business agreements between carriers 
> are in place before the nsis-protocol kicks in. This means 
> for me that: 
> 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).
> 
> 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
>

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 08:09:46 +0100

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: [email-masked]
> 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:  [email-masked]
 81359 Muenchen
 Germany

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:20:28 +0200

Hi Anders,

>   'service') to be mapped. This should be under the control of 

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.

>   to be passed between two carriers. nsis must also use this 

This is very close to a specific solution, so I don't think
we can go there yet.

> that has crossed the link between two carriers)

I think the requirement more properly is:

	NSIS SHOULD interact with accouting systems.
John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 09:21:25 +0100

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

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:25:49 +0200

Hi Robert,

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

> 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

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 09:29:32 +0100

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 09:31:05 +0100

Yes. 

Anders

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:32:33 +0200

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.

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:30:22 +0200

Hi Anders,

	The QoS-architecture MUST NOT restrict the parties relationship, 
      i.e. - the architecture MUST be completely agnostic to how
	the parties make service agreements.

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:37:37 +0200

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 09:43:01 +0100

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 8 mars 2002 09:38
> To: [email-masked]; Bergsten, Anders P. /Research
> /0920-754 50, 070-661 44 98; [email-masked]

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:51:24 +0200

Hi Anders,

Understood - I just trying to remind folks that calls have a specific
connotation, and we should be aware of this.

John

> From: ext [mailto:[email-masked]]
> Sent: 08 March, 2002 10:43
> To: Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]
> 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
>

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:08:16 +0100

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.

[email-masked] on 08/03/2002 09:47:32

  To:          [email-masked], Sven VAN DEN                  
               BOSCH/BE/ALCATEL@ALCATEL                       
                                                              
  cc:          [email-masked], [email-masked],     
               [email-masked]                    

  Subject      RE: [NSIS] section 3.5 in nsis-req-00.txt      
  :                                                           

Roland,

> 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

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 10:14:21 +0100

Hi John, Sven

> Provider A: Of the service S I know you provide I would like 10k

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.

---

From: [email-masked]
Date: Fri, 8 Mar 2002 11:17:36 +0200

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

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 10:36:00 +0100

Hi John,

> Question - where do the pre-defined services get defined?

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.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 11:07:33 +0100

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 12:08:27 +0200

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 11:13:26 +0100

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 11:14:31 +0100

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.

---

From: [email-masked]
Date: Fri, 8 Mar 2002 12:17:07 +0200

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.

> 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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 12:18:21 +0200

Hi Sven,

> Provider A: Of the service S I know you provide I would like 10k

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 12:41:29 +0200

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 11:40:03 +0100

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 13:53:01 +0100

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 <[email-masked]> on 08/03/2002 10:14:21

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL,         
               [email-masked], [email-masked]         
                                                              
  cc:                                                         

Hi John, Sven

> Provider A: Of the service S I know you provide I would like 10k

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.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 14:04:10 +0100

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

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 1:53 PM
> To: Winter Martin
> Cc: [email-masked]; [email-masked]; [email-masked]
> (globally

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 14:46:33 +0100

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.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 15:05:28 +0100

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

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

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 15:16:08 +0100

Hi Rüdiger,
 
> 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.

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 15:28:38 +0100

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

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 15:54:46 +0100

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 <[email-masked]> on 08/03/2002 14:46:33

  To:          "'Geib, Ruediger'"                             
               <[email-masked]>, Sven VAN DEN    
               BOSCH/BE/ALCATEL@ALCATEL                       
                                                              
  cc:          [email-masked]                                  

Hi Rüdiger, Sven,

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

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

---

From: [email-masked]
Date: Mon, 11 Mar 2002 15:50:50 +0100

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" <[email-masked]>@ietf.org on 08/03/2002
11:40:03

Sent by:  [email-masked]

To:   [email-masked], "Geib, Ruediger"
      <[email-masked]>
cc:   [email-masked]
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

---

From: [email-masked] (Gabor Fodor)
Date: Mon, 11 Mar 2002 16:28:09 +0100 (MET)

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 [email-masked] Mon Mar 11 15:51:42 2002
> From: [email-masked]
> To: "Geib, Ruediger" <[email-masked]>
> Cc: [email-masked], "Geib, Ruediger" <[email-masked]>,
>         [email-masked]
> 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 <nsis.ietf.org>
> X-BeenThere: [email-masked]
> 
> 
> Hi all,
>

---

From: [email-masked]
Date: Mon, 11 Mar 2002 17:17:03 +0100

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

[email-masked] (Gabor Fodor) on 11/03/2002 16:28:09

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   [email-masked]
Subject:  RE: [NSIS] section 3.5 in nsis-req-00.txt

Juan-Carlos,

/Gabor

---

From: [email-masked] (Gabor Fodor)
Date: Mon, 11 Mar 2002 18:08:23 +0100 (MET)

Hi Juan-Carlos,

> 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

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 [email-masked] Mon Mar 11 17:17:52 2002
> To: [email-masked] (Gabor Fodor)
> Cc: [email-masked]
> Date: Mon, 11 Mar 2002 17:17:03 +0100
>  03/11/2002 17:17:04
> X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27058
> X-Mailman-Version: 1.0

---

From: [email-masked]
Date: Tue, 12 Mar 2002 13:58:28 +0100

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

[email-masked] (Gabor Fodor) on 11/03/2002 18:08:23

Hi Juan-Carlos,

/Gabor

---

From: [email-masked]
Date: Sat, 16 Mar 2002 01:04:35 +0200

Hi Juan-Carlos,

> 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

---

From: Bob Braden <[email-masked]>
Date: Fri, 15 Mar 2002 23:30:38 GMT

*> 
  *> > 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

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sat, 16 Mar 2002 19:32:01 -0500

John,

> 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

---

From: [email-masked]
Date: Sun, 17 Mar 2002 16:15:56 +0200

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

---

From: Winter Martin <[email-masked]>
Date: Mon, 18 Mar 2002 11:19:25 +0100

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.

> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: Sunday, March 17, 2002 1:32 AM
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
> 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