Subject: Re: Question on GMPLS contentions resolution

From: Guangzhi Li <[email-masked]>
Date: Tue, 04 Sep 2001 10:51:52 -0400

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.

---

From: Fong Liaw <[email-masked]>
Date: Tue, 4 Sep 2001 21:26:19 -0700 (PDT)

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
 
> > LSPs have "won" the contention.

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

---

From: Guangzhi Li <[email-masked]>
Date: Wed, 05 Sep 2001 09:21:43 -0400

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

---

From: Eric Gray <[email-masked]>
Date: Wed, 05 Sep 2001 11:02:20 -0400

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

---

From: Eric Gray <[email-masked]>
Date: Wed, 05 Sep 2001 11:05:21 -0400

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