Re: Question on GMPLS contentions resolution

[Guangzhi Li <gli@research.att.com>]

Hang:

Yah. I see the point. As long as this clarification is addressed, the rule (2)
may not be needed since setup priority has to be greater than the holding
priority to preempt an established LSP.

One question: assume LSP A with Path message from node 1 and node 2 and LSP B
with Resv message from node 2 to node 1. Node 1 has cross-conneced for LSP A and
node 2 has cross-connected for LSP B. The setup prority is equal to the holding
priority for both LSP A and LSP B. It is easy to resolve the contention on node
2. How about node 1? LSP A has been setup on node 1 but LSP B has not. Resv
message is required to use the setup priority to preempt other established
LSPs.

What is the harm to put a rule without confliction with previous definitions.
Otherwise, other clarifications are required.

Regards,

Guangzhi

Hang Liu wrote:

> I think that Fong's points are valid. We can assume that "RESV" message
> means that the LSP has been set up (at least within the downstream node).
> There are the holding priority associated with it. The PATH message for the
> other LSP can win the contentinon only if its set-up priority > the holding
> priority of another LSP.
>
> Hang
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Wednesday, September 05, 2001 9:22 AM
> To: Fong Liaw
> Cc: Eric Gray; John Drake; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> 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