The MPLS WG Archive

[Guangzhi Li <gli@research.att.com>]

Hang:

NO. The PATH message is bi-directional and the RESV is uni-directional. If there
is a contention,  the contention happens with LSP A and the upstream label of
LSP B.

In your suggestion, you used IF. IF GMPLS specifies a consisten way to resolve
it, such as Resv wins Path message in all cases, there is no problem. A simply
local decision is NOT enough.

Please draw pictures and apply current GMPLS contention resolution schemes ONLY.
You will see something needs to be fixed.

Guangzhi

Hang Liu wrote:

> Guangzhi,
>
> For this case, if Node 1 always maps the label in the RESV message and
> creates RSB. LSP A will be set up. The suggested label in the PATH message
> from Node 1 is only preference. LSP B will be rejected by Node 2.
>
> Hang
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Tuesday, August 28, 2001 9:52 AM
> To: John Drake
> Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> John:
>
> No. Node 1 may send out the PATH message to node 2 as the same time as node
> 2
> sends out the RESV message to node 1. If the contention resolution is a
> local
> decision or policy implementation, node 1 may decide to fail LSP A since
> node 1
> has the higher node ID. Then both LSP A and LSP B are failed. This is not
> what
> we want. So, a consistent decision is required between these two nodes.
>
> Thanks,
>
> -- Guangzhi
>
> John Drake wrote:
>
> > Guangzhi,
> >
> > In Fong's note she indicated that the contention can be completely
> resolved
> > by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> > node 1 is told the result of node 2's decision making process.
> >
> > Thanks,
> >
> > John
> >
> > -----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.
> > > >
> > > >