Re: [mpls-tp] Alarm Reporting (aka AIS)

[maarten vissers <[e-mail]>]

Sasha,

It is not only AIS (including the LDI flag) that needs this context information. LKR is the other maintenance signal that requires it. See draft-ietf-mpls-tp-fault-03.txt.

-----

The text in section 3 of RFC5331 lists a couple of context-specific 
label space examples and ends with the following notion:

   There may be other sorts of contexts as well.  For instance, we
   define the notion of an MPLS label being used to establish a context,
   i.e., identify a label space.  A "context label" is one that
   identifies a label table in which the label immediately below the
   context label should be looked up.

RFC 5331 is as such open to other context-specific label spaces.

An example of such other context-specific label space is a MPLS-TP
Section and a MPLS-TP transport-LSP. Other examples could be Working 
and Protection SPME-LSPs. 

As RFC 5331 (August 2008) has been developed prior to MPLS-TP OAM, 
this OAM application of context-specific label spaces is not included; 
it will have to be included in one of the MPLS-TP RFCs; e.g. in 
draft-ietf-mpls-tp-fault-03.txt as the mechanisms in this draft 
require this context-specific label space information.

Such MPLS-TP Section and transport-LSP context-specific label spaces 
do not need to use upstream-allocated labels. P2P Sections and P2P 
transport-LSPs can use context-specific label spaces with 
downstream-allocated labels. P2MP transport-LSPs must use 
context-specific label spaces with upstream-allocated labels.

Regards,
Maarten

> -----Original Message-----
> From: Alexander Vainshtein [mailto:[e-mail]]
> Sent: 11 December 2010 20:11
> To: maarten vissers
> Cc: [e-mail]
> Subject: RE: [mpls-tp] Alarm Reporting (aka AIS)
> 
> Maarten,
> Lots of thanks for a proposing a very creative solution to the problem.
> 
> The down side of your proposal is that it requires somebody to insert
> context labels where none are used today (and indeed, none are
> required) - just for the sake of being able to insert the AIS
> correctly.
> 
> Please note also that 5331 only applies to upstream allocated labels,
> and there are certain restrictions associated with their usage. As a
> minimum, they require a different Ethertype (or Protocol number).
> 
> Do you imply that MPLS-TP must only use upstream-allocated labels?
> 
> Regards,
>      Sasha
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: maarten vissers [[e-mail]]
> Sent: Friday, December 10, 2010 3:15 PM
> To: Alexander Vainshtein
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
> 
> 
> Sasha,
> 
> LSP-AIS is to be inserted under signal fail conditions when the LSP
> does not terminate and the LSP label is swapped from A  to B. LSP-AIS
> is to be inserted with this registered label value B.
> 
> PW-AIS is to be inserted under signal fail conditions when the PW does
> not terminate and the PW label is swapped from C  to D. PW-AIS is to be
> inserted with this registered label value D.
> 
> When a LSP label is popped, the next function is an LSP MEP. For this
> case it is not necessary to insert the LSP-AIS packet as it would be
> terminated immediately in that LSP MEP; instead the server signal fail
> condition is forwarded from the adaptation sink to the MEP sink via the
> SSF signal. It is equipment specific how this SSF is implemented.
> 
> When a PW label is popped, the next function is a PW MEP. For this case
> it is not necessary to insert the PW-AIS packet as it would be
> terminated immediately in that PW MEP; instead the server signal fail
> condition is forwarded from the adaptation sink to the MEP sink via the
> SSF signal. It is equipment specific how this SSF is implemented.
> 
> When an LSP is terminated, its LSP MEP will be able to detect if there
> is a SF condition. For such case, the client LSP and/or PW and/or VLAN
> signals passing through this LSP MEP have LSP/PW labels that will be
> swapped. For the case of client VLANs (i.e. HVPLS), ETH-AIS for each of
> those VLANs is to be inserted. For the case of client LSPs or PWs,
> client LSP-AIS or PW-AIS should be inserted. As this will be a subset
> of the LSP, PW and/or VLAN signals passed through an input port, I
> understand from your email that today's MPLS NNI port designs do not
> have the ability to identify such subsets. Correct? Such subsets of
> LSPs, PWs and/or VLANs are missing their context information. This can
> be resolved by using context-specific label spaces, which I find
> defined in RFC5331.
> 
>    An example of such a context is a tunnel over which MPLS packets on
>    LSP1 may be received.  In this case, the top label of the MPLS
>    packet, after tunnel decapsulation, is looked up in a label space
>    that is specific to the root of the tunnel.  This does imply that Lr
>    be able to determine the tunnel over which the packet was received.
>    Therefore, if the tunnel is an MPLS tunnel, penultimate-hop-popping
>    (PHP) MUST be disabled for the tunnel.
> 
> I.e. A transport-LSP is a tunnel over which MPLS-TP LSP, PW and VLAN
> packets may be received. Use of a context-specific label space seems
> the appropriate existing MPLS compliant mechanism to be used. Such
> context specific label space can be much smaller than 1M, such that
> there will be no scalability issue.
> 
> Regards,
> Maarten
> 
> 
> 
> From: Alexander Vainshtein [mailto:[e-mail]]
> Sent: 9 December 2010 11:05
> To: Maarten Vissers
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls-tp] Alarm Reporting (aka AIS)
> 
> Maarten,
> One brief comment that you probably have heard quite a few times from
> me.
> 
> You have said in your response to Andy Reid:
> The adaptation sink functions in the transport network technologies not
> only "can know" this information, they actually "do know" this
> information.
> The problem with MPLS-TP is that, as long as its data plane is aligned
> with that of MPLS (and it is!) its analog of the "adaptation sink
> function", namely the ILM entry with the "Pop and Loop" action on a
> specific label do not have this information. I.e., when MPLS pops a
> label, it can handle both labeled and unlabeled packets that result
> from this action. When the resulting packet is labeled, handling of the
> next label does not depend on the previous one.
> And of course handling unlabeled packets (IP as an immediate client of
> an MPLS-TP LSP) is just as possible and, IMHO, just as relevant...
> 
> After writing this, I think (and I apologize that I've only noticed it
> that late), that IP as an MPLS-TP client that does not have any AIS is
> a great counter-example to AIS into the clients...
> 
> Regards,
>      Sasha