Re: Question on GMPLS contentions resolution

[Fong Liaw <fongliaw@yahoo.com>]

Guangzhi

GMPLS includes SESSION_ATTRIBUTE object,
but the current text on contention resolution
does not take it into account. So I think adding 
(1) as clarification is needed, however, I would 
change (1) to

"(1) Based on the LSPs' hold and setup priority."

I might remove (2) if it is understood that
receiving a Resv means hold priority should be
used in (1).

We already have (3), so that is fine.

-Fong
 
--- Guangzhi Li <gli@research.att.com> wrote:
> Hi, all:
> 
> I posted the contention resolution question 10 days
> ago. After some fruitful
> discussions with John Drake, Eric Gray, Fong Liaw,
> Hang Liu, I propose the
> following three rules to resolve any contention in
> GMPLS although there is no
> signaling correctness issue. The following rules
> should applied in sequence to
> both bi-directional and uni-directional LSPs:
> 
> (1) Higher priority LSP wins lower priority LSP.
> (2) LSP with Reply (Resv in RSVP) message wins LSP
> with Request
> (Path in RSVP) message.
> (3) LSP with the higher node ID assigning the label
> wins the contention
> if race conditions happen between two LSPs with
> Request messages.
> 
> Since race conditions won't happen between two LSPs
> with Reply messages,
> the above three rules solve all possible contention
> scenarios.
> 
> Proposed modification of the GMPLS functional
> specification, text from
> section 4.2:
>
---------------------------------------------------------------------------
> 
> By allowing bi-directional LSP setup and suggested
> label in the GMPLS
> framework,  contention for labels may occur between
> two bidirectional
> LSP setup requests, or between an uni-directional
> and a bi-directional
> LSP, traveling in opposite directions.  This
> contention occurs when both sides
> allocate the same resources (labels) at effectively
> the same time. If there is no
> restriction on the labels that can be used for
> bidirectional LSPs and if
> there are alternate resources, downstream label
> assignment will apply
> and there is no contention. However, if there is a
> restriction on the
> labels that can be used for the bidirectional LSPs
> (for example, if they
> must be physically coupled on a single I/O card), or
> if there are no
> more resources available, then the contention must
> be resolved by other
> means. Although contention resolution is not a
> mandatory requirement for
> signaling correctness, contention resolution is
> strongly recommended
> for performance optimization. To resolve contention,
> the following three rules
> SHOULD be applied in sequence:
> (1) A higher priority LSP wins over a lower priority
> LSP.
> (2) LSP with a Reply message wins over a LSP with a
> Request
> message.
> (3) LSP with higher node ID assigning the label wins
> the contention if
> race conditions happen between two LSPs with Request
> messages.
> ........
> 
> The rest of the text from this section should be
> updated accordingly.
> 
> Thanks,
> 
> Guangzhi
> 
> 
> >  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.
> 
> 


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com