RE: Question on GMPLS contentions resolution

[Hang Liu <hliu@tellium.com>]

Hi.

One observation is 

When the I/O ports are paired, the contention between a uni-directional LSP
and a bi-directional LSP is similar to the contention of two bi-directional
LSPs. When a uni-directional LSP wants a label (I am not sure how common a
uni-directional LSP is needed in the case of paired I/O), it actually
contends that I/O pair with the bi-directional LSP.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 7:45 PM
To: Karthik Subramanian
Cc: 'Hang Liu'; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


Karthik:

I understand your argument. But
(1) It it legal not to suggest a label in PATH for a uni-directional LSP but
to
suggest a label for a bi-directional LSP especially I/O ports are paired.
(2) If this is too weak, then assume another scenario: the PATH message of
LSP A
suggested a label but was rejected by N2 due to race condition of other
LSPs,
(such as a bi-directional LSP C from N2 to N1), then it is up to the RESV
message of LSP A to assign the label. At this time, the condition happens
between LSP A and LSP B.

You may say why LSP A is so unlucky and it may not happen two race
conditions in
a short time. But it may although the probability is very small :=)

If you draw pictures, you may find other scenarios.

-- Guangzhi


Karthik Subramanian wrote:

> Guangzhi,
> Let me try to understand what you are suggesting here. Please correct me
if
> I'm wrong.
>
>                    m------------>n
>                N1                   N2
>                    o<------------p
>
> m,n,o,p are the labels for a bidirectional port.
> LSP A is an uni-directional LSP whose direction is from N1 to N2
> LSP B is a bi-directional LSP whose direction is from N1 to N2.
>
> The sequence of operations is
>
> 1. N1 suggests 'n' for LSP A.
> 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve
> 'n' yet.
> 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to
> N1.
>    Simultaneously, for LSP B, N1 allocates 'o' as upstream label,
>        suggests 'n' for the forward direction and forwards the PATH.
>
> The problem is caused due to N1 suggesting the same label 'n' for 2 lsps.
> With regard to suggested labels you can take 2 approaches.
>
> 1. Suggested Label is reserved by the upstream node when the PATH is
> forwarded:
>       In this case, the problem won't arise, since during step 1, the link
> (m,n) is reserved and hence for LSP B, this port is unavailable (since the
> I/O ports of a bi-directional LSP are paired).
>
> 2. Suggested Label is NOT reserved by the upstream node until RESV comes:
>       In this case, during step 3, you are contradicting yourself by
making
> the cross-connect in N1 and hence reserving the port. I understand that
the
> I/O port pairing for bi-directional lsp might be a hardware restriction,
but
> its a contradiction nonetheless.
>
> You need to decide which approach to take and no violations must be made.
> The first approach seems logical to me.
>
> Karthik
>
> > From: Guangzhi Li [mailto:gli@research.att.com]
> >
> > I did not make it clear. I assume that the I/O ports of
> > Bi-directional LSP
> > are
> > paired. After node 1 configured the cross-connect with the
> > upstream label
> > (of course
> > suggested label) for LSP B,  node 1 received the uni-directional RESV
> > message for
> > LSP A, is it obviously defined in GMPLS that node 1 should
> > accept LSP A and
> > give up
> > LSP B or simply is it a local decision/policy implementation?
> >
> > -- Guangzhi
> >
> > Guangzhi Li wrote:
> >
> > > Hang:
> > >
> > > NO. The PATH message is bi-directional and the RESV is
> > uni-directional. If
> > there
> > > is a contention,  the contention happens with LSP A and the
> > upstream label
> > of
> > > LSP B.
> > >
> > > In your suggestion, you used IF. IF GMPLS specifies a
> > consisten way to
> > resolve
> > > it, such as Resv wins Path message in all cases, there is
> > no problem. A
> > simply
> > > local decision is NOT enough.
> > >
> > > Please draw pictures and apply current GMPLS contention
> > resolution schemes
> > ONLY.
> > > You will see something needs to be fixed.
> > >
> > > Guangzhi