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

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Title: Message

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.