Subject: signaling packets in CESoPSN

From: [email-masked]
Date: Fri, 9 Jul 2004 16:03:27 +0100

Recently the CESoPSN draft attracted some criticism on its last call over 
the use of application signaling (e.g. telephony CAS) in separately 
sequenced packets within the same PW (which incidentally has been part of 
this particular draft since February 2002).

I'd like to canvas opinions on the best way forward here. There are (at 
least) three potential ways of handling the issue:
1. Separate sequenced signaling stream in the same PW (as in the current 
draft)
2. Use a separate PW for the signaling channel
3. Use VCCV to create a channel to send the signaling packets down

I've outlined some of the pros and cons of each as I see it below. I'd 
welcome opinions on this, to try and build a satisfactory way forward and 
enable us to get the draft through last call.

1. Separate sequenced signaling stream in the same PW (as in the current 
draft)
-----------------------------------------------------
For:
- simplest to setup, needs no additional PW setup or label distribution

Against
- multiple sequenced streams in the same pseudo-wire
  (but note this is no different from VCCV, which may also contain an 
additional sequenced stream)
- two stage control word processing - examine L, M bits, then process 
sequence no.
  (but we are already forced into a two stage process to check for VCCV 
packets)
- does this constitute a separate layer?

2. Use a separate PW for the signaling channel
----------------------------------------------
For:
- solves the issue of separate sequences in the same PW

Against:
- more complex, requires extra label distribution
- both PWs need to share the same fate
   - what happens if one is successfully set up, but the other fails?
   - how can we ensure both PWs are setup and torn down together?

3. Use VCCV to create a channel to send the signaling packets down
------------------------------------------------------------------
For:
- signaling still shares the same PW, so setup issues are minimised

Against:
- still have multiple sequenced flows in the same PW
- signaling packets have much more complex format, and hence harder to 
both generate and parse

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 13 Jul 2004 15:53:05 +0200

Hi all,
I want to join Tim in soliciting opinion on the issue 
of signaling packets in CESoPSN especially wrt interpretation 
of section 5.1.2 of the Architecture draft dealing with
PWE3 Channel types. 

Just to remind you, the proposal described in the draft
seems to me aligned with Type 2 channel defined in this
section, while option 3 mentioned by Tim re-uses the VCCV 
mechanism to implement such a channel in a generic way.

My interpretation of the Architecture draft has been 
disputed by some of the WG participants during the Last Call.

Authoritative opinion of the Editors of the Architecture 
draft (now actually an RFC) on this issue would be, IMO, 
most helpful. But all opinion is, of course, welcome.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 09, 2004 5:03 PM
> To: [email-masked]
> Subject: [PWE3] signaling packets in CESoPSN
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 13 Jul 2004 10:05:27 -0700

Tim, all,

I would rather have a separate signaling channel (~option 2). I would go
a step further and say that the signaling channel MAY be sent on a
separate PW channel but can also be sent in another form (i.e. using IP
packets when the PW run directly over MPLS). There is no need to have a
separate signaling channel for each PW but rather the signaling
information between two PEs may use a single signaling channel to
transport information for multiple PWs running between the PEs.

In addition, I believe that  TDM emulation in general does not
require/need VCCV. Connectivity and alarms propagation are built-in into
the control word and the nature of the service (continuous packet
stream). 

Regards
Ron

---

From: [email-masked]
Date: Tue, 13 Jul 2004 23:06:26 +0100

Ron,
> Sent: 13 July 2004 18:05
<snipped>
> the control word and the nature of the service (continuous packet

This may be workable due to the nature of this particular client and the adaptation used/deemed-necessary here......but even saying this I not sure you are right, because if there is any client compression (which I don't agree with as a default case) I beleive one is proxying for the integrity checking behaviour (that should only occur at the proper client layer trail termination point) at an intermediate point.

As a general rule we ought to have OAM solutions for each layer network (appropriate to the mode) that are independent.......so that any viable client/server relationship can exist and we don't have specific pairwise client/server dependencies.  The whole problem here (IMO) stems from the fact that MPLS was never envisaged/designed as a layer network in its own right (despite the *MP* name) at t=0, and OAM was an afterthought for many.

If operator X owns a given layer network (any technology) and folks lease capacity off this then operator X should be able to manage that layer network irrespective of what other client layer networks run on it....where those clients may of course be owned by many other parties.

This is not a specific issue for MPLS or SDH or whatever......it applies to all client/server layer network cases, and should be a general starting point requirement of any sensible architecture.  The integrity of managing a network connection in some server layer network falls squarely on the shoulders of the (server layer) trail termination point which is below, and agnostic of, any specific client layer adaptation function above this (please see G.805).  Server layer defects (detected/handled at the server layer trail termination point) should be mapped (in the server->client layer adaption function) to the appropriate FDI syntax that is appropriate for the technology/mode of the client layer network(s) affected.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 14 Jul 2004 08:57:20 +0300

Ron, Tim, Sasha, and everyone, 

> I would rather have a separate signaling channel (~option 2). 
> I would go a step further and say that the signaling channel 
> MAY be sent on a separate PW channel but can also be sent in 
> another form 

So far, I completely agree.
If you want to separate the CAS into separate packets,
then send them in a dedicated CAS PW.
(and while you are at it, do the same for CCS !!!
 see the TDMoIP draft or Y.1413 Appendix II).

If you don't want to use a separate PW,
then the original method of placing the signaling
substructure at the end of the last packet
in the multiframe can be used.

> (i.e. using IP packets when the PW run directly 
> over MPLS). There is no need to have a separate signaling 
> channel for each PW but rather the signaling information 
> between two PEs may use a single signaling channel to 

While it is possible to concatenation the signaling bits
of multiple E1/T1s, I am not sure this is a great idea.
The two sides would have to agree on the order of the substructures,
and of course we would have to have some protocol to handling
the bringing up and taking down of one of the trunks.
In addition, we would have to consider fractional trunks 
(do you pad each separate substructure to an even number
of bytes?, etc).

> 
> In addition, I believe that  TDM emulation in general does 
> not require/need VCCV. Connectivity and alarms propagation 
> are built-in into the control word and the nature of the 
> service (continuous packet stream). 

Here I disagree somewhat.
I agree that we don't need VCCV for defect handling,
but we DO need it for performance monitoring.
I will discuss this in the next version of the TDMoIP draft.

But, in any case, I don't see what the connection is 
between CAS bits and VCCV. Not only would we have
to define a new payload format for VCCV, 
we would be somewhat abusing the draft-bryant-mcpherson-pwe3-cw-00.txt
meaning of the first nibble.
This should universally indicate a OAM flow,
and not be overloaded with service-specific semantics.

Finally, I would like to reiterate my dislike of option 1
(multiple sequenced flows in a PW)!

So we are basically left with three acceptable options for CAS:

  1) zero-overhead option - keep the CAS in place (for E1s leaving
timeslot 16)
     and structure-lock on the multiframe using the FRG field.
  2) the 1 PW option - CAS substructures and use of the FRG bits
  3) the 2 PWs option - a separate CAS (or CCS) PW.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 14 Jul 2004 10:37:01 +0200

Yaakov, Ron and all,
Please see a couple of brief comments inline.
I have snipped the text that does not deal
directly with these comments.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Wednesday, July 14, 2004 7:57 AM
> To: Ron Cohen; [email-masked]; Alexander Vainshtein; 
> [email-masked]
> Subject: RE: [PWE3] signaling packets in CESoPSN
> 
> 
... snipped ...
> of multiple E1/T1s, I am not sure this is a great idea.
[Sasha] I must say I agree with Yaakov on this.
... snipped ...
> I will discuss this in the next version of the TDMoIP draft.
[Sasha]I am not sure I understand that, but let's wait for
the promised next revision.
> and not be overloaded with service-specific semantics.
[Sasha] I think that the latest CW draft defines a generic
control/OAM channel within a PW using the 1st nibble of the 
CW and that this is fully aligned with the PWE3 Architecture. 
What's more, it EXPLICITLY provides for running multiprotocol 
over this channel.
>   1) zero-overhead option - keep the CAS in place (for E1s leaving
[Sasha] This option has not been defined in any draft and, just for
the reference, explicitly FORBIDDEN in ATM-CES.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 14 Jul 2004 11:26:07 +0300

> > But, in any case, I don't see what the connection is between CAS
bits 
> > and VCCV. Not only would we have to define a new payload format for 
> > VCCV, we would be somewhat abusing the 
> > draft-bryant-mcpherson-pwe3-cw-00.txt
> > This should universally indicate a OAM flow, and not be overloaded 
> > with service-specific semantics.
> >

OK, now I understand what you mean.

You are claiming thatit is legitimate to use VCCV for
CAS signaling, since it is a "control/signaling" channel.

But VCCV is a PW-layer OAM channel,
not a TDM-layer control channel.

If we accept your view we could overload VCCV
with numerous client layer control protocols.
I could imagine sending ATM OAM cells,
or perhaps audio from technician's channels
as VCCV with some appropriate payload format.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 14 Jul 2004 11:40:44 +0200

Yaakov and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, July 14, 2004 10:26 AM
> To: Sasha Vainshtein; [email-masked]
[Sasha] So far, so good.
> 
> You are claiming that it is legitimate to use VCCV for
[Sasha] Please read carefully the description of 
"Type 2 PW Channel" in Section 5.1.2 of the Architecture
document. 

It mentions a "sequenced, non-reliable channel" and 
its typical use is defined as "CE-CE signaling".
CAS definitely comes under this category.
ATM OAM cells need additional consideration
(see dratfs on OAM mapping) and "orderwire"
technician channels do not look suitable to me.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 14 Jul 2004 12:22:17 +0300

> [Sasha] Please read carefully the description of "Type 2 PW 
> Channel" in Section 5.1.2 of the Architecture document. 
> 
> It mentions a "sequenced, non-reliable channel" and its 
> typical use is defined as "CE-CE signaling".
> ATM OAM cells need additional consideration (see dratfs on 
> OAM mapping) and "orderwire"

I AM familiar with Section 5.1.2.

I agree that the CAS signaling should be put into
a SEPARATE Type 2 PW (that's what a PW channel means).

It should certainly not be in VCCV running inside the TDM Type 3 PW.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 14 Jul 2004 12:21:54 +0200

Yaakov and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, July 14, 2004 11:22 AM
> To: Sasha Vainshtein
> Cc: [email-masked]
[Sasha] This is your interpretation. IMO it is incompatible, e.g.,
with the rest of channel types (starting from the Channel Type 1)
associated with the PW.

I'd be happy to hear from the editors/co-authors of the Architecture
document (sorry for repeating myself).

---

From: [email-masked]
Date: Wed, 14 Jul 2004 17:11:20 +0100

Yaakov,
I too am coming to the conclusion that we should use a separate PW.

I think VCCV adds unecessary complexity to the signaling packets, even if 
one accepts Sasha's view that it is a legitmate use of the VCCV. Further, 
we still have separate sequenced streams running within the same PW, which 
is the original objection. Lastly, in the egress PE, VCCV packets may be 
diverted on classification to the entity responsible for OAM, and hence 
never reach the IWF.

Use a separate PW does give the problem that there are 2 PWs that need to 
be associated. For example, what happens if one PW fails, but the other 
stays up? However, linking of associated PWs is a generic problem that 
shouldn't be solved by this draft. There must be other cases where this is 
required, hence a common solution to this issue should be found. In the 
meantime, I don't see any reason why it needs to hold up this draft.

Tim

"Yaakov Stein" <[email-masked]>
Sent by: [email-masked]
14-Jul-2004 10:22 AM

        To:     "Sasha Vainshtein" <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [PWE3] signaling packets in CESoPSN

Y(J)S

---

From: [email-masked]
Date: Wed, 14 Jul 2004 17:16:06 +0100

Hi Yaakov,

A few additional points here...
Yaakov wrote 14 July 2004 06:57

<snipped> 

RC=> In addition, I believe that  TDM emulation in general does 
> > service (continuous packet stream). 
YS=> Here I disagree somewhat.
> I will discuss this in the next version of the TDMoIP draft.

And I disgree with both of you on this.  The defect handling (ie OAM) should be an intrinsic part of the trail's CI, ie the same irrespective of the client it carries.  So whilst you may take the view 'we are OK for our particular TDM client case' this does not satisfy me (and I assume other operators) because I want the same/consistent fault management irrespective of the client being carried.

And further.....

I can see where you are heading with the above remark Yaakov, but let me just remind folks of what ought to be the ordering of processing here.  This is important for the NE/MIB behaviour and subsequent NMS/OSS processing....and this ultimately impacts stuff like service/SLA specifications, inter-operator performance apportionment rules, operational effectiveness, etc:

-	be clear on the network mode considered....the base transport defects are *not* the same in each mode, ie cl-ps reduces to simple breaks of flows, co-cs can only have breaks of trails and swapped trails (and then only between exactly alike trails), co-ps can have trail breaks, swaps and mismering (with/without affecting the offending trail).  So the specification of the defects in terms of entry/exit criteria and consequent actions is not the same in all cases.  This also means the OAM required is not the same.  {Note: if you also don't respect the connectivity constraints required of the co-ps mode then the defect situation can significantly increase in complexity......and IMO can become almost impossible to specify/measure.}

-	persistent defects should be used as basis for defining unavailability.....(un)availability is a key SLA topic in its own right.

-	'available time' is the only time when it is valid to collect network performance (NP) metrics (ie delay/lost/errored traffic units) for use in a NP SLA.  NP measurements (at least wrt aggregation against the NP SLA) should be suspended during unavailability periods.  Note also that for some technologies/applications if one direction fails then both directions must be considered to be unavailable from a NP SLA viewpoint.
{Aside - Although I see it all the time, folks should not be sloppy and talk of 'QoS' as it has no objective meaning at the network level....QoS is a subjective issue, based on a given application's perception of some degree of NP metric(s) impairment.  We should strictly talk of NP parameters and their objectives.}

So, to recap, the correct ordering is:
-	define defects of mode in terms of entry/exit criteria and consequent actions
-	define (un)availability entry/exit criteria based on defect persistence
-	define NP metrics and their end-end objectives (metrics vary with mode obviously) for the available state for some HRX......then consider fair apportionment to operator domains.

We are not at some of the latter stages I noted above yet (eg HRX and apportionment rules), but if we don't get the basics right then we won't be able to easily/meaningfully get the later stuff right either.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Jul 2004 12:45:30 +0300

> And I disgree with both of you on this.  The defect handling 
> (ie OAM) should be an intrinsic part of the trail's CI, ie 
> the same irrespective of the client it carries.  So whilst 
> you may take the view 'we are OK for our particular TDM 
> client case' this does not satisfy me (and I assume other 
> operators) because I want the same/consistent fault 
> management irrespective of the client being carried.

Neil, 

Thanks for the review of defect modes for the various cases.

However, I stand by my original statement.

The VCCV provides PW-layer OAM functionality,
and as such needs to supply functionality
needed for a CO layer, mainly detection of breaks.
For certain clients we also need performance monitoring,
mainly one-way and round-trip delay, a bit of info on the PDV
and packet loss distributions, etc.

Not all PW types have the same OAM requirements,
so it would be severe overkill to demand that precisely
the same functionality be provided for e.g.  ATM and TDM PWs.

In particular, for constant rate real-time streams we don't need
keep-alives for connectivity checking, since the data itself
arrives at a constant predictable rate. Any adding of heartbeats
here is senseless BW increase (although needed for monitoring
of idle backup paths). 

This difference in handling would be objectionable were there to really
be such a thing as a "generic PW". But there isn't. TDM PWs, Ethernet
PWs
and ATM PWs are different creatures with different needs.
We grouped them together in order to combine underlying architecture
as much as possible, but the service-specific parts are still
significant.

Y(J)S

---

From: [email-masked]
Date: Thu, 15 Jul 2004 16:32:59 +0100

Hi Yaakov,

> However, I stand by my original statement.
NH=> Likewise.
> needed for a CO layer, mainly detection of breaks.
NH=> Its more than this.

> and packet loss distributions, etc.
NH=> Not as an 'always on' function across the population you don't.  PM is different to (and dependent on) fault-management.
> Not all PW types have the same OAM requirements,
NH=> Don't get this.  The client type should be irrelevant for the integrity management of the server trail.....this is a pretty fundamantal requirement.  We don't manage SDH or ATM trails in terms of the client they are carrying.....for a given type of trail they are all managed the same.

> the same functionality be provided for e.g.  ATM and TDM PWs.
NH=> And in a world where there can be SDHoverIPoverSDHoverEthernet....or any other permutations you like .....which is the client and which is the server, ie so which layer sets the (inheritiance) rules for the other layers?  But you are right in one sense.....PM is something to be decoupled from basic fault-management.  Former should be on-demand (and could vary in type), latter should be consistent, simple and 'always on' for all trails (irrespective of client).
> here is senseless BW increase (although needed for monitoring
NH=> Well of course I understand this.  But what if you have a case of TDMoverATMoverMPLS or whatever.....where the various layer networks here can be owned by different parties?  One won't always know what the ultimate client/application is.  As I noted earlier, we do not change how we fault-manage SDH VC4 trails (say) in terms of what client they may be carrying.......nor may we even own that client layer network.
> be such a thing as a "generic PW". But there isn't.
NH=> And therein lies the real gripe I have had here from day 1.  The layer network we should be managing consistently is MPLS......ditto IP, but this is a different layer network/mode, has different defects and requires different OAM......ditto SDH.  PWs seem to be some political sop to keep up the illusion that MPLS=IP......this simply is not true, and therein lies the start of the rot.

> Ethernet
NH=> This is where one should be differentiatiing 'client specific' and 'clinet generic' adaptation functions (some folks call these 'convergence layers').  However, OAM should be common to the server layer for all client cases.  I am rapidly losing sight of just what exactly a PW is.....it seems its different things to different folks depending of what they want to sell and to what audience.  I think this whole area is a bit of a mess (understatement).

regards, Neil