[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on GMPLS contentions resolution
What this requires is an RSVP implementation in which the Resv processing
checks to see whether there is any outstanding Path request specifying a
upstream label that is tied to the downstream label received in the Resv,
and if there is to tear down the LSP that was just established with the
Resv, as opposed to an implementation that would process Resvs serially. I
don't know how sensible this may or may not be.
-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 6: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.
> > >
> > >