Subject: RE: Question on GMPLS contentions resolution

From: Fong Liaw <[email-masked]>
Date: Mon, 27 Aug 2001 11:13:40 -0700

Guangzhi

The GMPLS contention resolution applies to the scenario
that two Path messages cross each other.  Your example
have Resv and Path cross each other so the rule in the
contention resolution does not directly apply and is more
of a policy and implementation issue.

Here is one possible solution and is within the 
interpretation of the draft, IMHO. here it is.
If node 2 already sends Resv to node 1, LSP A should
be considered established and therefore LSP B should
be rejected by node 2. If node 2 hasn't sent back Resv, 
LSP A is still in establishing mode and node 2 can resolve
the contention internally by rejecting LSP A or LSP B, based
on their setting up priority or it can change LSP A's
label and reprogram the cross-connect without ever noticed
by any external node.  In both cases, node 2 is the one
that resolve this contention.  Hope this helps.

p.s. I think you meant to use LABEL_SET since 
Suggested label is a suggestion, not a hard binding.

Regards
-Fong

>  -----Original Message-----
>  From: Guangzhi Li [mailto:[email-masked]]
>  Sent: Monday, August 27, 2001 6:17 AM
>  To: [email-masked]; [email-masked]
>  Cc: [email-masked]
>  Subject: Question on GMPLS contentions resolution
>  
>  
>  Dear GMPLS authors and all experts:
>  
>  During GMPLS last call, I posted the same question on the 
>  mailing list
>  without response. Please somebody spend a little time and 
>  check with the
>  following example? Something seems not clear when the current GMPLS
>  contention resution schemes are applied on a framework with both
>  bi-directional and uni-directional LSPs. Your clarification 
>  is very much
>  appreciated.
>  
>  Sincerely,
>  
>  Guangzhi
>  
>  -------------------------------------------------------------
>  -------------------------------------
>  
>  The issue arises because contention is resolved between 
>  bi-directional
>  LSPs by the node with the higher node index while for uni-directional
>  LSPs, contention is resolved by the downstream node. Consider the
>  following example of two nodes with paired, bi-directional interfaces
>  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
>  node 2 with ID = 50.  Node 1 uses label 1 for the 
>  transmitter port and
>  label 2 for the receiver port; node 2 uses label 4 for the 
>  transmitter
>  port and label 3 for the receiver port.   We assume that a
>  bi-directional LSP requires a single I/O interface.
>  
>  We consider two LSPs - a uni-directional LSP (LSP A) and a
>  bi-directional LSP (LSP B). Both LSPs are going from node 1 
>  to node 2,
>  with the uni-directional LSP setup request arriving marginally before
>  the bi-directional LSP.  LSP A does not use a suggested 
>  label, and thus
>  is assigned a label (port) by node 2.  Label 3 is assigned,
>  corresponding to label 1 at node 1.  At the same time, for LSP B (the
>  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
>  Because node 1 has the higher node ID, node 2 will assume (due to the
>  contention resolution rule for bi-directional LSPs) that LSP 
>  B wins the
>  contention and thus label 3 is assigned to LSP B.  Thus 
>  label 1 at node
>  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
>  LSPs have "won" the contention.
>  
>

---

From: Guangzhi Li <[email-masked]>
Date: Mon, 27 Aug 2001 17:13:24 -0400

Fong:

Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both
uni-directional and bi-directional together and uses the same port pool,
then a PATH and a RESV may cross each other. I think that it should be legal
based on current GMPLS specification. IF this scenario happens, GMPLS has to
provide one standard way to handle this situation.

Your suggestion works but it still involves the implementations of node 1
and node 2. Both nodes should interperate the same way. That means RESV
message always wins PATH message. No problem.

I assume that the I/O ports of bi-didrectional LSP are paired together, then
suggested_label = upstream_label and suggested_label is hard binding. Note
that contention happens in either this case or lack of resource. If
suggested_label could be different upstream_label, no contention problem at
all.

-- Guangzhi