The MPLS WG Archive

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Hello,

I have been thinking about OAM packet identification and I
think this evolving proposal looks promising.

There are several possible processing modes for OAM packets,
and I am interested in your thoughts on (a) which are needed, 
and (b) which can be supported by the current proposal.

For the sake of discussion I have given them numbers (with no
particular significance) and included my initial thoughts.

Mode 1: 
Packet transparently forwarded along user packet data path

This mode is needed for end-to-end OAM funcitons that depend
on following the user packet data path exactly (e.g., delay
measurement, as Indra mentioned, and path continuity tests).

Mode 2:
Packet transparently forwarded along user data path and also
passed to OAM processing (monitoring)

This mode can be easily combined with Mode 1, and is useful
for isolating faults and monitoring subnetwork connections.

Mode 3:
Packet forwarded to OAM processing, then forwarded along next
hop of user packet data path (possibly not following user packet
data path at all points within the LSR)

This mode may be useful for OAM packets that do not need to 
follow the user data path exactly within the LSR, need more 
flexible processing (i.e. are more suited to SW than HW 
processing), and are not too frequent.

Mode 4:
Packet forwarded to OAM processing and terminated

This is the common mode for termination points (LSP endpoints)
and segment endpoints (if segment OAM is supported).  The 
difficulty in the segment case is distinguishing which OAM
packets to terminate and which to pass if Mode 1 or 2 OAM packets
are also in use.  (Obviously Modes 3 and 4 can easily be combined.)

Mode 5:
Packet forwarded to previous hop on user packet data path 
(forwarding OAM packets following LSP upstream)

Same as Mode 1, but upstream so there is no "user packet data path"
per se.  This might be useful for end-to-end OAM funcitons that
require two way communication (are there any?) or funcitons
that require rapid communicaiton upstream (e.g., fault indication for
rapid protection switching).

Mode 6:
Packet forwarded to previous hop on user packet data path and also
passed to OAM processing (monitoring upstream OAM)

Same as mode 2, but upstream (do we detect a pattern here?).
As before, easily combined with Mode 5.  Might be good for subnetwork
connection protection switching, as long as the fault indication
does not cause any trouble passing further upstream.

Mode 7:
Packet forwarded to OAM processing, then forwarded to previous hop
on user packet data path

Same as Mode 3, but upstream.  Another option for upstream OAM
communication, possibly slower than Mode 5 or 6.

Mode 8:
Packet forwarded to AOM processing and terminated (upstream direction)

Same as Mode 4, but upstream.


Regarding OAM packet identification, it seems reasonable to use the
user packet label on top for Modes 1 and 2 so the packet will follow
the user data path downstream.  Mode 2 could rely on looking for a
reserved OAM label next on the stack.  Modes 3 and 4 are easily
supported with a reserved OAM label on top, or at the LSP endpoint
where the user packet label is popped anyway (though it might need
to be preserved as Peter mentioned).  However, supporting Modes 3 
or 4 at points within the path when the user label is on top is a 
problem (how to decide to forward only to OAM processing and not along
user packet path -- Indra: Is this the point you were making?)

In the upstream modes, the user label is not defined for forwarding
so perhaps this can always be done with an OAM reserved label on top.

So...  What do you think about this?  Can we identify a subset of
modes that are necessary and sufficient, or is it simpler to define
an OAM packet identification scheme that supports all of them and 
let folks decide later which mode to use in a particular OAM 
application?

Regards,
Ben Mack-Crane

Indra.Widjaja@tddny.fujitsu.com wrote:
> 
> Thomas:
> I think both end-to-end and hop-by-hop OAM packets as you mentioned
> below should be supported.
> A third possible way is segment OAM packets where you still want the
> OAM packets to be treated the same way as data packets in the
> segment connection. I believe this can be realized by using the first
> approach plus a dedicated OAM bit. Is there a requirement for this?
> indra
> 
> Theimer Thomas wrote:
> 
> > Actually, there are at least two ways to use such a reserved OAM label:
> >
> > - end-end OAM packets would have a label stack where the reserved
> >   label is inserted below the original top label. After the top label is
> >   popped at the egress node, the reserved label is processed by
> >   forwarding the packet to OAM handling. Thus, all packets are
> >   forwarded using the original top label. OAM packets are visible
> >   only to ingress and egress nodes, and use exactly the same
> >   path as user packets.
> >
> > - hop-by-hop OAM packets would have the reserved label pushed
> >   on top of the original top label. Each LSR along the LSP would
> >   then recognise the reserved top label, forward the packet to
> >   OAM handling, and then forward the packet using the label
> >   second on the label stack (the original top label).
> >
> > It may simplify things if two different reserved labels are defined
> > for end-end and hop-by-hop OAM packets, if people feel that
> > both are needed. The hop-hop case is really very similar to
> > the router alert label.
> >
> > A dedicated OAM header bit would serve a similar purpose, but is
> > not strictly required.
> >
> > Regards,
> >
> > Thomas Theimer
> > > -----Original Message-----
> > > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > > Sent: Monday, June 05, 2000 5:50 PM
> > > To:   'Peter Willis'; mpls@UU.NET
> > > Subject:      RE: OAM labels (was: can egress know the ingress of a
> > > packet?)
> > >
> > > Peter,
> > >
> > > But we can use two labels. The top label can be the reserved one, and the
> > > second label can be the actual label, which is used for forwarding the OAM
> > > packet. This is basically similar to the Router Alert Label = 1.
> > >
> > > Regards,
> > > -Shahram
> > >
> > > >-----Original Message-----
> > > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > > >Sent: Monday, June 05, 2000 11:37 AM
> > > >To: mpls@UU.NET
> > > >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> > > >
> > > >
> > > >
> > > >An LSR will be terminating many LSPs so will be terminating
> > > >many OAM flows.
> > > >How do you correctly diagnose LSPs with merged or corrupted
> > > >labels if they all
> > > >arrive on the same reserved label? The label the OAM flow
> > > >arrives on has to
> > > >match exactly the label used for the data (user plane) flow in
> > > >order to be able
> > > >to detect faults caused by LSRs using broken label swapping tables.
> > > >
> > > >So we need a bit somewhere in the MPLS header to identify an
> > > >OAM payload but
> > > >we need to keep the same label as used for the user plane data.
> > > >
> > > >Peter.
> > > >
> > > >