Re: Bandwidth modification in GMPLS

[Dimitri Papadimitriou <[e-mail]>]

Maarten,

See in-line...

Maarten Vissers wrote:
> 
> 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.

This is what i was trying to demonstrate (see previous email).
 
> 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.

This is a first proposal be sure the next version will be improved.
 
> 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.

Agreed. But one should be in agreement in what we consider by "not too
large"
 
Regards,
- dimitri.

> 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