Subject: Re: [PWE3] TDMoPW (RFC 5086, RFC 5087, ...): supported TDM trunks

From: Yaakov Stein <[email-masked]>
Date: Mon, 1 Dec 2008 13:05:12 +0200

Javi

I am not quite sure what your question is.
If you are asking whether different standards support different TDM types, the answer is yes.

The requirements RFC covers pretty much everything.

SONET/SDH is covered in RFC 4842.

SAToP covers all PDH.

CESoPSN and TDMoIP can carry E1 and T1,
while TDMoIP can also carry E3 and T3.

Y.1413 and Y.1453 incorporates SAToP, CESoPSN and TDMoIP,
and also allows all PDH types that the ITU defines.

N*DS0 is defined in ITU Recommendations for small enough N,
and thus this is also covered in CESoPSN and TDMoIP structure-aware modes.

As I have told you before, PWE does NOT define the NSP,
and thus anything which is not TDM - 
including multiple separate TDM streams and serial streams at rates not defined in G.702, 
is NOT defined in PWE documents.

Y(J)S

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Javi [[email-masked]]
Sent: Thursday, November 27, 2008 9:11 PM
To: [email-masked]
Subject: [PWE3] TDMoPW (RFC 5086, RFC 5087, ...): supported TDM trunks

I have found different references about TDM trunks must be transported
by each TDMPW:

+ RFC 4197 (Requirements for Edge-to-Edge Emulation of TDM Circuits over
PSN), chapter 5: indicates
   "E1, T1, E3, T3" and "NxDS0 with or without CAS" for PDH,
"VC-11/VC-12/VC-2/VC-3/VC-4, VC-4-4c,
      VC-4-16c, VC-4-64c" for SDH.

+ RFC 4553 (SAToP): indicates T1, E1, T3, E3 trunks.

+ RFC 5086 (CESoPSN): only indicates "E1" and "T1" (ESF and SF) trunks

+ RFC 5087 (TDMoIP AAL1, AAL2): indicates "E1, T1, E3, T3"  (and
fractional E1, fractional T1).

+ ITU-T Y.1453 (with packet format aligned with RFC 5086 for PSN
UDP/IP), chapter 7.1:
    - unstructured TDM: E1, DS1 (T1), DS2, E3, DS3, Nx64 and
"Synchronous serial data" (V.36 and V.37).
    - structured TDM: E1 (and fractional E1), DS1 (and fractional DS1),
DS2 and "Multiple synchronous DS0s".

So, I think they are not consistent among themselves:

1) DS2 is only indicated by ITU-T Y.1453.

2) SDH is only indicated by RFC 4197.

3) RFC 5087 indicate E1/T1 and E3/T3, but RFC 5086 only E1/T1.

4) In that context, what means exactly "NxDS0"?

5) And "Multiple synchronous DS0s"?

6) And "Synchronous serial data"?

I think it would be necessary to clarify the TDM trunks may be supported
by each TDMPW (apart from
fractional or no, and "NxDS0 Services" or no).

Regards,

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

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 1 Dec 2008 13:10:20 +0200

Javi

When the AAL1 PDUs are carried over ATM, then lost or mosirodered ATM cells 
are detected using the AAL1 sequence number.

For that reason, the 3-bit AAL1 sequence number limits the packet burst loss at 8
(preferably less).

When carrying AAL1 PDUs over PWs we rely on the PW sequence number to detect
packet loss of misorder. When a PW packet is lost the PW IWF fills in the missing TDM data.
Thus the AAL1 sequence number is only for backwards compatibility
and for interworking between TDM and ATM networks.

Y(J)S

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Javi [[email-masked]]
Sent: Thursday, November 27, 2008 9:31 PM
To: [email-masked]
Subject: [PWE3] TDMoPW (RFC 5087 and IT-T Y.1453): TDMoIP AAL1 sequence number mechanism

ITU-T 1.453, Appendix IV, indicates:

+ Using eight or more PDUs per packet invalidates the use of the AAL 1
sequence number
+ mechanism, and hence complicates interworking with ATM-based CES systems.

That is not mentioned by RFC 5087:

+ Why does it not appear on RFC 5087?

+ Why is "AAL 1 sequence number mechanism" invalidated if there are 8 or
more SAR-PDUs
  per TDMPW packet?. The NS field in SAR-PDU header is 3 bits, but I
don't understand the resason,
  and even less when ITU-T Y.1453 (and RFC 5087) suggests between 5 and
15 PDUs per packet for
  E3 and DS3 circuits.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 1 Dec 2008 13:27:25 +0200

Two questions:

I) RFC 5087, chapter 3.6 (TDMoIP AAL2 Options), establishes:

    + CID mapping bases is an OPTIONAL parameter; its existence and length
    +   are determined by the length field.  If the mapping of AAL2 CID
    +   values to a physical interface and time slot is statically
    +   configured, or if AAL2 switching [Q.2630.1] is employed, this
    +   parameter MUST NOT appear.

About that:

a) If mapping of AAL2 CID values to a physical interface and time slot
is statically configured:
  a.1) may it only be manually or by management?, or is it possible by
signalling?
[YJS] manual or signalled. See RFC 5287 for a possible signaling method for the MPLS case.

  a.2) If signalling is possible, what would Sub-TLV (MPLS, RFC5287) or AVPs
        (L2TPv3, draft-ietf-l2tpext-tdm-06) be used?
[YJS] We never defined the AAL2 signaling for L2TPv3. If you want to do so, please go ahead.

b.1) Is it possible to employ AAL2 switching [Q.2630.1] over a TDMoIP AAL.2?
[YJS} Yes, but only with the PEs as switching points.
b.2) Where is Q.2630.1 signalling transported?
[YJS] At the PEs. No P-routers are aware of the PW payload.
b.3) In which node is switching done? (each TDMPW is defined between two
PEs, without other PW nodes among them)
[YJS] Precisely. You can use AAL2 switchingn when the AAL2 PW is part
of the AAL2 end-to-end path. You can pick between PWs, or between a PW and an ATM network.

II) RFC 5087, Chapter 10 (Applicability Statement) establishes:

    + Data in inactive channels is not transported in AAL2 mode, and thus
    + this data will differ from that of the native service.

    What does it means?. As far as I know, ATM AAL.2 (ITU-T Y.363.2)
doesn't transport either inactive channels, then the same as AAL2 TDMoIP TDMPWs.

[YJS] You are missing the point. The AAL2 mode is not transport of AAL2 minicells
over MPLS or IP. It is a method of transporting channelized TDM. When replacing the
native TDM service with an AAL2-based one, the bits in inactive channels
(as well as the silence in active channels when using VAD) are not conserved.

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Mon, 01 Dec 2008 18:54:43 +0100

Yaakov,
> I) RFC 5287, chapter 3.6 (TDMoIP AAL2 Options), establishes:
>
In fact, the text above come from RFC 5287. In summury, I understand 
that "mapping of AAL2 CID values to
a physical interface and time slot" may be configured:

+ Statically (manually, by management, or signalled)

+ Using the optinal parameter "CID mapping bases"

+ Dinamically: with the "AAL type 2 signalling protocol" (Q.2630.1)

Furthermore, ATM Forum af-vmoa-0145.001 (Loop Emulation Service Using AAL2
Rev 1), chapter 4.4 (Assignment Of AAL2 Channels, CID Allocation), 
indicates allocation of CIDs
may be done when:

+ ELCP protocol is not used (chapter 4.4.2): it establishes several CID 
intervals for digital trunks,
D-channels for ISDN BRI and ISDN BRI.

[Question 1] Why are this intervals not used as default values for the 
parameter "CID mapping bases"?

+ ELCP protocol is used, chapter 5.3.1.1 (Emulated Loop Control Protocol 
– Channel Allocation Procedure)

[Question 2] May ELCP protocol be used in TDMoIP AAL2 for mapping of 
AAL2 CID values to
a physical interface and time slot?, is ELCP equivalent to Q.2630.1 for 
that mapping?
(As far as I know,ELCP is transported CID=8 and Q.2630.1 is transported 
over CID=2, Is it so?)

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Mon, 01 Dec 2008 19:09:02 +0100

> (as well as the silence in active channels when using VAD) are not conserved.
Ok, "native service" means "TDM service" (not AAL.2). Then, I agree. 
However, that "chapter 10" starts with:

+ It must be recognized that the emulation provided by TDMoIP may be 
imperfect. ...

And I don't think this is an imperfection of the emulation
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Javi <[email-masked]>
Date: Mon, 01 Dec 2008 19:17:32 +0100

Yaakov Stein escribió:
> Javi
>
> There were long discussions on the issue of the length field.
>
> You are missing an essential point by considering only the IP case.
>
> Consider what happens when the TDM PW is over MPLS.
> Then you don't know precisely the size of the headers,
> since you don't know if there are 0, 1, 2, ... tunnel headers.
>
> So you are right - the proper action would be to look at the length of entire Ethernet payload,
> but this length is in general unknown to the IWF in charge of the PW processing. 
> Only the length of payload + CW + PW label is known.
>
> It was decided to err on the safe side.
> Furthermore, since the PW processor wil in general not know what transport layer will be used
> (MPLS, IP, pure layer 2 Ethernet, other), this same strategy was used in the IP case as well.
But the IWF knows the PW type (it has been configurated when the PW has 
been established), So,
it would be possible to indicate a different behavoiur depending on the PSN:

+ PSN=IP, L2TPv3 and pure layer 2 Ethernet: LEN field may be zero if 
"IP, PW Label, RTP, CW" headers + Payload >= 46 bytes"

+ PSN=MPLS: LEN=0 if "CESoPSN header + the payload size" < 64 bytes

which is more efficient (it adds less padding).

Javi

---

From: Javi <[email-masked]>
Date: Mon, 01 Dec 2008 19:28:18 +0100

Yaakov,
> while TDMoIP can also carry E3 and T3.
Structured or unstructured E3/T3?
> and also allows all PDH types that the ITU defines.
Y.1453 covers structured T2 but not structured T3. And PWE3 covers T3 
but not T2. Which is
the reason of this?. Protocol stacks in Y.1453 are the same as the 
protocol stacks in PWE3 when
PSN is UDP/IP.
> and thus this is also covered in CESoPSN and TDMoIP structure-aware modes.
Are ITU-T "N*DS0" and RFC "Basic NxDS0 Services" not the same?
> is NOT defined in PWE documents.
The same. If protocol stacks in Y.1453 and PWE3 (when PSN is UDP/IP) are 
the same, why are they not cover in PWE?

Javi

---

From: Javi <[email-masked]>
Date: Mon, 01 Dec 2008 19:39:43 +0100

Yaakov,

+ Using eight or more PDUs per packet invalidates the use of the AAL 1
+ sequence number mechanism, and hence complicates interworking with
+ ATM-based CES systems.

> and for interworking between TDM and ATM networks.
As ITU-T I.363.1 indicates, when the AAL1 PDUs are carried over ATM , 
each cycle is
"8 SAR-PDUs" (from "SN=0" to "SN=7").

If more than 8 SAR-PDUs (several cycles) are transported per TDMPW 
packet, the sequence number
may be kept for interworking with ATM-based CES systems, although PW 
sequence number
is used to detect packet loss of misorder. Which is the problem of this? 
(use of the AAL 1
sequence number mechanism would be valid, although it is not used for 
detecying lost or
mosirodered ATM cells).

Javi

---

From: Javi <[email-masked]>
Date: Tue, 02 Dec 2008 18:24:55 +0100

Javi escribió:
> CESoPSN, Chapter "4.2.  PSN and Multiplexing Layer Headers":
>
>    + CESoPSN implementations working with IPv4 PSN MUST set the "Don't
>    + Fragment" flag in IP headers of the packets they generate.
>
>    Why is IP fragmentation not allowed? 
Javi

---

From: Javi <[email-masked]>
Date: Tue, 02 Dec 2008 18:25:09 +0100

Chapter "4.1.  CESoPSN Packet Format" indicates:

a) For PSN UDP/IP, "RTP must be placed immediately after the UDP header,
     then CW is after RTP (UDP/RTP/CW)":

   +   1.  Compliance with the existing header compression mechanisms for
   +       IPv4/IPv6 PSNs with UDP demultiplexing requires placing the RTP
   +       header immediately after the UDP header.

I agree.

b) For PSN L2TPv3/IP or MPLS, "CW must be placed immediately after the PW
      label, then RTP is after CW (PW Label/CW/RTP)":

   +   2.  Compliance with the common PWE3 mechanisms for keeping PWs Equal
   +       Cost Multipath (ECMP)-safe for the MPLS PSN by providing for PW-
   +       IP packet discrimination (see [RFC3985], Section 5.4.3).  This
   +       requires placing the PWE3 control word immediately after the PW
   +       label.

   + 3.  Commonality of the CESoPSN packet formats for MPLS networks and
   +       IPv4/IPv6 networks with Layer 2 Tunneling Protocol Version 3
   +       (L2TPv3) demultiplexing facilitates smooth stitching of L2TPv3-
   +       based and MPLS-based segments of CESoPSN PWs (see [PWE3-MS]).

I don't understand why the indicated reasons are enough. Is it possible a
more precise explanation?

Javi

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Dec 2008 20:13:51 +0000

Javi
>   +       requires placing the PWE3 control word immediately after the PW
Some LSRs peek beyond the bottom label and hash the IP header to  select
the ECMP path. We stop this from happening by setting the first nibble
of the CW to 0 (or 1 if it is an ACH). This looks to the LB system
like an IPv0 (1) pkt which disengages the  LB and means that all the
pkts from the PW go on the same path.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Dec 2008 20:14:56 +0000

Javi

Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 2 Dec 2008 15:38:01 -0500

Javi,
CESoPSN has its own fragmentation procedures, based on those in RFC 4623.
See section 5.1 in that RFC for a discussion of PW-layer fragmentation vs.
IP fragmentation.

Cheers,
Andy

---

From: Javi <[email-masked]>
Date: Wed, 03 Dec 2008 18:39:05 +0100

Andy,

RFC: 4623, chapter "5.1.  PW-Specific Fragmentation vs. IP fragmentation":

   If the overall traffic
   requiring fragmentation and reassembly is very light, or there are
   sufficient optimized mechanisms for IP PSN fragmentation and
   reassembly available, IP PSN fragmentation and reassembly may be
   sufficient.

   Deployments SHOULD avoid a situation that uses a combination of IP
   PSN and PW fragmentation and reassembly on the same node

So, it is possible to use "IP fragmentation" (when PW fragmentation is 
not used).

Why does CESoPSN indicates that IP fragmentation must never been used?

Javi

Andrew G. Malis escribió:
> Javi,
>
> CESoPSN has its own fragmentation procedures, based on those in RFC 
> 4623. See section 5.1 in that RFC for a discussion of PW-layer 
> fragmentation vs. IP fragmentation.
>
> Cheers,
> Andy
>
> On Tue, Dec 2, 2008 at 12:24 PM, Javi <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Javi escribió:
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 3 Dec 2008 15:17:27 -0500

Javi,
That was a design choice made by the CESoPSN authors (and agreed to in the
WG) because in this specific case, it's so much more efficient than IP
fragmentation, which is an important consideration for this application.

Cheers,
Andy

On Wed, Dec 3, 2008 at 12:39 PM, Javi <[email-masked]> wrote:

> So, it is possible to use "IP fragmentation" (when PW fragmentation is not
> used).
>
>> On Tue, Dec 2, 2008 at 12:24 PM, Javi <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>    Javi escribió:
>>

---

From: Javi <[email-masked]>
Date: Thu, 04 Dec 2008 18:44:31 +0100

Chapter "4.3.  CESoPSN Control Word" indicates:

   + LEN (bits (10 to 15) MAY be used to carry the length of the CESoPSN
   +  packet (defined as the size of the CESoPSN header + the payload size)
   +  if it is less than 64 bytes, and MUST be set to zero otherwise.
   + Note:  If fixed RTP header is used in the encapsulation, it is
   + considered part of the CESoPSN header.

I think it is so because PW processor will in general not know what 
transport layer will be used
and when the TDM PW is over MPLS, it don't know precisely the size of 
the headers,
since it don't know if there are 0, 1, 2, ... tunnel headers

[Question:]
But, why does IWF not know the transport layer used? (IWF must analize 
that layers).

Javi

---

From: Javi <[email-masked]>
Date: Thu, 04 Dec 2008 19:04:23 +0100

According each document, PDH TDM trunks may be transported by a TDMPW 
depend on its type:

+ RFC 4197 (Requirements for Edge-to-Edge Emulation of TDM Circuits over 
PSN),
  chapter 5: TDM trunks may be transported:
    - "E1, T1, E3, T3" and "NxDS0 with or without CAS" for PDH

+ RFC 4553 (SAToP): may be transported T1, E1, T3, E3 trunks (unstructured
  o channalized, only agnostic mode)

+ RFC 5086 (CESoPSN): may be transported "E1" and "T1" (ESF and SF) trunks
 (channalized, only SDT mode)

+ RFC 5087 (TDMoIP AAL1, AAL2): may be transported "E1, T1, and 
fractional E1,
  fractional T1" (agnostic and SDT modes) and "E3, T3"  (only agnostic 
mode)

+ ITU-T Y.1452, Y.1453 (with packet format aligned with SAToP, CESoPSN and
  TDMoIP for PSN UDP/IP), chapter 7.1:
   - unstructured TDM:
        * E1, T1, T2, E3, T3
        * Nx64, 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]);
        * "Synchronous serial data" (V.36 and V.37).
   - structured TDM:
        * E1 (and fractional E1), T1 (and fractional DS1), T2
        * Multiple synchronous DS0s.

[Question:]
If protocol stacks in Y.1453 and TDMoPW (SAToP, CESoPSN, TDMoIP) are the 
same (when PSN is UDP/IP),
why are supported native TDM services different?

- T2 (structured and unstructured) is covered by Y.1453, and not by TDMoPW.

- Structured E3/T3 are covered by TDMoPW, and not by Y.1453.

- Synchronous serial data (V.36 and V.37) is only cover by Y.1453, and 
not by TDMoPW.

- Multiple synchronous DS0s is only cover by Y.1453, and not by TDMoPW

Javi

---

From: Javi <[email-masked]>
Date: Thu, 04 Dec 2008 19:20:15 +0100

ITU-T Y.1453 (chapter 7.1) indicates:

For transfer of TDM streams over IP networks, it is required
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]);

IETF RFC 5086, Chapter 5.2 (Basic Nx64 Services) indicates:

   the basic structure preserved across the PSN for
   this service consists of N octets filled with the data of the
   corresponding NxDS0 channels belonging to the same frame of the
   originating trunk(s), and the service generates 8000 such structures
   per second.

CESoPSN covers the transport of channalized TDM E1/T1.

[Question:]

"Nx64 TDM mentioned by ITU-T Y.1453" are different channels. Then, why 
is it classified
as "unstructured TDM type" insteed of "structured TDM" (included in 
Basic Nx64 Services)?

Javi

---

From: Javi <[email-masked]>
Date: Thu, 04 Dec 2008 19:30:28 +0100

Using eight or more PDUs per packet invalidates the use of the AAL 1
sequence number mechanism, and hence complicates interworking with
ATM-based CES systems.

I know when carrying AAL1 PDUs over PWs we rely on the PW sequence
number to detect packet loss of misorder. Thus the AAL1 sequence number
is only for backwards compatibility and for interworking between TDM and
ATM networks.

If more than 8 SAR-PDUs (several AAL2 cycles) are transported per TDMPW 
packet, the sequence number is only kept for interworking with ATM-based
CES systems, although PW sequence number is used to detect packet loss of misorder.

[Question:]
Why does using eight or more PDUs per packet INVALIDATE
the use of the AAL 1 sequence number mechanism?
(I think in that case the use of the AAL 1 sequence number mechanism
would be valid, although it is not used for detecting lost or mosirodered ATM cells).

Javi

---

From: Javi <[email-masked]>
Date: Fri, 05 Dec 2008 13:17:37 +0100

RFC 5287, chapter 3.6 (TDMoIP AAL2 Options), establishes:

    CID mapping bases is an OPTIONAL parameter; its existence and length
    are determined by the length field.  If the mapping of AAL2 CID
    values to a physical interface and time slot is statically
    configured, or if AAL2 switching [Q.2630.1] is employed, this
    parameter MUST NOT appear.

In summury, I understand that "mapping of AAL2 CID values to
a physical interface and time slot" may be configured:

is possible in two ways:

+ ELCP protocol is not used (chapter 4.4.2): several CID intervals are 
statically assigned to digital trunks,
D-channels for ISDN BRI and ISDN BRI.

+ ELCP protocol is used, chapter 5.3.1.1 (Emulated Loop Control Protocol 
– Channel Allocation Procedure):
mapping of AAL2 CID values to a physical interface and time slot is 
dinamically configured by ELCP

[Question2]
is ELCP equivalent to Q.2630.1 for that mapping?
(As far as I know, ELCP is transported CID=8 and Q.2630.1 is transported 
over CID=2. Is it so?)

[Question 3] May ELCP protocol be used in TDMoIP AAL2 for mapping of 
AAL2 CID values to
a physical interface and time slot?

Javi

---

From: Javi <[email-masked]>
Date: Fri, 05 Dec 2008 13:23:30 +0100

RFC 4553 (SAToP) indicates a SAToP TDMPW may transport T1, E1, T3, E3 trunks
(unstructured o channalized, agnostic mode)

Why is SAToP not able to transport E2, T2 and E4, T4 TDM trunks?

Javi

---

From: Javi <[email-masked]>
Date: Tue, 16 Dec 2008 18:04:39 +0100

At least , I find an incongruity between:

+ RFC 5086 (chapter 3): indicates

    "...structured services considered in this specification are NxDS0 
services..."

+ ITU-T Y.1453 (chapter 7.1) indicates:

[Question:]

Is "Nx64 mentioned by ITU-T Y.1453" "structured TDM" insteed of 
"unstructured TDM type"?

Thanks,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 17 Dec 2008 18:23:44 +0200

Javi

Read the Y.1453 text more carefully.
The unstructured N*64K it discusses in 7.1 c), 
unlike the structured N*64K in 7.1 d)
is limited to particular ISDN configurations where there are serial bitstreams
carrying a particular multiple of 64K.
These particular signals were requested by ITU participants,
but I believe are sufficiently rare that they can be ignored.

The general N*64K case is handled as structured TDM.

Y(J)S

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Javi [[email-masked]]
Sent: Tuesday, December 16, 2008 7:04 PM
To: [email-masked]
Subject: [PWE3] RFC 5086 and ITU-T Y.1453: Nx64, ¿unstructured or structured?

[Question:]

Thanks,

Javi

---

From: Javi <[email-masked]>
Date: Wed, 17 Dec 2008 19:00:27 +0100

> The general N*64K case is handled as structured TDM.
Literally, ITU-T Y.1453 chapter 7.1:

...
c) The ability to transport the following unstructured TDM types:
   1) DS1 at 1544 kbit/s as defined in ITU-T Rec. G.703 [14];
   2) E1 at 2048 kbit/s as defined in ITU-T Rec. G.703;
   3) DS2 at rate 6312 kbit/s as defined in ITU-T Rec. G.703;
   4) Synchronous serial data as defined in ITU-T Recs V.36 [15] and 
V.37 [16];
   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]);
   6) DS3 at 44 736 kbit/s as defined in ANSI T1.107 [18];
   7) E3 at 34 368 kbit/s as defined in ITU-T Rec. G.751 [19].

d) The ability to transport the following structured TDM types:
   1) DS1 as defined in ITU-T Rec. G.704 [20];
   2) Fractional DS1 carrying N timeslots with N from 1 to 23 as defined 
in ANSI T1.107;
   3) E1 as defined in ITU-T Rec. G.704;
   4) Fractional E1 carrying N timeslots with N from 1 to 30 as defined 
in ITU-T
      Rec. G.704;
   5) Multiple synchronous DS0s;
   6) DS2 defined in ITU-T Rec. G.704.

Accordingly, I find:

+ "N x 64 k" is mentioned explicitly only for "unstructured TDM types". 
Also, Y.1453 references
  traditional bearer services I.231.x.

    For example, a I.231.5 service may be transported over a PRI using a 
E1 frame with 32 ITs.
    Why is it considered "unstructured" although there is a TDM frame 
with channels?

+ The general N*64K case: it is not mentioned explicitly for structured 
TDM. Do you mean
   Fractional DS1/E1carrying N timeslots?

In summary, how may an ISDN service I.231.x be transported in TDMoPW?, 
using SAToP or
using CESoPSN and TDMoIP?. And, aren't that ISDN services a type of 
"Nx64 services mentioned
by CESoPSN"?

Thanks,

Javix

---

From: Javi <[email-masked]>
Date: Thu, 18 Dec 2008 13:46:54 +0100

Thanks again,

I agree with you in general, except a detail.

In PRI, "particular ISDN signals" (i.e., I.231.x for N>2) are carried 
over a frame with
G.704 structure. Why do you tell they are strange?.

Moreover, in a TDM network, a E1 frame may transport ISDN services along 
with
other TDM services (i.e. an ISDN service I.231.6 in channels TI1 to TI7, 
and TDM services
from TI8 to TI31). In that case, I understand IWF must use CESoPSN or TDMoIP
necessarily because it have to transport "Nx64 services".

I don't understand why ISDN signals are tretared as an special case.

Thanks,

Javi

Yaakov Stein escribió:
> You are quite correct.
> General N*64K for N<31 is a fractional channelized E1.
> This can carried by a structured mode, such as CESoPSN or TDMoIP.
> It will, in general NOT be carried by SAToP, since it has no inherent framing,
> and thus you will not be able to recover the timeslots at the other end.
>
> The particular ISDN signals have their own framing
> and thus can be sent in structure-agnostic mode.
> They can also be sent structure-aware if you have an IWF that knows how to
> generate their strange framing.
>
> Y(J)S
>
> From: Javi [[email-masked]]
> Sent: Wednesday, December 17, 2008 8:00 PM
> To: Yaakov Stein
> Subject: Re: [PWE3] RFC 5086 and ITU-T Y.1453: Nx64, ¿unstructured or structured?
>

---

From: Javi <[email-masked]>
Date: Thu, 18 Dec 2008 18:38:51 +0100

PRI ISDN services (N>2):

I.231.6 (384 kbit/s, N=6)
I.231.7 (1536 kbit/s, N = 24)
I.231.8 (1920 kbit/s, N = 30),
I.231.10 (multiple-rate)

All of them have the same physical layer, I.431.
And I.431 (chapter 4.2) use the frame structure G.704.

So, all PRI ISDN services are carried over a G.704 frame. Therefore, 
they should be
treated as any structured TDM signal:

   2) Fractional DS1 carrying N timeslots with N from 1 to 23 as
      defined in ANSI T1.107;
      in ITU-T Rec. G.704;

Javi

Yaakov Stein escribió:
> Javi
>
> N=1 and N=2 cases are not in E1, they are BISDN sent in a 1b or 2B+D (144 kbps) stream.
> The N=3 and N=6 cases also have some physical layer defined.
>
> For other N only G.704 framing is defined.
>
> Y(J)S
>
>