Subject: [PWE3] CESoPSN (RFC 5086): CE Signaling

From: Javi <[email-masked]>
Date: Tue, 18 Nov 2008 19:40:55 +0100

Chapter 5.3: Extending Basic NxDS0 Services with CE Application Signaling

+ What does "CE Application Signaling" mean exactly? (only CAS, CSS or 
CAS, other?)

+ can CE Application Signaling coming from several trunks (ACs) be 
transported in a same CESoPSN PW?

+ If the CE maintains a separate application state per DS0 channel 
(e.g., CAS), with encoding RFC4733, how many bits CAS are transported in 
each "Encoded CE application state entry"?, a nibble ABCD?

+ For CAS, which is the advantage that "Extending Basic NxDS0 Services 
with CE Application Signaling" provides over "Trunk-Specific NxDS0 
Services with CAS"?

Thanks

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

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 18 Nov 2008 21:41:34 +0200

CE signaling means CAS bits.

The CE signaling is for all timeslots carried.
Since these usually belong to a single trunk, 
this is your answer. Nothing prohibits putting a TDM cross-connect (FCD)
before the interworking, thus mixing timeslots from different physical trunks.
However, there is a single logical trunk from the PW point of view.

Indeed, each entry in the signaling substructure contains 4 bits - ABCD.

I can't recall Sasha's terminology exactly, but I believe that
the trunk specific version maintains CAS multiframe integrity.
Without this the CAS multiframe will not be guaranteed to 
be in phase with the original one.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi
Sent: Tuesday, November 18, 2008 8:41 PM
To: [email-masked]
Subject: [PWE3] CESoPSN (RFC 5086): CE Signaling

Thanks

---

From: Javi <[email-masked]>
Date: Tue, 18 Nov 2008 21:35:15 +0100

> CE signaling means CAS bits.

The document MEF8 (Implementation Agreement for the Emulation of PDH 
Circuits over Metro Ethernet Networks), chapter "6.5 TDM APPLICATION 
SIGNALING"  declares

>  CE applications interconnected over a CESoETH service may exchange 
signaling in addition to TDM data.
>  The typical example is telephony applications that exchange their 
state (e.g. off-hook/on-hook).
>  This section describes a generic method for extending the Nx64kbit/s 
basic service by carrying CE signaling (CAS or CCS)

Accordingly, CE signaling may be CAS or CSS. Is it so in RFC5086?

> Indeed, each entry in the signaling substructure contains 4 bits - ABCD.
It is so for the signaling structure in "Trunk-Specific NxDS0 Services 
with CAS". But, is it also for the 32 bits
"Encoded (using RFC 4733) CE application state entry for the DS0 channel 
#N" in "Extending Basic NxDS0 Services
with CE Application Signaling"?

> be in phase with the original one.
Then, when is prefered to use "Extending Basic NxDS0 Services
with CE Application Signaling" insteed of "Trunk-Specific NxDS0
Services with CAS"?

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 19 Nov 2008 02:49:34 +0200

> The document MEF8 (Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks), 
<snip>
> Accordingly, CE signaling may be CAS or CSS. Is it so in RFC5086?

Of course telephony signaling may be CAS or CCS.
However, the CE signaling mode of CESoPSN is for CAS signaling.
It specifically states that CCS is left for a future document.
Incidentally, TDMoIP (RFC5087) has a CCS mode.

> with CAS". But, is it also for the 32 bits "Encoded (using RFC 4733) 
> CE application state entry for the DS0 channel  #N" in "Extending Basic NxDS0 Services

There is no difference. CESoPSN details CAS substructures.
I have no idea where you found a reference to RFC 4733,
other than the mention that the CAS signaling follows the documentation in 4733.

> with CE Application Signaling" insteed of "Trunk-Specific NxDS0

If you need to preserve multiframe phase.

Y(J)S

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Nov 2008 12:09:24 +0200

Yaakov, Javi and all,
First of all I'd like to thank Yaakov for responding to Javi's original email.

In addition, I'd like to provide a few responses/comments of my own which in certain cases may be different from Yaakov's.

1. To the best of my understanding, preservation of CAS multiframe phase *is a non-goal for circuit emulation*.
    The rationale: it is not preserved by native TDM equipment (different trunks are not synchronized wrt to CAS
    multiframe phase). In particular, if you want to use trunk-specific CES with CAS to carry timeslots (and CAS) coming
    from multiple trunks, the multiframe phase carried across the PSN would be that generated by the internal DS0
    cross-connect and, basically, not synchronized with that of any of the original user-visible trunks.

2. RFC 5086 does not really limit CE application state signaling to CAS. Section 5.3 and Appendix A of this document
    have been intentionally written in such a way as to describe a generic mechanism for reliably carrying CE application
    state across a PSN and to define a generic format of signaling packets for the case when the CE maintains a separate
    application state per DS0. At the same time both application-specific definition of the application states and their encoding 
    have been intentionally left out of  scope. 

3. Telephony applications using CAS are somewhat special in RFC 5086 because 
   (a) They maintain a separate state for each DS0 (so that the generic format of signaling packets defined in RFC 5086
        is applicable)
   (b) RFC 2833 has defined how to encode the state of an individual DS0 channel for this application. This encoding 
       has been extended in RFC 5244 (which, together with RFC 4733 and 4734 has obsoleted RFC 2833 but has been 
       published half a year later than RFC 5086), but the extension is backward-compatible.

4. It has been my opinion for quite some time that adding trunk-specific CES with CAS to the CESoPSN draft that have been
    the precursor of RFC 5086) has been unjustified. However, my attempts to remove it at some stage of the PWE3 WG 
    discussion has been opposed by some WG participants, and hence it has been left intact.

Hopefully, these notes will be useful.

Regards,
	Sasha

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: Wednesday, November 19, 2008 2:50 AM
> To: Javi; [email-masked]
> Subject: Re: [PWE3] CESoPSN (RFC 5086): CE Signaling
> 
> > The document MEF8 (Implementation Agreement for the 
> Emulation of PDH Circuits over Metro Ethernet Networks), 
> <snip>

---

From: Javi <[email-masked]>
Date: Wed, 19 Nov 2008 13:54:38 +0100

Alexander Vainshtein escribió:

Alexander, Yaakov and all,
>     cross-connect and, basically, not synchronized with that of any of the original user-visible trunks.
If it's possible to use "Trunk-Specific NxDS0 Services with CAS" to 
carry timeslots (and CAS) coming from multiple trunks, why is it named 
"Trunk-Specific"?.

>     have been intentionally left out of  scope. 
RFC5086 contains "CE application signaling (e.g., Channel-Associated 
Signaling (CAS))" and "e.g." means "for example". Appart from CAS, what 
may "CE signaling" be?
>     discussion has been opposed by some WG participants, and hence it has been left intact.
Which were the reasons to keep it?. I suppose it must add any advantage.

Regards, Javi
>>> It is so for the signaling structure in "Trunk-Specific 
>>>       
>> NxDS0 Services 
>>     
>>> with CAS". But, is it also for the 32 bits "Encoded (using 
>>>       
>> RFC 4733) 
>>     
>>> CE application state entry for the DS0 channel  #N" in 
>>>       
>> "Extending Basic NxDS0 Services
>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Nov 2008 15:14:17 +0200

Javi and all,
Please see inline below. I've snipped the parts of the original email that presumably are not relevant.

Regards,
	Sasha

Regards,
	Sasha

> From: Javi [mailto:[email-masked]] 
> Sent: Wednesday, November 19, 2008 2:55 PM
> To: Alexander Vainshtein; Yaakov Stein
> Cc: [email-masked]
> > In addition, I'd like to provide a few responses/comments 
> of my own which in certain cases may be different from Yaakov's.
> >
... snipped ...
> carry timeslots (and CAS) coming from multiple trunks, why is 
> it named "Trunk-Specific"?
>
[Sasha] You can carry timeslots from multiple trunks with the same (multi)frame, e.g., from multiple E1 or multiple T1/ESF trunks.
But you cannot mix timeslots coming from E1 and T1 trunks, because their multiframe structures are different.
The name "Trunk-specific" reflects this limitation of the technology; your questions indicate that it may be misleading.
> 
> > 2. RFC 5086 does not really limit CE application state 
> signaling to CAS. Section 5.3 and Appendix A of this document
> >     have been intentionally written in such a way as to 
> describe a generic mechanism for reliably carrying CE application
> >     state across a PSN and to define a generic format of 
> signaling packets for the case when the CE maintains a separate
> >     application state per DS0. At the same time both 
> application-specific definition of the application states and 
> their encoding 
> Signaling (CAS))" and "e.g." means "for example". Apart from CAS, what 
> may "CE signaling" be?
> 
[Sasha] I do not have any other examples ready at hand. 
>
> > 4. It has been my opinion for quite some time that adding 
> trunk-specific CES with CAS to the CESoPSN draft that have been
> >     the precursor of RFC 5086) has been unjustified. 
> However, my attempts to remove it at some stage of the PWE3 WG 
[Sasha] You should ask the people who have then opposed removing trunk-specific
CES with CAS from the draft.  But if you want my guess (FWIW),  one of their reasons could be 
an already existing implementation (or perceived ease to produce one). 
As you probably know, a camel is a horse that has been designed by an SDO...

---

From: Javi <[email-masked]>
Date: Wed, 19 Nov 2008 17:44:44 +0100

Alexander and all,
> However, there is a single logical trunk from the PW point of view.
For TDMoIP AAL.2 (RFC 5087), I understand that PW must be aware of that. 
At least, RFC5287 contents that the interface parameter "TDMoIP AAL2 
Options" includes the field "CID mapping bases" and:

"When it is present, and the channels belong to N physical interfaces 
(i.e., N E1s or T1s), it MUST be N
   bytes in length.  Each byte represents a number to be subtracted from
   the CID /*to get the timeslot number for each physical interface*/.  For
   example, if the CID mapping bases parameter consists of the bytes 20
   and 60, this signifies that timeslot 1 of trunk 1 corresponds to CID
   21, and timeslot 1 of trunk 2 is called 61."

But this field is not used in other methods (SAToP, TDMoIP AAL.1, CESoPSN).

If a TDM cross-connect, before the interworking, is used, timeslots from 
different physical trunks are mixed.
Then, the CE-bound instance of the CESoPSN IWF receives the PW PDUs from 
the PSN and extracts the TDM data.
But tf in CESoPSN "there is a single logical trunk from the PW point of 
view", how to get the timeslot number for each physical interface?

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Wed, 19 Nov 2008 18:00:04 +0100

> [Sasha] I do not have any other examples ready at hand. 

I also. Then, would it not be more clear to use only the term "CAS 
signaling"? (I think that the term "CE application signaling" is misleading)

RFC 5086 contents:

5.3. Extending Basic NxDS0 Services with CE Application Signaling
5.4. Trunk-Specific NxDS0 Services with CAS

Would it be right?

5.3. Extending Basic NxDS0 Services with CAS
5.4. Trunk-Specific NxDS0 Services with CAS

or

5.3. Extending Basic NxDS0 Services with CE Application Signaling
5.4. Trunk-Specific NxDS0 Services with CE Application Signaling
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Nov 2008 23:50:36 +0200

Javi,
Published RFCs cannot be modified. if there is a real need, IETF may start working on a new edition and publish a new RFC that obsoletes the previous one.
So your proposal may be considered if/when the WG decides to start work on 5086bis.

Regards,
	Sasha

> Sent: Wednesday, November 19, 2008 7:00 PM
> To: Alexander Vainshtein
> Cc: [email-masked]; Yaakov Stein

---

From: Javi <[email-masked]>
Date: Thu, 20 Nov 2008 17:57:47 +0100

Alexander and all,
> The name "Trunk-specific" reflects this limitation of the technology; your questions indicate that it may be misleading.
Then, I undesrtand that "Trunk-specific" means: timeslots from multiple 
trunks and all trunks must be of the same type.

RFC4197, chapter 7.1 Connectivity, establishes:

   1.  The emulation MUST support the transport of signals between
       *Attachment Circuits (ACs) of the same type* (see Section 5) and,
       wherever appropriate, bit-rate.

Is this the same as "Trunk-specific"?. If it is so, I don't understand 
which is the meaning contributed by the term "Trunk-specific"