Subject: RE: OAM labels (was: can egress know the ingress of a packet?)

From: Theimer Thomas <[email-masked]>
Date: Mon, 5 Jun 2000 18:46:26 +0200

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:[email-masked]]
> Sent:	Monday, June 05, 2000 5:50 PM
> To:	'Peter Willis'; [email-masked]
> 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:[email-masked]]
> >Sent: Monday, June 05, 2000 11:37 AM
> >To: [email-masked]
> >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.
> >
> >

---

From: "Indra.Widjaja" <[email-masked]>
Date: Mon, 05 Jun 2000 14:14:47 -0400

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

---

From: Ben Mack-Crane <[email-masked]>
Date: Tue, 06 Jun 2000 09:45:03 -0500

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

---

From: "Indra.Widjaja" <[email-masked]>
Date: Tue, 06 Jun 2000 14:31:55 -0400

Ben:
Please see my comments below.
indra

> measurement, as Indra mentioned, and path continuity tests).

OAM packet is inserted at an ingress LSR and is identified by an
OAM label located at the bottom of the stack. When all user labels
have been popped at an egress LSR, the OAM label directs the
packet to an OAM engine for processing.

> for isolating faults and monitoring subnetwork connections.

Do you assume that monitoring can be done at any intermediate LSR?
If the answer is yes, then since only OAM packets (and not user packets)
are to be selectively monitored, there is a need to identify an OAM packet
based on user label at the top. Therefore there is a need for another
OAM bit in the label stack entry.

> are also in use.  (Obviously Modes 3 and 4 can easily be combined.)

Are OAM packets forwarded hop-by-hop or transparently along the data path?
If forwarding is hop-by-hop, then Mode 3 already takes care of this.
If forwarded along the user data path, then Mode 2 may be able
to take of this case.

> rapid protection switching).

Do you mean: packet forwarded to *the ingress* on user
packet data path rather than to previous hop?
One end-to-end application is for Mode 1 to do forward performance
monitoring, and this mode to do backward performance reporting.
However, I think we can use the same Mode 1 (or Mode 3) in the
backward direction in terms of forwarding OAM packets
(after processing at the egress).

> user packet path -- Indra: Is this the point you were making?)

I was more thinking that in Mode 4, you want to forward OAM packets
along the user data path (if forwarding is hop-by-hop, then Mode 3
already takes care of this case). So the OAM label cannot be on top.
However, Mode 4 is different from Mode 1 in that OAM termination
at any node (including intermediate nodes) is allowed.
It seems that the OAM label can be located at any level between the
bottom (inclusieve) and top (exclusive) of the stack as long as the
OAM path is restricted within the same level of hierarchy.

> let folks decide later which mode to use in a particular OAM

Sounds right.

---

From: Ross Callon <[email-masked]>
Date: Tue, 06 Jun 2000 16:36:50 -0400

>both are needed. The hop-hop case is really very similar to

If the outer header carries the OAM label (and the inner label
carries the real label) then I don't see any problems. The MPLS
forwarding tables can be set up to send the special label to the
"process more carefully" stack.

If the outer label identifies the LSP, and the inner label is a
special OAM value, then I think that there is a problem with
penultimate hop label popping.

Personally I think that penultimate label popping is important
enough that it needs to be preserved.

Ross

---

From: Ben Mack-Crane <[email-masked]>
Date: Wed, 07 Jun 2000 10:45:47 -0500

Hello Indra,

See responses below.  I've tried to clarify some things, but,
as others have pointed out, continuing this discussion might 
wait until we have some agreement on the problems that need 
to be solved.

Regards,
Ben

> packet to an OAM engine for processing.
My description of these Modes may have been unclear -- they are 
essentially defining possible per hop behaviors for OAM packet
handling.  For example, the ingress LSR uses Mode 4 (termination --
actually origination or "termination source"), intervening LSRs
use Mode 1 (transparent) and the egress uses Mode 4 ("termination 
sink").  How these particular modes are tied together along a path
to accomplish some OAM function, and how to determine which mode
to apply to a given OAM packet, is the interesting part.

> OAM bit in the label stack entry.
Right.  This is an example of the problem of identifying how to handle
OAM packets (how to identify, from the packet, whether the packet is OAM and
which OAM processing mode to use).

> If forwarded along the user data path, then Mode 2 may be able
Yes.  As before, these are per hop Modes, so Modes 2 and 3 support looking
at AND forwarding the OAM packet.  Mode 4 removes the OAM packet from the 
network (it does not go beyond this LSR).

> (after processing at the egress).
My intent here was that there be a backward OAM path that follows
the same hops as the LSP, but since LSPs are unidirectional there
is no backward user data path.  Maybe it is better to say "Packet
forwarded to LSP previous hop LSR" so the idea of following the user 
packet data path doesn't confuse things.

> OAM path is restricted within the same level of hierarchy.
For cases where the packet must go to OAM processing regardless, the
OAM label can be on top, but as you point out this is a problem if
we are talking about the entire path of an OAM packet and it must be
passed transparently over some hops (in this case the user data label
must be on top, and some other means of identifying the packet as OAM
must be used when it is to be passed to OAM processing).