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

From: <[email-masked]>
Date: Sun, 29 Nov 2009 19:21:50 +0000

Hola Javi,

You wrote:

> I detail my question.

I cannot answer your questions, sorry for that.

However I have additional questions after reading the RFC:

--- What happens if instead of CAS CCS is used for the signalling?
--- E1 CAS uses a multiframe which includes RAI (note this is different from
    the E1 RAI, how is this transferred?
--- Currently transport of most E1 is checked with CRC-4 how it this transferred?
--- CRC-4 errors are reported by using REI, this is not mentioned at all, why?

Has this RFC been liaised to the ITU-T SG15 experts for review?

Regards, Huub.

> According to RFC 5086, the mechanism:
> 
> + "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": it transport CAS 
> signalling for the telephony applications.
> 
> In principle, both represent two distinct possibilities. However:
> 
> a) Apart from CAS for the telephony applications, what other real 
> example of CE Application Signaling may be proposed?
> 
> b) If the mechanism 5.3 necessary, why is not covered by the RFC 5087 
> (TDMoIP) for AAL.1?
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Javi <[email-masked]>
Date: Sun, 29 Nov 2009 20:44:44 +0100

Hello Huub,
> --- What happens if instead of CAS CCS is used for the signalling?
Yoy may transport CSS signalling in transparent mode (as another bearer 
channel) or in HDLC mode (RFC 5087)
>     the E1 RAI, how is this transferred?
"5.4.  Trunk-Specific NxDS0 Services with CAS" carry CAS signalling from TDM multiframe in CAS substructures, including error indicators (detailed RCFC 5086, CESoPSN)

> --- Currently transport of most E1 is checked with CRC-4 how it this transferred?
Flags L, R, M are used to indicate error in transmission and reception. 
Also, sequence numbers of SAR-PDUs (AAL.1) and CPS-PDU (AAL.2) may be 
used to detect losses.
> Has this RFC been liaised to the ITU-T SG15 experts for review?
ITU-T Y.1453 coincides with the transport of TDM data over a PSN UDP/IP, 
without mentioning the concept Pseudowire.

Regards, Javi

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 29 Nov 2009 22:37:34 +0200

Huub, Javi and all,

Please see some answers inline below (blue italics).

Hopefully they will address your concerns.

Regards,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Sunday, November 29, 2009 9:21 PM
To: Javi; [email-masked]
Subject: Re: [PWE3] Transport of CAS over CESoPSN [RFC 5086]

 HolaJavi,

[[Sasha]] You can send CCS messages "as is" in the signaling packets.
--- E1 CAS uses a multiframe which includes RAI (note this is different from
    the E1 RAI, how is this transferred?

[[Sasha]] It is not transferred at all.
--- Currently transport of most E1 is checked with CRC-4 how it this transferred?

[[Sasha]] CESoPSN terminates E1/T1 framing (including CRC-4/CRC-6) at ingress and regenerates it at egress. If you do not want (for some reason) to terminate framing, use SAToP (as described in RFC 4553).
--- CRC-4 errors are reported by using REI, this is not mentioned at all, why?

[[Sasha]] Please see the previous response.

Has this RFC been liaised to the ITU-T SG15 experts for review?
[[Sasha]] Please read ITU-T Y.1413. It is (more or less) a translation of RFC 4553, 5086 and 5087 into the ITU-T language.
Regards, Huub.

> example of CE Application Signaling may be proposed?

[[Sasha]] As mentioned above, you can us the method in 5.3 to carry CCS.

But actually the main difference between the methods in 5.3 and 5.4 is that 5.3 preserves the format of the basic CESoPSN packets, thus facilitating reuse of HW. Signaling packets are relatively rare and can be generaged and terninated by SW.

> b) If the mechanism 5.3 necessary, why is not covered by the RFC 5087

[[Sasha]] I cannot answer that, but I've added Yaakov Stein to the CC list.

---

From: Javi <[email-masked]>
Date: Sun, 29 Nov 2009 22:06:32 +0100

Thanks Alexander,

Very clear. I hope the answer of Yaakov Stein.

Two related questions: under these RFCs CESoPSN [RFC 5086], TDMoIP AAL1 
y AAL2 [RFC 5087], I understand that:

+ 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)

+ 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)?

If a TDMPW could transport channels from different TDM trunks, how may a 
single TDMPW carry error indicators (AIS, RDI) of all TDM trunks?. 
Control Word (CW) may only carry error indicators from a trunk. So, may 
a single TDMPW emulate one or several TDM trunks?

Javi

 > 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./