RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes

["Yoram Bernet" <[e-mail]>]

The drafts discussed in the attached mail (approved for RFCs) might shed
some light on the interaction of RSVP and diffserv...
 
Y
 
 

-----Original Message-----
From: Jay Wang [mailto:[e-mail]]
Sent: Monday, September 25, 2000 3:18 PM
To: 'Brian E Carpenter'; [e-mail]
Cc: '[e-mail]'
Subject: RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress
nodes





> -----Original Message----- 
> From: Brian E Carpenter [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Monday, September 25, 2000 1:40 PM 
> To: [e-mail] 
> Cc: '[e-mail]' 
> Subject: Re: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress 
> nodes 
> 
> 
> Dave Hotlosz wrote: 
> > 
> > Hi, 
> > I have a question I haven't seen addressed yet, again if I 
> missed it a 
> > pointer 
> > is great. 
> > 
> > First I've seen some comments about ensuring proper capacity of the 
> > DS domain to service 
> > all the traffic that ISP can send under the SLA agreements. 
> I've noticed 
> > that some venders 
> > are using RSVP to allocate resources for diffserve traffic. Is this 
> > something that most if not 
> > all will be doing in order to ensure proper bandwidth for diffserve 
> > traffic? Or is it that the 
> > SLA and policys in place will require ingress nodes to limit traffic

> > into the DS domain and 
> > the number of ingress nodes into a particular domain are limited in 
> > order to service all ingress 
> > nodes up to the SLA requirements? I haven't seen this 
> specified anywhere 
> > and it seems like 
> > a missing piece to me. 
> 
> Yes, it's required that DS domains police incoming traffic, 
> which is why 
> the traffic conditioning described in the router model includes 
> policing actions. The diffserv configuration at ingress routers has to

> include the necessary policing parameters. These will be derived from 
> COPS, SNMP or any other method of router configuration. And they will 
> be needed regardless of whether RSVP/diffserv integration is 
> in use - that 
> simply adds a dialogue between the end system and the ingress router. 
> 
> 
> > 
> > The other part I'm concered with is the fact that DS 
> domains can have 
> > differing actions on a 
> > DSCP and I don't see anyway of finding out what those 
> actions are from 
> > the DS domain. 
> > Will a ingress node only enter one DS domain or can it 
> enter more than 
> > one DS domain. 
> > Should the ingress node be able to query a DS doamin for PDB/PHB and

> > adjust it's DSCP 
> > to match the domain? If it is using a MF classifier does it 
> use RSVP to 
> > ensure the DS domain 
> > treats the packet at the right classification and service level? 
> 
> If two domains touch but have incompatible SLAs (i.e. they treat the 
> same DSCP differently) there will be traffic conditioning at 
> the boundary. 
> This is assumed to be statically configured, not discovered 
> dynamically. 
> 
> > 
> > In RSVP you can make sure the network will reserve 
> bandwidth for your 
> > traffic and you get 
> > confirmation about the network connection and how it will 
> handle it. I'd 
> > like to see a similar 
> > mechanism for diffserve where you can query a DS domain and find out

> > PDB/PHB for a domain 
> 
> That's exactly what diffserv doesn't do. Diffserv service classes 
> are agreed and configured in advance, not discovered or created 
> dynamically. 
> 
> > as well as a way to register priority for values in the 
> fields that a DS 
> > domain uses in addition 
> > to the DSCP in a domain that does MF classification. 
> 
> Can't parse. 
> 

Dave, 

If not misunderstanding your comment, I think you were saying that we 
should devise a mechanism, in addition to the DSCP, to allow us to
specify 
the priority level for a RSVP-signaled flow over a DS domain.  But in
fact 
DSCP is not used by a DS router to do MF classification as you
suggested. 
DSCP encodes the information that instructs a DS router how to treat the

packet from the perspective of QoS/forwarding, and this could in fact
include 
the priority level for the corresponding flow. It is all up to (and
intentionally 
so) the DS domain as far as how to differentiate the services using the
DSCP 
although one may argue that for EF traffic there is little flexibility
though. 


- Jay 


> 
> > 
> > I think the ingress node and the DS doamin should have a defined 
> > interface for getting and setting 
> > this information. 
> 
> We explicitly chose not to define dynamic signalling for diffserv, 
> to avoid scaling problems. 
> 
> > Also if it will be common to be using RSVP and diffserve 
> together in a 
> > DS domain that their 
> > use together should be defined. 
> 
> See ISSLL. 
> 
> > This will help resolve the questions 
> > about allocation and use 
> > of DS domain resources when traffic in a node or to a egress exceeds

> > configured capacity. 
> 
> That's an operational matter of configuring x resources for 
> IntServ and 100-x 
> for DiffServ. 
> 
>    Brian 
> 
> _______________________________________________ 
> diffserv mailing list 
> [e-mail] 
> http://www1.ietf.org/mailman/listinfo/diffserv
<http://www1.ietf.org/mailman/listinfo/diffserv>  
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
<http://www-nrg.ee.lbl.gov/diff-serv-arch/>  
> 

--- Begin Message ---

The IESG has approved the following Internet-Drafts as Proposed
Standard:

 o Format of the RSVP DCLASS Object
	<draft-ietf-issll-dclass-01.txt>

 o Specification of the Null Service Type
	<draft-ietf-issll-nullservice-00.txt>

In the same action, the IESG approved publication of A Framework
For Integrated Services Operation Over Diffserv Networks 
<draft-ietf-issll-diffserv-rsvp-05.txt> as an Informational RFC.  

These documents are the product of the Integrated Services over
Specific Link Layers Working Group.  The IESG contact persons are
Allison Mankin and Scott Bradner.

 
Technical Summary
 
 The Integrated Services architecture provides a means for the delivery
 of end-to-end QoS to applications over heterogeneous networks. To
 support this end-to-end model, the Intserv architecture must be
 supported over a wide variety of different types of network elements.
 In this context, a network that supports Differentiated Services
 (Diffserv) may be viewed as a network element in the total end-to-end
 path, and a framework may described on this basis for the support of
 particular Integrated Services over Diffserv networks, with RSVP
 playing a key role.

 RSVP signaling may be used to request QoS services and enhance the
 manageability of application traffic's QoS in a differentiated service
 (diffserv or DS) network.  When using RSVP with DS networks it is
 useful to be able to carry Differentiated Services Code Points (DSCPs)
 in RSVP message objects.  One example of this is the use of RSVP to
 arrange for the marking of packets with a particular DSCP upstream
 from the DS network's ingress point, at the sender or at a previous
 network's egress router.  The DCLASS object is used to represent and
 carry DSCPs within RSVP messages.  The "Format of the RSVP DCLASS
 Object" document specifies the format of the DCLASS object and
 discusses its use.

 In the typical RSVP/Intserv model, applications request a specific
 Intserv service type and quantify the resources required for that
 service. For certain applications, the determination of service
 parameters is best left to the discretion of the network
 administrator. For example, Enterprise Resource Planning (ERP)
 applications are often mission critical, and they often require some
 form of prioritized service, but may not be able readily to specify
 their resource requirements. To serve applications of this sort, the
 notion of the 'Null Service' is defined. The Null Service allows
 applications to identify themselves to network QoS policy agents,
 using RSVP signaling, without requiring them to specify their resource
 requirements. QoS policy agents in the network respond by applying
 QoS policies appropriate for the application (as determined by the
 network administrator).  This mode of RSVP usage is particularly
 applicable to networks that combine differentiated service (diffserv)
 QoS mechanisms with RSVP signaling. In this environment, QoS policy
 agents may direct the signaled application's traffic to a particular
 diffserv class of service.


Working Group Summary

 The working group supported publication of these three documents, and
 they also received some discussion by the related WGs, RSVP and
Diffserv.

Protocol Quality

 These documents were reviewed for the IESG by Allison Mankin.

--- End Message ---