Subject: [PWE3] Different manipulation of channels in a Nx64 service

From: Javi Muñoz <[email-masked]>
Date: Mon, 12 Dec 2011 18:27:30 +0100

I have the next situation:

ISDN TE_A1 <---> [        ]       [        ] <---> ISDN TE_A2
ISDN TE_B1 <---> [        ]       [        ] <---> ISDN TE_B2
ISDN TE_C1 <---> [AGW(PE1)] <---> [AGW(PE2)] <---> ISDN TE_C2
...              [        ]       [        ]
ISDN TE_D1 <---> [        ]       [        ] <---> ISDN TE_D2

Each AGW finishes several ISDN interfaces (then, several TDM circuits).

* ISDN_TE_A1 has stablished a 64kbps call with ISDN_TE_A2 using the RTP 
codec CLEARMODE.
* ISDN_TE_B1 has stablished a 64kbps call with ISDN_TE_B2 using the RTP 
codec G.711-u without VAD
* ISDN_TE_C1 has stablished a 64kbps call with ISDN_TE_C2 using the RTP 
codec G.711-u with VAD
...
* ISDN_TE_D1 has stablished a 64kbps call with ISDN_TE_D2 using the RTP 
codec G.711-u without VAD

(the codec to use for each call would be indicated by an external 
signalling to the TDMPWs, such as Megaco)

Is it possible to use a single TDMoPW TDMoIP AAL2 to emulate all these 
calls?

If this is not possible to use different codec, at least, would it be 
possible to use a single TDMoPW TDMoIP AAL2 to emulate all calls with 
the same type of codec and media manipulation (i.e. calls "ISDN_TE_B1 - 
ISDN_TE_B2" and "ISDN_TE_D1 - ISDN_TE_D2").

NOTE: I propose directly AAL2, and not CESoPSN or TDMoIP AAL2, due to 
they are different calls, so that it is necessary to dynamically modify 
the number of channels, which is only supported by AAL2.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 13 Dec 2011 08:26:09 +0000

Javi

If I understand you question, you are asking whether an AAL2 TDMoIP PW can mix channels that 
1) originated from different TDM trunks,  and 
2) that are encoded with different coding systems (A-law, u-law, VAD, etc. etc.)

The answer to the first part is a strong affirmative.
One of the advantages of "loop emulation" (AAL2) as opposed to "circuit emulation"
is that you break the timing relationship between the ingress and egress channels.
Put more formally, the TDM trunk (e.g., E1) is terminated and the individual channel ("loop")
is extracted and optionally manipulated. Thus there is no requirement for the
channels muxed in the PW to come from the same TDM trunk.
Were we to try to do this using circuit emulation, we would have to allow for different clocks,
as is done in PDH and SDH systems. Note that TDM itself (E1 and T1) requires its clients
to be of precisely the same frequency and phase.

Please note, however, that the precise mapping of channels to trunks+timeslots
would need to be configured by a management system as the TDM control protocol extensions 
in RFC 5287 define an optional "mapping base" which only supports the single-trunk case.

The answer to the second part is not very different.
Since the channels are completely independent, they can carry anything you want.
I have been involved in cases where some of the CIDs were data (clear channel)
perhaps even from >1 timeslot, while others were voice with VAD,
or even compressed voice.
However, the AAL2 control protocol extensions are woefully insufficient to describe
what is needed here. They indeed contain a VAD indicator and encoding field,
but only for the entire PW, not for individual CIDs.
It would be a trivial exercise to extend the TLV, but it would become very bulky.

If you absolutely can not configure and need to recognize the channel type automatically,
I can think of two alternatives.
First, you could rely on the native AAL2 UUI codepoint differentiation defined in I.366.
Second, you could use the method described in Y.1452 for multiplexing RTP streams
(at the price of additional overhead).

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi Mu?oz
Sent: Monday, December 12, 2011 19:28
To: [email-masked]
Subject: [PWE3] Different manipulation of channels in a Nx64 service

Regards,

Javi

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

---

From: Javi Muñoz <[email-masked]>
Date: Tue, 13 Dec 2011 12:25:21 +0100

Yaakov,
> 1) originated from different TDM trunks,  and
I assumed that this part was possible (we had already discussed in 
previous post).
> 2) that are encoded with different coding systems (A-law, u-law, VAD, etc. etc.)
This was my question.
> in RFC 5287 define an optional "mapping base" which only supports the single-trunk case.
As we have already spoken on other occasions, my intention is to use 
Megaco for this mapping of channels to trunks+timeslots.

> but only for the entire PW, not for individual CIDs.
What extensiones do you mean exactly?

> If you absolutely can not configure and need to recognize the channel type automatically,
My intention was also to use MeGaCo(The node that finishes Q.931/SIP 
signaling know the type of each channel, so it can indicate to the AGW / 
PE using Megaco). Do you see any problem with that?

> (at the price of additional overhead).
What method do you mean?(What clause Y.1452 is defined?).

Regards,

Javi
> ISDN TE_A1<--->  [        ]       [        ]<--->  ISDN TE_A2
> ISDN TE_B1<--->  [        ]       [        ]<--->  ISDN TE_B2
> ISDN TE_C1<--->  [AGW(PE1)]<--->  [AGW(PE2)]<--->  ISDN TE_C2
> ...              [        ]       [        ]
> ISDN TE_D1<--->  [        ]       [        ]<--->  ISDN TE_D2
>
>

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 13 Dec 2011 18:21:31 +0000

Javi

If you use Megaco to set up the channels then everything should be fine.

I was thinking about extending the AAL2 TLV to have sub-TLVs per CID
rather than a single encoding field for all CIDs simultaneously.

Although I was editor of Y.1452 I don't remember the clause number
(and I am not on my PC right now).
I think it is the last clause - it talks about muxing RTP flows.
There you can have a RTP header for each CID, and so identify encoding
with higher granularity.

Y(J)S

-----Original Message-----
From: Javi Muñoz [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2011 13:25
To: [email-masked]
Cc: Yaakov Stein
Subject: Re: [PWE3] Different manipulation of channels in a Nx64 service

Yaakov,
This was my question.

Regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Tue, 13 Dec 2011 20:26:35 +0100

Yaakov
> (and I am not on my PC right now).
It is clause 11. It proposes to carry the RTP header in each CID. This 
allows to indicate de Payload Type. But, how may it indicate if using 
G.711 with or without VAD, for instance?
> you could rely on the native AAL2 UUI codepoint differentiation defined in I.366.
>
Regards

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Wed, 14 Dec 2011 11:52:36 +0100

Yaakov,

A question about Y.1452. In the figure 11-1, what exactly is VoIP 
header?: "only the RTP header" or "the RTP, UDP and IP headers"?

And an opinion. If we decide to use a TDMPW for each call:

ISDN TE_A1<--->   [        ]<-TDMPW1->  [        ]<--->   ISDN TE_A2
ISDN TE_B1<--->   [        ]<-TDMPW2->  [        ]<--->   ISDN TE_B2
ISDN TE_C1<--->   [AGW(PE1)]<-TDMPW3->  [AGW(PE2)]<--->   ISDN TE_C2
...
ISDN TE_D1<--->   [        ]<-TDMPWn->  [        ]<--->   ISDN TE_D2

taking into account that:

* They are user calls(thus, they are established / released quite often).

* Each call can be of a different type (voice, VBD, CLEARMODE, ...).

* Each operator (OPN) has many AGWs(not only the two shown in Figure, 
possibily tens of thousands), so that a TE in a AGW may call to a TE in 
any other AGW.

What kind of TDMPW would you use:

* CESoPSN or TDMoIP AAL1

and / or

* TDMoIP AAL2  ?

Regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Thu, 15 Dec 2011 18:52:26 +0100

For the opinion about using CESoPSN/TDMoIP AAL1 and/or TDMoIP AAL2, I 
would add that:

* Some calls may be switched (SVCs) and others permanent (PVCs).

Also, I'd like to know your opinion whether you think is better a TDMPW 
per call, or use a TDMPW for multiple calls (muxing).

Regards,

Javi

El 14/12/2011 11:52, Javi Muñoz escribió:
> possibily tens of thousands), so that a TE in a AGW may call to a TE 
> in any other AGW.
>

---

From: Javi Muñoz <[email-masked]>
Date: Fri, 16 Dec 2011 12:20:22 +0100

Yaakov,

And an additional question.

When using a TDMPW TDMoIP AAL2 per call(mono or multichannel), I think 
it might be better to simply use RTP. In a ISDN multichannel call, the 
"N" 1x64 kbps-channels may be modeled as a virtual single channel of 
rate Nx64 kbps, then as a single stream of media:

Media of "stream Nx64"
         RTP
         UDP
         IP

TDMoIP AAL2 would keep the identification of the channel to which each 
sample belongs (but it is not necessary to be a single stream carrried 
over "N" channels).

If this is correct, then the RTP solution here would be better to have 
less overhead.

Regards,

Javi

El 15/12/2011 18:52, Javi Muñoz escribió:
> Also, I'd like to know your opinion whether you think is better a 
> TDMPW per call, or use a TDMPW for multiple calls (muxing).
>
> Regards,
>
> Javi
>
>

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Dec 2011 09:38:52 +0000

See RFCs 3551 and 3389.

Y(J)S

-----Original Message-----
From: Javi Muñoz [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2011 21:27
To: [email-masked]
Cc: Yaakov Stein
Subject: Re: [PWE3] Different manipulation of channels in a Nx64 service

Yaakov
Regards

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Dec 2011 09:43:54 +0000

[YJS] The RTP header. There is no need for UDP/IP as the RTP is carried over MPLS.

* CESoPSN or TDMoIP AAL1

and / or

* TDMoIP AAL2  ?

[YJS] If the TDM trunks are mostly full (i.e., the timeslots are mostly active)
and/or the BW efficiency is not critical,
then use circuit emulation. It minimizes the processing delay and processing power needed.

[YJS] If the trunks are mostly empty and/or the BW is limited,
then use loop emulation. However, take into account that this degrades
certain features.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Dec 2011 10:01:26 +0000

Regarding the overhead, RTP over UDP over IP over MPLS
is much more wasteful than RTP directly over MPLS according to Y.1452.

Also, using PWs give you additional features (such as VCCV) that may or may not be useful.

However, standard VoIP over MPLS is indeed an option.
See Y.1414 - there it is the first option.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi Mu?oz
Sent: Friday, December 16, 2011 13:20
To: [email-masked]
Cc: Yaakov Stein
Subject: Re: [PWE3] Different manipulation of channels in a Nx64 service

Yaakov,

Media of "stream Nx64"
         RTP
         UDP
         IP

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Sun, 18 Dec 2011 18:13:37 +0100

Yaakov,

> [YJS] The RTP header. There is no need for UDP/IP as the RTP is carried over MPLS.

[Javi] I don't understand, Y.1452 only mentions VoIP over UDP/IP 
networks. Perhaps I did not adequately explain.
The question was: If we have several VoIP flows over a UDP/IP network:

Media1     Media2    ...    Media_n
  RTP        RTP      ...     RTP
  UDP        UDP      ...     UDP
  IP         IP       ...     IP

What protocol stack is the proposalby Y.1452/Figure 11-1?

(A)

[AAL2 Header|RTP Header|Media1] [AAL2 Header|RTP Header|Media2]... [AAL2 
Header|RTP Header|Media_n]
UDP
IP

or

(B)

[AAL2 Header|IP Header|UDP Header|RTP Header|Media1]... [AAL2 Header|IP 
Header|UDP Header|RTP Header|Media_n]
UDP
IP

If we use the option A, it would require that all VoIP flows have the 
same source and destination IP addresss and UDP ports (so, the same 
source and destination application).

Regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Wed, 21 Dec 2011 12:57:13 +0100

Yaakov,

RFC3389 (PT for noise confort) allows to convey CNG-related
parameters to the egress PE.

However, the problem I see is at the ingress point: how to tell the
ingress PE that it may apply VAD procedures for a given channel.
Of course, if VAD were allowed, the ingress PE would supress
silences and use RFC3389 to carry CNG parameters, as you said.

If we consider using AAL2 TDMoIP PWs to multiplex calls coming
to the ingress PE from different channels, these channels may be
encoded differently. Some would allow VAD, some others wouldn't.

AAL2-mode TDMPW control plane (sub-TLV "AAL2 options") allows to
indicate whether VAD is allowed for _all_ channels conveyed by the
TDMPW or not, but it is unable to allow VAD for some channels and
to deny VAD for the other.

Regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Thu, 22 Dec 2011 17:00:18 +0100

Yaakov,
> then use loop emulation. However, take into account that this degrades

What specific parameters are degraded more in AAL2-mode?

May any of them affect to ISDN calls, avoiding its NGN emulation?

Regards,

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Fri, 23 Dec 2011 12:54:12 +0100

What is more efficient?

(a) a TDMPW per call

or

(b) a TDMPW for multiple calls (muxing).

A think (b) it requires less overhead and less control plane messages.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 25 Dec 2011 16:42:14 +0000

Javi

As these discussions apparently do not interest most of the readers of this list,
I propose that if you have further questions that we continue the discussion off-list
(as we have been doing for the past week).

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi Mu?oz
Sent: Friday, December 23, 2011 13:54
To: [email-masked]
Subject: [PWE3] A TDMPW per call o a TDMPW for multiple calls

What is more efficient?

(a) a TDMPW per call

or

Regards,

Javi