Subject: MPLS over FR

From: Mohit Misra <[email-masked]>
Date: Wed, 15 Aug 2001 08:42:44 +0900

I have a doubt regarding MPLS over FR. Consider the case when two LDP peers
are connected over a FR cloud and intermediate FR switches are MPLS unaware.
A label mapping (DLCI) is negotiated between them. When the upstream node
sends a labled packet with the negotiated DLCI, the intermediate switches
will modify this value and finally it will reach the downstream node with a
different DLCI value (which was not negotiated ). ATM solves this problem by
VCID notification. How it is resolved in FR case ?
				/Mohit

---

From: Zaheer Aziz <[email-masked]>
Date: Tue, 14 Aug 2001 17:51:20 -0700

At 08:42 AM 8/15/2001 +0900, Mohit Misra wrote:
>sends a labled packet with the negotiated DLCI,

LSRA---dlci 1--FR-SW1-----FR-SW2--dlci 2---LSRB----FEC X

LSRA and LSRB are LDP peers and has exchanged label (L) for FEC X.
FR-SW are not running MPLS.

This negotiated label (L) through LDP is put in MPLS Header for any traffic 
destined for FEC F, but
to reach LSRB, LSRA uses DLCI 1 which FR-SW1 understands and forwards it to 
SW2 which maps DLC2
to reach LSRB.
Now LSR B receives MPLS header with label L and it should have a mapping in 
LFIB to forward appropriately.

Thanks
Zaheer

>the intermediate switches

---

From: Eric Gray <[email-masked]>
Date: Wed, 15 Aug 2001 09:04:21 -0400

Mohit,

    Please read section 6 of RFC 3034 - in particular the very first statement
which says (in part):

"To support label switching a Frame Relay Switch MUST implement the
   control component of label switching, ..."

--
Eric Gray

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Thu, 16 Aug 2001 11:53:10 +0400 (RET)

Hi Zaheer,
	How do you do this label stacking in FR n/ws? As far as my
knowledge is concerned I don't find any reference any where(including 3034
RFC) regarding label stacking in FR. Eric's quote from 3034 is more
appropriate here, I feel.

regards
Bhushana

---

From: Zaheer Aziz <[email-masked]>
Date: Wed, 15 Aug 2001 23:46:01 -0700

>Hi Zaheer,

Hi Bhushana,

>appropriate here, I feel.

For Frame Relay encapsulation as described in RFC 1490 it should be like 
in  section

4.1.  Routed Frames sections
Modification in the packet done by LSR would be
ethertype  be 8847(unicast IPv4) followed by label stack (32 bits each) 
followed by data payload, FCS and 7E Flag

What Eric is talking about it when DLCI == labels when FR switches in the 
middle runs LDP, where as your question precisely asked when FR switches 
are not running MPLS.

You wrote
"Consider the case when two LDP peers are connected over a FR cloud and 
intermediate FR switches are MPLS unaware."

Switches will not look at the MPLS labels and they should just switch based 
on DLCI mapping taken from Frame Relay header
(Q.922 Address)

Hope this helps
Zaheer

---

From: Eric Gray <[email-masked]>
Date: Thu, 16 Aug 2001 10:52:53 -0400

Zaheer,

    I'm not certain I entirely agree with what you've suggested here.

    Encapsulation of generic MPLS labels over a Frame Relay PVC
(or SVC) is somewhat messier than even you've indicated.  Either
the two end points of the FR-PVC/SVC have to infer the following
label stack from the DLCIs, or the FR-PVC/SVC has to carry the
generic MPLS labels encapsulated in some higher level protocol
for which support is directly defined in RFC 1490 (e.g. Ethernet), or
by cheating (somewhat) by using SNAP and OUI indicating that an
Ethertype follows and following it with the Ethertype for Unicast
MPLS (not IPv4).  I think this is a slight cheat, because it may not
be the case that every FR switch will support this Ethertype, it not
having been defined all that long ago.

    Also, FR-LSRs (like ATM-LSRs), labelled packets are supposed
to be transmitted using NULL encapsulation.  Therefore, it is likely
that even MPLS aware FR switches may not be expecting to see the
SNAP/OUI/Ethertype combination for MPLS labelled packets.

    My interpretation of the original question was based somewhat on
the suggestion that the DLCIs negotiated by non-adjacent FR-LSRs
should in some way be significant to each such LSR inspite of the fact
that there are intervening non-LSR FR switches.  This cannot be the
case, which is why I pointed out the text relating to the use of common
control.