Subject: Re: [PWE3] Transport of CAS over CESoPSN [RFC 5086]

From: Yaakov Stein <[email-masked]>
Date: Tue, 1 Dec 2009 20:16:01 +0200

> b) If the mechanism 5.3 necessary, why is not covered by the RFC 5087
> (TDMoIP) for AAL.1?
[[Sasha]] I cannot answer that, but I've added Yaakov Stein to the CC list.

Sorry for being out of email contact for a while.
If I understand the question correctly, you are asking why TDMoIP/AAL1 does not
add a CAS substructure similar to CESoPSN. This is because the AAL1 already has one
(it's called AAL1 structured with CAS).

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 1 Dec 2009 20:22:20 +0200

Javi, 

+ A PW CESoPSN or TDMoIP AAL1 can only carry TDM channels from a single 
TDM trunk (if a cross-connect is used to mix channels from different TDM 
trunks, this would not be visible to the TDMPW)

[YJS] This can be done, but it is not usually worth the effort for full trunks.
You may also get into trouble with the L and R indications.

+ A PW TDMoIP AAL2 is able to carry channels from different TDM trunks 
(identified by their CID). May these trunks be of different type (E1 and 
some other DS1, for example)?

[YJS] Yes, however you need to be careful if you mix ulaw and Alaw encoded voice.

If a TDMPW could transport channels from different TDM trunks, how may a 
single TDMPW carry error indicators (AIS, RDI) of all TDM trunks?. 

[YJS] It can't. What you can do is to indicate AIS with the L
and use the M field to modify it (not specified in the RFC),
and then rely on the data itself (where there are all-ones).

[YJS] A better way is to separate the trunks into timeslots,
and the indicate which timeslots are out of service using trunk conditioning
instead of AIS.
However, no solution is perfect.
That's what I meant when I said that it is usually not worth the effort.

Control Word (CW) may only carry error indicators from a trunk. So, may 
a single TDMPW emulate one or several TDM trunks?

[YJS] addressed above

---

From: Javi <[email-masked]>
Date: Tue, 01 Dec 2009 21:31:17 +0100

Yaakov Stein escribió:
> /[[Sasha]] I cannot answer that, but I've added Yaakov Stein to the CC 
> list./
>
The question was: CESoPSN (RFC 5086) defines two mechanism to transport 
CAS signalling:

  + "5.3.  Extending Basic NxDS0 Services with CE Application 
Signaling":  it may transport the state signalling of CEs, e.g., CAS for 
the telephony applications.
  + "5.4.  Trunk-Specific NxDS0 Services with CAS (CAS substructure)": 
it transport CAS signalling for the telephony applications.

However, TDMoIP AAL1 (RFC 5087) only provides the second one. Why is 
"Extending Basic NxDS0 Services with CE Application Signaling" not 
defined by RFC 5087?

Evenmore, for CESoPSN[RFC5086], RFC 5611 only mentions "CESoPSN basic 
mode" (0x0015) and "trunk-specific CESoPSN service with CAS" (0x0017), 
but not "5.3.  Extending Basic NxDS0 Services with CE Application 
Signaling". Why?

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 2 Dec 2009 22:57:52 +0200

Javi

As I explained in my last message, TDMoIP (5087) does not define a separate
signaling substructure at the PW level which can be transported either
with the data or in a separate packet. This substructure is always part
of the data stream since it is defined at the AAL1 level.

I'll leave for Sasha to explain why the L2TP document neglects one of the CESoPSN modes.

Y(J)S

----Original Message-----
From: Javi [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 22:31
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [PWE3] Transport of CAS over CESoPSN [RFC 5086]

Javi

---

From: Javi <[email-masked]>
Date: Thu, 03 Dec 2009 21:43:01 +0100

Hi Yaakov,

[Javi] Evenmore, for CESoPSN[RFC5086], RFC 5611 (and [RFC 4446]) only mentions "CESoPSN basic 
mode" (0x0015) and "trunk-specific CESoPSN service with CAS" (0x0017), 
but not "5.3.  Extending Basic NxDS0 Services with CE Application 
Signaling". Why?

[YJS] I'll leave for Sasha to explain why the L2TP document neglects one of the CESoPSN modes.

[Javi-new] I hope Sasha may respond.

[Javi] If trunk TDM is E1, for example (with N=31 timeslots for information), the payload of an PW CESoPSN or TDMoIP AAL1 may transport more than 31 octets, from two different trunks E1. Is it right?

[YJS] Yes.

[Javi-New] Ok. I suppose that the criterion that both PEs must agree to 
relate each byte of the PW payload with the timeslots from the trunks 
used is out of scope. Am I wrong?

[YJS] AAL2 is Loop Emulation (LES) and not Circuit Emulation (CES). It has no mechanism for indicating circuit level defects, as it does not emulate the circuit.

[Javi-new] Do you mean AAL2 may not emulate a TDM trunk?

I thought circuit level defects are indicated by control flags (L, R, M) 
from Control Word, so that, each TDMPW:

								May emulate
0x0011   Structure-agnostic E1 over Packet           One Full TDM Trunk per TDMPW (but no two trunks per TDMPW)
0x0012   Structure-agnostic T1 (DS1) over Packet     Idem
0x0013   Structure-agnostic E3 over Packet           Idem
0x0014   Structure-agnostic T3 (DS3) over Packet     Idem
0x0015   CESoPSN basic mode                          One Full E1/DS1 TDM Trunk per TDMPW, or one Nx64 service*
0x0017   CESoPSN TDM with CAS                        Idem with CAS signalling
0x0016   TDMoIP AAL1 Mode                            One Full E1/DS1 TDM Trunk per TDMPW, or one Nx64 service*
0x0018   TDMoIP AAL2 Mode                            One Full E1/DS1 TDM Trunk per TDMPW, or one Nx64 service*

* Nx64 services: "N" timeslots, from one or several TDM trunks, per TDMPW. Does it not include "circuit level defects"?

Regards,

Javi

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 5 Dec 2009 19:58:12 +0200

Javi,
Both RFC 5287 and RFC 5611 support setup of CESoPSN PWs that carry both TDM data and CE application signaling as described in Section 5.3 of RFC 5086.

However, they do not use (and, indeed, do not need) a separate PW type for that.

RFC 5287 uses for this purpose a  2-bit SP field in the "TDM Options" Interface Parameter sub-TLV (please see Figure 1 and Section 3.8 for details).
RFC 5611 uses for this purpose a 2-bit SP field in the TDM PW AVP (please see Section 2.1 for details).

In both cases the semantics of the SP field is the same:

 *   SP = '00' means that the corresponding CESoPSN PW is not associated with any CE application signaling
 *   SP = '01' means that the corresponding CESoPSN PW carries TDM data packets while CE application signaling is carried in a separate PW
 *   SP = '10' means that the corresponding  PW carries only CE application signaling packets for a CESoPSN PW, while TDM data is carried in a separate PW (that is set using SP = '01')
 *   SP = '11' means that both TDM data and CE signaling are carried in the same PW. The packets carrying TDM data and signaling packets are distinguished by the value of M bits in their respective CW as described in RFC 5086.

Hopefully this clarifies the misunderstanding.

Regards,
     Sasha

________________________________
From: Javi [mailto:[email-masked]]
Sent: Thursday, December 03, 2009 10:43 PM
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [PWE3] Transport of CAS over CESoPSN [RFC 5086]

Hi Yaakov,

[YJS] Yes.

[Javi-New] Ok. I suppose that the criterion that both PEs must agree to relate each byte of the PW payload with the timeslots from the trunks used is out of scope. Am I wrong?

I thought circuit level defects are indicated by control flags (L, R, M) from Control Word, so that, each TDMPW:

                                                                May emulate

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Sat, 12 Dec 2009 01:33:41 +0100

I'd appreciate a help to answer the following questions:

a) [YJS] AAL2 is Loop Emulation (LES) and not Circuit Emulation (CES). 
It has no mechanism for indicating circuit level defects, as it does not 
emulate the circuit.

Does it mean AAL2 may not emulate a TDM trunk? I thought circuit level 
defects are indicated by control flags (L, R, M) from Control Word, so 
that, each TDMPW:

                                                          May emulate
     0x0011   Structure-agnostic E1 over Packet           One Full TDM 
Trunk per TDMPW (but no two trunks per TDMPW)
     0x0012   Structure-agnostic T1 (DS1) over Packet     Idem
     0x0013   Structure-agnostic E3 over Packet           Idem
     0x0014   Structure-agnostic T3 (DS3) over Packet     Idem
     0x0015   CESoPSN basic mode                          One Full 
E1/DS1 TDM Trunk per TDMPW, or one Nx64 service*
     0x0017   CESoPSN TDM with CAS                        Idem with CAS 
signalling
     0x0016   TDMoIP AAL1 Mode                            One Full 
E1/DS1 TDM Trunk per TDMPW, or one Nx64 service*
     0x0018   TDMoIP AAL2 Mode                            One Full 
E1/DS1 TDM Trunk per TDMPW, or one Nx64 service*

  * Nx64 services: "N" timeslots, from one or several TDM trunks, per 
TDMPW. Does it not include "circuit level defects"?

b) Emulation service of fractional TDM trunk: What exactly?. I thought 
that indicates TDMPW emulates TDM circuit end to end, carrying only the 
channels in use in order to conserve bandwidth, but then it would not 
CBR, but VBR.

c) Besides manually or by management, how do I configure TDM channels 
which must carry a TDMPW, using the control plane?. For example, what 
L2TPv3 AVP should be used?

d) Is it true that SAToP and TDMoIP AAL.1 transparent mode offer CES 
(they emulate full TDM trunks)?

e) TDMoIP AAL.2:

+ In L2TPv3 TDMoIP AAL.2, how do you know the length of the payload 
TDMPW? (since it may contain a number of minicells dynamically variable).

+ ITU-T I.366.1 (SSCS for CCS) and I.366.2 (SSCS for bearer channel) are 
used?

+ what CID may be used to transport CCS, any CID data (9-255) or the CID 
8 (using I.366.1 SSCS)?

f) TDMoIP uses CIDs AAL.2 but in CESoPSN and TDMoIP AAL.1 SDT, how PEs 
identify TM channels carried on a TDMPW?. I think:
+ Each PE identifies the channels of its trunks through a couple: (TDM 
Port, position of the channel in the trunk).
+ For each TDM channel carried by a TDMPW, PE maintains, locally, a 1:1 
association between the previous pair and the "relative position with 
which the channel is carried in the payload TDMPW".
For output PE may reconstruct the same TDM trunks existing into inbound 
PE, both PEs should use a common approach to this identification of the 
channels.

Is this right?. Is it defined in a document or it is dependent on 
implementation?

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Sat, 12 Dec 2009 01:40:37 +0100

I have compiled a table (TDMPW.pdf) trying to summarize the main 
features of different types of TDMPW. I would appreciate any help on 
data not yet complete (in red) as well as any other comments.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 13 Dec 2009 06:48:20 +0200

Quite a lot of questions - my answers are interleaved below.

Y(J)S

From: Javi [mailto:[email-masked]]
Sent: Saturday, December 12, 2009 02:34
To: [email-masked]
Cc: Alexander Vainshtein; Yaakov Stein
Subject: TDM Channels and TDMPW Payload

a) [YJS] AAL2 is Loop Emulation (LES) and not Circuit Emulation (CES). It has no mechanism for indicating circuit level defects, as it does not emulate the circuit.

Does it mean AAL2 may not emulate a TDM trunk?
No, absolutely not. You can emulate a full trunk by emulating all of its channels.
However, you can also use AAL2 to glue together channels that do not come from a single trunk.

                                                          May emulate

Yes, trunk defects can be so indicated. If the AAL2 channels come from a single E1 or T1 you can use the L, R and M.

b) Emulation service of fractional TDM trunk: What exactly?. I thought that indicates TDMPW emulates TDM circuit end to end, carrying only the channels in use in order to conserve bandwidth, but then it would not CBR, but VBR.

I am not sure what you are asking. You can use CESoPSN and TDMoIP-AAL1 to emulate a fraction of a trunk - but the fraction
and which channels are transported, can not change. Using AAL2 allows you to dynamically add and remove channels as needed.

c) Besides manually or by management, how do I configure TDM channels which must carry a TDMPW, using the control plane?. For example, what L2TPv3 AVP should be used?

Sasha ?

d) Is it true that SAToP and TDMoIP AAL.1 transparent mode offer CES (they emulate full TDM trunks)?

Yes, as does CESoPSN.

e) TDMoIP AAL.2:

+ In L2TPv3 TDMoIP AAL.2, how do you know the length of the payload TDMPW? (since it may contain a number of minicells dynamically variable).

L2TPv3 TDMoIP has not been defined in the IETF.

+ ITU-T I.366.1 (SSCS for CCS) and I.366.2 (SSCS for bearer channel) are used?

I.366.2

+ what CID may be used to transport CCS, any CID data (9-255) or the CID 8 (using I.366.1 SSCS)?

CCS is usually NOT transferred inside the AAL2. Once again, AAL2 is a loop emulation service.
You can transfer the CCS using the appendix to RFC 5087, or any other means (e.g., static single channel TDMoIP-AAL1).

f) TDMoIP uses CIDs AAL.2 but in CESoPSN and TDMoIP AAL.1 SDT, how PEs identify TM channels carried on a TDMPW?. I think:
+ Each PE identifies the channels of its trunks through a couple: (TDM Port, position of the channel in the trunk).
+ For each TDM channel carried by a TDMPW, PE maintains, locally, a 1:1 association between the previous pair and the "relative position with which the channel is carried in the payload TDMPW".
For output PE may reconstruct the same TDM trunks existing into inbound PE, both PEs should use a common approach to this identification of the channels.

Is this right?. Is it defined in a document or it is dependent on implementation?

CES services do NOT try to identify the channels - the channels (if there are any) are transparently transported.
So all you have to do is to match up the trunks. The TDM end equipment knows how to pick out the channels.
If you need visibility of the channels, you need a loop (channel) emulation service.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 13 Dec 2009 06:57:00 +0200

Javi

I agree with most of your table.

There are 3 AAL1 types, called unstructured, structured, and structured with CAS.

A TDMoIP-AAL1 PW MAY be used to transfer more than one trunk (as we have discussed in the past)
although the L and R indications are no longer 1-1 with the AC defect indications.

AAL2 payload sizes are not constant, and thus there is no recommended size.

AAL2 can emulate a full trunk, of a fractional one, or many trunks 
(up to 248 channels, or 8 less if the newer reserved values are respected).

Note that AAL1 channels are fixed as in CESoPSN. I do not understand the difference you try to make there.
Only AAL2 can dynamically change the number of channels.

Y(J)S

-----Original Message-----
From: Javi [mailto:[email-masked]] 
Sent: Saturday, December 12, 2009 02:41
To: [email-masked]
Cc: Yaakov Stein; Alexander Vainshtein
Subject: Comparative table of different types of TDMPWs (SAToP, CESoPSN, TDMoIP AAL.1/AAL.2)

I have compiled a table (TDMPW.pdf) trying to summarize the main features of different types of TDMPW. I would appreciate any help on data not yet complete (in red) as well as any other comments.

Regards,

Javi

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 13 Dec 2009 07:47:12 +0200

Javi, Yaakov,
Yaakov, lots of thanks for detailed responses.
Javi, responding to the question that has been forwarded to me by Yaakov, and snipping all the rest for clarity (magenta italics).

Regards and best Hanukkah wishes,
     Sasha
________________________________
From: Yaakov Stein [[email-masked]]
Sent: Sunday, December 13, 2009 6:48 AM
To: Javi; [email-masked]
Cc: Alexander Vainshtein
... snipped ---

Sasha ?
[[Sasha]] As Yaakov has said in his email, structure-aware circuit emulation services (both CESoPSN and TDMoIP in the AAL1 mode)do not provide any indication of specific DS0 channels they carry across the PSN. All they care about is that the number of these channels matches between two PEs. In the case of MPLS PWs this is done by the BIt-Rate Interface parameter sub-TLV. In the case of CESopSN over L2TPv3, the same functionality is provided by the Bit Rate field in the TDM PW AVP. In both cases, PW setup will be rejected if these values differ.
... snipped to the end---

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 19:06:42 +0100

Thanks, some comments inline

[Javi] Does it mean AAL2 may not emulate a TDM trunk?

[YJS] No, absolutely not. You can emulate a full trunk by emulating all 
of its channels. However, you can also use AAL2 to glue together 
channels that do not come from a single trunk.

[Javi-New] Then I'm confused. You say "AAL2 does not emulate the 
circuit. but "AAL2 can emulate a full trunk". For me, a TDM circuit and 
a TDM trunk are the same. Which is the difference?

[Javi] I thought circuit level defects are indicated by control flags 
(L, R, M) from Control Word, so that, each TDMPW:

                                                          May emulate

[YJS] Yes, trunk defects can be so indicated. If the AAL2 channels come 
from a single E1 or T1 you can use the L, R and M.

[Javi-New] ITU-T Recommendation Y.1452 (clause 8.3.1),  describing 
TDMoIP AAL.2, indicates bits R, M of the CW are reserved (value always 
0). If indeed a TDMPW AAL.2 can emulate a full trunk, where does it 
carry circuit level defects?

b) [Javi] Emulation service of fractional TDM trunk: What exactly?. I 
thought that indicates TDMPW emulates TDM circuit end to end, carrying 
only the channels in use in order to conserve bandwidth, but then it 
would not CBR, but VBR.

[YJS] I am not sure what you are asking. You can use CESoPSN and 
TDMoIP-AAL1 to emulate a fraction of a trunk -- but the fraction

and which channels are transported, can not change. Using AAL2 allows 
you to dynamically add and remove channels as needed.

[Javi-New] I detail my question. RFC 5087, clause 5.2: "Although AAL1 
may be configured to transport fractional E1 or T1 circuits...". Also, 
ITU-T Recommendation Y.1453 (clause 7.1) indicates a "TDMPW" (TDM stream 
exactly) must be able to carry "N × 64 k" and "Fractional DS1/E1". Which 
is the difference between a fractional TDM circuit and a Nx64 
(application/service)?

e) [Javi] In L2TPv3 TDMoIP AAL.2, how do you know the length of the 
payload TDMPW? (since it may contain a number of minicells dynamically 
variable).

[YJS] L2TPv3 TDMoIP has not been defined in the IETF.

[Javi-New] RFC 5087 (clause 4.3) defines the data plane for a TDMPW 
based on L2TPv3. Under the protocol stack that there is proposed, how do 
you know the payload length (variable)  of each TDMPW?

[Javi] In TDMoIP AAL.2, ITU-T I.366.1 (SSCS for CCS) and I.366.2 (SSCS 
for bearer channel) are used?

[YJS] I.366.2

[Javi-new] When CCS signalling is carried by TDMPW in transparent mode 
(not in HDLC mode), If AAL2 carries CCS signaling  using I.366.1 
(SSCSAR), it would use I.366.1. Is not that correct?

f) [JYS] CES services do NOT try to identify the channels -- the 
channels (if there are any) are transparently transported.

So all you have to do is to match up the trunks. The TDM end equipment 
knows how to pick out the channels.

If you need visibility of the channels, you need a loop (channel) 
emulation service.

[Javi-New] Then, how does output PE identify TDM trunk of  input PE to 
which TDMPW is associated?

Regards

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 19:10:23 +0100

> /[[Sasha]] As Yaakov has said in his email, structure-aware circuit 
> _emulation_ services (both CESoPSN and TDMoIP in the AAL1 mode)do 
> not provide any indication of specific DS0 channels they carry across 
> the PSN. All they care about is that the number of these channels 
> matches between two PEs. In the case of MPLS PWs this is done by the 
> BIt-Rate Interface parameter sub-TLV. In the case of CESopSN over 
> L2TPv3, the same functionality is provided by the Bit Rate field in 
> the TDM PW AVP. In both cases, PW setup will be rejected if these 
> values differ. /
>
And for TDMoIP AAL.2?

Regards,

Javi

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Dec 2009 21:26:39 +0200

Yaakov,
Could you please answer the question about TDMoIP in AAL2 mode?

Regards,
     Sasha

________________________________
From: Javi [[email-masked]]
Sent: Monday, December 14, 2009 8:10 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; [email-masked]
Subject: Re: TDM Channels and TDMPW Payload

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 21:39:43 +0100

I detailed the question. The channel identification is performed by 
CIDs. The relationship between TDM trunks and CIDs may be:
+ Static: only values "9-255", or "8" and "0-7 "may be used?
+ Dynamic: may ELCP[af-vmoa-145.001] (CID 8) or Q.AAL2[Q.2630.1] (CID 2) 
be used?

Regards

Alexander Vainshtein escribió:
> ------------------------------------------------------------------------
> *From:* Javi [[email-masked]]
> *Sent:* Monday, December 14, 2009 8:10 PM
> *To:* Alexander Vainshtein
> *Cc:* Yaakov Stein; [email-masked]
> *Subject:* Re: TDM Channels and TDMPW Payload
>
>
>>

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 14 Dec 2009 22:58:32 +0200

Sasha and Javi

As we said before, AAL2 mode is not defined for L2TPv3.

For the MPLS case there is a parameter called the TDMoIP AAL2 Options that
can be used to signal the mapping between CIDs and timeslots for the simplest cases
(e.g. a single trunk, or several trunks, with CIDs in timeslot order).
Anything more complex than that will require a management system.

Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, December 14, 2009 21:27
To: Javi
Cc: Yaakov Stein; [email-masked]
Subject: RE: TDM Channels and TDMPW Payload

Yaakov,

Regards,
     Sasha

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 14 Dec 2009 23:08:37 +0200

[Javi-New] Then I'm confused. You say "AAL2 does not emulate the circuit. but "AAL2 can emulate a full trunk". For me, a TDM circuit and a TDM trunk are the same. Which is the difference?

AAL2 emulates each timeslot separately. It is thus a Loop (timeslot) Emulation Service.
In particular, individual timeslots may not be transferred at all, or may hold trunk conditioning to show that they are idle.
You can USE AAL2 to emulate an entire trunk by emulating all the timeslots in that trunk,
but in general you will lose the native trunk-level defect indications.
That is why Y.1452 says that the trunk level flags are not used - since in the general case they have no meaning
(since the timeslots may not come from the same physical trunk!).
However, as I said, there is no reason NOT to use them in the particular case that all the timeslots
happen to come from the same TDM trunk.

[Javi-New] RFC 5087 (clause 4.3) defines the data plane for a TDMPW based on L2TPv3. Under the protocol stack that there is proposed, how do you know the payload length (variable)  of each TDMPW?

You will not know the length of the entire payload for AAL2 payloads. Each minicell has its own length,
and since they are concatenated in the MPLS packet, you have to parse each minicell as it comes.
The final one should end precisely on the end of the MPLS packet. If that does not happen you have a malformed
packet error.

[Javi-new] When CCS signalling is carried by TDMPW in transparent mode (not in HDLC mode), If AAL2 carries CCS signaling  using I.366.1 (SSCSAR), it would use I.366.1. Is not that correct?

I think that I was clear in saying that this should not be done.

[Javi-New] Then, how does output PE identify TDM trunk of  input PE to which TDMPW is associated?

I think that Sasha answered this already.

Y(J)S

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 22:34:03 +0100

> There are 3 AAL1 types, called unstructured, structured, and structured with CAS.  
[Javi] I agree. And, for CESoPSN, there are basic service, basic service 
with CE signalling, and basic service with CAS. But I thought it was 
better grouping them. Do you think they should be in separate columns?
> although the L and R indications are no longer 1-1 with the AC defect indications.
[Javi] I suppose you refer to CESoPSN and AAL.1 TDMoIP. And, why not the 
same for TDMoIP AAL.2 (in a previous email, we have said "AAL2 can 
emulate a full trunk and carries channels from different trunks)?
> AAL2 payload sizes are not constant, and thus there is no recommended size.
[Javi] I don't understand why. TDMoIP AAL.1 may carry N channels from a 
TDM trunk, same as TDMoIP AAL.2, and both may emulate a TDN trunk. If it 
is recommended "1 to 8" (E1/DS1) or "5 a 15" (E3/DS3) SARPDUs for ALL1, 
how many CS-PDUs (or minicells) are recommended for TDMoIP AAL.2 when 
E1/DS1 is emulated?

[Javi] Which is the recommended size for the payload of a CESoPSN PW in 
CAS mode?
> (up to 248 channels, or 8 less if the newer reserved values are respected).
[Javi] Which are the newer reserved values?
> Only AAL2 can dynamically change the number of channels.
[Javi] I tried to emphasize that only AAL.2 can dynamically change the 
channels. CESoPSN, TDMoIP AAL.1 in SDT mode, and TDMoIP AAL.2 can 
emulate a full trunk, of a fractional one, or many trunks

[Javi] ITU-T Recommendation Y.1453 (clause 7.1) indicates a "TDMPW" (TDM 
stream exactly) must be able to carry "N × 64 k" and "Fractional 
DS1/E1". Which is the difference between a fractional TDM circuit and a 
Nx64 (application/service)?

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 22:42:14 +0100

Thanks. Any about this?

[Javi-New] ITU-T Recommendation Y.1452 (clause 8.3.1),  describing 
TDMoIP AAL.2, indicates bits R, M of the CW are reserved (value always 
0). The, if a TDMPW AAL.2 can emulate a full trunk, where does it carry 
circuit level defects?

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 22:51:36 +0100

> circuit. but "AAL2 can emulate a full trunk". For me, a TDM circuit 
> and a TDM trunk are the same. Which is the difference?
>
>  
>
> In particular, individual timeslots may not be transferred at all, or 
> may hold trunk conditioning to show that they are idle.
>
> That is why Y.1452 says that the trunk level flags are not used -- 
> since in the general case they have no meaning
>
Ok, I understand flags in TDMoIP AAL.2 are not used in general (ITU-T 
Y.2452), but it could be used in the particular case that all the 
timeslots. However, in this particular case, AAL.2 would be offering a 
service CES, not LES. Or is there any difference that I see?

Regards

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 15 Dec 2009 08:28:51 +0200

Javi

I interleave my answers to some of your questions below.

Y(J)S

[Javi] I don't understand why. TDMoIP AAL.1 may carry N channels from a TDM trunk, same as TDMoIP AAL.2, and both may emulate a TDN trunk. If it is recommended “1 to 8” (E1/DS1) or “5 a 15” (E3/DS3) SARPDUs for ALL1, how many CS-PDUs (or minicells) are recommended for TDMoIP AAL.2 when E1/DS1 is emulated?

You are missing the point behind AAL2. In AAL2 we only send active channels (where channels may be defined as active
by various NSP functions, e.g. signaling indicating that there is a call in progress, VAD, etc.).
This reduces the bandwidth consumed. In the extreme case there may be NO channels.

So the number of channels changes from moment to moment.
If you want to recommend a size, then use AAL1 or CESoPSN.

ATM Forum specification af-vmoa-0145.001 (2003), Loop Emulation Service Using AAL2 Rev 1
reserves CIDs 8-15 as well.

[Javi] ITU-T Recommendation Y.1453 (clause 7.1) indicates a "TDMPW" (TDM stream exactly) must be able to carry "N × 64 k" and "Fractional DS1/E1". Which is the difference between a fractional TDM circuit and a Nx64 (application/service)?

A fractional E1 or T1 is just that – e.g., half an E1 or quarter T1.
N*64 is simply N 64kbps streams without the necessity of any connection between them.
For example, you might have 4 microphones, or 6 devices with 64kbps ports.

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 15 Dec 2009 08:36:15 +0200

Ok, I understand flags in TDMoIP AAL.2 are not used in general (ITU-T Y.2452), but it could be used in the particular case that all the timeslots. However, in this particular case, AAL.2 would be offering a service CES, not LES. Or is there any difference that I see?

Although the AAL2 emulates a circuit, it is not a circuit emulation service in the usual sense.
In particular

1)       it is variable bitrate

2)       it does not accurately reproduce the values in timeslots not being transferred
                  (e.g., if a timeslot has a voice service and we are using VAD there is no connection between the Alaw/uLaw values
                    in the egress  timeslot and the ingress ones, although it sounds correct to the ear)

3)       frequently other functions are employed, e.g. speech compression, which means that even in active channels the egress values are not the ingress ones

4)       there are additional functions that need to taken into account, e.g. heartbeats and CNG

5)       there is the possibility of CID switching without TDM NSPs.

Y(J)S

---

From: Javi <[email-masked]>
Date: Thu, 17 Dec 2009 16:13:30 +0100

Ok.

Related to this. For CES in SDT mode (CESoPSN or TDMoIP AAL.1), 
transported channels are static from the standpoint of TDMPW. However, 
could cross-connects (NSP) be used  to be changing (for management or 
manual configuration) the channels carried by a TDMPW, although this is 
not aware of the change?. In this case, the channels carried by CES may 
change dynamically.

Regards,

Javi

Yaakov Stein escribió:
>                   (e.g., if a timeslot has a voice service and we are 
> using VAD there is no connection between the Alaw/uLaw values
>
> 3)       frequently other functions are employed, e.g. speech 
> compression, which means that even in active channels the egress 
> values are not the ingress ones
>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 17 Dec 2009 17:16:42 +0200

Javi

A TDM cross-connect is an NSP function, and is transparent to the PWE devices.
So it is perfectly fine for a DXC to change the timeslot sources, and even structure-agnostic PWs
will continue to transport the trunks.

The difference between AAL2 and the other modes is that the NUMBER of timeslots transported can change,
and that the PE (or wherever the PW IWF is) is active in the timeslot mappings.

Y(J)S

From: Javi [mailto:[email-masked]]
Sent: Thursday, December 17, 2009 17:14
To: [email-masked]
Cc: Yaakov Stein
Subject: Re: TDM Channels and TDMPW Payload

Ok.

Related to this. For CES in SDT mode (CESoPSN or TDMoIP AAL.1), transported channels are static from the standpoint of TDMPW. However, could cross-connects (NSP) be used  to be changing (for management or manual configuration) the channels carried by a TDMPW, although this is not aware of the change?. In this case, the channels carried by CES may change dynamically.

Regards,

Javi

Yaakov Stein escribió:

it is variable bitrate

it does not accurately reproduce the values in timeslots not being transferred
                  (e.g., if a timeslot has a voice service and we are using VAD there is no connection between the Alaw/uLaw values
                    in the egress  timeslot and the ingress ones, although it sounds correct to the ear)

frequently other functions are employed, e.g. speech compression, which means that even in active channels the egress values are not the ingress ones

there are additional functions that need to taken into account, e.g. heartbeats and CNG

there is the possibility of CID switching without TDM NSPs.

Y(J)S

---

From: Javi <[email-masked]>
Date: Mon, 14 Dec 2009 22:30:42 +0100

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 17 Dec 2009 17:54:49 +0100

> [Javi] Which is the difference between a fractional TDM circuit and a 
> [JYS] A fractional E1 or T1 is just that – e.g., half an E1 or quarter T1.
>

Then, I do not understand why ITU-T Y.1453 clasifies ISDN bearer 
services in circuit mode as Nx64 TDM traffic, and unstructured one. They 
use channelized E1/DS1 (hence structured).

== Clause 7.1

c) The ability to transport the following unstructured TDM types:
    5) N × 64 k (i.e., for N = 1 as defined in ITU-T Rec. I.231.1 [17], 
for N = 2 as defined in
       ITU-T Rec. I.231.5 [37], for N = 3 as defined in ITU-T Rec. 
I.231.10 [38] and for
       N = 6 as defined in ITU-T Rec. I.231.6 [39]);

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 17 Dec 2009 19:00:45 +0200

Then, I do not understand why ITU-T Y.1453 clasifies ISDN bearer services in circuit mode as Nx64 TDM traffic, and unstructured one. They use channelized E1/DS1 (hence structured).

You are bringing up an interesting point.
Y.1453 (which I edited) allows carrying ISDN bearer services as structured N*64
(without the need to call out that they ARE ISDN),
but it also allows unstructured transport of ISDN services which have their own physical interfaces.
For example, 2B+D at 144kbps. Participants at the time brought up various other physical interfaces
that are defined, but perhaps not widely deployed. They too may be carried in an unstructured way.

Y(J)S