Subject: RE: can egress know the ingress of a packet?

From: [email-masked]
Date: Mon, 5 Jun 2000 09:27:31 +0100

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: [email-masked]
Date: Mon, 5 Jun 2000 22:42:36 +0100

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