Subject: RE: Proposed MS-PW "QoS" Requirements Clarifications

From: [email-masked]
Date: Thu, 31 Mar 2005 08:43:20 +0100

Dave,
 
Regarding your suggestion to carry parameters such as the average rate, burst duration and peak rate, and your references to RFC2697/RFC2698, I assume that this is to support per MS-PW policing/queuing at S-PEs? One case where per MS-PW policing will be needed is at border S-PEs where a provider may not trust another provider to police individual MS-PWs correctly. One case where per MS-PW queues (and associated traffic counters) could be used is at border S-PEs to obtain per MS-PW usage information in order to support usage based inter-provider charging models. Based on these inter-provider use cases, I agree that there will be a requirement to carry traffic parameters in order to support per MS-PW policing/queuing.
 
In the intra-provider case however, my view is that per MS-PW policing/queuing at S-PEs will not be required (in most cases). I believe a common approach will be to use per MS-PW/AC policing at the edge and class based queuing/policing everywhere else. At non PW switching capable nodes, packets will be classified/queued based on information in the tunnel LSP header (e.g. EXP field, label). At S-PEs, after popping the tunnel label, packets will need to be classified based on information in the MS-PW LSP header, mapped to the appropriate tunnel LSP (and EXP value) and queued accordingly. In this scenario, assuming each S-PE has a route to reach the destination U-PE (based on reachability or topology information), the MS-PW signalling protocol just needs to specify how much bandwidth is required and carry enough information (e.g. EXP field) to perform CAC and reserve the required bandwidth for the corresponding DS-TE tunnel LSP (or CT in the multi-class LSP case, draft-minei-diffserv-te-multi-class-00.txt).
 
This approach is well suited to MS-PWs that map to a single class of service. If a MS-PW maps to multiple classes of service then things get more complicated as the signalling protocol needs to carry <bandwidth, EXP> pairs, and multiple bandwidth reservations and CAC decisions must be made at each hop. In addition, in the DS-TE case, depending on the network design/topology, tunnels for different CTs could potentially traverse different S-PEs, making things significantly more complicated.
Rather than reserve bandwidth at each hop for some types of MS-PWs, an alternative will be to set up the MS-PWs without performing any CAC or reserving any bandwidth in the same way that RFC2547 VPNs are set up. This approach relies on per MS-PW/AC policing at the edge, and network monitoring/planning to configure appropriate queue weights in order to ensure that there is enough bandwidth available. Obviously MS-PWs that have been setup without using CAC must use different tunnel LSPs to MS-PWs setup using CAC, otherwise performing CAC on those MS-PWs is a waste of time.
 
Regarding your suggestion to carry QoS parameters such as latency, jitter, loss, my feeling is that this should be for further study and is not a short term requirement (although other providers may disagree ?). Firstly, to support this model, standardised performance monitoring tools/MIBs would be required to provide source U-PEs and S-PEs with network performance information on a per tunnel LSP/class of service basis. I do not believe these are available today and I am not aware of any work in progress in this area? Secondly, in the intra-provider case where class based queuing is commonly used, by signalling a specific class of service for a MS-PW (e.g. by specifying an EXP value) then the latency, jitter, loss, etc. characteristics will be inherited from the tunnels LSPs. Therefore, by mapping ACs to classes of service at the edge that can meet the required (latency, jitter, loss) requirements, there is no need to signal the traffic characteristics using the MS-PW signalling protocol. 
 
This approach does not work well in the inter-provider case because different providers will offer different class of service options with varying traffic characteristics, and therefore it may be very difficult or not possible to map class of service definitions between providers. However, inter-provider PW setup is a general issue and I do not think the MS-PW requirements document needs to state exactly what parameters must be carried in order to solve the problem as these will be dependent on the solutions. For example, an inter-provider solution might be developed that uses BGP for signalling and routing, in which case BGP communities might be used to signal QoS parameters, e.g. Well Known Community X means that a MS-PW requires <200ms delay.

I agree that if the QoS requirements are too vague then we need to provide further clarification, although we don’t want to start getting too specific otherwise we will end up trying to write a protocol design specification. If consensus is that the requirements document should specify exactly which traffic parameters should be carried then I don't have any strong objections. However, I think it will be difficult to cover all current and future intra and inter provider cases as QoS models vary significantly between providers and new solutions will become available over time. I would prefer to define requirements along the lines of:
 
- The MS-PW signalling protocol must support the option to carry traffic parameters that allow per MS-PS policers and queues to be dynamically configured during MS-PW setup at U-PEs/S-PEs.
- The MS-PW signalling protocol must carry enough information for a S-PEs to be able to select appropriate tunnel LSPs, e.g. EXP field corresponding to required traffic class.
- The MS-PW signalling protocol must carry traffic parameters that will support inter-provider signalling, e.g. to support future PCE solutions.
 
Regards,
Richard

	-----Original Message----- 
	From: David McDysan [mailto:[email-masked]] 
	Sent: Fri 25/03/2005 09:53 
	To: Spencer,R,Richard,XDE73 R 
	Cc: [email-masked] 
	Subject: Proposed MS-PW "QoS" Requirements Clarifications

	Richard,
	
	I agree with the sentiment of your comment. Here are a few specific
	proposals on changing section 6.3
	draft-martini-pwe3-mh-pw-requirements-01.txt with the intent of clarifying
	the requirements:
	
	I made a comment similar to the following on 1/19/05 and that has not been
	addressed in the -01 requirements draft:
	
	The current requirement on traffic parameters is much too general. There
	needs to be standard on how to signal the requested Quantity of Service
	(QoS) (i.e.,  traffic parameters (e.g., the average rate, burst duration and
	peak rate from RFC 2215, the FR style parameters from
	draft-shah-pwe3-pw-qos-signaling-02.txt, or the SRTCM or DRTCM from RFCs
	2697 and 2698, respectively).  A number of these traffic parameter specs do
	have an equivalence for cerating
	
	The requirements also need to precisely specify how the Quality of Service
	(QoS) characteristics are signaled. The current requirement is too general.
	There must also be some reference for the defintion of "QoS Class." Possible
	references are a minimal set of Diffserv PHBs and the associated semantics
	from Baker/Babriaz being discussed in tsvwg or the effort in the ITU-T
	updating Y.1540 and Y.1541. 
	
	Gerry Ash pointed out NSIS-based QoS-NSLP signaling for Y.1541 QoS classes
	that could also be relevant, see
	http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt.
	
	I pointed this out again on 2/9/05 and also made the following comment based
	upon reading the above draft.
	
	Signaling the accumulated QoS parameter (latency, latency variation, loss,
	etc.) is more general, yet more complex. The use of certain class or service
	(CoS) (e.g., Y.1541) implicitly assumes a reference configuration, which may
	or may not be appropriate. If this CoS method is used, the protocol SHOULD
	track the domains traversed so that it could be mapped against the reference
	model.
	
	Suggest that both methods: accumulate QoS parms and use CoS be mentioned in
	the next version.
	
	Also, I recommend that specifics on Quality of Service metrics and
	measurement methods be added. The ietf ippm working group has produced a
	number of documents in this area that should be referenced.
	
	Does anyone object to adding the above more specific requirements and cited
	references to the pwe3 wg document that will be based upon
	draft-martini-pwe3-mh-pw-requirements-01.txt?
	
	Thanks,
	
	Dave
	
	> -----Original Message-----
	> From: [email-masked] [mailto:[email-masked]] On
	> Behalf Of [email-masked]
	> Sent: Friday, March 25, 2005 3:48 AM
	> To: [email-masked]; [email-masked]
	> Cc: [email-masked]; [email-masked]
	> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	>
	> I really can't understand why there is speculation over the
	> agreement of requirements in the requirements draft (which
	> has been accepted as a WG document). The MS-PW requirements
	> draft is a joint effort between a number of tier 1 service
	> providers. Every requirement has been submitted by one of the
	> contributing providers, and I would assume that each of the
	> requirements is based on current/planned network deployments
	> and associated network design goals - I do not think the
	> contributing authors would waste their time submitting
	> requirements otherwise.
	> 
	> There may be requirements that are still missing,
	> particulalry from providers that have not yet contributed to
	> the draft. Some of the requirements included in the draft may
	> need further explanation, and the draft itself may need
	> further work to tidy it up (i.e. remove duplication, improve
	> readability). Also, over time some of the requirements may
	> change as new solutions/services become available and
	> networks evolve. However, the current draft describes the
	> MS-PW requirements as perceived by the contributing tier 1
	> service providers today, and these requirements will not
	> change significantly in the short term.
	> 
	> Therefore, for the purposes of MS-PW discussions, these
	> requirements should be accepted as the definitive MS-PW
	> requirements regardless of what stage in the IETF
	> standardisation process the requirements draft is at.
	> 
	> Regards,
	> Richard
	>
	>       -----Original Message-----
	>       From: [email-masked] on behalf of Gray, Eric
	>       Sent: Thu 24/03/2005 16:14
	>       To: Bruce Davie
	>       Cc: 'Kireeti Kompella'; [email-masked]
	>       Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	>      
	>      
	>
	>       Bruce,
	>      
	>               You left out the obvious point at which we might
	>       "have [requirements]" - when there are customers who
	>       say they would like to have it...  :-)
	>      
	>       --
	>       Eric
	>      
	>       -----Original Message-----
	>       From: [email-masked]
	> [mailto:[email-masked]]On Behalf Of
	>       Kireeti Kompella
	>       Sent: Thursday, March 24, 2005 3:45 PM
	>       To: Bruce Davie
	>       Cc: [email-masked]
	>       Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	>      
	>      
	>       On Wed, 23 Mar 2005, Bruce Davie wrote:
	>      
	>       > --On Wednesday, March 23, 2005 11:48 AM -0800 Kireeti Kompella
	>       > <[email-masked]> wrote:
	>       >
	>       > > On Wed, 23 Mar 2005, Bruce Davie wrote:
	>       ...
	>       > I haven't passed judgment on RSVP. It certainly seems
	> premature to start
	>       > increasing the number of protocols for PWs before we
	> agree on the
	>       > requirements.
	>      
	>       Good to hear that.
	>      
	>       However (believe it or not), the authors didn't propose
	> the above
	>       document solely for the purpose of increasing the number of PW
	>       protocols.  Thay have what they believe are sound technical and
	>       pragmatic reasons.
	>      
	>       > > For that matter, it's not like we have a single PW
	> protocol.  The
	>       > > "unhelpful" event already occurred, for better or
	> worse.  Now we
	>       > > should focus on what's the most suitable protocol
	> for the reqts.
	>       >
	>       > Once we have the reqts, I agree.
	>      
	>       When do we "have the reqts"?  When:
	>       a) it's a WG doc?
	>       b) it's in WG Last Call?
	>       c) it's in IETF Last Call?
	>       d) it's an RFC?
	>      
	>       > I chose my words carefully. By saying "at this time"
	> I do indeed
	>       > mean that, when we have a better sense of the
	> requirements, it would
	>       > be a good time to decide which protocol(s) the
	> working group will
	>       > adopt to meet them.
	>      
	>       Same question as above: when can we say that we have a
	> better sense of
	>       the requirements?
	>      
	>       Kireeti.
	>       -------
	>      
	>       _______________________________________________
	>       pwe3 mailing list
	>       [email-masked]
	>       https://www1.ietf.org/mailman/listinfo/pwe3
	>      
	>       _______________________________________________
	>       pwe3 mailing list
	>       [email-masked]
	>       https://www1.ietf.org/mailman/listinfo/pwe3
	>      
	>
	>

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