Subject: Reflecting new-MAM/SAM definition in diff-te drafts

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 23 Apr 2003 10:26:26 +0100

Hello,

Assuming there is agreement to add the enhancement to the current MAM
definition, below is a first cut at the main changes that would result
in the diff-te drafts. 
Could you check these out?

Thanks

Francois

MAM/SAM draft - Definition
===========================
The "newMAM/SAM" definition could look like this:

	o Maximum Number of Bandwidth Constraints (MaxBC)= 
		  Maximum Number of Class-Types (MaxCT) + 1 = 9
        (where one of the bandwidth constraints is the "Max reservable
Bandwidth")
	o for each value of b in the range 0 <= b <= 7: 
		Reserved (CTb) <= BCb, 
	o SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 
		for all "c" in the range 0 <= c <= (MaxCT-1)

Illustration diagram would look like: 
   
  I------------------------------------------------------------I
  I--------------II-------------II-------------I               I
  I    CT2       II   CT1       II     CT0     I  CT2+CT1+CT0  I
  I--------------II-------------II-------------I               I
  I------------------------------------------------------------I
   
  <-----BC2------><-----BC1-----><-----BC0-----> 
  <------------------------Max Reservable Bandwidth------------>

MAM/SAM draft - Formulas for computing Unreserved bandwidth
============================================================
 The example formulas for computing Unreeserved Bandwidth would be
changed to:
   
        "Unreserved TE-Class [i]" = 
	 MIN [
	   [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p  ,
	   [Max Reservable Bandwidth - SUM ( Reserved (CTb,q) ) ] for q
<= p and 0 <= b <= 7,
           ]

RDM draft - Definition
===========================
The RDM definition could be slightly updated (to clarify relationship to
Max Res Bw which is differnet to new-MAM/SAM) like this:

	o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 
		Number of Class-Types (MaxCT) = 8 	
	 (where BC0 is the "Max reservable Bandwidth")
	o for each value of b in the range 0 <= b <= (MaxCT - 1): 
		SUM (Reserved (CTc)) <= BCb, 
		for all "c" in the range b <= c <= (MaxCT - 1)

Illustration diagram becomes:
   
  I------------------------------------------------------I 
  I-------------------------------I                      I 
  I--------------I                I                      I 
  I    CT2       I    CT2+CT1     I      CT2+CT1+CT0     I 
  I--------------I                I                      I 
  I-------------------------------I                      I 
  I------------------------------------------------------I 
   
  I-----BC2------> 
  I----------------------BC1------> 
  I-------------------------BC0 = Max Reservable Bw------> 

Protocol draft "4.1.1. Bandwidth Constraints (BCs)"
==============================================

For DS-TE, the existing "Maximum Reservable link bandwidth" parameter 
is retained and its semantic is generalized as the aggregate bandwidth 
constraints across all Class-Types. So that, independently of the
Bandwidth 
Constraint Model in use, :
	SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 
      for all "c" in the range 0 <= c <= (MaxCT-1). 

Additionally, on every link, a DS-TE implementation MUST provide for 
configuration of up to 8 additional link parameters which are the 
eight other potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. 
The LSR MUST interpret these Bandwidth Constraints in accordance with 
the supported Bandwidth Constraint Model (i.e. what bandwidth 
constraint applies to what Class-Type and how). 

Where the Bandwidth Constraint Model imposes some relationship among 
the values to be configured for these Bandwidth Constraints, the LSR 
MUST enforce those at configuration time. For example, when the 
"Russian Doll" Bandwidth Constraints Model is used (See [DSTE-
RUSSIAN]), the LSR must ensure that BCi is configured smaller or 
equal to BCj, where i is greater than j, and that BC0 is equal 
to the Max Reservable Link Bandwidth. 
As another example, when the "Separate and Aggregate constraint Model"
is used 
(See [DSTE-SAM]), the LSR must ensure that all BCi are configured
smaller or 
equal to the Maximum Reservable Bandwidth.

Protocol draft "5.1. Bandwidth Constraints "
============================================
(this should also address some of Dimitry's Last Call comments on -proto
draft).

As detailed above in section 4.1.1, up to 8 Bandwidth Constraints 
( BCb, 0 <= b <= 7) are configurable on any given link. 

With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained 
with a generalized semantic so that it MUST now be interpreted as 
the aggregate bandwidth constraint across all Class-Types, independently

of the Bandwidth Constraints Model.
 
This document also defines the following new optional sub-TLV to 
advertise the eight potential Bandwidth Constraints (BC0 to BC7): 

"Bandwidth Constraints" sub-TLV: 
Bla, bla, bla : unchanged

A DS-TE LSR MAY optionally advertise Bandwidth Constraints. 

A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 
"Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints" 
sub-TLV to do so. For example, 
considering the case where a Service Provider deploys DS-TE with TE-
classes associated with CT0 and CT1 only, and where the Bandwidth 
Constraints model is such that only BC0 and BC1 are relevant to CT0 
and CT1: a DS-TE LSR which does advertise Bandwidth Constraint would 
include the "Max Reservable Bw" sub-TLV and the "Bandwidth Constraints" 
sub-TLV in the IGP advertisement 
and the latter should contain only BC0 and BC1. 

Note that including the existing "Maximum Reservable Bw" sub-TLV when 
advertising Bandwidth Constraints is 
useful in migration situations where some LSRs in the network are not 
DS-TE capable (see Appendix C) and thus do not understand the new 
"Bandwidth Constraints" sub-TLV.  

Rest of section is unchanged.

RDM draft - handling advertisement of both "Max Res bw" and BC0
===============================================================
Some of the text that usd to be in proto needs to be moved (somewhere)
into Russian draft, as it is now specific to RDM. This text relates to
behaviour when receiving in IGP advertisment both a "Max Res Bw" and
BC0. It could read :

[DSTE-PROTO] states that 
"A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 
"Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints" 
sub-TLV to do so. " 
With RDM, BC0 is the Maximum Reservable Bandwidth. A DS-TE LSR receiving
both the 
old "Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints"
sub-TLV for 
a given link where the RDM model is used, MAY ignore the "Maximum
Reservable Bw" sub-TLV.

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Fri, 25 Apr 2003 14:32:23 -0500

Francois,

I have some major concerns about your proposed MAM/SAM direction.  I don't think we want to introduce all this increased complexity in the BC models.  We can resolve the issues raised in recent discussions much more easily:

1. The MAM definition can be clarified in the current MAM specification draft to address the possible ambiguity in the DSTE requirements draft.  The DSTE requirements draft doesn't serve to be the defining I-D for any of the BC models, that's the purpose of the functional specifications of the various BC models.
2. Regarding the allowance of cross-CT preemption in MAM, it should be allowed (as several have assumed/interpreted), and that point should be clarified in the MAM specification draft. 
3. The 'maximum link bandwidth' parameter is a physical constraint and serves to limit the assignable sum of link bandwidth across class types.  In the recent discussion, this constraint has sometimes been referred to as an 'implicit max link BW constraint'.  However there is nothing 'implicit' about this constraint/parameter, it is an existing link parameter and a physical constraint on assignable link bandwidth.
4. Given comment #3, we don't need to use the 'max reservable link bandwidth' parameter instead of the 'maximum link bandwidth' parameter, as you have proposed.

Other related comments:

1. We definitely don't want to further extend ospf/isis to advertise more bandwidth constraints, as you stated in your email on 3/25/03:
"Where MAM currently has a Maximum Number of Bandwidth Constraints of 8 (i.e. one per CT), this model would have a maximum of 9 BCs (i.e. one per CT plus one aggregate). BTW, this in turn, would require change to the ISIS/OSPF extensions which can only advertise 8 Bandwidth Constraints."
Further complexity in ospf/isis lsa advertisements is unacceptable.
2. There is no need to add another BW constraint model (SAM), as you have proposed, to serve as an 'enhanced MAM'.  The point is to clarify MAM as stated above, which in fact has the same functionality you propose for SAM, we only need to make the clarifications in the MAM functional specification I-D.

Once again, we don't want to introduce all this additional complexity.  All we need to do at this point is to make some clarifications in the MAM functional specification I-D.

Thanks,
Jerry

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: Wednesday, April 23, 2003 5:26 AM
To: [email-masked]
Subject: Reflecting new-MAM/SAM definition in diff-te drafts

Hello,

Thanks

Francois

   

   

RDM draft - Definition

   
   
  I-----BC2------> 

 

[DSTE-PROTO] states that

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 25 Apr 2003 16:28:14 -0400

Gerald,

> 3. The 'maximum link bandwidth' parameter is a physical 
> constraint and serves to limit the assignable sum of link 
> bandwidth across class types.  In the recent discussion, this 
> constraint has sometimes been referred to as an 'implicit max 
> link BW constraint'.  However there is nothing 'implicit' 
> about this constraint/parameter, it is an existing link 
> parameter and a physical constraint on assignable link bandwidth.
> 4. Given comment #3, we don't need to use the 'max reservable 
> link bandwidth' parameter instead of the 'maximum link 
> bandwidth' parameter, as you have proposed.

The 'maximum link bandwidth' as defined is the actual link capacity and not
meant to be used as a reservation constraint. The 'max reservable link
bandwidth' was originally defined for this purpose. The amount of confusion
around these definitions puzzles me.

Dimitry

P.S. Excerpts from draft-katz-yeung-ospf-traffic-09.txt:

 2.5.6. Maximum Bandwidth

   The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that
   can be used on this link in this direction (from the system
   originating the LSA to its neighbor), in IEEE floating point format.
   This is the true link capacity.  The units are bytes per second.

   The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in
   length.

 2.5.7. Maximum Reservable Bandwidth

   The Maximum Reservable Bandwidth sub-TLV specifies the maximum
   bandwidth that may be reserved on this link in this direction, in
   IEEE floating point format.  Note that this may be greater than the
   maximum bandwidth (in which case the link may be oversubscribed).
   This SHOULD be user-configurable; the default value should be the
   Maximum Bandwidth.  The units are bytes per second.

   The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four
   octets in length.