The MPLS WG Archive

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

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

Indra.Widjaja@tddny.fujitsu.com wrote:
> 
> Ben:
> Please see my comments below.
> indra
> 
> Ben Mack-Crane wrote:
> 
> > 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).
> 
> 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.
> 
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.

> >
> >
> > 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.
> 
> 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.
> 
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).

> >
> >
> > 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.)
> 
> 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.
> 
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).

> >
> >
> > 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).
> 
> 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).
> 
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.

> >
> >
> > 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?)
> 
> 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.
> 
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).
> >
> >
> > 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?
> 
> Sounds right.
> 
> >
> >
> > 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.
> > > > > >
> > > > > >