The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Oct> msg00420



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

Doubt in MPLS-VPN ....

  • From: neil.2.harrison@bt.com
  • Date: Mon, 29 Oct 2001 12:42:08 -0000

Shirish Indurkar wrote 29 October 2001 11:29
> My question is how we can be sure that the MPLS-VPN Packet  
> is really Safe 
> when it traverses  through the P routers ? I mean how the 
> corporate information
> is still secured when it passes through the P routers ? It is 
> still traversing 
> through the Public infrastructure unencrypted .
NH=> One mechanism that you can consider for using is to make sure each LSP
has a unique means of identification in the data-plane.  In the MPLS OAM
work this is indeed a primary consideration wrt fault detection/handling.
We define a CV (connectivity verification) packet that is periodically sent
from the source to the sink of the LSP....its very similar to having a
'hello' function, but here its only relevant to the data-plane and decoupled
from the routing/processing of any control-plane which is present.  The CV
contains a network-wide unique identifier.  This allows all the following
faults to be automatically detected by the operator:
-	simple breaks in connectivity (either below or within the MPLS
fabric)
-	swapped LSPs
-	unintended merging of LSPs (where the offending LSP may or may not
be affected).
So if a VPN's traffic is leaking out (or being leaked into) you can detect
this by noting the occurrence of the unexpected CV flow....and you can then
take the appropriate action which is dependent on the specific defect type
(eg suppress traffic to protect customer traffic integrity) as necessary.
It should also help Ops people diagnose the problem more efficiently, and
allow operators to develop consistent QoS/availability SLAs (since these are
based on well-defined defect states).

The customer can still encrypt the traffic of course for complete
security......the above is primarily targeted at making fault-management
simpler and more efficient for the operator, though it clearly allows the
operator to offer some stronger integrity verification mechanisms and a
provides basis for SLA specification.

Note - the technique is not dependent on having any specific server
technology (under MPLS) or client technology (over MPLS).  It is also
decoupled from whatever control-plane is being used (inc none).  It
therefore has generic application, eg ATM/MPLS interworking say.