Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 4 May 2004 15:51:43 +0300

Sasha, 

In CESoPSN "A special combination of flags in the CESoPSN control word
is used to 
distinguish between data and signaling packets", namely L=0, M=11
(a combination marked as reserved in Y.1413).

When signalling is carried in separate packets,
what processing has to be performed when a lost
packet is detected (as it is not immediately clear whether
the lost packet is signaling or data) ?

Is the optional RTP timestamp REQUIRED for this case?

Do you allow signalling packets to be sent in a separate PW?

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 4 May 2004 15:59:41 +0200

Yaakov and all,
Annex A of the draft states that signaling packets use a separate
numbering sequence (independent from that of the data packets).
Hence the mechanism for detection of lost data packets used
with the basic NxDS0 services (or with SAToP) will not be
affected by presence of signaling packets and vice versa.

It probably makes sense to move the caveat on the separate 
numbering sequence of signaling packets to the body of the draft
to avoid misunderstaning. Would this be OK with you?

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: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, May 04, 2004 2:52 PM
> To: Sasha Vainshtein; [email-masked]; [email-masked]
> Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL
> 
> 
> Sasha, 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 5 May 2004 08:55:38 +0300

Sasha, 

I thought that this is what you intended,
but didn't see it in the text.

This is indeed somewhat better, but opens
a new can of worms.

First, sequencing is a feature covered in the
architecture draft, and the TDM case already
deviates somewhat from the norm in requiring
the sequencing (not leaving it optional) and
hence not assigning a special meaning to zero.

However, having a single PW maintain two separate
sequencing streams seems a much more major deviation
from the PWE architecture as I understand it.
Basically you are running two independent PWs
under a single label, and I think this requires
some consideration. I realize that you are reticent
to require assignment of two separate PW labels,
as this would require more messaging or provisioning,
but I am not sure that this extra work is in vain.

Second, since the sequences are independent,
but run at different rates, nothing prevents them
from becoming close. Hence the sequence number processing
can not rely on the sequence number alone, but MUST
check the L+M fields. In fact, the L+M fields must be checked
FIRST, and only then the sequence processing performed.

Finally, how do I know to expect this "double PW with a single label"?
Is it signalled at setup ?

Y(J)S

> From: Sasha Vainshtein [mailto:[email-masked]] 
> Sent: Tuesday, May 04, 2004 17:00
> To: Yaakov Stein
> Cc: [email-masked]; [email-masked]
> Annex A of the draft states that signaling packets use a 
> separate numbering sequence (independent from that of the 
> data packets).
> numbering sequence of signaling packets to the body of the 
> draft to avoid misunderstaning. Would this be OK with you?
> 
> With best regards,
>                                    Sasha Vainshtein
> > is used to distinguish between data and signaling packets", namely 
> > L=0, M=11 (a combination marked as reserved in Y.1413).
> > 
> > When signalling is carried in separate packets, what 
> processing has to 
> > be performed when a lost packet is detected (as it is not 
> immediately 
> > clear whether the lost packet is signaling or data) ?
> >

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 5 May 2004 10:46:56 +0200

Yaakov and all,
Please see some answers inline.
Hopefylly they will be helpful.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, May 05, 2004 7:56 AM
> To: Sasha Vainshtein
[Sasha] Sorry, I've checked the latest architecture
draft (-07) and it DOES NOT say anything about
"assigning special meaning to zero".  It is true 
that the TDM case differs from the convention used
by various L2 encapsulations over MPLS, but this
is not related to signaling packets.
> from the PWE architecture as I understand it.
[Sasha] IMHO this is fully compliant with the notion of
PWE3 Channel types discussed in Section 5.1.2 of the
said draft. The applicable channel type 
is explicitly listed in item 2 of this Section
(A high-priority, unreliable, sequenced channel)and,
according to the draft, is typically used for CE-CE
signaling. 
> FIRST, and only then the sequence processing performed.
[Sasha] This is probably correct and deserves explicit 
mentioning in the draft. 
> Is it signalled at setup ?
[Sasha] Yes, of course - but signaling is not discussed in the
draft in question.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 5 May 2004 12:01:52 +0300

Sasha,

Your answers are intriguing, as usual.

Further comments interleaved to snippets below.

Y(J)S

> Sorry, I've checked the latest architecture draft 
> (-07) and it DOES NOT say anything about "assigning special 
> meaning to zero".  

I didn't mean to imply that this behavior contradicted
the architecture draft (if it would I would have asked for
the architecture draft to be changed). All I meant was
that only SAToP, CESoPSN and TDMoIP do not skip the zero value.

> IMHO this is fully compliant with the notion of
> PWE3 Channel types discussed in Section 5.1.2 of the said 
> draft. The applicable channel type is explicitly listed in 
> item 2 of this Section (A high-priority, unreliable, 
> sequenced channel)and, according to the draft, is typically 
> used for CE-CE signaling. 

... and I assume that you are also invoking the succeedin statement
from the architecture draft 
   "The data channels (2, 3 and 4 above) should be carried "in band"
with
   one another to as much of a degree as is reasonably possible on a
   PSN."

But did this really imply SEPARATE sequencing for the various
channels in a single PW ?

I would certainly like to hear Stewart's view on this
(as author of the aforementioned draft)
as well as the WG at large.

I had interpreted "in-band" to mean "over the same PSN",
or even "over thee same tunnel", not "over the same PW".

The architecture draft does not mention any method of
demuxing these channels (which you DO provide in your draft)
and thus if we adopt your interpretation we could have multiple
un-marked streams with separate sequencing running together
in a single PW. This would be indeed be mystifying.

> [Sasha] Yes, of course - but signaling is not discussed in 
> the draft in question. 

If we do go this way I would suggest adding the appropriate
parameter specifying
  1) signaling substructure appended to data packet
  2) signaling substructure in separate packets with independent
sequencing
  3) signaling substructure in separate PW
to your control protocol extensions draft.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 5 May 2004 12:27:17 +0200

Yaakov and all,
Please see some more inline below.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, May 05, 2004 11:02 AM
> To: Sasha Vainshtein
[Sasha] Note also that the L2TPv3 L2-specific sublayer
also does not skip zero (in addition to providing a 24-bit
sequence number).  
> as well as the WG at large.
[Sasha] I do not see it as a major architectural issue beyond
the TDM. The difference between the TDM PWs and the rest of
them wrt packet loss is essential: TDM PWs MUST compensate
each lost packet, while non-TDM can, by default, simply drop
mis-ordered packets. I would also glad to hear from Stewart
and from the WG at large on this subject.
> or even "over thee same tunnel", not "over the same PW".
[Sasha] Unless things have changed drastically from the last
time I looked at the TDMoIP draft, you use two types of
packets - data and signaling - in the AAL2-based mode -
over the same PW. Or did I miss something?
> to your control protocol extensions draft.
I will consider this option when I update the signaling draft; 
more comments on it are really welcome.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 5 May 2004 13:58:29 +0300

... the plot thickens ...
 
> [Sasha] Note also that the L2TPv3 L2-specific sublayer also 
> does not skip zero (in addition to providing a 24-bit 
> sequence number).  

as does RTP and just about every other sequencing method.

> and from the WG at large on this subject.

The use of the zero sequence number is not the question.
The use of multiple sequencing streams in a single PW is.

> > 
> > I had interpreted "in-band" to mean "over the same PSN", or 
> > even "over thee same tunnel", not "over the same PW".
> >
> packets - data and signaling - in the AAL2-based mode - over 
> the same PW. Or did I miss something?

No, you haven't missed anything. 
The AAL2 method definitely has separate signaling subframes, 
which can be (depending on implementation) placed into
separate packets. Separate signaling packets share the
SAME sequence number series. However, this is not critical
as in your case as the subframes have their own sequencing (in the UUI
field).

A long time I had considered the option of using
a separate sequencing method, but rejected it due to its not conforming
with what I considered a general architectural principle
(you will see in a moment why I consider this a fundamental question).
That principle is that a PW carries a single flow.
In particular:
  1) a PW is either sequenced or not
  2) when it is sequenced there is a single sequence per PW

You are proposing multiple sequenced and unsequenced streams per PW.
In other words, you are proposing a third level of flow:
   1) A tunnel
   2) PWs in the tunnel
   3) flows in a PW

Do we really want/need this third level?
Are there separate set-up and maintenance entities for this third level?
Do I need VCCV, performance parameters, etc for this new level?

We have already basically turned the PW into a full-blown layer network.
Taking over the job of a friend of ours :)    I would like to ask
whether we need to define yet another layer network inside this one?

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 5 May 2004 14:14:43 +0200

Yaakov and all,
Please see some more below.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, May 05, 2004 12:58 PM
> To: Sasha Vainshtein
[Sasha] L2TPv3 is used to carry, say FR over an IP PSN.
This means that forthe same type of AC (FR), you have
two different numbering methods: one for an MPLS PSN and 
another fo an IP PSN. So I agree with you that the plot
thickens - but it leads further and further from the
initial scope.
> That principle is that a PW carries a single flow.
[Sasha] This very much depends on what you define as a flow.
E.g., the "port mode" of FR PWs carries multiple DLCIs which
could be called "flows" as well.
The current architecture does not refer to any such notion,
so, IMHO, everybody can presume what suits him/her best.
> You are proposing multiple sequenced and unsequenced streams per PW.
[Sasha] I agree with you that a PW can be either sequenced or not
and I have tried to convince the FR draft editor to impose 
some such limitation. The current draft does not preclude a mix of
sequences (i.e., with non-zero SN) and unsequenced (with zero SN)
PW packets on the same FR PW which, IMHO, should be fixed.
And, to the best of my understanding, I do NOT propose any 
UNSEQUENCED flows within a CESoPSN PW.
> In other words, you are proposing a third level of flow:
[Sasha] IMHO, this is goes far beyond my modest and
very specific proposal. I am not sure that such a
generalization is justified and definitely was not
intended. Hence I find it difficult to answer your very
generic questions below, BUT I believe I have answered
some of them already (wrt setup) in the previous message.

---

From: Luca Martini <[email-masked]>
Date: Wed, 05 May 2004 09:48:47 -0600

Sasha,

Indeed there are differences in the drafts , regarding sequence numbers 
handling , and control words.
This does not mean that it will be accepted by the IESG, and it does not 
mean we have free run of deigning even more different schemes.

Definely we never meant to have different sequenced flows in the same 
PW. This is not part of the architecture.
Please do not mistake merged flows within a PW with separate flows 
within the PW.
For example when many ATM VCs are transported as one VP in a PW, they 
are one flow, as they separate VCs have been merged into a single flow 
in a PW.

The point here is to create a standard that can re-use maybe part of the 
same hardware to transport different types of PWs. It seems to me that 
even the sequencing in the tdm drafts should conform to the rest of PWE3 
designs.

Note that I'm on vacation until monday , and desperately attempting to 
stay away from this computer ... ;-)

Bye
Luca

Sasha Vainshtein wrote:

>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>  
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 5 May 2004 19:09:52 +0200

Luca and all,
Please see a few words inline (do not want to 
keep you bound to the computer:-).

With best regards,
                                   Sasha Vainshtein

> From: Luca Martini [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2004 5:49 PM
> To: Sasha Vainshtein
> Cc: 'Yaakov Stein'; [email-masked]; [email-masked]
> Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL
> 
> 
> Sasha,
> 
There is a reason for such a difference between TDM and non-TDM PWs:
in case of TDM, you MUST compensate for each paylod byte that has been
lost, while in case of non-TDM it is enough to discard mis-ordered
packets (and sometimes you can skip even that).

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: 05 May 2004 09:32:09 -0400

> packets (and sometimes you can skip even that).

	This still doesn't seem to justify the departure in
methods.  I agree with Luca in that we should try to
have as few different ways of doing the same thing
as possible.

	--Tom

---

From: Shahram Davari <[email-masked]>
Date: Wed, 5 May 2004 11:21:48 -0700

Hi Sasha,

I also share the concern that Yaakov and Luca expressed regarding
the CAS packets multiplexed in the same PW. This would require 2 seq
number tracking per PW.

I also have another concern, but before I elaborate on that I would like to mention that in structured emulation, the network MUST generate Trunk conditioning as specified in Bellcore TR-NWT-000170, rather than AIS/RDI. 

Now my concern: Based on Table 1: The Interpretation of bits L and M in the CESoPSN CW, it appears that L=1& M=00 may or may not generate AIS/Truck conditioning at the far end, depending on the configuration. In order to reduce the amount of configuration, I suggest using L=1& M=00, only when your payload is omitted and you want AIS/Truck Conditioning generated at the far end. And use another code point such as L=1 & M=01 to indicate a valid payload, which doesn't need AIS/Trunk conditioning to be generated at the far-end.

Similarly for L=0 & M=10, you may want to have another codepoint such as L=0 & M=01 if
you want RDI/Trunk conditioning be generated, while using L=0 &M=10 for the case that you don't want to generate RDI/Trunk conditioning.

In any case we have to make sure that the interpretation of these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413.

Yours,
-Shahram

> Sent: Wednesday, May 05, 2004 11:49 AM
> To: Sasha Vainshtein

---

From: [email-masked]
Date: Wed, 5 May 2004 20:50:55 +0100

Further point...

If there are 2 independent Seq No streams then it seems to me you will require 2 independent Seq No aberration tests (which essentially means that defect entry/exit criteria need defining for these).  The consequent actions however might not be independent.

regards, Neil 

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Shahram Davari
> Sent: 05 May 2004 19:22
> To: 'Luca Martini'; Sasha Vainshtein
> I also have another concern, but before I elaborate on that I 
> would like to mention that in structured emulation, the 
> network MUST generate Trunk conditioning as specified in 
> Bellcore TR-NWT-000170, rather than AIS/RDI. 
> 
> Now my concern: Based on Table 1: The Interpretation of bits 
> L and M in the CESoPSN CW, it appears that L=1& M=00 may or 
> may not generate AIS/Truck conditioning at the far end, 
> depending on the configuration. In order to reduce the amount 
> of configuration, I suggest using L=1& M=00, only when your 
> payload is omitted and you want AIS/Truck Conditioning 
> generated at the far end. And use another code point such as 
> L=1 & M=01 to indicate a valid payload, which doesn't need 
> AIS/Trunk conditioning to be generated at the far-end.
> 
> you want RDI/Trunk conditioning be generated, while using L=0 
> &M=10 for the case that you don't want to generate RDI/Trunk 
> conditioning.
> 
> In any case we have to make sure that the interpretation of 
> these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413.
> 
> Yours,
> -Shahram
> 
>  
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 May 2004 11:37:17 +0200

Shahram and all,
I'd like to point out that the draft explicitly states the
need for an appropriate NSP in order to provide structured
TDM services. IMO, the Trunk Conditioning functionality you
have mentioned is a "native TDM" function and hence should 
be performed by the NSP which would then act not just as
a Framer but as a Digital Cross-Connect (DXC) system.

I also do not think that using additional codepoints can
reduce the need of configuration (which seems to be one of
your concerns). E.g., the decision to generate or not to
generate AIS towards the local CE cannot, IMO, be based
solely on indications received by the CE-bound IWF instance.
E.g., please consider the case where several groups of timeslots
on the same TDM trunk act as ACs for different IWF instances while
"far ends" of the corresponding CESoPSN PWs use ACs that originate
in different trunks. Killing the entire "near end" trunk with AIS
just because AIS has been observed on one of the "far end" trunks
would hardly be the best possible solution. On the other hand, making
each "far end IWF" aware of the fatc that its peer shares (or does 
not share) the trunk with other IWF instances does not look a
good solution either.

With best regards,
                                   Sasha Vainshtein

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2004 8:22 PM

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 6 May 2004 11:58:49 +0300

Luca/Sasha, 

My feeling is that we need as much similarlity as possible
between the difference service emulations.

The sequence number skipping zero issue seems to me
to be "mostly harmless", as we don't need to indication
that a TDM packet is not carrying a sequence number,
as all packets are sequenced.

I am more concerned with the concept of multiple sequenced flows
inside a PW. This seems to me to verge on the dangerous,
and I would like to avoid it if possible.

As far as I see there ARE other alternatives to handle
the signaling substructure, including the original technique
of appending it to a data packet.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 May 2004 12:12:21 +0200

Yaakov and Luca,
Carrying of singnaling info in separate packets has, IMO,
a certain advantage since it allows to use the same
data plane mechanisms for services with and without signaling.

Another advantage is trunk independence (i.e., ability to
pass signaling between bundles of timeslots originating,
say in E1 and T1/ESF trunks). This functionality
CANNOT be achieved by appending signaling structures to
the data. 

Please note also that the draft treats transport of signaling
information in separate packets as OPTIONAL (indeed, the
word must be capitalized in accordance with 2119 - will fix
after the LC). Hence the implementors that think that 
this behavior is dangerous, are free not to implement it 
and to use other available methods.

Carrying signaling info in a separate PW solves the problem
of two sequencing flows in the same PW BUT introduces some
new ones stemming from interdependency of the two PWs.
E.g., the setup mechanism must provide for ability to associate
the data PW with its paired signaling PW, both must be 
torn down together etc. So I'd say that this proposal fully 
complies with RFC 1925 (item 6).

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, May 06, 2004 10:59 AM
> To: Sasha Vainshtein; Luca Martini

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 6 May 2004 12:32:17 +0300

Sasha, 

I find your quoting of 1925 apt - 
you are moving the problem to a different part of the network, 
in fact you are creating a new network layer!

Regarding the optionality, I am not sure that even optional
features should be allowed to create new network layers.

I don't understand your explanation of trunk independence.
In the unlikely case of having E1 and T1 trunks converging
on one IWF (apparently situated on the border between North America
and Europe), the are two consistent options:

  1) add a NSF that multiplexes them taking timing into account
     (we don't want to recreate PDH functionality in the PW),
  2) open two PWs, one for the E1 and one for the T1.

These E1 and T1 trunks will have different timing sources
and MUST NOT be mixed into a single PW.
In addition, as you mention, they have different (multiframe)
structure sizes, and thus SHOULD NOT be placed into a single PW.

Due to the last point, if you indeed intend to use separate
signaling packets, I guess you would use one for the E1 and
one for the T1, resulting in three separately sequenced flows
in the PW. 

Y(J)S

> Sent: Thursday, May 06, 2004 13:12
> To: Yaakov Stein; Luca Martini
> Carrying of singnaling info in separate packets has, IMO, a 
> certain advantage since it allows to use the same data plane 
> mechanisms for services with and without signaling.
> 
> 
> pass signaling between bundles of timeslots originating, say 
> in E1 and T1/ESF trunks). This functionality CANNOT be 
> achieved by appending signaling structures to the data. 
> 
> information in separate packets as OPTIONAL (indeed, the word 
> must be capitalized in accordance with 2119 - will fix after 
> the LC). Hence the implementors that think that this behavior 
> is dangerous, are free not to implement it and to use other 
> available methods.
> 
> E.g., the setup mechanism must provide for ability to 
> associate the data PW with its paired signaling PW, both must 
> be torn down together etc. So I'd say that this proposal 
> fully complies with RFC 1925 (item 6).
> 
> 
> 
> With best regards,
>                                    Sasha Vainshtein
> > The sequence number skipping zero issue seems to me to be "mostly 
> > harmless", as we don't need to indication that a TDM packet is not 
> > carrying a sequence number, as all packets are sequenced.
> > 
> > As far as I see there ARE other alternatives to handle the 
> signaling 
> > substructure, including the original technique of appending it to a 
> > data packet.
> > 
> > Y(J)S
> > 
> 
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 May 2004 12:51:39 +0200

Yaakov and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, May 06, 2004 11:32 AM
[Sasha] I am not sure what exactly does and what does not
make TDM PWs a "new network layer".  If you see any EXPLICIT
conradiction between usage of two separate sequencing schemes
with a single PW and the protocol layering scheme as
presented in the PWE3 architecture, please spell it out
in order to make THIS discussion more specific.
> I don't understand your explanation of trunk independence.
[Sasha] I have not probably explained weel. The intention has
been to, say, a trans-atlatic PW with timeslots at one end
originating in a T1 trunkl and timeslots at the other end
originating in an E1 trunk. (Of course this would also
require A-law to mu-loaw transplation, but this is purely
NSP and hence out of the PWE3 scope). 
> and Europe), the are two consistent options:
[Sasha] As I have said above, this was NOT teh case I have had
in mind.

---

From: [email-masked]
Date: Thu, 6 May 2004 13:25:33 +0100

Sasha,

Sasha Vainshtein wrote 06 May 2004 10:37
<snipped>

> not share) the trunk with other IWF instances does not look a

NH=> May I make a plea for folks to try and get au fait with the descriptions of layer networks as defined in G.805 and respect these.  If this was understood here then there is no problem.  That is (for example):

If the failures are in 64k trails then these exist above (ie are clients to) a server E1 or T1 (say) layer trail.  The only defect detection/handling that is relevant here is at the 64k layer level....specifically, there *must* be no defect detection/handling at the server E1/T1 level (or indeed any further lower server layer networks below these).  If there is a failure between the trail termination points of the E1 or T1 server layer however, then at the E1/T1 trail sink point a FDI (ie AIS here) must be mapped to *all* the affected 64k client layer trails.  And of course, as for the previous case there must be no defect detection/handling ine any layer networks below the affected E1/T1 trail.

So in fact, both the proposals for handling the case you gave are incorrect.....the required behaviour is as I outlined above.

This is a fundamental behaviour requirement in any client/server relationship between 2 layer networks.  Now if one does not have client/server layer independence (eg because one is compressing the client say) you are going to create problems.  Specifically, one will be creating proxy client layer trail termination functions in the wrong (server) layer network (or, perhaps more accurately, at the client<=>server adaptation function) at the i/w point.  And as a further observation here, the BW savings acrrued from doing this are not warranted IMO in terms of the problems it creates.

regards, Neil

---

From: [email-masked]
Date: Thu, 6 May 2004 13:25:36 +0100

Please think about the functional architecture you are discussing here.  For exmaple:   The traffic data-plane and the control data-plane trail entities can have various levels of disjointedness.  In some networks they might be physically disjoint (eg OTNs), in others they might be only virtually disjoint (CCS7 for the PSTN say) and in some other cases might be carried within a common lower layer network trail, eg CAS in an E1....the 64k client CAS channel/trail here is for the control of (and only the control of) the client 64k traffic channels/trails that are in the same parent lower layer E1 trail......so althought both the 64k CAS channel/trail and each of the 64k traffic clients are independent at the 64k layer, they are all carried by the same server layer E1 trail.

So the required functional model is quite different in all these cases.  So please be very careful to which case you are referring, and use the appropriate functional model.

regards, Neil
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Sasha Vainshtein
> Sent: 06 May 2004 11:12
> To: 'Yaakov Stein'; Luca Martini

---

From: [email-masked]
Date: Thu, 6 May 2004 13:25:41 +0100

Yaakov, please see in-line.  regards, Neil

> Yaakov Stein
> Sent: 06 May 2004 10:32
NH=> Precisely.....see my other related mail for further examples.  I wish for more folks would try and grok this layer network stuff better as they might then produce solutions that don't have latent downstream problems from (probably unintended) architectural violations. 
> features should be allowed to create new network layers.
NH=> I would not be prescriptive here, but what I would say is that if folks properly defined/understood their proposals in func arch terms then we would better understand all the consequences of the proposal and make a better informed judgement.
> structure sizes, and thus SHOULD NOT be placed into a single PW.
NH=> Arrghhh!  The E1 and T1 trails belong to different layer networks anyway....*all* their functions (ie their complete Characteristic Information in G.805 speak) *must* be terminated at any i/w point.  The only thing that is common is the higher layer 64k layer network traffic channels (but even these might be diferent at a higher level still, eg A vs u law encoding say).  And of course, although the signalling channels use the same 64k layer network as the traffic channels for ransport, these can be quite different in terms of the higher level signalling protocol used.  Further, if the 64k clients are *not* part of a common 64k layer network then as Yaakov also says their timing behaviour will be different.

---

From: [email-masked]
Date: Thu, 6 May 2004 13:25:45 +0100

Sasha....<snipped>
> make TDM PWs a "new network layer". 

NH=> I can see that.  Please look at G.805/809.  Better, read chapter 3 (and if time chapter 4) of my colleague Andy Reid's book on 'Broadband Networking' {ISBN 0-89006-578-0}.

> If you see any EXPLICIT
NH=> See the comments I made earlier about this case to Yaakov.

regards, Neil

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 May 2004 15:48:26 +0200

Neil and all,
Please see some comments/answers inline below.

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 06, 2004 2:26 PM
> To: Sasha Vainshtein; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> NH=> May I make a plea for folks to try and get au fait with 
> the descriptions of layer networks as defined in G.805 and 
> respect these.  If this was understood here then there is no 
> problem.  That is (for example):
> 
> If the failures are in 64k trails then these exist above (ie 
> are clients to) a server E1 or T1 (say) layer trail. 
>
[Sasha] AFAIK, no failures/defects have been defined for 64K
trails. This may be very bad from the generic leyer networks
view as described in G.805 etc., but this is THE ONLY SPECIFIC
kind of trails this draft deals with. One way to deal with
this problem has been already proposed (in a different forum),
namely to forbit emulation of NxDS0 services because they 
do not fit the correct architecture anyway. This draft clearly 
pursues a different option.
>
> The 
> only defect detection/handling that is relevant here is at 
> the 64k layer level....specifically, there *must* be no 
> defect detection/handling at the server E1/T1 level (or 
> indeed any further lower server layer networks below these).  
> If there is a failure between the trail termination points of 
> the E1 or T1 server layer however, then at the E1/T1 trail 
> sink point a FDI (ie AIS here) must be mapped to *all* the 
> affected 64k client layer trails.  And of course, as for the 
> previous case there must be no defect detection/handling ine 
> any layer networks below the affected E1/T1 trail.
>
The behavior you've described is one that is implemented in the draft.
However, the draft allows additional functionality for the case when
your NxDS0 service is used to emulate a partially populated E1 or
T1 trunk. Once more, the architecturally correct way would be to carry
the entire trunk, say 24 timeslots instead of only 4 or 8 actually
used and to ignore the BW price tag that goes with it as well as
to prevent ability to provide Voice and Data services on a
single trunk (quite a business in some places, e.g., in the US).
Another option would be to propagate the trunk AIS and RDI indications
across the PW and to use them as needed.
>
> So in fact, both the proposals for handling the case you gave 
> are incorrect.....the required behaviour is as I outlined above.
> 
> This is a fundamental behaviour requirement in any 
> client/server relationship between 2 layer networks.  Now if 
> one does not have client/server layer independence (eg 
> because one is compressing the client say) you are going to 
> create problems.  Specifically, one will be creating proxy 
> client layer trail termination functions in the wrong 
> (server) layer network (or, perhaps more accurately, at the 
> client<=>server adaptation function) at the i/w point.  And 
> as a further observation here, the BW savings acrrued from 
> doing this are not warranted IMO in terms of the problems it creates.
>
[Sasha] You clearly prefer BW-inefficient but architecturally 
correct solutions. I do not have any problems with that,
but some people have different opinion and the draft provides
for their needs as well as it can be restricted to suit
your position.

---

From: [email-masked]
Date: Thu, 6 May 2004 16:14:30 +0100

Thanks Sasha....please see below.

<snipped>
> trails.
NH=> I agree.  This is historical. 

> This may be very bad from the generic leyer networks
> view as described in G.805 etc.,
NH=> Correct....this is the key point.  That is, the fact we have historical errors/deficiencies means we should learn from them.  For example, SDH had strong OAM built-in to it from day 1 due to the lessons learned from not having this in PDH.  A key (and unintentional) spin-off of this was that SDH was pretty-well bug-free from the box, ie the vendors could use the OAM to de-bug their kit during its development/testing before we operators took large-scale delivery.  For the *general* case what I am saying is corect....so if one deviates from this, then we need to understand the consequences of doing so before agreeing to it.
<snipped>

> for their needs as well as it can be restricted to suit
NH=> Understood.  I too have no problem with this either providing we understand the consequences either way and are quite open/honest about this.  What I do have problems with however is when folks try and tell me that some (usually quite obvious) architectural violation is 'correct/normal' behaviour and (for whatever reason) refuse to see things any other way.  I am sure you know the stuff I mean here.

regards, Neil

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 6 May 2004 18:42:06 +0200

Neil,
Thankk you, and please see a very short response inline below
(I have skipped some text for clarity).

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, May 06, 2004 5:15 PM
> To: Sasha Vainshtein
> [email-masked]; [email-masked]
... snipped ,,,
> NH=> Understood.  I too have no problem with this either 
> providing we understand the consequences either way and are 
> quite open/honest about this.  What I do have problems with 
> however is when folks try and tell me that some (usually 
> quite obvious) architectural violation is 'correct/normal' 
> behaviour and (for whatever reason) refuse to see things any 
> other way.  I am sure you know the stuff I mean here.
> 
[Sasha] I definetely agree with you on the need to be quite
open and honest about everything you do. The same goes
for making at least a honest attempt to understand
the position presented by the others (to the best of one's ability:-).

---

From: Shahram Davari <[email-masked]>
Date: Mon, 10 May 2004 06:36:13 -0700

Sasha,

AIS of a few time slots should not generate AIS for the whole T1/E1.
This is a principle of client/server AIS relationship. Therefore
your example is moot.

Yours,
Shahram

> Sent: Thursday, May 06, 2004 5:37 AM
> To: Shahram Davari
> Cc: 'Yaakov Stein'; [email-masked]; [email-masked]; 'Luca Martini'

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 10 May 2004 16:40:28 +0200

Shaharam and all,
Please consider the case when you want to emulate behavior of
a regular E1/T1 trunk over a PW, but, since only a few timeslots
are actually used on this trunk, you use structure-aware emulation.
In this case - an this is the example I've tried to present for your
consideration before,- AIS of an E1/T1 trunk observed at one end 
of the PW must be translated to AIS at the other end of the PW.
One of the reasons for that requirement can be the need to trigger
trunk conditioning in the corresponding CE (if this CE is a DXC).

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, May 10, 2004 3:36 PM
> To: Sasha Vainshtein

---

From: Shahram Davari <[email-masked]>
Date: Mon, 10 May 2004 07:03:05 -0700

Hi Sasha,

Mapping AIS from server to client is fine. So in you new example if the fractional T1/E1
indicates AIS, then again you must generated trunk conditioning toward downstream. You may want to generate trunk conditioning at the PE that first detects TDM failure (ingress PE), or at the egress PE. If you generate trunk conditioning at the ingress PE , then you must tell the other end not to generate trunk conditioning, but only send whatever it receives to the customer. While if the ingress PE can't generate trunk conditioning, it should tell the egress PE to generate it.

So there are only 2 cases, either the egress PE should or should not generate trunk conditioning, depending on ingress PE capabilities. That is why I asked for 2 L/M code points.

Yours,
-Shahram

> Sent: Monday, May 10, 2004 10:40 AM
> To: Shahram Davari
> > > > > >>a separate sequencing method, but rejected it due 
> to its not 
> > > > > >>conforming

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 10 May 2004 17:25:18 +0200

Shahram and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, May 10, 2004 4:03 PM
> To: Sasha Vainshtein
> Mapping AIS from server to client is fine. So in you new 
[Sasha] Sorry to say, but is one and the same example
all the way. Presumably I have not explained it well enough.
> example if the fractional T1/E1
> indicates AIS, then again you must generated trunk 
> conditioning toward downstream. 
[Sasha] Bellcore TR-NWT-170 to which you refer defines requirements
to digital cross-connect (DXC) systems. These systems, indeed,
must generate trunk conditioning (namely, release telephony calls)
on the downsream channels (timeslots) that have been affected
by an upstream local ("red") or remote ("yelow") alarm.
Now, structure-aware TDM PWs are NOT DXCs, nor are their IWFs.
The PWEe reference model has defines a dedicated element for
handling this kind of functionality, namely the NSP. 
The draft under consideration postulates the need for an NSP
for structure-aware TDM PWs. Such an NSP can be a plain E1/T1
framer, or it can support DXC functions as well. In the latter
case, this DXC would implement traffic conditioning, and the
only thing needed for this purpose is conveyance of the
appropriate signals by the structure-aware TDM PW.
>
> You may want to generate 
> trunk conditioning at the PE that first detects TDM failure 
> (ingress PE), or at the egress PE. If you generate trunk 
> conditioning at the ingress PE , then you must tell the other 
> end not to generate trunk conditioning, but only send 
> whatever it receives to the customer. While if the ingress PE 
> can't generate trunk conditioning, it should tell the egress 
> PE to generate it.
> 
> So there are only 2 cases, either the egress PE should or 
> should not generate trunk conditioning, depending on ingress 
> PE capabilities. That is why I asked for 2 L/M code points.
> 
[Sasha] Please note that the two cases you describe are 
hardly dynamic. So, instead of carrying some indications in the
data it is enough to configure the IWF to pass or not to pass
signals received over the TDM PW to the local NSP. Please
note that this does not increase the amount of local configuration,
when compared with your proposal, just move some configuration
from one end of the PW to the other. Note also that there is no need
to exchange the NSP capabilities and desired behavior during the
PW setup.
> > > > > > This does not mean that it will be accepted by the 
> IESG, and 
> > > > > > it does not 
> > > > > > The point here is to create a standard that can 
> re-use maybe 
> > > > > > part of the 
> > > > > > >>as in your case as the subframes have their own 
> sequencing 
> > > > > > (in the UUI
> > > > > > >>field).
> > > > > > >>
> > > > > > >>(you will see in a moment why I consider this a 
> fundamental 
> > > > > > question).
> > > > > > >>Are there separate set-up and maintenance 
> entities for this 
> > > > > > >>third level?

---

From: Shahram Davari <[email-masked]>
Date: Mon, 10 May 2004 07:41:40 -0700

Hi Sasha,

> Sent: Monday, May 10, 2004 11:25 AM
> To: Shahram Davari
 
SD-> Have a look at ATM Forum's af-vtoa-0078.000. It requires generating trunk conditioning
by the ATM network. So it is not restricted to DXCs. 

> appropriate signals by the structure-aware TDM PW.

OK, but a single flag can't tell the folowing to the PE:

1)A defect is detected at the other end, however you don't need to generate
any RDI/trunk conditioning
2) A defect is detected at the other end, and you need to generate
RDI/trunk conditioning
3)There is no problem at the other end.

> to exchange the NSP capabilities and desired behavior during the

This is avalid argument.

Yours,
-Shahram

> > > > > > > For example when many ATM VCs are transported as 
> one VP in 
> > > > > > a PW, they 
> > > > > > > are one flow, as they separate VCs have been 
> merged into a 
> > > > > > > single flow 
> > > > > > > in a PW.
> > > > > > > 
> > > > > > > same hardware to transport different types of 
> PWs. It seems 
> > > > > > > to me that 
> > > > > > > even the sequencing in the tdm drafts should 
> conform to the 
> > > > > > > rest of PWE3 
> > > > > > > designs.
> > > > > > > 
> > > > > > > >>We have already basically turned the PW into a 
> full-blown 
> > > > > > > >>layer network.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 10 May 2004 17:47:25 +0200

Shaharm and all,
Please see inline (marked SV-> to distinguish
from my earlier ones).

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, May 10, 2004 4:42 PM
> To: Sasha Vainshtein
SV->I am aware of that and also of the fact that af-vtoa-0078.000
includes the TDM NSP in the ATM CES IWF. Personally I prefer
the IETF reference model.
> > to exchange the NSP capabilities and desired behavior during the
SV-> I am glad we have reached some understanding.
> > > > > > > > Definely we never meant to have different 
> sequenced flows 
> > > > > > > in the same 
> > > > > > > > Note that I'm on vacation until monday , and 
> desperately 
> > > > > > > > attempting to

---

From: Shahram Davari <[email-masked]>
Date: Mon, 10 May 2004 08:02:31 -0700

Hi Sasha,

> Sent: Monday, May 10, 2004 11:47 AM
> To: Shahram Davari

SD-> No matter how you slice it, the PE MUST generate trunk conditioning
and not AIS/RDI for the structured mode.

> SV-> I am glad we have reached some understanding.

OK.

-Shahram
> > > > > > > > > Indeed there are differences in the drafts , 
> regarding 
> > > > > > > > > sequence numbers 
> > > > > > > > > >>You are proposing multiple sequenced and 
> unsequenced 
> > > > > > > > streams per PW.
> > > > > > > > > >>
> > > > > > > > > >>    
> > > > > > > > > >>
> > > > > > > > > >>Do I need VCCV, performance parameters, etc 
> for this 
> > > > > > new level?
> > > > > > > > > >>
> > > > > > > > > >>Taking over the job of a friend of ours :)  
>   I would 
> > > > > > > like to ask