The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2005-May> msg00051



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Non-Standard use of MPLS

  • From: "Victoria Fineberg" <fineberg@illinoisalumni.org>
  • Date: Fri, 27 May 2005 10:33:23 -0400
  • Resent-Date: Fri, 27 May 2005 11:01:44 -0400
  • X-OriginalArrivalTime: 27 May 2005 14:30:27.0922 (UTC) FILETIME=[A0B67320:01C562C8]
  • X-Originating-Email: [vfineberg1@msn.com]
  • X-Originating-IP: [64.4.56.205]
  • X-Scanned-By: MIMEDefang 2.45

The phrase "non-standard" has several interpretations.

If you define "standard" as RFCs 303x, then the use
of MPLS labels for Pseudowire (PW) multiplexing is
non-standards.

Another set of new MPLS applications is being
developed by the MPLS and Frame Relay Alliance
(soon to become MPLS Frame Relay and ATM
Forum, or MFA Forum).  The Alliance has defined
the MPLS-based User to Network Interface (UNI)
and Proxy Admission Control protocol (see
http://www.mplsforum.org/tech/library.shtml )


As far as using MPLS labels for encryption, it's an
interesting thought.  I don't know if anybody is doing
this, so I am just thinking out loud here.

Let's say you encrypt the IP packet payload BUT NOT
the IP header using the *Transport* mode of IPsec and
put the cryptographic information into an MPLS label on
top of the original IP header.  Now, you have to tell the
router that the label has to be popped and preserved, the
router has to do IP-based forwarding, find the appropriate
egress interface, re-attach the saved label and send the
packet on.  This scenario does *not* sound very useful to me.

However -
you can encrypt both the IP packet payload AND the
IP header using the *Tunnel* mode of IPsec.  You can
then put cryptographic information into the bottom MPLS
label (adjacent to the encrypted IP header) and put a tunnel
MPLS label on top.  Unlike the previous scenario, you will
be using MPLS labels in both ways, the "standard" one and
as a carrier of encryption information.  In order for this to
work, either the PE routers will have to do the IPsec based
encryption/decryption, or the CE device would do
encryption/decryption and communicate with the provider's
cloud via the MPLS UNI (see the MFA reference above).


Victoria


Victoria Fineberg
fineberg@illinoisalumni.org


----- Original Message ----- 
From: "Bob Anders" <mplsbob@gmail.com>
To: <mpls-ops@mplsrc.com>
Sent: Friday, May 27, 2005 6:34 AM
Subject: [MPLS-OPS]: Non-Standard use of MPLS


Dear MPLS-Experts,

I am aware that MPLS is intended to be used for switching purposes,
but I was wondering if anyone knows about implementations or plans
that make use of MPLS in a non-standard way, like

- MPLS is still used to make forwarding decisions, but the stack
contains also non-forwarding relevant information either in Exp bits
or in separate labels (type of information possibly identified by Exp
bits)
Or
- The MPLS stack is only used as a "vehicle" to encode additional
non-forwarding relevant information. Forwarding decisions are still
based on the underlying protocol (e.g. IPv4).

When talking about non-forwarding relevant data, I am thinking of
information used for encryption, network statistics, billing, etc ...

If there is anything out there (or maybe planed by IETF or whoever)
that makes use of MPLS-like stacks as described above, I would be
happy to hear about it (URLs, papers, ...).

Thanks and have a nice weekend!

  Bob

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml