Re: Question on GMPLS contentions resolution

[Eric Gray <eric.gray@sandburst.com>]

Guangzhi,

    The reference to setup and holding priorities would require a reference
to [RSVP-TE] and [CR-LDP] references already included in the draft.
Whther or not these need to be specifically called out again is a call for
the authors - assuming that they include any of your proposed changes.

--
Eric Gray

You wrote:

> Fong:
>
> Would you please explain more why (2) is not needed if (1) is changed ?
> IF (holding priority == setup priority), how to resolve it ?
>
> By the way, how to interperate holding priority and setup priority should be
> explained when they are defined.
>
> (3) is an extension of current GMPLS specification. Current GMPLS clearly says that
> this rule deals with two bi-directional LSPs.
>
> Guangzhi
>
> Fong Liaw wrote:
>
> > 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