The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
>Sent: Monday, June 05, 2000 4:28 AM
>To: EGray@zaffire.com; swtan@mmu.edu.my; kireeti@juniper.net;
>dwilder@baynetworks.com; Shahram_Davari@pmc-sierra.com
>Cc: mpls@UU.NET
>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:EGray@zaffire.com]
>> Sent:	Wednesday, May 31, 2000 3:00 AM
>> To:	'Tan Su Wei'; Kireeti Kompella; 
>dwilder@baynetworks.com; Eric Gray;
>> Shahram_Davari@pmc-sierra.com
>> Cc:	mpls@UU.NET
>> 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:swtan@mmu.edu.my]
>> > Sent: Monday, May 29, 2000 7:33 PM
>> > To: Kireeti Kompella; dwilder@baynetworks.com; EGray@zaffire.com;
>> > Shahram_Davari@pmc-sierra.com
>> > Cc: mpls@UU.NET
>> > 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
>> > 
>> > 
>