Subject: Label Space

From: Srinivas T M <[email-masked]>
Date: Tue, 1 May 2001 07:40:33 -0700 (PDT)

Hi,
    Here is a basic doubt.
Why per-interface label space only used in case of
ATM/FR?
  Can we use platform label space in case of ATM/FR ?

   Can we configure label space (per-interface or
Platform label space) per LSR wise?
 
  If LSR has both ATM and Ethernet ports, then how do
use label space if label space is configured?

Thanks in Advance,
Srini

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: "James R. Leu" <[email-masked]>
Date: Tue, 1 May 2001 11:57:44 -0500

Hello David,

> The choice of per-interface or per-platform doesn't have to be a global
> setting.  Some interfaces can have a private label space while all the
> others share a platform label space.  It is possible (for instance) to
> put the Ethernet interfaces in the platform label space while giving
> each ATM interface its own label space.

I agree, but I have never understood how hierarchical tunnels (such as
those used in RSVP bypass tunnels) would work over private label spaces.

> I think it's also possible to have multiple separate label spaces that
> contain more than one interface each.  But I'm not sure of this.

That would indeed handle the above question.  (assign the interfaces that
would be part of the bypass to the same label space, label allocation becomes
much simpler). I too am not sure it is a valid use of label spaces.

Any insight would be useful. Thanks.

Jim
-- 
James R. Leu

---

From: David Charlap <[email-masked]>
Date: Tue, 01 May 2001 13:23:15 -0400

"James R. Leu" wrote:
> 
>> The choice of per-interface or per-platform doesn't have to be a
>> global setting.  Some interfaces can have a private label space
>> while all the others share a platform label space.  It is possible
>> (for instance) toput the Ethernet interfaces in the platform label
>> space while giving each ATM interface its own label space.
> 
> I agree, but I have never understood how hierarchical tunnels (such
> as those used in RSVP bypass tunnels) would work over private label
> spaces.

Certain things (like LDP remote peers and bypass tunnels) become
difficult with per-interface label spaces.  The routers must be able to
deal with the possibility that the next-hop for an already-established
LSP may jump from one interface to another.  When this happens, its
label must also jump.  If the label is already in use on the new
interface, however, then one or the other must be preempted.

There are some ways around this problem, but they will not all be
possible, depending on hardware.

For instance, if the switch has a very large label space, but can only
allocate a (relatively) small number of labels from the space, then it
can allocate labels on the interfaces where they are used, and prevent
the other interfaces from using the same label values (without actually
installing those labels on those interfaces.)  This way, there won't be
conflict if a label should happen to change interfaces.

But some hardware may be unable to lock-off a label value without
actually consuming the resources associated with that label.  Meaning
some other scheme might be necessary.

The problem is difficult, and I suspect there will be no single solution
that will work well on all hardware platforms.  But I think there are
solutions.

>> I think it's also possible to have multiple separate label spaces
>> that contain more than one interface each.  But I'm not sure of
>> this.
> 
> That would indeed handle the above question.  (assign the interfaces
> that would be part of the bypass to the same label space, label
> allocation becomes much simpler). I too am not sure it is a valid
> use of label spaces.

The only problem with this is that a switch that only has per-interface
support in the hardware will have the same problems using this scheme as
it will with per-platform label spaces.

I mention this only because some hardware designs may make this a good
idea.  For instance, if several ports are all wired to the same
forwarding chip, it might make sense for them to share a single label
space, even if they can't share that space with ports attached to other
forwarding chips.

-- David

---

From: Srinivas T M <[email-masked]>
Date: Tue, 1 May 2001 10:25:17 -0700 (PDT)

Hi,
      Thanks for reply.
In case of LSP's established through targeted session
will use only platform Label space. That means, If we
want to establish LSP through targeted session, we
must configure the platform label space in LSR even
all interfaces in LSR uses per-interface label space.
 Is it right?

Thanks,
Srini

> There's no reason why not, other than the fact that
> existing ATM
> switches don't have native hardware support for
> per-platform VC spaces.
> 
> Yes.

---

From: David Charlap <[email-masked]>
Date: Tue, 01 May 2001 13:36:03 -0400

> all interfaces in LSR uses per-interface label space.

See my other message.

I think LDP remote peers can be implemented with per-interface label
spaces, but it creates problems that may not be easy to solve on your
hardware.

-- David

---

From: David Charlap <[email-masked]>
Date: Tue, 01 May 2001 11:18:27 -0400

Srinivas T M wrote:
> 
>     Here is a basic doubt.
> Why per-interface label space only used in case of ATM/FR?

ATM cell switching assigns VCIDs on a per-interface basis.  As such,
most (if not all) existing ATM hardware is designed around per-interface
and not per-platform.

This could be worked around by duplicating the per-interface labels
across all interfaces.  But now every logical label allocation is
consuming n (where "n" is the number of interfaces) label allocations in
the hardware - this can quickly exhaust the label space if used in a
large network.

>   Can we use platform label space in case of ATM/FR ?

There's no reason why not, other than the fact that existing ATM
switches don't have native hardware support for per-platform VC spaces.

Yes.

-- David

---

From: Eric Gray <[email-masked]>
Date: Tue, 01 May 2001 17:02:12 -0400

David,

    Please see in-line comments, below.

> interface, however, then one or the other must be preempted.

Could be that the terminology we're using is ambiguous, but I'm not
sure I agree with the above.  One way that an LSR might deal with
the possibility of a next hop change for an LSP is to use liberal label
retention.  This will work even if the per-interface label space is in
use between two LSRs with multiple interfaces in common and the
only thing about the next hop that changes is the interface to use
for a specific LSP.  There is no requirement to avoid overlapping
label usage, in this case.

For LDP remote peers, labels are stacked and labels exchanged
by remote peers are only visible when all labels above them in the
stack have been popped.  In this case, the term 'interface' takes
on an interesting meaning.   One approach (I think the one you're
assuming and - possibly - the common interpretation), is to treat
all LSPs between two remote LSRs as if they are all part of the
same 'interface' - in which case the distinction between label
spaces (per-interface, and per-platform) is moot.   This approach
is the simplest, and - since the labels used are below the top level
label in forwarding packets - there is unlikely to be a hardware
reason why this cannot be supported.  If labels are stacked, then
assignment of labels are orthogonal at each stack level from the
sender's point of view.   If there is some reason why assignments
at differing stack levels are not orthogonal (possibly because of
private label semantics) from the receivers point of view, there
would only be a problem if the receiver somehow assigned an
innappropriate label for some label stacking context.  An LSR
has to deal with its own faults.

This approach is not very clean and has the potential to introduce
problems if the remote peers are trying to do different things.  For
example, if the peers are remote LDP peers, one may be sending
hello messages on each LSP it intends to use (as a group resource,
for instance) with the same LSR ID (including the per-platform
label space) and a different set of hello messages on other LSPs
to the same remote peer LSR (using a different LSR ID).  Possibly
the intent is to use different LDP sessions to control labels
established for different purposes.  This LSR would naturally tend
to expect labels it has advertised only on LSPs over which it is
also receiving hello messages from the remote peer (also using the
per-platform label space - since,  otherwise, multiple LDP session
would exist).  Suppose, however, that the other LSR is JPLIG and
is only sending hello messages over a single LSP since it was built
with the assumption that it could use any label it acquires from the
remote peer on any LSP to that remote peer irrespective of whether
or not it is keeping up a session over that LSP.  Oila` - there is a
problem.

I believe that label distribution paradigms (e.g. - MPLS BGP)
that rely on use of the per-platform label space, explicitly state
this as a requirement.  Perhaps I'm wrong, however, and they
simply count on the implementer to do the right thing.  :-)

> possible, depending on hardware.

A working LSR does not advertise the per-platform label space
over an interface on which it will not work.  A working peer does
not attempt to use per-platform labels on an interface over which
it is not currently maintaining a session with a per-platform peer.

As discussed (in some detail) above, this changes when label
stacking is in use - but then so does the hardware dependency.

> space, even if they can't share that space with ports attached to other

Which is an excellent example of why the per-platform label space
must be applied within a context of LDP session management - at
least whenever LDP is in use.  In this case, the LSR that you point
out could maintain this in two ways: by requiring that each interface
is supported by its own per-interface LSR peer and each such peer
advertises all of the same labels to all peers attached to any of these
interfaces (which will get ugly if the same LSR is attached to more
than one of these interfaces) or by maintaining a single LDP peer
session with any LSRs attached to any of these interfaces (which
allows it to advertise each label only once with respect to any peer)
and using the per-platform label space.

---

From: David Charlap <[email-masked]>
Date: Tue, 01 May 2001 19:46:20 -0400

Eric Gray wrote:
>> difficult with per-interface label spaces.  The routers must be
>> able to deal with the possibility that the next-hop for an
>> already-established LSP may jump from one interface to another.
>> When this happens, its label must also jump.  If the label is
>> already in use on the new interface, however, then one or the
>> other must be preempted.
> 
> the possibility of a next hop change for an LSP is to use liberal
> label retention.

This will work for most cases.  If the next-hop for an ordinary LSP
changes, there's no problem.  You either use the label you already have
(if retention is liberal and you have a label) or you request a new one.

Some of the fast-recovery drafts, however, don't allow time for that. 
They assume that labels will already be in place on the backup
interface.  Which means the label must either be allocated on a
per-platform basis, or it must be pre-reserved on the backup interface -
using scarce resources.

It is possible to not allocate the label on the backup interface if you
can be certain that no other LSP uses that label's value, however.  This
can simulate the effect of a platform label space (at least as much as
is necessary for the recovery mechanism) without wasting resources.

> stack have been popped.

Correct.  This only really impacts the edge router.  Transit routers
only use the top label.

The big deal here is that the TCP session between the remote peers may
hop from interface to interface if the routing table changes.  If labels
are per-interface, then any labels mapped as part of that TCP session
must hop interface with the TCP session.

> In this case, the term 'interface' takes on an interesting meaning.
> One approach (I think the one you're assuming and - possibly - the
> common interpretation), is to treat all LSPs between two remote
> LSRs as if they are all part of the same 'interface' - in which
> case the distinction between label spaces (per-interface, and
> per-platform) is moot.   This approach is the simplest, and - since
> the labels used are below the top level label in forwarding packets
> - there is unlikely to be a hardware reason why this cannot be
> supported.

I think what you're describing is a situation where the TCP connection
between remote peers is router-to-router, and not interface-to-
interface.  So nothing changes if the TCP stream hops interfaces.

But this can't work if you have per-interface label spaces.

Since it is not normally possible to use anything more than the label's
value when determining the meaning of that label, a remote peer's label
space must be shared with the label space of whatever interface the TCP
session is going out on.

If the egress router is using per-interface label spaces and the inner
label is only known to one interface, then that inner label will only be
processed if the packet arrives on that interface.  If a fast reroute
causes the inner label to be placed into a different LSP, and the packet
arrives at the egress on a different interface, that interface won't
know what to do with the inner label - or it may have a different NHLFE.

The problem doesn't exist with per-platform label spaces, because every
interface knows about the inner label.  But there doesn't seem to be any
easy solution to this for boxes that can't support per-platform label
spaces, unless per-platform functionality is faked - perhaps by
duplicating remote-peer labels across all interfaces - which will waste
resources.

> simply count on the implementer to do the right thing.  :-)

I'm not sure what's a hard requirement here.  IMO, per-platform
functionality should be possible to fake on those routers that don't
actually support it.  But the amount of work and complexity involved may
be too much to make it worthwhile.

-- David

---

From: David Charlap <[email-masked]>
Date: Wed, 02 May 2001 12:10:17 -0400

Eric Gray wrote:
>> 
>> It is possible to not allocate the label on the backup interface
>> if you can be certain that no other LSP uses that label's value,
>> however.  This can simulate the effect of a platform label space
>> (at least as much as is necessary for the recovery mechanism)
>> without wasting resources.
> 
> I'm not sure of the distinction between allocating a label (in this
> usage) and being certain that no other LSP will use it.  If you
> allocate it without signaling, then you are essentially 'reserving'
> it.  If you are ensuring that is is not used for any other LSP,
> then you are essentially 'reserving' it.

Not quite.

If the scarce resource is the range of label values themselves, then you
are right.  Keeping other LSPs away from it is the same as a
reservation.

But if your scarce resource is something else - perhaps table entries in
a forwarding chip - then this is not necessarily the case.  To actually
"reserve" a value would be to install it in the port's forwarding
hardware, while simply avoiding the use of a specific label value can be
done without installing anything in the forwarding hardware. 

In other words, it may be possible to consume labels without consuming
all of the forwarding resources that normally go along with those
labels.

>> The big deal here is that the TCP session between the remote peers
>> may hop from interface to interface if the routing table changes.
>> If labels are per-interface, then any labels mapped as part of
>> that TCP session must hop interface with the TCP session.
> 
> This is skirting a thin line.  TCP is not normally associated with
> an interface and not every implementation pays strict attention to
> the interface over which a TCP connection is maintained.  Therefore,
> relying on label validity to jump around with TCP connectivity will
> most probably lead to (if it is not already) a protocol error.

Obviously, if the TCP connection's interface can't be tracked, then
remote peers can't work without per-platform label spaces (or an
emulation thereof.)

>> Since it is not normally possible to use anything more than the
>> label's value when determining the meaning of that label, a remote
>> peer's label space must be shared with the label space of whatever
>> interface the TCP session is going out on.
>
> This is plainly wrong.  When using the per-interface label space,
> the interface on which a label is received is obviously part of the
> logical context in which the label must be considered.  This can
> be done in any number of ways.

I must be unclear hree.

When a router receives two stacked labels, it obviously uses the
interface in determining what to do with the top label.

My point is regarding the next label down (the second-level label).

This label is, obviously, allocated as a part of whatever label space
the TCP session (for the remote peer) is associated with.  This is the
same as with all labels.

The problem happens when there is no per-platform label space.  The
remote peer's labels must be allocated as a part of an interface's label
space.  But since the peer is not directly attached, there can be no
guarantee that traffic from that peer (that is, traffic using
second-level labels requested over that TCP channel) will always arrive
on the same interface.

Which means that these second-level labels must either be installed
per-platform, or at least installed on all interfaces that the label
might conceivably arrive on.

The rest of my hypothesizing is an attempt to reduce this down to the
one interface that the label actually does arrive on.  If the data is
strictly following the routing table, it may be possible to assume that
the TCP session will hop interfaces in unison with the data packets. 
Therefore, if the TCP session hopping can be detected (and as you've
already written, it may not be possible to detect this), its labels can
be moved at that time.

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 02 May 2001 11:31:53 -0400

David,

    Please see comments below.

> per-platform basis, or it must be pre-reserved on the backup interface -

If you're not using the per-platform label space, then pre-reservation
must be considered a more optimal use of scarce resources then  use
of the per-platform label space (where all labels are pre-reserved at
all interfaces, or at least, all interfaces in common).

> is necessary for the recovery mechanism) without wasting resources.

I'm not sure of the distinction between allocating a label (in this usage)
and being certain that no other LSP will use it.  If you allocate it
without
signaling, then you are essentially 'reserving' it.  If you are ensuring
that
is is not used for any other LSP, then you are essentially 'reserving' it.
And, if you allocate it and signal the allocation, then the choice of label

space is irrelevant, since this choice is part of the signaling process.

> must hop interface with the TCP session.

This is skirting a thin line.  TCP is not normally associated with an
interface and not every implementation pays strict attention to the
interface over which a TCP connection is maintained.  Therefore,
relying on label validity to jump around with TCP connectivity will
most probably lead to (if it is not already) a protocol error.

> interface.  So nothing changes if the TCP stream hops interfaces.

I believe that it is safer to assume TCP connectivity is IP entity to
IP entity than it is to assume that it is interface to interface.

However, if a specific system implementation (this is NOT a
limitation induced by any specific hardware component) cannot
consider the interface on which a label was received, then that
system does not support the per-interface label space.  Period.

And, please, before anyone jumps all over this statement, having
an individual label processor for each and every interface is one
way to use the interface on which a label is received as part of
the context for considering the label - even if none of the label
processors is individually capable of knowing what interface a
label was received on.

As a side note, I strongly suspect that building label processors
that are not at least somewhat capable of considering the input
interface (in some abstraction), is probably not as good a way
to sell lots of label processors as it might at first appear.

> be too much to make it worthwhile.

Agreed, and agreed.

--
Eric Gray