Subject: The need for MS-PW TE and CAC

From: [email-masked]
Date: Fri, 25 Mar 2005 09:03:31 -0000

Hi Peter,
 
(I've renamed the thread to reflect the topics under discussion).
 
Each node will know how much bandwidth is available in each tunnel LSP that it is the headend for. Therefore at each hop, a node will be able to make a MS-PW CAC decision based on the bandwidth request received via the signalling protocol and the amount of (unreserved) bandwidth in the tunnel(s) that provide reachability to the destination U-PE.
 
As you point out, an ingress node won't know how much bandwidth is available beyond the tunnels it knows about, and therefore in some cases crankback will be required. However, in other cases, the network topology may be constructed in such a way that there is only one possible route to a destination U-PE (and one backup route). In this case, careful network planning must be used to ensure that there is always enough resource available in the network to setup the number of new MS-PWs that it is estimated will be required. This shouldn't be an issue in the core because core networks are over-provisioned for a number of reasons anyway. Also, even in the access/backhaul where bandwidth for individual traffic classes is typically over-subscribed, there should still always be enough capacity to set up new MS-PWs in line with new service uptake projections, otherwise the network planners aren't doing there job properly. Saying that, in order to support network planning, information about how much bandwidth has been reserved for MS-PWs for each tunnel LSP must be managed using offline tools in order to determine when tunnel LSP bandwidth reservation thresholds are being reached.
 
Protocols such as RSVP-TE and CR-LDP (in conjunction with OSPF/IS-IS TE) support network planning by keeping track of reserved/available bandwidth, and also support TE, but do not provide a complete TE solution. These protocols know how much bandwidth has been reserved, but do not know how much bandwidth is actually being used. Therefore, one could implement RSVP-TE/CR-LDP making use of CSPF but efficient network utilisation will not be achieved if network utilisation levels are not in line with bandwidth reservations. Regardless of whether or not TE protocols are used, operators must still use offline network monitoring and planning tools to ensure that bandwidth is reserved in line with current/projected traffic requirements.
 
I would also argue that the key benefit of using RSVP-TE is not that it supports TE. If a provider wants to use RSVP-TE purely to support TE then there are other means of ensuring traffic is distributed efficiently and to ensure traffic does not simply follow the shortest path, e.g. ECMP, IGP metric tuning, policy based routing, etc. Depending on individual service provider requirements and network topology, RSVP-TE may or may not be the most appropriate tool to support TE. I would say that the key benefits of RSVP-TE are that it can be used to create a mesh of P2P CO tunnel LSPs to which CAC can be applied in order to support capacity planning, and that by using DS-TE, bandwidth for high priority traffic can be protected in failure scenarios when there is not enough bandwidth available to route all traffic (these benefits are as a result of using a CO-PS network mode rather than a CL-PS network mode).
 
I think another important point is that there are likely to be other services in a converged MPLS network that share the same tunnels as MS-PWs. One such service is Layer 3 VPNs based on RFC2547. For L3 VPNs you can apply CAC on a per VPN, per class of service basis at the edge, but due to the connectionless any-to-any bursty nature of the traffic, it is not possible to accurately reserve bandwidth and perform CAC on a per VPN, per tunnel LSP basis. This is because the traffic matrix is dependant on customer routing and it is not known at VPN setup how much traffic will be sent to each customer route (which may change significantly over time). Nonetheless, per tunnel LSP CAC must be performed for L3 VPN traffic in order to ensure that L3VPN traffic does not consume resources reserved for MS-PWs. This is a difficult problem to solve from a network planning perspective as it requires the use of L3VPN customer routing information and/or traffic resource utilisation information collected using offline tools to establish the traffic matrix. The point I'm making here is that MS-PW CAC is only one part of the big picture and it isn't the most difficult part to solve.
 
Regards,
Richard

	-----Original Message----- 
	From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
	Sent: Thu 24/03/2005 16:48 
	To: 'Thomas D. Nadeau' 
	Cc: [email-masked]; Spencer,R,Richard,XDE73 R; [email-masked]; [email-masked] 
	Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt

	> -----Original Message-----
	> From: Thomas D. Nadeau [mailto:[email-masked]]
	[snipped].
	> >
	> > However, even if you are not interested in finding the
	> *optimal* path,
	> > you still need to find a path with sufficient resources.
	> How would you
	> > do that?
	>
	>       Why are you making the assumption that you need sufficient
	> resources to be signaled?
	>
	>       --Tom
	>
	
	Tom,
	
	I am not sure how to interpret your question. I did not use the word "signaled" and did not assume that signaling would play a role.
	
	This is the issue: Assume that there is an infrastructure with pre-established PSN Tunnels between U-PEs and S-PEs and assume that these PSN Tunnels have certain QoS properties. Based on those QoS properties, a certain number of PWs can be set up through a PSN Tunnel. However, with an increasing number of PWs there may be a point at which the PSN Tunnel is "full" and can not support additional PWs. How do you know? Is there an off-line tool that keeps track? Is there a protocol like OSPF-TE that allows nodes to advertise residual bandwidth on PSN Tunnels? Do the PEs themselves keep track? But if so, how would an ingress PE know which route to take?
	
	There are several solutions (mentioned in Richard's and my emails). Which one is most attractive to BT?
	
	Does this help?
	
	Peter
	
	>
	>
	> >
	> > Peter
	> >
	> >> -----Original Message-----
	> >> From: [email-masked] [mailto:[email-masked]]
	> >> Sent: Thursday, March 24, 2005 11:07 AM
	> >> To: [email-masked]; [email-masked];
	> >> [email-masked]
	> >> Cc: [email-masked]
	> >> Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	> >>
	> >>
	> >> Nurit,
	> >>
	> >> Please can you expand on what you mean by TE MS-PW?
	> >>
	> >> There are a number of definitions of what TE means but I
	> >> would say that the purpose of TE is to increase resource
	> >> utilisation and network performance, and to guarantee
	> >> resources for high priority traffic under failure conditions.
	> >>
	> >> To achieve this I think there are two key functions:
	> >>
	> >> [1] Use of offline network monitoring/modelling techniques or
	> >> CSPF to calculate optimal paths through the network.
	> >>
	> >> [2] Use of mechanisms/techniques (e.g. signalling of LSPs
	> >> with explicit paths) to ensure traffic follows the optimal
	> >> paths determined in [1].
	> >>
	> >> Optimal path calculation for tunnel LSPs is based on the
	> >> physical/logical link topology. To perform optimal path
	> >> calculation for MS-PWs, then the calculations need to be
	> >> based on the tunnel LSP topology, i.e. the bandwidth
	> >> available in each tunnel LSP.
	> >>
	> >> If we want to support end-to-end path computation at the
	> >> source using CSPF for MS-PWs, then I believe we will need to
	> >> advertise tunnel LSPs as FA-LSPs into the TE database. An
	> >> alternative would be to perform the end-to-end MS-PW path
	> >> calculation using offline tools based on per tunnel LSP
	> >> utilisation information. In both cases we need a setup
	> >> mechanism with an ERO capability to ensure traffic follows
	> >> the optimal path.
	> >>
	> >> An alternative method of providing path optimisation would be
	> >> to perform hop-by-hop tunnel selection. Hop-by-hop tunnel
	> >> selection first of all would require reachability
	> >> information, (i.e. knowledge of which tunnels can be used to
	> >> reach the destination). Also, in order to avoid following the
	> >> shortest path, per hop policies would be required in order to
	> >> select the most appropriate tunnel (e.g. always choose the
	> >> tunnel with the most bandwidth available or always choose a
	> >> red tunnel over a blue tunnel). Hop-by-hop CAC would be
	> >> required to check at each hop that bandwidth is available,
	> >> and crankback would be needed for cases where the next hop
	> >> doesn’t have a tunnel available that meets the MS-PW resource
	> >> requirements.
	> >>
	> >> This approach makes the assumption that reachability
	> >> information is available, and this requires route calculation
	> >> based on the tunnel LSP topology. There are a number of ways
	> >> route calculation based on the tunnel LSP topology could be
	> >> performed, but this is a problem that has not yet been
	> >> addressed within PWE3 or L2VPN. An alternative to route
	> >> calculation based on the tunnel LSP topology would be to use
	> >> flooding, which is one of the approaches proposed in
	> >> “draft-shah-bocci-pwe3-ms-pw-signaling-00.txt”.
	> >>
	> >> From my own perspective, based on a BT specific network
	> >> topology, I do not need TE at the MS-PW layer. The core (with
	> >> S-PEs at the edge) will be constructed using TE-LSPs which
	> >> will take care of core network resource utilisation and
	> >> provide protection against core failures. As U-PEs are likely
	> >> to be dual homed to S-PEs I might perform some load
	> >> balancing, but there is no need for TE. Therefore, the MS-PW
	> >> setup mechanism needs to support CAC and backup MS-PWs, but
	> >> does not need to support MS-PW TE.
	> >>
	> >> Regards,
	> >> Richard
	> >>
	> >>
	> >>
	> >>    -----Original Message-----
	> >>    From: [email-masked] on behalf of Nurit Sprecher
	> >>    Sent: Thu 24/03/2005 07:17
	> >>    To: Thomas D. Nadeau; Stewart Bryant
	> >>    Cc: pwe3
	> >>    Subject: RE: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	> >>   
	> >>   
	> >>
	> >>    Hi Tom,
	> >>   
	> >>    We should distinguish between MS PWs and SS PWs.
	> >>    The protocol that we have is appropriate for non-TE MS
	> >> PWs and also for
	> >>    SS PWs (both TE and non-TE). However for TE MS PWs it
	> >> is not appropriate
	> >>    because the requirements of the TE MS PW should be
	> >> signaled such that
	> >>    the S-PEs can use the information to select the
	> >> appropriate Tunnel/link
	> >>    for the PW. For example, to select a Tunnel that its
	> >> egress is hop
	> >>    through which the MS PW should transmit (fro policy
	> >> sake for example), a
	> >>    Tunnel that has enough BW, and support the required
	> >> Diffserv-TE class,
	> >>    that its traffic priority is not smaller than the
	> >> priority of the PW,
	> >>    that the Tunnel is protected with mechanism that
	> >> provides up to 50ms
	> >>    restoration time in case of a failure, etc. I think
	> >> that the (only)
	> >>    example above indicates that there are "significant advantage to
	> >>    signaling PWs using an alternative means". So maybe now
	> >> you should
	> >>    "think otherwise" as you said.
	> >>   
	> >>    The natural protocol that already provides us with this
	> >> capability is
	> >>    the RSVP-TE protocol (which is already used and deployed for TE
	> >>    Tunnels). As I already stated, it should only be
	> >> extended to support the
	> >>    PW identifier (PW ID/Type) and the control word, which
	> >> is a very little
	> >>    extension (especially relatively to the extension that
	> >> LDP protocol
	> >>    should go through to support the signaling of the TE
	> >> information).
	> >>   
	> >>    Nurit.
	> >>   
	> >>   
	> >>    -----Original Message-----
	> >>    From: [email-masked]
	> >> [mailto:[email-masked]] On Behalf Of
	> >>    Thomas D. Nadeau
	> >>    Sent: Wednesday, March 23, 2005 5:41 PM
	> >>    To: Stewart Bryant
	> >>    Cc: pwe3
	> >>    Subject: Re: [PWE3] draft-raggarwa-rsvpte-pw-01.txt
	> >>   
	> >>    -----BEGIN PGP SIGNED MESSAGE-----
	> >>    Hash: SHA1
	> >>   
	> >>   
	> >>            Personally speaking, I don't think that it is useful
	> >>    for the WG to spend time and effort re-inventing
	> >>    the wheel, so to speak, which is what this draft
	> >>    represents. We already have a protocol for
	> >>    signaling PWs that works, and is deployed. If
	> >>    there were some significant advantage to signaling
	> >>    PWs using an alternative means, I would think
	> >>    otherwise, but it seems this is just being proposed
	> >>    as an alternative means for achieving the same
	> >>    end result.
	> >>   
	> >>            --Tom
	> >>   
	> >>   
	> >>   
	> >>    > At IETF62 the authors of
	> >>    >
	> >>    > Setup and Maintenance of Pseudowires using RSVP-TE
	> >>    >
	> >> ftp://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-01.txt
	> >>    >
	> >>    > asked for the draft to become a WG draft.
	> >>    >
	> >>    > What is the view of members of the PWE3 WG?
	> >>    >
	> >>    > Stewart
	> >>    >
	> >>    > _______________________________________________
	> >>    > pwe3 mailing list
	> >>    > [email-masked]
	> >>    > https://www1.ietf.org/mailman/listinfo/pwe3
	> >>    >
	> >>    -----BEGIN PGP SIGNATURE-----
	> >>    Version: GnuPG v1.2.4 (Darwin)
	> >>   
	> >>    iD8DBQFCQY4dHwfkLUURkkwRAgbtAJ9Bpc/zSm0TungLQ/LOQOD8VXDr+ACfXkWS
	> >>    obq/1BEDNhqeTW+u8DzaYGU=
	> >>    =s7XE
	> >>    -----END PGP SIGNATURE-----
	> >>   
	> >>    _______________________________________________
	> >>    pwe3 mailing list
	> >>    [email-masked]
	> >>    https://www1.ietf.org/mailman/listinfo/pwe3
	> >>   
	> >>   
	> >>    _______________________________________________
	> >>    pwe3 mailing list
	> >>    [email-masked]
	> >>    https://www1.ietf.org/mailman/listinfo/pwe3
	> >>   
	> >>
	> >>
	> >
	> -----BEGIN PGP SIGNATURE-----
	> Version: GnuPG v1.2.4 (Darwin)
	>
	> iD8DBQFCQy6MHwfkLUURkkwRAigKAJ9nGKDlhhsAPy3Dnv/vTJfbn/jIjwCfazjr
	> Z9E6fQzZNFpLmrqX1rAndDg=
	> =7Cks
	> -----END PGP SIGNATURE-----
	>

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 25 Mar 2005 09:29:57 -0500

Thanks, Richard,

The new subject title seems like an invitation to continue this thread. However, at this point I have nothing to add. Your last email hit the nail on the head.

Peter

> Sent: Friday, March 25, 2005 4:04 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: The need for MS-PW TE and CAC
> 
> 
> Hi Peter,
>  
> Each node will know how much bandwidth is available in each 
> tunnel LSP that it is the headend for. Therefore at each hop, 
> a node will be able to make a MS-PW CAC decision based on the 
> bandwidth request received via the signalling protocol and 
> the amount of (unreserved) bandwidth in the tunnel(s) that 
> provide reachability to the destination U-PE.
>  
> As you point out, an ingress node won't know how much 
> bandwidth is available beyond the tunnels it knows about, and 
> therefore in some cases crankback will be required. However, 
> in other cases, the network topology may be constructed in 
> such a way that there is only one possible route to a 
> destination U-PE (and one backup route). In this case, 
> careful network planning must be used to ensure that there is 
> always enough resource available in the network to setup the 
> number of new MS-PWs that it is estimated will be required. 
> This shouldn't be an issue in the core because core networks 
> are over-provisioned for a number of reasons anyway. Also, 
> even in the access/backhaul where bandwidth for individual 
> traffic classes is typically over-subscribed, there should 
> still always be enough capacity to set up new MS-PWs in line 
> with new service uptake projections, otherwise the network 
> planners aren't doing there job properly. Saying that, in 
> order to support network planning, information about how much 
> bandwidth has been reserved for MS-PWs for each tunnel LSP 
> must be managed using offline tools in order to determine 
> when tunnel LSP bandwidth reservation thresholds are being reached.
>  
> Protocols such as RSVP-TE and CR-LDP (in conjunction with 
> OSPF/IS-IS TE) support network planning by keeping track of 
> reserved/available bandwidth, and also support TE, but do not 
> provide a complete TE solution. These protocols know how much 
> bandwidth has been reserved, but do not know how much 
> bandwidth is actually being used. Therefore, one could 
> implement RSVP-TE/CR-LDP making use of CSPF but efficient 
> network utilisation will not be achieved if network 
> utilisation levels are not in line with bandwidth 
> reservations. Regardless of whether or not TE protocols are 
> used, operators must still use offline network monitoring and 
> planning tools to ensure that bandwidth is reserved in line 
> with current/projected traffic requirements.
>  
> I would also argue that the key benefit of using RSVP-TE is 
> not that it supports TE. If a provider wants to use RSVP-TE 
> purely to support TE then there are other means of ensuring 
> traffic is distributed efficiently and to ensure traffic does 
> not simply follow the shortest path, e.g. ECMP, IGP metric 
> tuning, policy based routing, etc. Depending on individual 
> service provider requirements and network topology, RSVP-TE 
> may or may not be the most appropriate tool to support TE. I 
> would say that the key benefits of RSVP-TE are that it can be 
> used to create a mesh of P2P CO tunnel LSPs to which CAC can 
> be applied in order to support capacity planning, and that by 
> using DS-TE, bandwidth for high priority traffic can be 
> protected in failure scenarios when there is not enough 
> bandwidth available to route all traffic (these benefits are 
> as a result of using a CO-PS network mode rather than a CL-PS 
> network mode).
>  
> I think another important point is that there are likely to 
> be other services in a converged MPLS network that share the 
> same tunnels as MS-PWs. One such service is Layer 3 VPNs 
> based on RFC2547. For L3 VPNs you can apply CAC on a per VPN, 
> per class of service basis at the edge, but due to the 
> connectionless any-to-any bursty nature of the traffic, it is 
> not possible to accurately reserve bandwidth and perform CAC 
> on a per VPN, per tunnel LSP basis. This is because the 
> traffic matrix is dependant on customer routing and it is not 
> known at VPN setup how much traffic will be sent to each 
> customer route (which may change significantly over time). 
> Nonetheless, per tunnel LSP CAC must be performed for L3 VPN 
> traffic in order to ensure that L3VPN traffic does not 
> consume resources reserved for MS-PWs. This is a difficult 
> problem to solve from a network planning perspective as it 
> requires the use of L3VPN customer routing information and/or 
> traffic resource utilisation information collected using 
> offline tools to establish the traffic matrix. The point I'm 
> making here is that MS-PW CAC is only one part of the big 
> picture and it isn't the most difficult part to solve.
>  
> Regards,
> Richard
> 
> 	Cc: [email-masked]; 
> Spencer,R,Richard,XDE73 R; [email-masked]; [email-masked] 
> 	I am not sure how to interpret your question. I did not 
> use the word "signaled" and did not assume that signaling 
> would play a role.
> 	
> 	This is the issue: Assume that there is an 
> infrastructure with pre-established PSN Tunnels between U-PEs 
> and S-PEs and assume that these PSN Tunnels have certain QoS 
> properties. Based on those QoS properties, a certain number 
> of PWs can be set up through a PSN Tunnel. However, with an 
> increasing number of PWs there may be a point at which the 
> PSN Tunnel is "full" and can not support additional PWs. How 
> do you know? Is there an off-line tool that keeps track? Is 
> there a protocol like OSPF-TE that allows nodes to advertise 
> residual bandwidth on PSN Tunnels? Do the PEs themselves keep 
> track? But if so, how would an ingress PE know which route to take?
> 	
> 	There are several solutions (mentioned in Richard's and 
> my emails). Which one is most attractive to BT?
> 	
> 	Does this help?
> 	
> 	Peter
> 	
> 	>
> 	>
> 	> >
> 	> > Peter
> 	> >

---

From: "Florin Balus" <[email-masked]>
Date: Fri, 25 Mar 2005 10:40:57 -0500

This is a really sound, pragmatic analysis of the problem of TE, CAC for
MS-PW!

Just to add to it: the topologies I saw in all the Service Provider
scenarios I came across show a rather simple spread of S-PEs, with clear
delimitation of PW domains and a relatively small number of hops to be
traversed. 

At each transition between PW Domains, 2 S-PE "gateways" are present in most
of the cases, simplifying a lot the overall problem space and the choices
that MS PW signaling has to make. 

Also I would say on another debated aspect, that even from a (ms) pw
resiliency perspective, end-to-end hot-standby is an overkill for the vast
majority of PWs.  

See also some in-line comments...

Regards,
Florin

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [PWE3] The need for MS-PW TE and CAC
> 
> 
> Hi Peter,
>  
> planners aren't doing there job properly. 

As a result, in a well engineered network, cranckbacks will be rather the
exception than the rule.

> Saying that, in 

I would add that to fully exploit the features of RSVP-TE/CR-LDP for the MH
PW case, there is a need of an equivalent functionality to build a dedicated
view of the MH PW "Topology". In other words only the U-PEs, S-PEs and
related RSVP-TE tunnels between them should be considered when path
computation for a destination U-PE is to be performed. For that to happen
you need to create RSVP-TE Tunnels between all possible S-PEs inside one PW
domain and advertise these tunnels as FA-LSPs into the TE database. 

We need to discuss more about what this means in a MH PW "community" where
S-PEs and U-PEs could be spread across the overall routing topology,
possibly not in the "proper position" (e.g. in the OSPF example, the ABRs
might not be S-PEs). In addition to that path computation needs to take a
minimal approach, at least for the bulk of PWs. That is the path selection
should be done so that I could easily predict, control which PWs will be
handled by which S-Pes so that even under failure scenarios I respect
strictly the principle of one hop, (SS-)PW domain. 

> 	> >> doesn't have a tunnel available that meets the 
> MS-PW resource
> 	> >> requirements.
> 	> >>
> 	> >> "draft-shah-bocci-pwe3-ms-pw-signaling-00.txt".
> 	> >>

---

From: "Amante, Shane" <[email-masked]>
Date: Fri, 25 Mar 2005 09:19:11 -0700

With respect to draft-raggarwa-rsvpte-pw-01.txt, I don't support making
it a WG item, at this time, for the following reasons:

1) One of the use cases in draft-martini-pwe3-mh-pw-requirements-01.txt,
Section 5 (ii & iv), discusses the need for the MS-PW solution to
provide an "interworking" function between two, diverse PWE3 [MS-PW]
signalling protocols.  The problem with this is: a) it adds complexity;
b) I would be obliged to run yet another signalling protocol I do not
use for PWE3's today, (if only on my ASBR's) in order to connect to
other carriers who only run RSVP-TE; and, c) ultimately, all this does
is *add* OpEx to run my network.  I, and I'm sure other carriers, want
to reduce OpEx.

2)  Why are we (re-)inventing the wheel again, and it appears
specifically as it relates only to PWE3?  Can someone explain why the
work in the PCE WG to establish Inter-Area and, more importantly,
Inter-Carrier PSN tunnels is insufficient for PWE3 to use as the
underlying PSN substrate?  I would also note that PCE WG is supposed to
be taking a _comprehensive_ look at signalling Inter-Provider PSN
tunnels, which includes many of the thornier issues relative to security
of the control plane, diversity of paths through domains, crankback,
etc. between two, independently operated domains.  I would rather PWE3
did not (re-)invent the wheel again, poorly/haphazardly and only for
PWE3 tunnels if it can be avoided.
    Perhaps a more constructive approach may be to have the PWE3 (along
with L3VPN) WG feed requirements into the PCE WG (if they haven't
already), in order to have a comprehensive PSN solution that works, and
works well, for both PWE3 and IPVPN?  In the mean time, we can take a
look at developing a "minimalist" solution for MS-PW, that doesn't
include every QoS knob and QoS corner-case one can think of.  This
allows "brave" carriers, who may not actually need all the QoS stuff, to
get out there and start experimenting and/or deploying it sooner rather
than later.

-shane

---

From: Eric Rosen <[email-masked]>
Date: Mon, 28 Mar 2005 10:25:13 -0500

Richard> (I've renamed the thread to reflect the topics under discussion)

Good idea.   Perhaps we can use  this thread to try  to pin down  the way in
which  the  various  requirements   impact  the  protocols,  and  leave  the
cheerleading to the other thread.

Peter>  The ultimate goal  of QoS  is to  provide performance  guarantees to
Peter> end-user applications. In that sense, QoS applies to PWs.  

No argument  there.  The question of  course is whether  the QoS of a  PW is
anything more than the QoS of the tunnels it traverses. 

Peter> S-PEs  manage individual PWs.  They must  be configured  (manually or
Peter> through a signaling protocol) to recognize individual PWs and through
Peter> buffering and  scheduling settings  assure that the  QoS requirements
Peter> for each PW are met.

I think  the buffering and scheduling  algorithms belong to  the lower layer
(i.e., to the  tunnel).  Queuing resources belong to and  are managed by the
consumer of the  queue.  The tunnel has  to be informed of the  needs of its
clients, sure.

I assume you are not envisioning a  situation in which you need to do per-PW
shaping at each switch point?

Dave> I  interpret CAC  in  this context  as  to whether  the particular  PW
Dave> capacity  parameters   (i.e.,  Quantity  of  Service)   fit  within  a
Dave> particular PSN tunnel that meets the Quality of Service parameters for
Dave> the  PW ...  With a  MS-PW, the  information needed  to  perform these
Dave> functions needs to be communicated to the the S-PEs, preferably via a
Dave> control protocol instead of S-PE by S-PE configuration.

Yes, it seems clear that it  is necessary to signal the parameters needed to
select  the tunnels.  Presumably  these parameters  would be  configured (or
otherwise discovered) at the endpoints and then signaled to the intermediate
switching points.   However, the ability  to use those parameters  to select
the appropriate  tunnel is  not a new  feature, it's  a feature that  any PW
implementation has to have, and  the procedures for signaling the parameters
are not complex. 

I do have some questions about this: 

- Will the same set of parameters be relevant at every switching point? 

- Will  there be  local policy  at the  switching points  which  may augment
  and/or override some of the QoS parameters? 

- Are  we making any  assumptions about  the technology  of the  various PSN
  tunnels  (such as  the assumption  that all  the PSN  tunnels  are RSVP-TE
  LSPs), or are the QoS parameters meant to be independent of the PSN tunnel
  technology? 

Richard> In order  to protect  against S-PE failure,  backup MS-PWs  will be
Richard> required for at least a subset of MS-PWs. 

The requirement here  is that if an S-PE, service should  be resumed in less
time than it takes to set up a new segment (to a new S-PE)?

Consider the  environment where the S-PEs are  at administrative boundaries,
and you  don't have  much if  any visibility across  the boundary.   In this
case, I think what one needs is not a backup PW, but a backup segment.  That
is, you  need a backup exit  point from your administrative  domain, but you
don't  really care  what came  before or  what comes  after  (that's someone
else's responsibility). 

In evaluating the impact of the  requirements on the protocols, I'm not sure
that adequate attention  has been paid to the scenario  where the S-PEs mark
administrative  boundaries, and  there  is limited  visibility, and  limited
ability to control, what is beyond the boundary.

Richard> Cranckback will be required in cases where a selected next-hop S-PE
Richard> does not  have a tunnel LSP  with enough bandwidth  available to be
Richard> able to setup the MS-PW.  

Crankback  seems  like a  solution,  not  a  requirement.  The  requirement,
presumably, is to find a feasible  path, given limited visibility of what is
beyond the next S-PE.  

I think one of the problems here is that there is no common understanding of
just when you would use an S-PE and when you wouldn't.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 28 Mar 2005 10:42:29 -0500

Peter> S-PEs  manage individual PWs.  They must  be configured
Peter>(manually or through a signaling protocol) to recognize
Peter> individual PWs and through buffering and  scheduling settings
Peter> assure that the  QoS requirements for each PW are met.

Eric> I think  the buffering and scheduling  algorithms belong
Eric> to  the lower layer (i.e., to the  tunnel).  
Eric> Queuing resources belong to and  are managed by the
Eric> consumer of the  queue.  The tunnel has  to be informed
Eric> of the  needs of its clients, sure. 
Eric> I assume you are not envisioning a  situation
Eric> in which you need to do per-PW shaping at each switch point?

Eric,

My email made the argument: if a) then this, if b) then that. The sentences that you quote refer to "that".

Do I think that "that" is the best solution? In general, no. I agree with arguments made by you and Richard that it is preferable to do traffic engineering on the PSN tunnels and assure in that manner that the PWs will not experience congestion.

That said, in many end-to-end QoS solutions there are points in the network where some form of hierarchical queuing and shaping is required. In your email you mention the special conditions imposed by S-PEs that are on the border of autonomous systems. With regards to QoS, the borders between autonomous systems are actually the points where you may want to do per-PW policing and shaping.

Peter

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Eric Rosen
> Sent: Monday, March 28, 2005 10:25 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] The need for MS-PW TE and CAC 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 28 Mar 2005 10:52:14 -0500

> the borders between  autonomous systems are actually the  points where you
> may want to do per-PW policing and shaping 

I see  the need for  policing at the  borders, in case the  initial provider
hasn't done the  shaping properly.  But what is the need  for shaping at the
borders?

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 28 Mar 2005 11:08:11 -0500

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Monday, March 28, 2005 10:52 AM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]; [email-masked]

It is possible that customer traffic meets the SLA profile at the edge of the first provider's network, but - traveling through that network - incurs delay and jitter so that it does not meet the profile anymore when it reaches the second provider. (E.g. if some packets incur more delay than others, burst sizes may grow beyond the allowed maximum burst size.)
Rather than dropping all packets that exceed the profile, the second provider could shape the traffic so that it conforms again. The second provider could also accept the non-comforming stream without shaping, but theoretically it is possible that that screws up the QoS guarantees given to other PWs.

I realize that this is a theoretical argument that may not be relevant in practical deployments of PWs.

Peter

---

From: David McDysan <[email-masked]>
Date: Tue, 29 Mar 2005 09:21:03 -0500

Responding to some of Eric's points ">" below as indicated by Dave>.

> Peter>  The ultimate goal  of QoS  is to  provide performance  
> Peter> guarantees to end-user applications. In that sense, 
> QoS applies to PWs.
> 
> No argument  there.  The question of  course is whether  the 
> QoS of a  PW is anything more than the QoS of the tunnels it 
> traverses. 

Dave> I believe we need to include a PW with a default, or "best effort"
behavior.

> Peter> (manually or through a signaling protocol) to recognize 
> I think  the buffering and scheduling  algorithms belong to  
> the lower layer (i.e., to the  tunnel).  Queuing resources 
> belong to and  are managed by the consumer of the  queue.  
> The tunnel has  to be informed of the  needs of its clients, sure.
> 

Dave> Yes, but we need to specify how such tunnel behavior is invoked. For
example, are the PW label EXP bits used or the EXP bits from the preceding
tunnel, and what is the semantics of the EXP bits?

> I assume you are not envisioning a  situation in which you 
> need to do per-PW shaping at each switch point?
> 
> Dave> particular PSN tunnel that meets the Quality of Service 
> parameters 
> Dave> for the  PW ...  With a  MS-PW, the  information needed  to  
> Dave> perform these functions needs to be communicated to the 
> the S-PEs, 
> Dave> preferably via a control protocol instead of S-PE by 
> S-PE configuration.
> 
> Yes, it seems clear that it  is necessary to signal the 
> parameters needed to select  the tunnels. 

Dave> Or determine whether any are acceptable.

> Presumably  these 
> parameters  would be  configured (or otherwise discovered) at 
> the endpoints and then signaled to the intermediate
> the appropriate  tunnel is  not a new  feature, it's  a 
> feature that  any PW implementation has to have, 

Dave> SS PW does not detail requirements for traffic parameters or support
for QoS (See section 9 of RFC 3916). I believe that MS-PW should have
stronger requirements.  If this is done well, then I would prefer to use
single segment MS-PW instead of SS-PW.

> and  the 
> procedures for signaling the parameters are not complex. 
> 

Dave> In order to achieve interoperability and assign an end-to-end
significance to QoS, yes, I believe so. In an earlier post I had proposed a
specific set of standardized traffic parameter and QoS syntax and semantics
asking if anyone had any objections. I have read any as of today.

>   and/or override some of the QoS parameters? 

Dave> There was a discussion on this point, in January I believe. The
outcome I recall is that if all S-PEs cannot support the requested traffic
and QoS parameters, then the PW setup should fail. In the event of failure,
the sender can back off and retry. Suggest that this be added to section 6.3
of the MS-PW requirements. Requirement iii does capture the requirement that
a setup attemtp SHOULD fail.

>   LSPs), or are the QoS parameters meant to be independent of 

Dave> I think there is an implicit assumption people are making here, and I
think it would be a good idea to make it an explicit assumption in the
requirements. I'm not aware of another IETF standards track protocol that
would reserve capacity and provide some level of QoS differentiation other
than RSVP-TE.

> 
> Richard> In order  to protect  against S-PE failure,  backup MS-PWs  
> Richard> will be required for at least a subset of MS-PWs.
> 
> The requirement here  is that if an S-PE, service should  be 
> resumed in less time than it takes to set up a new segment 
> (to a new S-PE)?
> 
> case, I think what one needs is not a backup PW, but a backup 
> segment.  That is, you  need a backup exit  point from your 
> administrative  domain, but you don't  really care  what came 
>  before or  what comes  after  (that's someone else's 
> responsibility). 
> 
> In evaluating the impact of the  requirements on the 
> protocols, I'm not sure that adequate attention  has been 
> paid to the scenario  where the S-PEs mark administrative  
> boundaries, and  there  is limited  visibility, and  limited 

Dave> This is a good point. I recommend that this be included in the
requirements. 

> Richard> Cranckback will be required in cases where a 
> selected next-hop 
> Richard> S-PE does not  have a tunnel LSP  with enough bandwidth  
> Richard> available to be able to setup the MS-PW.
> 
> Crankback  seems  like a  solution,  not  a  requirement.  
> The  requirement, presumably, is to find a feasible  path, 
> given limited visibility of what is beyond the next S-PE.  
> 

Dave> I agree.

> I think one of the problems here is that there is no common 
> understanding of just when you would use an S-PE and when you 
> wouldn't. 
> 

Dave> Suggest that the use cases could be extended to at least give examples
to answer this question.

---

From: Shahram Davari <[email-masked]>
Date: Wed, 30 Mar 2005 09:09:30 -0800

Eric,

>  guarantees to
> QoS of a  PW is

I think a more important question is how can one ensure that the MS-PW traverses the appropriate tunnels in each PW segment. The appropriate tunnel
might be based on QoS characteristics, but it may also be based on policy
issues such as pricing, reliability, etc. 

-Shahram