The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Sharam and thanks for support,

You observed:
	>	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.

Before I looked at the TTL option, this was the basis of what I had
orginally planned.  In my orginal analysis I considered parsing the label
field into a 16 bit true label field and a 4 bit payload ID field.  But if
we assume the client layer protocol is temporally invariant we really don't
need a payload ID.......this is implied at label assignment time.  So 4 bits
is perhaps overkill and just 1 bit would do.  My orginal intention was to
use this codepoint(s) to identify the 1st octet of the payload as an OAM
pkt, and then the 1st octet would specify the specific OAM functionality.

Another option, which is what I think you and Thomas Theimer are suggesting,
is to assign a special OAM 'alert' label.  This seems OK, and the only
downside is that we get 2 stacked labels for each OAM pkt but only 1 label
for the traffic at LSP level N.......but that does not seem such a problem
(as the OAM BW should be kept small anyway).  After such an indentification
mechanism the OAM processing would be as above, ie look at 1st OAM pkt octet
to determine function.

Note - I have extensive experience of ATM OAM and I want to avoid all the
problems that happened with this.  In the work I have looked at for MPLS,
the OAM functions are pared to the absolute minmimum whilst delivering
maximum benefit.  I would need to show you my work though to explain better.

Many thanks for offer to help with drafting (are you any good at state
diagrams in ASCII?!!!).  

Regards, Neil