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

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

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.

[email-masked] on 07/03/2002 14:17:56

  To:          [email-masked]                    
                                                              
  cc:          [email-masked](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:[email-masked]]
> Sent: den 7 mars 2002 13:27
> To: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98
> Cc: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Thu, 07 Mar 2002 17:15:15 +0100

Hi,

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