Re: Bandwidth modification in GMPLS

[Maarten Vissers <[e-mail]>]

Dimitri,

I am not comparing the two methods. I am describing how LCAS operates the SEQ
IDs and how connection management has to support virtual concatenation with
LCAS. GMPLS is an implementation of distributed connection management, and must
therefore support what I described.

In addition, connection management must support a means to perform the same
capabilities for the case one or both endpoints do not support LCAS, but allow
resizing the pipe. The proposal you made in your LBM document is much more
restrictive than LCAS capable implementations. It is up to the operators to
decide if these restrictions are acceptable. It is most likely a trade of
between less restrictions/more complex protocol and more restrictions/less
complex protocol.

Personally, I would like to compare two proposals: one that supports all LCAS
capabilities (except of course the hitless one), the other that includes
restrictions. If the complexity difference is not too large, go for the full
capabilities support, otherwise select the one with the restrictions.

Regards,

Maarten

Dimitri Papadimitriou wrote:
> 
> 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