Re: Bandwidth modification in GMPLS

["manoj juneja" <[e-mail]>]

Hi Dimitri/Marteen,

              I got the idea that the bandwidth modification for
SDH/SONET LSPs has to be supported by using the LBM draft. What about
the bandwidth modification for LSC LSPs ? How these are supported ? Are
the bandwidth modification for LSC LSPs need to be supported using the
RSVP-TE procedures ? I hope that the bandwidth modification for FSC
LSPs is not allowed ?

What about the SE style of reservation ? Is it supported in GMPLS ?

Is it that bandwidth modification for LSC/FSC LSPs are allowed by first
establsihing the new LSP and then tearing down the old (with/without
double booking of resources) ?

Please correct me I am wrong.

Regards,
manoj.


>From: Dimitri Papadimitriou <[e-mail]>
>To: Maarten Vissers <[e-mail]>
>CC: manoj juneja <[e-mail]>, [e-mail],   
>[e-mail], [e-mail],   "Helvoort, Huub van" 
><[e-mail]>
>Subject: Re: Bandwidth modification in GMPLS
>Date: Mon, 03 Dec 2001 22:02:54 +0100
>
>Maarten,
>
>First for people reading these e-mails the discussion here
>is not focused on a comparison between LCAS versus something
>else but only on control plane issues (more precisely which
>are the GMPLS mechanisms to be provided in order to enable
>bandwidth modification on different scenarios)
>
>Now, to continue the discussion we have defined in the GMPLS
>LBM I-D the Circuit ID and the LSP Sequence Number for that
>purpose (see Section 5.2). Together with the following rule:
>
>"All LSPs belonging to the same circuit MUST have the same
>Circuit ID. All LSPs MUST have a unique LSP sequence number
>in that Circuit ID, the LSP sequence number MUST be the
>sequence number of the first SPE/VC of the overall virtually
>concatenated circuit."
>
>Therefore, the scenarios you have defined are a combination
>of the methods described in Section 5.1 and 5.2.
>
>To illustrate this, let's take your example back:
>
> > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 
>to
> > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not 
>connected
> > VC-4 SNPs.
> >
> >         VC-4 with G1    via route A
> >         VC-4 with G2    via route A
> >         VC-4 with G3    via route B
> >         VC-4 with G4    via route B
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> Circuit ID #1 (for instance) will include LSP SEQ ID#0
>    and LSP SEQ ID#1 (here we assume that Route A is link
>    diverse from Route B to preserve generality of the
>    proposed method)
>
> > Assume that the VC-4 trail via G2 is the first one which clears its 
>Signal Fail
> > (SF) condition, then this trail will pass through the signal with SEQ 
>ID=0. If
> > the second one is via G4, then this one passes through the signal with 
>SEQ ID=1.
> > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ 
>ID=3.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP
>    SEQ ID#1 to the SEQ ID=0
>
> > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry 
>SEQ ID #4.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    via route A             SEQ ID=4
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> To update the LSP SEQ#0 you follow the rules defined in
>    the Section 5.1
>
> > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be 
>no change
> > of SEQ ID, only there will be an indication not to transmit over those 
>VC-4
> > trails. If later on it is decided to continue over route A only, the SEQ 
>IDs
> > are adapted as follows:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    not connected
> >         VC-4 with G4    not connected
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
>
>=> you delete the VC-4 components with the re-sequencing as described
>    at the end of the Section 5.1 with the restriction that "SPEs/VCs
>    can be removed from an LSP but only at the end of that LSP (i.e.
>    starting at SPE/VC sequence number X)"
>
> > If the demand for bandwidth doubles again, it is possible to add say 
>three more
> > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the 
>order
> > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=4
> >         VC-4 with G4    via route C             SEQ ID=5
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    via route C             SEQ ID=3
> >         VC-4 with G7    not connected
>
>=> once again you follow the rule described in Section 5.1
>
>There is no need to use the multiplier for this purpose (this
>field is used for instance to operate a change on multiple LSP
>using the same message - it has been provided to avoid lengthy
>repetitions of the same operation)
>
>Once again (i think that Eric has already provided this comment)
>the scope of the LSP SEQ ID is not to reproduce the LCAS defined
>structures within the control plan but to provide a consistent
>control plane definition (allowing a level of consistency checking
>between the control plane and the transport plane.)
>
>Are we in agreement, or do you want further comparison of both
>methods ?
>
>Regards,
>- dimitri.
>
>Maarten Vissers wrote:
> >
> > Dimitri,
> >
> > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal 
>has a
> > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not 
>fixed...
> > this is under control of LCAS and may change with time...
> >
> > When you set up the connection to transport the VC-4-4v signal via two 
>routes
> > (A, B), two VC-4 termination points will be connected to the A route, 
>two other
> > to the B route.
> > There are typically 7 VC-4 termination points per GbE port... let's 
>refer to
> > those 7 VC-4 termination points by means of SubNetwork Point (SNP) 
>addresses G1
> > .. G7.
> >
> > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 
>to
> > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not 
>connected
> > VC-4 SNPs.
> >
> >         VC-4 with G1    via route A
> >         VC-4 with G2    via route A
> >         VC-4 with G3    via route B
> >         VC-4 with G4    via route B
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > Assume that the VC-4 trail via G2 is the first one which clears its 
>Signal Fail
> > (SF) condition, then this trail will pass through the signal with SEQ 
>ID=0. If
> > the second one is via G4, then this one passes through the signal with 
>SEQ ID=1.
> > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ 
>ID=3.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    not connected
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry 
>SEQ ID #4.
> >
> >         VC-4 with G1    via route A             SEQ ID=3
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route B             SEQ ID=2
> >         VC-4 with G4    via route B             SEQ ID=1
> >         VC-4 with G5    via route A             SEQ ID=4
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be 
>no change
> > of SEQ ID, only there will be an indication not to transmit over those 
>VC-4
> > trails. If later on it is decided to continue over route A only, the SEQ 
>IDs
> > are adapted as follows:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    not connected
> >         VC-4 with G4    not connected
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    not connected
> >         VC-4 with G7    not connected
> >
> > If the demand for bandwidth doubles again, it is possible to add say 
>three more
> > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the 
>order
> > those trails become available is G6, G3, G4 then the SEQ IDs will be:
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=4
> >         VC-4 with G4    via route C             SEQ ID=5
> >         VC-4 with G5    via route A             SEQ ID=2
> >         VC-4 with G6    via route C             SEQ ID=3
> >         VC-4 with G7    not connected
> >
> > Looking at the connection setup details, I do not setup a VC-4-2v via A 
>and
> > another VC-4-2v via B initially... I do setup two groups of two VC-4
> > connections, which together support the  VC-4-4v trail; a VC-4-4v is not 
>the
> > same as two times a VC-4-2v. The use of NVC parameter here seems as such 
>not
> > appropriate. The only alternative present is the MT field.
> >
> > Alternative is to redefine NVC as "This field indicates the number of 
>identical
> > co-routed connections that are requested for this LSP. These connections 
>are all
> > of the same type."
> >
> >         But if I assume for a moment an alternative example in which the
> >         virtual concatenated endpoints are outside of the network of
> >         interest, then a UNI/E-NNI request using MT will result in the
> >         same connections being setup compared to such request using the
> >         modified NVC definition. What am I missing here?
> >
> > The traffic parameters for these two group-connections supporting the 
>VC-4-Xv
> > trail are thus:
> >
> > initially:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >
> > after 5th VC-4 trail addition:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >         route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >
> > after route B connections being released:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> > after 4th, 5th, 6th connection being added via route C:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> > To add the 3rd VC-4 connection to the VC-4 group-connection over route 
>A, a
> > MODIFY message is required. In your LBM document you propose to signal 
>the diff
> > value only, and consequently let the switch nodes compute the new total 
>(i.e.
> > new = original + diff). It will work as well to signal the new value and 
>let the
> > switch nodes compute the difference (i.e. diff = new - original). We 
>need to
> > evaluate the pros/cons of both approaches before selecting one.
> >
> > When the group-connection via route B is removed, this group-connection 
>has to
> > be released.
> >
> > When the group-connection via route C is to be added, this 
>group-connection has
> > to be setup.
> >
> > In addition to these cases, the MODIFY message has to support also the 
>decrease
> > case. E.g. assume that route A is more expensive than route C, then one 
>would
> > obviously prefer to release a VC-4 connection via route A when the total
> > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s.
> >
> > after 3rd connection via route A is removed:
> >         route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1]
> >         route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1]
> >
> >         VC-4 with G1    via route A             SEQ ID=1
> >         VC-4 with G2    via route A             SEQ ID=0
> >         VC-4 with G3    via route C             SEQ ID=3
> >         VC-4 with G4    via route C             SEQ ID=4
> >         VC-4 with G5    not connected
> >         VC-4 with G6    via route C             SEQ ID=2
> >         VC-4 with G7    not connected
> >
> > When using a MODIFY message which includes the new traffic parameters 
>(and not
> > the diff ones), the same MODIFY message can be used for addition and 
>removal of
> > connections to/from the group. This looks like a pro for a MODIFY 
>message
> > definition including the new traffic parameters.
> >
> > One note to the above scenarios... the set of 7 VC-4 SNPs can be 
>operated as a
> > single SNP Pool (SNPP). Instead of requesting the setup of a 
>group-connection to
> > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could 
>choose to
> > request the setup of two 2-group-connections to SNPP "G1-G7" and let the 
>local
> > switch node decide which specific SNPs will be allocated.
> > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 
>connection,
> > and to add the 4/5/6th VC-4 connections via route C later on.
> >
> > I hope this clarifies some of the capabilities of the control plane 
>needs to
> > support when a group-connection is to be modified, and the operation of 
>the SEQ
> > ID within virtual concatenation with LCAS.
> >
> > Regards,
> >
> > Maarten
> >
> > Dimitri Papadimitriou wrote:
> > >
> > > Maarten,
> > >
> > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used
> > > for bandwidth increase purpose since it is used for a different
> > > semantic.
> > >
> > > SPEs/VCs can only be added at the end of an LSP. For instance,
> > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is
> > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the
> > > sequence numbered from 0 to X+Y-1.
> > >
> > > The number Y of SPEs/VCs to add is given by the following
> > > equation: new NVC - old NVC. The first new SPE/VC will have a
> > > sequence number equals to the sequence number of the previously
> > > last VC + 1 (i.e. X).
> > >
> > > In such a case (in your below example)
> > >
> > >  - Connection X - A - Y traffic parameters
> > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0
> > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0
> > >
> > >    remember that MT = 0 is an invalid value (as per draft-ietf-ccamp
> > >    -gmpls-sonet-sdh-02.txt)
> > >
> > > The MT field in this picture is used in the following way (the
> > > number Y of SPEs/VCs to add is given by the following equation:
> > > (new NVC * new MT) - (old NVC * old MT) just notice that in most
> > > cases new MT will be equal to old MT):
> > >
> > >  - 2 Connections X - A - Y traffic paramters
> > >    * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0
> > >    * Increase to     VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0
> > >
> > > Your second example is depicted in the section 5.2 of the
> > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use
> > > of the multiplier (MT) in that context is not recommended.
> > >
> > > Regards,
> > > - dimitri.
> > >
> > > Maarten Vissers wrote:
> > > >
> > > > Manoj,
> > > >
> > > > There is a difference between
> > > > 1) modifying the bandwidth of a connection and
> > > > 2) replacing the connection by a different connection.
> > > >
> > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, 
>whereas a VC-4
> > > > connection is a connection in a VC-4 network layer. These network 
>layers are
> > > > independent, and as such you can only replace a VC-3 connection by a 
>VC-4
> > > > connection by releasing the VC-3 connection and requesting to set up 
>a VC-4
> > > > connection.
> > > >
> > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. 
>NVC(*) or MT
> > > > >= 1), by adding/removing connection members. If this 
>group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) 
>then the supported client link's bandwidth is modified as a result.
> > > >
> > > >         Example: Consider VC-4-Xv trail between nodes X and Y which
> > > >         supports an Ethernet link between these two nodes. When X is
> > > >         increased from 4 to 5, the Ethernet link bandwdith is 
>increased
> > > >         from 600 Mb/s to 750 Mbit/s.
> > > >
> > > >         Assume that the VC-4-Xv trail is supported via two diverse
> > > >         routes (X - A - Y and X - B - Y), each providing two VC-4
> > > >         connections. Then the bandwidth modification will increase
> > > >         the number of connections on one of the two routes; e.g. the
> > > >         route via A. The associated traffic parameters will be:
> > > >
> > > >         - Connection X - A - Y traffic parameters
> > > >                 * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, 
>T=0
> > > >                 * After increase:  ST=6, RCC=0, NCC=0, NVC=0, MT=3, 
>T=0
> > > >         - Connection X - B - Y traffic parameters (unchanged)
> > > >                 * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0
> > > >
> > > > What is needed is a MODIFY request which allows for an identified 
>connection to
> > > > modify the MT value.
> > > >
> > > > (*) Note that the parameter NVC is interpreted as to represent the 
>number of
> > > > components in a virtual concatenated signal connection... in this 
>example NVC=4
> > > > and grows to NVC=5. As the virtual concatenated signal is 
>transported via two
> > > > routes, each having half of the member connections, I have the 
>impression that
> > > > MT is the parameter to use.
> > > >
> > > > Or to turn this around and look at the source for the bandwidth 
>modification
> > > > first, we may assume that over the e.g. Ethernet UNI the call 
>controller
> > > > (G.8080) at the network side receives a request to increase the 
>enthernet link
> > > > from 600 to 750 Mbit/s. The call controller then decides to support 
>this
> > > > ehternet bandwidth modification request by means of a modification 
>of the
> > > > group-connection via route A... it then issues a connection 
>modification request
> > > > for this group-connection... etc.
> > > >
> > > > Add 1) True bandwidth modification of an individual connection is 
>possible for
> > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM 
>VC or MPLS
> > > > links (G.805) over which the connection is transported have spare 
>capacity, the
> > > > bandwidth of an individual VP, VC or LSP can be increased.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > manoj juneja wrote:
> > > > >
> > > > > Hi All,
> > > > >          If the bandwidth modification is not supported by GMPLS 
>then
> > > > > it should be clearly mentioned in the drafts (at least the 
>architecture
> > > > > draft). Please see the attached mail for reference.
> > > > >
> > > > > I am still not clear whether GMPLS supports SE-style of 
>reservation.
> > > > > My original question related to SE-style of reservation was and I 
>didn't
> > > > > get any reply on the mailing list :
> > > > >
> > > > >       "  I have a doubt related to SE style of reservation in 
>GMPLS. As
> > > > > in RSVP-TE, multiple senders can share the reservation but they 
>can be
> > > > > assigned different labels to distinguish different senders from 
>one
> > > > > other.
> > > > > In GMPLS, as the label itself is a resource on the link, it means 
>that
> > > > > if there are multiple senders in the same session sharing 
>reservation,
> > > > > they should be assigned the same label. They can't be assigned
> > > > > different labels or is it that GMPLS does not support SE style of
> > > > > reservation ?"
> > > > >
> > > > > Please correct me if I am missing something.
> > > > >
> > > > > Regards,
> > > > > manoj.
> > > > >
> > > > > >From: Maarten Vissers <[e-mail]>
> > > > > >To: manoj juneja <[e-mail]>
> > > > > >CC: [e-mail]
> > > > > >Subject: Re: Bandwidth modification in GMPLS
> > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100
> > > > > >
> > > > > >Manoj,
> > > > > >
> > > > > >manoj juneja wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > >         Is it possible to modify/increase the bandwidth of an 
>existing
> > > > > >GMPLS
> > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it 
>be
> > > > > >possible to
> > > > > > > increase the bandwidth to say VC-4 ?
> > > > > >
> > > > > >No, this is not possible.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >Maarten
> > > > > >
> > > > > > >
> > > > > > > Should the new request be considered independent of previous 
>one ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > manoj.
> > > > > > >
> > > > > > > 
>_________________________________________________________________
> > > > > > > Get your FREE download of MSN Explorer at
> > > > > >http://explorer.msn.com/intl.asp
> > > > > ><< mvissers.vcf >>
> > > > >
> > > > > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
><< dimitri.papadimitriou.vcf >>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp