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

From: Theimer Thomas <[email-masked]>
Date: Mon, 5 Jun 2000 16:24:53 +0200

Actually, you may want to consider the router alert label as defined in the
label encapsulation document as follows:

There are several reserved label values:

              i. A value of 0 represents the "IPv4 Explicit NULL Label".
                 This label value is only legal when it is the sole
                 label stack entry.  It indicates that the label stack
                 must be popped, and the forwarding of the packet must
                 then be based on the IPv4 header.

             ii. A value of 1 represents the "Router Alert Label".  This
                 label value is legal anywhere in the label stack except
                 at the bottom.  When a received packet contains this
                 label value at the top of the label stack, it is
                 delivered to a local software module for processing.
                 The actual forwarding of the packet is determined by
                 the label beneath it in the stack.  However, if the
                 packet is forwarded further, the Router Alert Label
                 should be pushed back onto the label stack before
                 forwarding.  The use of this label is analogous to the
                 use of the "Router Alert Option" in IP packets [6].
                 Since this label cannot occur at the bottom of the
                 stack, it is not associated with a particular network
                 layer protocol.

You could use the router alert label to mark OAM packets. I am not sure if
this is compatible with
current implementations using the router alert label. So you may want to
define another OAM
alert label for marking OAM packets. Another issue is to work around the
uni-directional nature 
of LSPs which is not well suited for OAM. 

Some people may also be concerned how this maps to ATM LSRs.

Thomas Theimer
> -----Original Message-----
> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Monday, June 05, 2000 3:51 PM
> To:	[email-masked]'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Shahram Davari
> Cc:	[email-masked]
> Subject:	RE: can egress know the ingress of a packet?
> 
> Hi Neil,
> 
> I also think we need some sort of OAM function at MPLS layer. And as you
> said, to be able to process OAM cells, they must be recognized by LSRs.
> But
> it might be hard to change the definition of TTL field at this point in
> time. So I have a different proposal. Why don't we assign/reserve some
> Label
> values to be used only by OAM packets. This is very analogous to ATM, in
> which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
> =0-15).
> For example we could assign Label = 0 for the Keepalive messages that you
> described.
> 
> I am interested in writing such an I-D, and in fact my company is expert
> in
> ATM OAM, so we could leverage that knowledge for the MPLS OAM.
> 
> Regards,
> Shahram Davari
> Product Research
> PMC-Sierra, Inc. (Ottawa) 
> 555 Legget drive,
> Suit 834, Tower B,
> Ottawa, ON K2K 2X3, Canada
> Phone: +1 (613) 271-4018
> Fax  : +1 (613) 271-7007
>     
>  
> 
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >Sent: Monday, June 05, 2000 4:28 AM
> >To: [email-masked]; [email-masked]; [email-masked];
> >[email-masked]; [email-masked]
> >Cc: [email-masked]
> >Subject: RE: can egress know the ingress of a packet?
> >
> >
> >Here's one reason why a network operator might want to know the LSP
> >source..................
> >
> >IP addresses must be absolute since a CNLS forwarding regime 
> >is 'memoryless'
> >on a link by link basis.  Further, when used in the Internet 
> >the absolute
> >addresses must also be globally unique (or in the case of 
> >private internets,
> >private-network-wide unique). 
> >
> >Compare this now to label forwarding.  This requires an a priori set of
> >user-plane connections (not necessarily BW reservations) to be 
> >set up, ie
> >LSPs, as determined by the FEC/IGP control-plane for the basic 
> >LDP case, or
> >via some other route determination method outside the IGP for 
> >a TE case say.
> >Labels are relative addresses that by definition are not 
> >globally unique,
> >and indeed they only need to be unique per interface on a link basis.
> >
> >With absolute addresses sent in some form of temporally deterministic
> >keepalive one can detect/diagnose all cases of connectivity defects, eg
> >breaks, swappped connections, mismerging between different 
> >connections, self
> >mismerging (aka looping).  So the IP layer is OK in handling 
> >these defects
> >to a large extent (there are some subtle issues of control-plane vs
> >user-plane defect detection and the span of the defect 
> >detection mechanisim,
> >which I don't want to get into here as they are 2nd order to the main
> >point).
> >
> >The handing of all of these types of connectivity defect is 
> >not clear in
> >MPLS.  We do, however, have the TTL field in the MPLS OH, but 
> >this not a
> >defect detection/diagnosis tool but rather a "damage 
> >limitation mechanism".
> >Further, it is relevant only for the specific case of self 
> >mismerged LSPs in
> >the MPLS layer (*not* the IP layer please note).  So currently 
> >we have no
> >method for a network operator to detect/diagnose connectivity 
> >failures which
> >could, for example, result in one customer's traffic being 
> >mismerged into
> >another customer's traffic.  I would argue that this should be 
> >of concern to
> >those developing MPLS and those planning to use it.
> >
> >It would seem that we need some form of 'Connectivity Verification'
> >keepalive that contains an absolute LSP source address, and 
> >which is was
> >sent periodically from the source of an LSP to its sink.  This 
> >would allow
> >all the types of connectivity defect to be detected and diagnosed by an
> >operator.  [There are also issues regarding consequent actions, and in
> >particular the downstream/upstream indication of defects that 
> >need to be
> >considered, eg for correct QoS/availability SLA measurement 
> >and correctly
> >targeted protection switching, especially in the case of nested LSPs.
> >Further, how such functions are processed at the LSP sink 
> >points is a matter
> >for local consideration wrt the importance of the LSP's traffic being
> >monitored/protected.]
> >
> >Assuming we agreed on the above, then the problem we face is 
> >that there is
> >currently no method of identifying such a Connectivity Verification
> >keepalive pkt from within the normal user-plane traffic.  One possible
> >solution could be based on reducing TTL field from 8 to 7 bits 
> >(this would
> >still seem more than adequate) and use the 1 bit now spare as 
> >an indicator
> >that the next MPLS pkt was either normal user-plane data or a 
> >Connectivity
> >Verification pkt.
> >
> >So.......to go back to the question that started this thread........one
> >reason an operator might want to know the source of an LSP is 
> >to protect its
> >customer's traffic from being incorrectly delivered (or 
> >interfered with) due
> >to network-based defects occuring in either the MPLS user-plane or
> >control-plane.  And in any case, operators will want some method of
> >detecting/diagnosing/correcting such defects.
> >
> >In past mail exchanges (most off-line) I know some people are 
> >starting to
> >think about the OAM-type functions I am alluding to above (eg people
> >studying protection switching of LSPs, and especially those 
> >routed outside
> >the IGP).  Indeed, I am tempted to write a draft ID for 
> >consideration which
> >we can then hack about and decide whether to pursue or not.  
> >However, before
> >I do so I would like to feel (i) there is sufficient support 
> >for such work
> >within the IETF MPLS community and (ii) that 'stealing' one of 
> >the TTL bits
> >from the MPLS OH would be OK.  Can I have some views please?
> >
> >Regards, Neil
> >
> >> -----Original Message-----
> >> From:	Eric Gray [SMTP:[email-masked]]
> >> Sent:	Wednesday, May 31, 2000 3:00 AM
> >> To:	'Tan Su Wei'; Kireeti Kompella; 
> >[email-masked]; Eric Gray;
> >> [email-masked]
> >> Cc:	[email-masked]
> >> Subject:	RE: can egress know the ingress of a packet?
> >> 
> >> Tan,
> >> 
> >> 	No information is added to the IP header to
> >> aid in determining what LSP it is to be propagated
> >> on except for the MPLS label (which is prepended as
> >> part of the MPLS stack and is not part of the IP
> >> header).  When the last useful label is removed from 
> >> a data packet (either by popping it or by using an
> >> explicit NULL label), there is no longer any way to 
> >> positively identify the LSP that it was forwarded on.
> >> 
> >> 	I had the impression - because of the way that
> >> you asked your question - that you were trying to 
> >> find out how LSP information might be inferred from
> >> the label on a packet.  Again, (and as Kireeti already
> >> pointed out) it cannot be easily inferred from the IP
> >> packet once all useful label information is gone.  I
> >> doubt that it can be determined absolutely at that 
> >> point through much less than magic.
> >> 
> >> --
> >> Eric Gray
> >> 
> >> > -----Original Message-----
> >> > From: Tan Su Wei [mailto:[email-masked]]
> >> > Sent: Monday, May 29, 2000 7:33 PM
> >> > To: Kireeti Kompella; [email-masked]; [email-masked];
> >> > [email-masked]
> >> > Cc: [email-masked]
> >> > Subject: Re: can egress know the ingress of a packet?
> >> > 
> >> > 
> >> > Dear All,
> >> >     Thanks for answering my question.
> >> > As Kireeti wrote:
> >> >     > Perhaps we've gone off on an tangent here.  The question
> >> >     > as I understood it is "when a *data* packet arrives at
> >> >     > the egress, can we know which ingress and which LSP it
> >> >     > travelled on?" -- and the answer is, not without some
> >> >     > extracurricular work.
> >> >     >
> >> >     > Tan, can you clarify your question?
> >> > 
> >> > and my question is exactly as above. I'm sorry if there is any
> >> > misunderstanding.
> >> > For the posted answer from Mr. Eric Gray
> >> > 
> >> >     It is possible to know the LSP traversed, only if
> >> >     the LSP is "identified".  This is possible with either
> >> >     CR-LDP (using LSP-ID) or RSVP-TE (using SESSION).
> >> > 
> >> > Lets if the LSP is "identified" using either lspid or session 
> >> > object (during
> >> > the LSP setup time, right?) , to know the lsp and ingress the 
> >> > *data* packet
> >> > from, is that mean we need adding a field in the data 
> >packet on this
> >> > information? (Maybe ip header option field?).
> >> > Since information get from the incoming label and 
> >interface might be
> >> > incorrect when there is LSP merge.
> >> > Is my interpretation correct?
> >> > 
> >> >     Thank you for your reply.
> >> > 
> >> > Regards
> >> > Tan Su Wei
> >> > 
> >> > 
> >

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 Jun 2000 08:00:24 -0700

Hi Thomas,

Good observation. Actually at the end of the label encapsulation document it
is mentioned that label values between 4-15 are reserved for future use,
which can be leveraged for these kind of operations.

Regards,
-Shahram 

>From: Theimer Thomas [mailto:[email-masked]]
>Sent: Monday, June 05, 2000 10:25 AM
>To: 'Shahram Davari'; [email-masked]'
>Cc: [email-masked]
>Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
>
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 5 Jun 2000 10:43:44 -0700

Hi,

This looks like a good solution.

-Shahram

>From: Peter Willis [mailto:[email-masked]]
>Sent: Monday, June 05, 2000 12:55 PM
>To: Shahram Davari
>Cc: [email-masked]
>Subject: Re: OAM labels (was: can egress know the ingress of a 
>packet?) 
>
>
>> Peter,
>> 
>> Sometimes OAM packets may need to be processed by 
>intermediate nodes as
>> well. By having the top label to be the forwarding label for 
>OAM packets, we
>> are forced to processing them only at the egress node.
>
>	OK can we do both? For most OAM functions I'm only interested in
>	OAM processing at the edge. Besides which if we require 
>intermediate
>	LSRs to process all OAM then this will not scale. However I do
>	admit in some circumstances I may like an intermediate node
>	to do something e.g. a LSP traceroute function.
>
>	Its just from experience I know that if the OAM/test 
>tools available
>	use packets that are not treated the same as the users 
>data packets
>	then the results are often doubtful (for example see 
>the misleading
>	results caused by using ping).
>> 
>> BTW, if the second label is OAM label, I don't think it will 
>cause any
>> implementation problem. Because the egress node before 
>popping the top
>> label, by looking at the S bit, knows that there is still 
>another label.
>
>	I was more thinking along the lines of; pop the outer label,
>	find its an OAM label, NOW I need to know the outer label to
>	process the OAM packet correctly but I've already used it and
>	lost it! 
>
>	Setting the S bit could also cause a minor problem. Presumably
>	the S bit in the user data label will be set but not in the
>	OAM data outer label. Hence if we have an implementation bug to
>	do with the operation of the S bit it would not be detected by
>	the OAM.
>
>Peter.
>> 
>> 
>> Regards,
>> -Shahram
>> 
>> >From: Peter Willis [mailto:[email-masked]]
>> >Sent: Monday, June 05, 2000 12:27 PM
>> >To: Shahram Davari
>> >Cc: [email-masked]
>> >Subject: Re: OAM labels (was: can egress know the ingress of a 
>> >packet?) 
>> >
>> >
>> >Shahram,
>> >
>> > Wouldn't it be better to have the top label
>> >as the one that is used for forwarding the OAM & user data and 
>> >the second 
>> >label the one that identifies an OAM flow within a particular 
>> >LSP? This way 
>> >the OAM
>> >data gets treated exactly the same as the user data by the 
>> >non-edge LSRs.
>> >Obviously the problem with this approach is that the 
>> >terminating LSR does not
>> >know it has an OAM packet until it has popped the outer label; 
>> >this may cause
>> >implementation problems (Does it?).
>> >
>> >If the OAM data is treated differently from the user data then 
>> >any faults in
>> >the user data plane may not be detected correctly. The 
>trouble with the
>> >Route Alert Label =1 type approach is that it is effectively 
>> >out-of-band;
>> >LSRs will treat this differently from user data which is not 
>> >what we want.
>> >
>> >Peter.
>> >
>> >> 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  
>> >> 
>> >> >From: Peter Willis [mailto:[email-masked]]
>> >> >Sent: Monday, June 05, 2000 11:37 AM
>> >> >To: [email-masked]
>> >> >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: Theimer Thomas <[email-masked]>
Date: Wed, 7 Jun 2000 11:09:48 +0200

> From:	Ross Callon [SMTP:[email-masked]]
> To:	Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
> 
> 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.
	[Theimer Thomas]  Good point. We missed that. However, if the
penultimate hop removes the top label, the egress node will receive the
packet with an OAM label on top. That would still trigger OAM processing in
the egress node, so I don't necessarily see a problem here, except that
perhaps the egress node needs to be an LSR. If not, then in my view the
penultimate hop is really the logical endpoint of the LSP, and should
process the OAM label if present. However, I must admit I don't clearly
understand how penultimate hop popping is really applied in a network. I
also could not find any explicit support in LDP, CR-LDP and TE-RSVP. Without
such support, is anyone actually using that mechanism in practice ?

	Thomas

---

From: Nhat Thanh Hoang <[email-masked]>
Date: Wed, 7 Jun 2000 13:52:00 +0200

Hi,

Penultimate hop does use in MPLS VPN context according to Cisco's
implementation, but they use TDP instead of LDP.  (Correct me if I'm wrong.)

/Nhat Thanh

Telia Research

-----Original Message-----
From: Theimer Thomas [mailto:[email-masked]]
Sent: den 7 juni 2000 11:10
To: 'Ross Callon'
Cc: [email-masked]
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)

	Thomas

---

From: Theimer Thomas <[email-masked]>
Date: Wed, 7 Jun 2000 16:35:18 +0200

> To:	'Theimer Thomas'; 'Ross Callon'
> Theimer,
> 
> I think what Ross meant was that using PHP, when OAM label is below the
> forwarding label, the egress node can't determine the LSP that the OAM
> packet belongs to.
	[Theimer Thomas]  OK, thanks for the clarification.
	In this case the label stack at the egress does not identify the LSP
anymore.
	That means, one would have to insert something like an LSPID into
the
	the OAM packet payload to allow for such identification. That may be
	useful anyway to detect misinserted packets.
	The basic purpose of an OAM label - to get the packet directed to an
OAM
	process at a certain LSR - should not be defeated by PHP.

	Regards,

	Thomas

---

From: "Mancour, Tim" <[email-masked]>
Date: Wed, 7 Jun 2000 10:35:01 -0400

Tom,

I understand the intent, but the idea of processing a label which is under
the top label seems to be in violation to the section 3.9 of the MPLS
architecture draft which states:

	Although, as we shall see, MPLS supports a hierarchy, the processing
      of a labeled packet is completely independent of the level of
      hierarchy.  The processing is always based on the top label, without
      regard for the possibility that some number of other labels may have
      been "above it" in the past, or that some number of other labels may
      be below it at present.

If we proceed down this path then this type of label processing behavior
should be clearly reflected in the MPLS architecture.

TimM

-----Original Message-----
From: Theimer Thomas [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 5:10 AM
To: 'Ross Callon'
Cc: [email-masked]
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)

	Thomas

---

From: [email-masked]
Date: Wed, 7 Jun 2000 16:47:58 +0100

Hi Ben,

Before we define the 'modes' (as you refer to them Ben), I think it
important first to define why we want these modes.  I largely see the key
needs of OAM as:
-	making sure all  potential defect conditions can be detected and the
appropriate consequent actions taken
-	making sure customer traffic is not sent to the wrong place, ie 1st
level of security
-	making sure alarms are only raised in the appropriate place and that
operational staff get simple but adequate diagnostic tools
-	making sure protection-sw occurs in the appropriate place
-	making sure that if there are availability SLAs and QoS SLAs in
place we can measure them......noting that QoS metrics are really only valid
if the entity being considered is in the 'up-state' (which we need to define
1st)

Beyond this we have 'nice to have but not essential' functions.  In
particular, this is where I would place doing things like sampling the
network with 'probes' to give some network-wide statistical characterisation
of specific QoS parameters, eg errors pkts, abs/var on delay, etc.  One can
incur large processing costs if you aim to to detailed QoS metric collection
on a continuous basis network-wide, cf the PM cell in ATM.  A route trace
OAM function would also fall into the nice to have category.

I penned the following 'OAM principles' some time ago and then aimed to
define a min set of OAM functions that I thought we might need from MPLS to
satisfy them:

Layer independence:	Each layer network must have its own OAM
functionality to detect failures and abnormal performance that is not
dependent on a specific server or client layer technology.  This is critical
to ensure that layer networks can evolve (or be removed) without impacting
other layer networks.

End-to-end (E2E) and per domain monitoring capability:	It should be
possible to simultaneously measure the E2E and per domain (a specific case
of subnetwork partitioning) performance of trails.
Note - A key point about performance metrics (such as errored-PDUs,
lost-PDUs, PDU temporal arrival variance, etc) is that they are only
relevant when the connection is in the Available State.  Therefore,
connectivity status is the primary in-service metric that must be identified
at all times.

Defects:	All the major defect conditions that can affect trails must
be identified with in-service measurable entry and exit criteria, and all
consequent actions specified.  If possible, the entry and exit criteria
should be temporally harmonised as far as possible to simplify state
processing at trail termination points.  Attention should be paid to
relating the defect entry/exit criteria to 'short-breaks', which are
generally accepted as 3-9s periods of gross signal disturbance from which
the network may self-recover.  If the event lasts for >=10s this is the
normally accepted threshold for entering the Unavailable State - see next
item.

Availability:	The most important performance metric of a trail (or a
subnetwork partition thereof) is availability.  It is therefore critical to
define the entry and exit criteria for the Unavailable/Available State and
understand how these relate to the stopping/starting of the aggregation of
available state performance metrics such as PDU loss (noting that this may
be effectively applied at an earlier point to preserve the integrity of the
available state metrics, eg after 3s say, which marks the onset of (at
least) a short-break).

Decoupling of user behaviour from connectivity assessment:	It is
critical to remove user traffic behaviour from trail connectivity
assessment.  In practical terms, this means decoupling user behaviour from
all defect and (the dependent) available state entry/exit criteria.

Forward and Backward Defect Indicators:	The node in the layer network which
detects a defect (sourced from within that layer) must apply a well-known
Forward Defect Indication (FDI).  In the majority of current WAN
technologies such a signal has been termed AIS (Alarm Indication Signal).
At the trail termination point (or, if applicable, any subnetwork
termination point) the FDI signal must (i) create a complimentary Backward
Defect Indication (BDI) (which is removed at the upstream trail (or
subnetwork) termination point) and (ii) map the FDI signal from the server
layer to the FDI signal of the client layer(s) as part of the adaptation
process.

The primary purpose of the FDI is to suppress downstream and client layer
alarms (so that there is not an 'alarm explosion' and so Operations
Personnel can correctly target the real defect location source).  Three
secondary purposes of FDI (and indeed BDI) are:
(i) to allow correct processing of available state performance metrics;
(ii) to inform the ultimate end-system/customer applications that the
connection is no longer functioning correctly and to take appropriate
action, eg in the case of voice perhaps mute the speech path;
(iii) provide a user-plane originated trigger mechanism for
protection-switching purposes (maybe via control-plane functionality).  Note
that correctly targeted protection-switching in the context of nested MPLS
LSPs requires special attention.

From the preceding we should note that, if possible, the FDI/BDI signals
should provide information on the defect location and type (such information
is very useful to the lead operator for many reasons).

Connectivity verification:	A key characteristic of layer networks is
that they must have their own (within layer) globally unique addressing
structure that defines the layer network access points.  However, within the
layer network relative addressing may be used (which only has to be unique
per interface) as a mechanism to provide fast route forwarding of PDUs, eg
VPI/VCI of ATM, DLCI of FR, the 'label' of MPLS.

When relative addressing is used there is danger of misbranching defects.
These cover a variety of connectivity failures, including simple loss of
connectivity, swapped connections, unintended mismerging, self-mismerging
(ie routing loops), etc.  Unless detected and corrected, the consequence of
such defects can be very severe for an operator, ranging from simple SLA
availability violation through to more serious security, censorship and
misbilling implications.  The diagnosis (eg detection and location) of such
failures is difficult unless a globally unique trail source address is
periodically transmitted to detect these failures.

Customers should not be used as defect detectors:		Wherever
possible, the OAM tools should not require that customers have to act as
failure detectors.

OAM functionality under fault conditions:	Under fault conditions a
layer network cannot be expected to behave in a predictable manner.
Therefore care should be exercised when specifying and using OAM tools that
require a reliable layer network to function in a predicable manner for
fault diagnosis.

Against these principles I identified these minimal set of OAM
pkt/functions:

1	A Connectivity Verification (CV) pkt.  This would contain the
absolute source address of the LSP and be sent periodically from LSP
source->sink.  This will detect all the various connectivity failures that
could exist.  This would be the workhorse OAM tool, and used for assessing
up/down-states.  It would be used in conjunction with the FDI/BDI described
below.

2	A  CV+P (P=performance) pkt.  This is the same as the above, but
also contains a count of the payload pkts/octets sent from the LSP
source->sink between consecutive CV+P pkts....to simply allow a 1st level
assessment of lost traffic.  I would *not* suggest this be used in a
continuous mode (processing cost issue) but in an ad hoc mode for
trouble-shooting.  Note that at mid-LSP points one could passively tap-off
such a CV+P flow for subnetwork partition measurements......and the absolute
LSP source address should make this easier than chasing through the varying
relative label assignments (think of doing this in large and possibly
international networks, say at some NNIs).

3	Forward and Backward Defect Indicators (FDI/BDI).  These essentially
'come on' when the CV flow 'goes off'.  CV + FDI can be used together to
diagnose whether a fault lies within an LSP span or not.......useful for
prot-sw and alarm suppression.  They can also contain details of the type of
defect and its location......so that this can aid downstream operational
people in co-operation during fault diagnosis (again very useful in
large/international environments).  FDI goes downstream and the BDI goes
upstream (to tell the source end of downstream faults).

Earlier today I sent those on the list who have expressed an interest in
drafting an OAM ID some further thoughts/analysis of how the above would
work in a nested LSP environment, based on the use of special OAM labels in
a dual-stacked manner.......since I know there is great reluctance to change
any of the current MPLS header structure to provide a specific 'OAM payload
idetifier' field.  I think maybe that the group of people who have expressed
an interest in this work should perhaps take this subject off-line now until
we have better agreements and more mature proposals to put before the rest.

Regards, Neil

> From:	Ben Mack-Crane [SMTP:[email-masked]]
> Sent:	Tuesday, June 06, 2000 3:45 PM
> To:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc:	[email-masked]
> 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
> 
> [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
> > > > Sent: Monday, June 05, 2000 5:50 PM
> > > > To:   'Peter Willis'; [email-masked]
> > > > 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
> > > > >to detect faults caused by LSRs using broken label swapping tables.
> > > > >