Re: Question on GMPLS contentions resolution

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

Guangzhi,

    In any case where there is a tie between holding priority and setup
priority, holding priority wins.  Setup priority MUST be higher (i.e. -
have a lower value) than holding priority for setup to win.  This is not
clearly stated anywhere in the current RSVP-TE draft, nor in the
RFC (2751) that it refers to, nor in the CR-LDP draft.  However, it
may be directly inferred from the fact that the setup priority is allowed
to be equal to the hold/holding priority for the same LSP being setup
but may not be greater.  The stated reason for this is to preclude an
LSP from being preempted by another LSP having identical priorities
and then preempting that LSP in turn.  Clearly this intent would not
be satisfied if a tie resulted in preemption.

--
Eric Gray

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