[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on GMPLS contentions resolution
John,
Even in processing Resv messages serially, it is quite reasonable (if not
actually required) for an implementation to want to retrieve the PSB. It is
conceivable that the delta in such a case for checking outstanding Path
requests is not that great. Moreover, how much work is node 2 going to
have to go through to ascertain that - as Fong had implied - the completion
of LSP A means that LSP B does not have to be completed? It seems to me
that - once again - it is be left open to the implementer to determine where
the work gets done in this case.
If options may be ugly, ambiguity can be hideous.
--
Eric Gray
You wrote:
> 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.
> > > >
> > > >