Subject: Label-based forwarding at R[n]?

From: Scott Mallonee <[email-masked]>
Date: Fri, 03 Sep 1999 16:40:46 -0400

Hi All,

I am engaged in a discussion that perhaps someone might be kind enough to comment upon.

In [ARCH] 2.16 when PHP is discussed:

> From an architectural perspective, this is perfectly appropriate.
> The purpose of the level m label is to get the packet to Rn.  Once
> R[n-1] has decided to send the packet to Rn, the label no longer has
> any function, and need no longer be carried.
> 
> If one does not do this [PHP], then when the LSP egress receives a packet,
> it first looks up the top label, and determines as a result of that
> lookup that it is indeed the LSP egress.  Then it must pop the stack,
> and examine what remains of the packet.  ...  If there is
> no other label on the stack, then the packet is forwarded according
> to its network layer destination address.  Note that this would
> require the egress to do TWO lookups, either two label lookups or a
> label lookup followed by an address lookup.

My question is this: if m=1, why couldn't R[n] forgo PHP and use the layer m label to
index non-MPLS forwarding instructions? Is this a valid implementation option? Is there a
protocol-based hard requirement that packet be cracked in this case and conventional
forwarding be performed?

Best Regards,

Scott
-- 
+--------------------------------------------------------------------+
| Scott Mallonee                                       (540)822-4432 |
| Newbridge Networks Incorporated                      (703)736-5982 |
+--------------------------------------------------------------------+

---

From: Rohit Chhapolia <[email-masked]>
Date: Fri, 03 Sep 1999 17:06:39 -0400

Scott,

> protocol-based hard requirement that packet be cracked in this case and conventional

I think it is possible to use the layer m label to index non-MPLS actions. For host-based
LSPs, it could mean that packet should be given to local modules for processing rather than
to IP forwarding module (which then looks at the destination IP address and gives packet to
local modules for processing). For prefix-based LSPs, information about the outgoing interface
can be associated if it's known that all the packets coming on this LSP will go out on
this interface.

For ex.
 A-----B-------C

In this network, suppose B receives a Label request with FEC=C but decides to become egress
(due to configuration or other means) and sends a label back to A. But, now that all packets
on this LSP must go to C for further action, B can store interface going to C
with this label and when packets are received with this label, these can be directly
sent on this interface after popping label without next hop lookup. I think of it as implicit
penultimate hop popping.

Rohit

-- 
Rohit Chhapolia
Ficon Technology, Inc.
mailto:[email-masked]
http://www.ficon-tech.com

---

From: Eric Gray <[email-masked]>
Date: Fri, 03 Sep 1999 17:07:01 -0400

Scott,

	Indirectly, this has already been discussed.  Some
time back there was a discussion on aggregation of labels
in which at least one person pointed out that the egress 
may want to use the same label for all packets that would
be forwarded using the same output interface.  Implied in
this is the notion that any label could be used to decide
an output interface at the egress LSR.

	It is a small step from this to use a label to index
into a table containing L3 and L2 forwarding information -
which would also include output interface - for egressing
labeled packets to L3.  Since the egress determines how its
labels are assigned and interpreted, this is relatively
straight forward - if you want to do it.

	One thing that the implementer must consider is the
possibility that a route would have changed (such that the
packet is now supposed to be output on another interface)
and a new label may not yet have been negotiated with the
upstream peer(s).  Implicit in this consideration is the
perturbation of LSPs - perhaps unnecessarily - as a result
of changing local output interfaces for one or more route
changes.  

	All of this is implementation detail.  Use of PHP
allows for one potential optimization in implementation.
There will be others.