Subject: RE: Question on GMPLS contentions resolution

From: Hang Liu <[email-masked]>
Date: Tue, 28 Aug 2001 14:19:24 -0400

Guangzhi,

It is true that a consistent way is needed to handle this case. Otherwise,
as you mentioned,  both LSP A and LSP B may fail.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 1:39 PM
To: Hang Liu; John Drake; Fong Liaw; [email-masked]; [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Hang:

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
>
> Hang Liu wrote:
>
> > Guangzhi,
> >
> > For this case, if Node 1 always maps the label in the RESV message and
> > creates RSB. LSP A will be set up. The suggested label in the PATH
message
> > from Node 1 is only preference. LSP B will be rejected by Node 2.
> >
> > Hang
> >
> > -----Original Message-----
> > From: Guangzhi Li [mailto:[email-masked]]
> > Sent: Tuesday, August 28, 2001 9:52 AM
> > To: John Drake
> > Cc: Fong Liaw; [email-masked]; [email-masked]
> > Subject: Re: Question on GMPLS contentions resolution
> >
> > John:
> >
> > No. Node 1 may send out the PATH message to node 2 as the same time as
node
> > 2
> > sends out the RESV message to node 1. If the contention resolution is a
> > local
> > decision or policy implementation, node 1 may decide to fail LSP A since
> > node 1
> > has the higher node ID. Then both LSP A and LSP B are failed. This is
not
> > what
> > we want. So, a consistent decision is required between these two nodes.
> >
> > Thanks,
> >
> > -- Guangzhi
> >
> > John Drake wrote:
> >
> > > Guangzhi,
> > >
> > > In Fong's note she indicated that the contention can be completely
> > resolved
> > > by node 2, so I'm not sure that there's an interoperability issue.
I.e.,
> > > node 1 is told the result of node 2's decision making process.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Guangzhi Li [mailto:[email-masked]]
> > > Sent: Monday, August 27, 2001 2:13 PM
> > > To: Fong Liaw
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Question on GMPLS contentions resolution
> > >
> > > Fong:
> > >
> > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network
runs
> > both
> > > uni-directional and bi-directional together and uses the same port
pool,
> > > then a PATH and a RESV may cross each other. I think that it should be
> > legal
> > > based on current GMPLS specification. IF this scenario happens, GMPLS
has
> > to
> > > provide one standard way to handle this situation.
> > >
> > > Your suggestion works but it still involves the implementations of
node 1
> > > and node 2. Both nodes should interperate the same way. That means
RESV
> > > message always wins PATH message. No problem.
> > >
> > > I assume that the I/O ports of bi-didrectional LSP are paired
together,
> > then
> > > suggested_label = upstream_label and suggested_label is hard binding.
Note
> > > that contention happens in either this case or lack of resource. If
> > > suggested_label could be different upstream_label, no contention
problem
> > at
> > > all.
> > >
> > > -- Guangzhi
> > >
> > > Fong Liaw wrote:
> > >
> > > > Guangzhi
> > > >
> > > > The GMPLS contention resolution applies to the scenario
> > > > that two Path messages cross each other.  Your example
> > > > have Resv and Path cross each other so the rule in the
> > > > contention resolution does not directly apply and is more
> > > > of a policy and implementation issue.
> > > >
> > > > Here is one possible solution and is within the
> > > > interpretation of the draft, IMHO. here it is.
> > > > If node 2 already sends Resv to node 1, LSP A should
> > > > be considered established and therefore LSP B should
> > > > be rejected by node 2. If node 2 hasn't sent back Resv,
> > > > LSP A is still in establishing mode and node 2 can resolve
> > > > the contention internally by rejecting LSP A or LSP B, based
> > > > on their setting up priority or it can change LSP A's
> > > > label and reprogram the cross-connect without ever noticed
> > > > by any external node.  In both cases, node 2 is the one
> > > > that resolve this contention.  Hope this helps.
> > > >
> > > > p.s. I think you meant to use LABEL_SET since
> > > > Suggested label is a suggestion, not a hard binding.
> > > >
> > > > Regards
> > > > -Fong
> > > >
> > > > >  -----Original Message-----
> > > > >  From: Guangzhi Li [mailto:[email-masked]]
> > > > >  Sent: Monday, August 27, 2001 6:17 AM
> > > > >  To: [email-masked]; [email-masked]
> > > > >  Cc: [email-masked]
> > > > >  Subject: Question on GMPLS contentions resolution
> > > > >
> > > > >
> > > > >  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: Hang Liu <[email-masked]>
Date: Wed, 29 Aug 2001 11:17:39 -0400

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:[email-masked]]
Sent: Tuesday, August 28, 2001 7:45 PM
To: Karthik Subramanian
Cc: 'Hang Liu'; John Drake; Fong Liaw; [email-masked]; [email-masked]
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: John Drake <[email-masked]>
Date: Wed, 29 Aug 2001 08:29:31 -0700

I think this is Guangzhi's #7, which he indicated could be derived from the
existing text.  (I wasn't sure that it could.)  The correct resolution may
be to indicate that a Resv always beats a Path and that for two Paths, the
higher node always wins?

----Original Message-----
From: Hang Liu [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 8:18 AM
To: 'Guangzhi Li'; Karthik Subramanian; [email-masked]'
Cc: Hang Liu; John Drake; Fong Liaw; [email-masked]; [email-masked]
Subject: RE: Question on GMPLS contentions resolution

Hi.

One observation is 

Hang

-----Original Message-----
From: Guangzhi Li [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 7:45 PM
To: Karthik Subramanian
Cc: 'Hang Liu'; John Drake; Fong Liaw; [email-masked]; [email-masked]
Subject: Re: Question on GMPLS contentions resolution

Karthik:

-- Guangzhi

if
making
the
but