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

From: "David Allan" <[email-masked]>
Date: Wed, 7 Jun 2000 09:57:27 -0400

Can we bring a bit of discipline to this discussion.

- what problems are we trying to diagnose?
- what functionality do we require to take corrective action (protection
switching, fault sectionalization etc.)
- what mechanisms are required to diagnose the problems?
- what flows are required to propagate knowledge of the problems?
- how can we specify encoding those flows?

We know the last item in the list is a problem, but lets not solve it first.
We seem to agree it needs solving, I see lots of suggestions to populate the
toolbox.

Neil has mentioned a number of interesting issues as far as defects are
concerned (a combined list would include):
- segment or span failure,
- segment or span degredation,
- nodal failure,
- topology failure (misdirected end point or routing loop),
each of which may require a specific tool to diagnose.

There's at least two aspects to the functionality:
- fault detection and sectionalization
- propagation of knowledge of a defect to the nodes which require knowledge
of the defect

And some interesting twists to consider such as:
- assymetrical defects (one direction of a link fails)
- partial tree failure
- timliness of defect detection

Feel free to add or subtract from this list, maybe we can get a useful
concensus view. There's really nothing new here, the sandbox is different.

cheers
Dave

> -----Original Message-----
> From:	Indra.Widjaja [SMTP:[email-masked]]
> Sent:	Tuesday, June 06, 2000 2:32 PM
> To:	Ben Mack-Crane
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject:	Re: OAM labels (was: can egress know the ingress of a
> packet?)
> 
> 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.
> 
> >
> >
> > 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.
> 
> >
> >
> > 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.
> 
> >
> >
> > 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).
> 
> >
> >
> > 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.
> 
> >
> >
> > 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
> >
> > [email-masked] 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:[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: Manshaee Mohammad-Hossein <[email-masked]>
Date: Wed, 7 Jun 2000 20:06:15 +0430 (IRST)

Hi,

First I must say that I start studying MPLS and If you see that my
questions are cheap! pardon!

but my question:

about ATM and MPLS: I want to know that where is the place of Label
in ATM cells.

If we put them on VPI/VCI the length of Labels and VPI/VCI aren't same!

and if you put labels like IP packets we have problem in ATM switch.
I mean page 28 in "Multiprotocol Label Switching Architecture"

yours,

MH Manshaei

---

From: Florian-Daniel Otel <[email-masked]>
Date: Wed, 7 Jun 2000 17:45:16 +0200 (MEST)

> [1  <text/plain; iso-8859-1 (7bit)>]

> - how can we specify encoding those flows?

Well, I'll add only one more mail to these threads re-iterating what me
Thomas, Neil and others already said:

Is it possible that we consider this (i.e. OAM functionality) in
the light of:
	-Existing drafts for protection/restoration/loop prevention
	-ping/traceroute for MPLS
	-ICMP  and MPLS-ICMP
	-other expressed OAM needs

While i see quite a bit of overlapping IMHO I think we can tie
everything up and address all these issues in  a consistent manner. It 
would be a really nice way to clean this OAM slate and have everything
addressed in a consistent manner. The only thing that needs to be done
is to gather all the ideas under one frame. AFAICT there are enough
ideas already expressed to be a critical mass...

Just my $0.02 worth.

Regards,

Florian.

---

From: "Indra.Widjaja" <[email-masked]>
Date: Wed, 07 Jun 2000 16:50:31 -0400

I agree with Dave that the problem can be approached more
systematically by identifying the requirements/issues first.
I don't think the encoding thread was started intentionally, but
more because it just popped up and led to interesting discusssions.
Maybe we can get back to the general issues now.
indra