The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

On Mon, 2002-04-15 at 08:31, neil.2.harrison@bt.com wrote:
[snip]
> A key behavioural tenet of the defect detection/handling OAM CV pkt, is that
> it must be treated as normal traffic and is therefore only ever relevant to
> the LSP source/sink points.....it is completely transparent to intermediate
> LSRs.  This is nothing unusual, but normal/required behaviour in layered
> networks.  And each LSP is independent in this respect, ie 1 or more LSPs
> can form a client=>server relationship with a lower level LSP, thus each LSP
> has its own independent CV flow.
> 
> This is achieved by adding a (lower) extra labelled header to the normal
> traffic on an LSP when a CV pkt is sent.  The key differences (from normal
> traffic) are:
> -	S bit is now only set on OAM alert labelled header
> -	OAM alert labelled header carries globally unique label (14 is
> suggested) to identify the payload as an OAM pkt.....this is what was
> discussed on the list over 12 months ago now, and seemed the only
> non-contentious solution to the problem of not having a PID field in the
> MPLS header.

which means that intermediate LSRs that use a hash to load balance MPLS
traffic over equal cost links/paths have to be careful to exclude the S
bit from any hash.

I'm not sure that this is the case for all current implementations...

In fact this also would seem to imply that you have to hash over a fixed
number of labels (to ensure that both the OAM traffic and the user
traffic get the same hash value).  This coarsens the load balancing
granularity somewhat :(

The alternatives would be either to preclude hashed load-balancing or to
require OAM-aware core LSRs.  Neither of these options is acceptable
IMO.

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================