Subject: make-before-break in Gmpls

From: Manoj Agiwal <[email-masked]>
Date: Tue, 3 Dec 2002 02:48:25 -0600

Hi ,
         The gmpls architecture documents says 
"GMPLS does not add anything new. Elegant re-routing is possible with the
concept of "make-before-break" whereby an old path is still used while a new
path is set up by avoiding double reservation of resources. Then, the node
performing the re-routing can swap on the new path and close the old path.
This feature is supported with RSVP-TE (using shared explicit filters) and
CR-LDP (using the action indicator flag). 
          Will this feature will hold good for optical networks as well ,
where we have TDM , LSC  LSPs. This would require use of 
     SE style in optical networks . Does signaling has to take care of not
reserving extra resources ( bandwidth / time slot )
    across the common path of the two LSPs , what will happen at the nodes
where the two routes diverge and converge .
    Is it expected that the signal will get multicast to both the routes ,
and at the node where the route converge the signal
    is selected from the better of the two paths till the rerouted LSP is
torn down .
Regards,
Manoj

---

From: [email-masked]
Date: Wed, 04 Dec 2002 02:38:38 +0100

hi,

i think this issue concerning "se style" has been discussed
some time ago but let's try here to give a bit more details,
lsp's in gmpls are control plane entities mapping data plane
ones, merging here does get sense if and only if the data
plane would deliver the same capability, since the soft-
provisioning that we can expect in shared meshed restoration
is purely a control plane driven mechanism the corresponding
entity doesn't occur at the data plane level and in particular
for tdm, lsc and fsc lsp's, once committed you find out the 
ff style as used today, as such there is no today something
like you seem to assume as setup of an lsp "split" it when 
a recovery lsp is needed and then "merge" it back when the
recovery lsp find back the working lsp path, then next even
if the methods that are under definition may be thought as
similar to the frr ones, the following for instance wouldn't
strictly apply (see fast-reroute):

"When using the sender-template-specific approach, the protected
LSPs and the backup paths SHOULD use the Shared Explicit (SE)
style. This allows bandwidth sharing between multiple backup
paths. The backup paths and the protected LSP MAY be merged by the
Detour Merge Points, when the ERO from the MP to the egress is the
same on each LSP to be merged, as specified in [RSVP-TE]."

this because for non-packet networks do soft-provisioning 
means let the capability to share the bandwidth on a control
plane view of the resource basis otherwise just provision 
it (commit it) since having a dedicated soft-provisioning 
on a per lsp basis just means be dedicated at the data plane 
level (if we assume a consistent usage of the mechanisms), 
and on the other side have merging (not multiplexing) of 
lsc or tdm at the data plane level is impossible (afaik) 
thus the fact that one knows that the requested lsp is for 
recovery purposes (link protection tlv s bit set) and its 
resources have to allocated within a pool but not committed 
(ie reserved) something which is needed in any case, do
the job here.  

hope this clarifies a bit,
- dimitri.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 05 Dec 2002 10:11:23 -0500

In message <[email-masked]>, [email-masked] wri
> hope this clarifies a bit,

This doesn't seem to me to clear it up.

In make-before-break, sharing bandwidth means that you will use one or
the other LSP, but never both.  Same with FRR - the primary or detour
is used, but not both at the same time.  Such a merge is at least in
principle possible for TDM, LSC, and FSC (although LSC required either
same wavelength or wavelength shifting or OEO).  I said "in
principle".  Therefore in principle, SE could be used for TDM, LSC,
and FSC.  In practice, this may not (ever) be true.

The ingress would need to know if bandwidth was shareable when doing a
reroute.  Otherwise, it may pick a path for which the RSVP signaling
always fails for no apparent reason.  That the RSVP signaling would
fail would not be apparent from the TE-LSDB before the signaling.
Reroute by trial and error is not a good option.

Is there a way for the ingress to know on which "links" bandwidth is
shareable?  Should it simply be assumed that bandwidth is not
shareable on any TDM, LSC, and FSC links?

Curtis

---

From: Yangguang Xu <[email-masked]>
Date: Thu, 05 Dec 2002 10:54:41 -0500

Curtis,

> shareable on any TDM, LSC, and FSC links?

You raised some good points here. For TDM, LSC and FSC, external resources
(link/port) can be in two states. If a internal cross connection is performed,
the associated external resource is committed and thus not sharable anymore.
Otherwise, it is sharable. So we can treat any non-committed resource as
sharable. The rest are not sharable.

Then the complication is when a non-committed resource gets committed, the rest
paths sharing the resource need to be re-arranged in order to guarantee the SLA
in case of double failures. How does FRR handle this?

Thanks,

Yangguang

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 05 Dec 2002 12:21:38 -0500

> in case of double failures. How does FRR handle this?

The answer to your question "How does FRR handle this?" is "not very
well at the moment but there is potential to do better".  While
seemingly flipant its an accurate answer.  I'll provide detail below.

There are two uses for SE, make-before-break and FRR.  I don't mean to
dodge your question, but I'd like to discuss make-before-break first,
then FRR.

Unlike FRR, make-before-break reroute from the ingress is done with
full bandwidth reservations (reserved and commited) and results in no
excess bandwidth being reserved and then wasted.  The new LSP is
reserved on a slightly different path but is able to share bandwidth
with the LSP it is replacing on any links in common in order to
accomplish a smooth transition.  It is important for the ingress to
know if this type of sharing is possible at all links for which both
the old and new LSP have in common and for which not enough bandwidth
is available for both the old and new without sharing.

Currently FRR cannot accurately account for bandwidth that can be
shared among backups that are not expected to fail at the same time
(do not protect any common SRLG).  This leaves two options for
deployment, reserve/commit full bandwidth on the backups or don't
reserve/commit full bandwidth on the backups.  In the former case far
more bandwidth is reserved than will ever be needed.  This might be OK
on a network that was massively overprovisioned.  In the latter case,
there is a chance that when the failures occur, the backups paths will
be congested (for packet links) or if the reservation must be
increased to "commit" the resource, then that operation will fail.

Practitioners seem to be opting for zero bandwidth reservations which
are increased to a full bandwidth reservations when the PLR puts the
backup into use.  This is not a good solution for packet networks.  It
is even less attractive for TDM, LSC and FSC.

Various methods to provide bandwidth reservation sharing have been
made going back as for as 1999 (afaik, maybe earlier as well).  Some
involve signaling the link, node, or set of SRLGs that a backup will
be using, and puts the intellegence to determine the potential for
sharing at each link.  One involves simply advertising the amount of
shareable bandwidth and sharable bandwidth used and puts the
intellegence at each PLR.

The issue of how backup bandwidth is shared, and therefore your
question of "How does FRR handle this?" is tangential to the issue of
whether TDM, LSC and FSC can share resources that are reserved and
committed by more than one LSP for which only one of those LSPs will
use the resource at one time and will use the entire resource to the
exclusion of the others.  It is "in principle" possible for TDM, LSC
and FSC (with the prior caveat regarding same-color or wavelegth
conversion).  If the ingress (or PLR for FRR) is to make an accurate
decision, then it needs to either know whether the sharing is possible
before attempting to setup an LSP, or it must assume that TDM, LSC and
FSC cannot support sharing.  IMHO traffic layout by trial and error is
not an option.

Curtis