Subject: PW switching and OAM

From: [email-masked]
Date: Thu, 14 Oct 2004 12:45:55 +0100

The impact of PW switching on OAM does not seem to have been discussed in
much depth yet, but I think that given where we are with the OAM message
mapping draft, it is worth looking at how this applies in the multi-hop
case.

If by PW switching/stitching we are creating a layer network, then I think
the OAM model should not be any different from a layer network today. That
is, we have clear definitions of segment and and to end OAM on the PW.
However, the OAM tools for PWs e.g. VCCV, assume a single-hop (as noted by
Sasha in a previous email) i.e. effectively a single OAM segment.  What are
the implications of extending these to a multi-hop PW network?

The other question that I have is how to deal with fault alarm propagation
between concatenated single hop PWs. At the moment, we can use either
in-band or out of band  fault notification mechanisms, depending on the PW
type or encapsulation used. draft-martini-pwe3-pw-switching-00.txt says
that one motivation for stitching PWs is to enable ultimate PEs with
different signaling and encapsulation protocols to be connected. While I
agree that this is a good motivation in principle, I think it raises some
questions about how to propagate fault notifications across the stitching
node. For example, take the case of an ATM PW being transported end to end
across two PW domains. In one domain, only static PWs with ATM cell mode
encapsulation are supported. In the other domain, ATM SDU mode is supported
with PW status signalling. Getting fault notifications across the switching
node implies that the node will have to understand ATM AIS/RDI, and
translate this to PW status signalling. This is an extreme example, but I
think it illustrates that there need to be some pragmatic constraints on
the PW types that we stitch e.g. the same OAM mechanisms in each domain.

Best regards,

Matthew

---

From: [email-masked]
Date: Thu, 14 Oct 2004 15:07:49 +0100

Matthew......

[email-masked] wrote 14 October 2004 12:46
 
> 
> The impact of PW switching on OAM does not seem to have been discussed

> in much depth yet, but I think that given where we are with the OAM 
> message mapping draft, it is worth looking at how this applies in the 
> multi-hop case.

> If by PW switching/stitching we are creating a layer network, then I 
> think the OAM model should not be any different from a layer network 
> today. That is, we have clear definitions of segment and and to end 
> OAM on the PW. However, the OAM tools for PWs e.g. VCCV, assume a 
> single-hop (as noted by Sasha in a previous email) i.e. effectively a 
> single OAM segment.
> What are the implications of extending these to a multi-hop 
> PW network?
NH=> I could see this issue coming up right from the outset.  And the
1st thing you need to be clear on is the mnode you are dealing with as
the defects (and OAM required) are different in each case, viz:
-	cl-ps:  breaks only
-	co-cs:  breaks and swaps between *exactly* alike entities
-	co-ps:  breaks, swaps between any entities, and various
mismerging cases

The differences arise because of the nature of the traffic unit on
link-connections.  That is:
-	in cl-ps mode each/every traffic unit naturally carries a CV
function (ie DA)
-	in the co-cs mode the link-connectioons are physical/real (time
or space or freq metric) and the trail BW is quantised/fixed,
-	and in the co-ps mode the link-connection ID are abstract and
the trail BW is variable.

For the co-ps and co-cs modes we must therefore add the missing CV
function.  This is done correctly in SDH (trail-trace field), it's not
done completely correctly in ATM (but close, ie CC is missing source
address) and its not done right at all in FR.  It is done correctly and
the most sparsely in Y.1711 (BTW this spec should apply to any co-ps
technology).  BFD is starting to look a bit like Y.1711 (it has to, the
required CV function forces this) but its still not right.  Why?....

Because to correctly deal with p2mp constructs and to make sure the
required consequent actions are taken at the right place (ie trail sink)
the OAM must be unidirectional and it it must be done in the
data-plane......this applies to both the co-cs and co-ps modes (it does
not however apply to the cl-ps mode).  Note also this is a forced
behaviour in the co-cs mode as the control/management plane is forced to
be OOB wrt the traffic data-plane.  SDH is a great of example of doing
this right, and ATM gets some of this right.....and interestingly enough
folks rely on this fact whether they realise it or not, ie its largely
taken for granted IMO.
> 
> 
> The other question that I have is how to deal with fault alarm 
> propagation between concatenated single hop PWs. At the moment, we can

> use either in-band or out of band  fault notification mechanisms,
NH=> OOB is wrong for CV and FDI functions.  FDI must be sent in the
data-plane in the syntax of the client(s) affected and from the server
trail term point....and this is a recursive requirement over all
affected client layer networks (ie the clients of the initially affected
clients if you follow me).  The BDI function can go OOB as this not a
direct fault-handling function, but merely there to allow single-ended
monitoring of the defect behaviour of both directions.

> depending on the PW type or
> encapsulation used. draft-martini-pwe3-pw-switching-00.txt 
> says that one motivation for stitching PWs is to enable 
> ultimate PEs with different signaling and encapsulation 
> protocols to be connected. While I agree that this is a good 
> motivation in principle, I think it raises some questions 
> about how to propagate fault notifications across the 
> stitching node. For example, take the case of an ATM PW being 
> transported end to end across two PW domains. In one domain, 
> only static PWs with ATM cell mode encapsulation are 
> supported. In the other domain, ATM SDU mode is supported 
> with PW status signalling. Getting fault notifications across 
> the switching node implies that the node will have to 
> understand ATM AIS/RDI, and translate this to PW status 
> signalling. This is an extreme example, but I think it 
> illustrates that there need to be some pragmatic constraints 
> on the PW types that we stitch e.g. the same OAM mechanisms 
> in each domain.
NH=> All these issues are arising because folks are not understanding
the differences between the modal behaviours....you simply can't apply
the same approach in all cases.  I'll send you something off-list that
explains this more completely.

regards, Neil
> 
> Best regards,
> 
> Matthew
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Thu, 14 Oct 2004 15:44:36 +0100

> -	in cl-ps mode each/every traffic unit naturally carries a CV
               ^^
This should obviously be SA.

Apologies....regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 14 October 2004 15:08
> To: [email-masked]; [email-masked]
> Subject: RE: [PWE3] PW switching and OAM
> 
> 
> Matthew......
> 
> NH=> I could see this issue coming up right from the outset.  
> And the 1st thing you need to be clear on is the mnode you 
> are dealing with as the defects (and OAM required) are 
> different in each case, viz:
> -	cl-ps:  breaks only
> The differences arise because of the nature of the traffic 
> unit on link-connections.  That is:
> For the co-ps and co-cs modes we must therefore add the 
> missing CV function.  This is done correctly in SDH 
> (trail-trace field), it's not done completely correctly in 
> ATM (but close, ie CC is missing source
> address) and its not done right at all in FR.  It is done 
> correctly and the most sparsely in Y.1711 (BTW this spec 
> should apply to any co-ps technology).  BFD is starting to 
> look a bit like Y.1711 (it has to, the required CV function 
> forces this) but its still not right.  Why?....
> 
> Because to correctly deal with p2mp constructs and to make 
> sure the required consequent actions are taken at the right 
> place (ie trail sink) the OAM must be unidirectional and it 
> it must be done in the data-plane......this applies to both 
> the co-cs and co-ps modes (it does not however apply to the 
> cl-ps mode).  Note also this is a forced behaviour in the 
> co-cs mode as the control/management plane is forced to be 
> OOB wrt the traffic data-plane.  SDH is a great of example of 
> doing this right, and ATM gets some of this right.....and 
> interestingly enough folks rely on this fact whether they 
> realise it or not, ie its largely taken for granted IMO.
> > 
> > 
> NH=> OOB is wrong for CV and FDI functions.  FDI must be sent 
> in the data-plane in the syntax of the client(s) affected and 
> from the server trail term point....and this is a recursive 
> requirement over all affected client layer networks (ie the 
> clients of the initially affected clients if you follow me).  
> The BDI function can go OOB as this not a direct 
> fault-handling function, but merely there to allow 
> single-ended monitoring of the defect behaviour of both directions.
> 
> NH=> All these issues are arising because folks are not 
> understanding the differences between the modal 
> behaviours....you simply can't apply the same approach in all 
> cases.  I'll send you something off-list that explains this 
> more completely.
> 
> regards, Neil
> > 
> > Best regards,
> > 
> > Matthew
> > 
> > 
> > 
> >