RE: Question on GMPLS contentions resolution

["Anantha, Vic" <Vik.Anantha@CintaNetworks.com>]

Could somebody point me to where I can read up more about the node IDs that
are being mentioned here. Are they IP addresses that are interpreted as 32
bit unsigned integers?

Vik

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Monday, August 27, 2001 2:13 PM
To: Fong Liaw
Cc: ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


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

Fong Liaw wrote:

> 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:gli@research.att.com]
> >  Sent: Monday, August 27, 2001 6:17 AM
> >  To: ccamp@ops.ietf.org; mpls@UU.NET
> >  Cc: gli@research.att.com
> >  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.
> >
> >