FW: Relationship between "Shared Mesh Restoration" and DSTE Bandwidth Constraints Models

"Francois Le Faucheur (flefauch)" <[email protected]> Wed, 27 Aug 2003 09:17:39 +0100
Newsgroups gmane.ietf.tewg
Message-ID <[email protected]>
Just a resend (seems like it didn't go through the first time).
Francois

	-----Original Message-----
	From: Francois Le Faucheur (flefauch) 
	Sent: 26 August 2003 15:19
	To: [email protected]
	Subject: Relationship between "Shared Mesh Restoration" and DSTE
Bandwidth Constraints Models
	
	
	Hello,
	 
	We agreed in Vienna that the relationship between the Shared
Mesh Restoration mechanisms being developed in CCAMP and the DS-TE
Bandwidth Constraints Models needed to be investigated so we can decide
"if there is or is not an issue and if it needs to be addressed or not".
	 
	In a nutshell (see [A] below for more details), our conclusions
are that:
	    - Shared Mesh Restoration can work simultaneously with
DS-TE. 
	    - Shared Mesh Restoration should operate independently
within each DS-TE Class-Type (and not across Class-Types).
	    - Shared Mesh Restoration can work with RDM, MAM and MAR
	 
	Thus, our proposal for moving ahead on this is:
	    - make a wording change to the definition of "Reserved
(CTc)" which is used in the formulas for defining RDM, MAM and MAR so
that the formulas are compatible with how Shared-Mesh Restoration
performs bandwidth reservation/CAC (see [B] below for exact word change)
	    - add a note in RDM, MAM and MAR specs that these BC Model
definitions are compatible with Shared Mesh Restoration with the
assumption that Shared Mesh Restoration operates independently within
each Class-Type.
	 
	I would like to thank Yakov, Anna and JP for working with me on
this topic.
	 
	Please let us know promptly if you have comments/issues with
this.
	 
	Thanks
	 
	Francois
	 
	 
	[A]
	===
	Shared Mesh Restoration is defined in
draft-ietf-ccamp-gmpls-recovery-functional-00.txt (see section 3.3).
	 
	One key concept is that backup LSPs can share bandwidth as long
as they protect from failure of different resources (since signaling is
used at failure time to activate a particular pre-established backup
LSP). Because they can share bandwidth, it is clear that the total
amount of bandwidth actually *reserved* by the backup LSPs can be
smaller than the sum of the bandwidth *signaled* by each individual
backup LSP.
	 
	Another concept discussed in the context of Shared Mesh
Restoration is "Excess Traffic LSP" (altough I think this is not yet
documented in the current draft but will be added in upcoming one).
Excess Traffic LSPs may be established (at a lower preemption priority)
and use the resources allocated (but not currently used) by backup LSPs
(at higher preemption priority). The idea being that these Excess
Traffic LSPs will get preempted as soon as resources are actually needed
by some backup LSPs. Since Excess Traffic LSPs "borrow" bandwidth from
backup LSPs when those don't need it, it is clear that the bandwidth
actually "reserved* collectively by backup LSPs and Excess Traffic LSPs
is smaller than the sum of the bandwidth *signaled* separately by backup
LSPs and by Excess Traffic LSPs.
	 
	So a first conclusion is that the definition of "Reserved (CTc)"
needs to be ajusted to take into account the fact that the amount of
bandwidth actually reserved collectively by LSPs is not just a sum of
bandwidth reserved individually by all LSPs but rather that multiple
LSPs may share bandwidth resources and that what matters is the amount
of bandwidth *actually reserved" across the set of LSPs.
	 
	 
	So now, how can Shared Mesh Restoration operate in conjunction
with DS-TE?
	 
	We recommend that Shared Mesh Restoration operates only within
each Class-Type. This means that bandwidth sharing across Primary
LSPs/Backup LSPs and Excess Traffic LSPs only occurs within each given
CT. In other words, back up LSPs protecting Primary LSP of CTx are
expected to also belong to CTx. Similarly Excess Traffic LSPs sharing
bandwidth with Backup LSPs of CTx are expected to also belong to CTx.
	 
	In this model, we can see that :
	    - Shared Mesh Restoration model will define how much
bandwidth is actually collectively reserved by Primary LSPs + Backup
LSPs + Excess Traffic LSPs within a given Class-Type.
	    - DS-TE Bandwidth Constraints Model defines the set of
bandwidth constraints applicable to the bandwidth collectively reserved
by a given CT.
	    - the two models (ie Shared Mesh Restoration and BC Models)
are effectively orthogonal; ie the definitions of the Shared Mesh
Restoration concepts affect how one computes the amount of bandwidth
actually reserved by a given CT, but this does not affect/modify
which/how the bandwidth constraints apply to each CT. Thus, Shared Mesh
Restoration can operate simultaneously with DS-TE with RDM, MAM or MAR
BC models and these BC Models can be defined independently of eth
detailed concepts/rules of Shared Mesh Restoration.
	 
	Note that, instead, one could conceive an extremely generic
model for how Shared Mesh Restoration operates with DS-TE whereby Shared
Mesh Restoration spans arbitrarily across Class-Types, for example where
Primary LSPs (or Excess Traffic LSPs) of one CT could share bandwidth
with backup LSPs of another CT. However, this does not seem to offer
significant real practical benefits while it introduces a significant
level of complexity. For a start, in such a model Sahred Mesh
Restoration and BC Models are no longer orthogonal and the definitions
of Shared Mesh Restoration concepts may affect how the bandwidth
constraints affect each CT. We concluded that the complexities of such a
generic model were not justified and not worth pursuing at this stage.
	 
	 
	[B]
	==
	
	Current definition is:
	"Reserved (CTc)" is defined as the sum of the bandwidth
reserved by all established LSPs which belong to CTc. 
	New Definition will be:
	"Reserved (CTc)" is defined as the total amount of the bandwidth
reserved by all established LSPs which belong to CTc.