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.