Subject: Re: [PWE3] TDMPW and MeGaCo/SDP

From: Javi Muñoz <[email-masked]>
Date: Tue, 01 Feb 2011 14:15:43 +0100

That's right, but it is necessary to define it.

Does any working group, as mmusic, not plan to define it in 
collaboration with PWE3?

Normally, each transport proposal includes SDP extensions it needs. For 
instance:

+ IETF RFC4733 (RTP Payload for tones): codecs "telephone-event" 
(a=rtpmap:100 telephone-event/8000) and "tone" (a=rtpmap:101 tone/8000)
+ IETF RFC4734 (Events for Modem signals): codes (a=fmtp:101 
0-15,32-41,43,46,48-49,52-68)
+ ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=gpmd")
+ ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl")
+ ITU-T V.150.1: Annex E (attribute and codec "a=sprtmap:<PT_dinámico> 
v150mr/8000")
+ ITU-T V.151: Annex C (codec T.140: "a=rtpmap:<PT_dinámico> t140c/8000")
...

So, I think it would be logical that the SDP extensions needed to 
describe PWs were done by a PW document.

For instance, we may propose any like this:

m=audio <puerto> RTP/AVP <PT_dinámico>
a=rtpmap:<PT_dinámico> TDMoIP/8000

Would it be necessary to indicate to the Media Gateway other PW 
parameters such as?:

a=pw:Payload_Type    (SAToP, CESoPSN, TDMoIP_AAL1, TDMoIP_AAL2)
a=pw:PW_Identifier

or, is it enough to negotiate them by the PW control plane?

Thanks

Javier Muñoz
>
>
> El 29/01/2011 10:31, Stewart Bryant escribió:
>> That is outside the scope of the PW.
>>
>> The NSP (specifically excluded from the domain of the PW) would need 
>> to handle that.
>>
>> Stewart
>>
>> On 29/01/2011 01:13, Javi wrote:
>>> Assuming the next situation:
>>>
>>> ISDN Terminal 1  -   MG1 -  [IP network] -  MG2   -   ISDN Terminal 2
>>>
>>> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway 
>>> Controller) via MeGaCo[H.248.1].
>>>
>>> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN 
>>> B-channels over the IP network:
>>>
>>> + By a single RTP session (when monochannels ISDN services)
>>>
>>> + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services.
>>>
>>>
>>> How may MGC indicate to the MG that it uses PWs at the IP termination?
>>>
>>> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote 
>>> descriptors. However, how may be that SDP description of TDMPWs?
>>>
>>> Thanks,
>>>
>>> Javier Muñoz
>>> _______________________________________________
>>> 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: Tue, 1 Feb 2011 15:53:23 +0000

Javi

Can you explain what you think needs defining via SDP here ?

The PW between your MGs is completely transparent to the MGs
(logically, your MGs are connected via a TDM interface)
and the MGC should not be meddling with its parameters at all.

You examples of carrying tones or VBD over RTP are not analogous,
as here the PW is providing the transport BELOW the logical flow,
not a feature being carried OVER the RTP transport.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi
Sent: Saturday, January 29, 2011 14:10
To: [email-masked]
Subject: Re: [PWE3] TDMPW and MeGaCo/SDP

Possible, but it is necessary to define it.

No working group, as mmusic, plans to define it in collaboration with PWE3?

So, I think it would be logical that the SDP extensions needed to 
describe PWs weredone by a PW document.

Thanks

Javier Muñoz

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 1 Feb 2011 17:56:38 +0200

Yaakov, Javi, and all,
I concur with Yaakov. TDM PWs should not be involved in the MG signaling.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Tuesday, February 01, 2011 5:53 PM
To: Javi; [email-masked]
Subject: Re: [PWE3] TDMPW and MeGaCo/SDP

Javi

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi
Sent: Saturday, January 29, 2011 14:10
To: [email-masked]
Subject: Re: [PWE3] TDMPW and MeGaCo/SDP

Thanks

Javier Muñoz

---

From: Javi <[email-masked]>
Date: Tue, 01 Feb 2011 18:12:57 +0100

Assuming the next edge to edge comunication

ISDN TE <--- [D/B channels] --->  AGW <----[NGN (IP) network ]---->  NGN TE

* TE: Terminal equipment
* AGW: Access Gateway

[ITU-T Y.2262/Appendix IV] propose:

a) ISDN Monorate bearer services (1 × 64-kbit/s): may be emulated by a 
single RTP session.

ISDN TE <--- [1xB channel] --->  AGW <----[RTP session]---->  NGN TE

b) ISDN Multirate bearer services (N x 64-kbit/s): may be emulated by 
TDMoIP[Y.1453] (=UDP/IP TDMPWs).
We may suppose the next scheme:

ISDN TE <--- [NxB channels] --->  AGW <----[TDMPW]---->  NGN TE

If it was so, "NGN TE" would be implement the PW stack protocol:

TDMPW Payload Type
CW
RTP
UDP
IP

Here, AGW and NGN TE would be PEs (at L2TPv3 notation: AGW=LCCE LAC; NGN 
TE=LCCE LNS).

Is it right that a terminal equipment (TE NGN) is a PW edge?. I think it 
is not good choice. Then, which would be the right scheme for "b)"?

Javier Muñoz

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 1 Feb 2011 19:51:42 +0200

Javi, and all,
You refer to an ITU-T standard that proposes usage of TDM PWs but  references yet another ITU-T standard.

To the best of my recollection, ITU-T has not ever asked PWE3 to review this proposal (whether this was necessary is a different issue).

So I'd say that your questions should be addressed to the ITU-T Question/Study Group that has created the ITU standard in question.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Javi
Sent: Tuesday, February 01, 2011 7:13 PM
To: [email-masked]
Subject: [PWE3] TDMPW terminated at terminal equipment

* TE: Terminal equipment
* AGW: Access Gateway

TDMPW Payload Type
CW
RTP
UDP
IP

Javier Muñoz

---

From: Javi <[email-masked]>
Date: Thu, 03 Feb 2011 01:11:09 +0100

Sahsa, Yaakov and all,

> To the best of my recollection, ITU-T has not ever asked PWE3 to review this proposal (whether this was necessary is a different issue).
That is the intention of my e-mail. ITU-T proposes TDMoIP[Y.1453], but  
the TDMoIP is equivalent to UDP/IP-based pseudo-wires [IETF RFC 5087].

So, I would like to know the opinion of the PWE3 group. May UDP/IP 
TDMPWs help to support ISDN multirate bearer services (N x 64-kbit/s)?:

a) In a communication between two ISDN terminals, each one connected to 
the IP network via an access gateway (AGW). The UDP/IP TDMPW is 
establish between the AGWs (each AGW is a PE).

ISDN TE [NxB channels] --->   AGW<----[TDMPW]---->   AGW<--- ISDN TE [NxB channels]

b) In a communication between an ISDN terminal and an IP terminal. The 
ISDN terminal is connected to the IP network via an access gateway 
(AGW). The UDP/IP TDMPW is establish between the AGW and the IP 
terminal. Here, AGW and NGN TE would be PEs

ISDN TE [NxB channels] --->   AGW<----[TDMPW]---->   IP TE

> So I'd say that your questions should be addressed to the ITU-T Question/Study Group that has created the ITU standard in question.

I think Yaakov had helped in drafting the ITU-T Y.1453 Recomendation.

Yaakov, Can you give us your opinion?

Regards,

Javi

> ISDN TE<--- [D/B channels] --->   AGW<----[NGN (IP) network ]---->   NGN TE
>
> * TE: Terminal equipment
> * AGW: Access Gateway
>
>
> ISDN TE<--- [1xB channel] --->   AGW<----[RTP session]---->   NGN TE
>
>
> ISDN TE<--- [NxB channels] --->   AGW<----[TDMPW]---->   NGN TE
>

---

From: Javi <[email-masked]>
Date: Thu, 03 Feb 2011 01:33:21 +0100

Yaakov, Sahsa, and all,

> Can you explain what you think needs defining via SDP here ?

I will try to justify why the SDP description is needed.

My scenario is that of an ISDN terminal connected to the IP network via
an access gateway, communicating with a another ISDN terminal. The AGW 
relays the ISDN
signalling to an MGC, which controls the AGW media by using Megaco.

I'm interested in supporting multichannel services. I'm exploring TDMPWs 
to convey the data flows over the IP network. The TDMPW is establish 
between both access gateways (then, each one is an PE):

|ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> |AGW| <-- 
[1xD channel ] |ISDN TE|
|_______| [NxB channels] --> |___| <--------[TDMPW]-------->|___| <-- 
[NxB channels] |_______|

* TE: Terminal equipment
* AGW: Access Gateway and PE
* MGC: Media Gateway Controller

1º An ISDN TE sends and Q.931 SETUP message to establish an ISDN 
multichannel call.

2º Upon receiving that ISDN signaling message, the MGC must tell the AGW 
(using MeGaCo/SDP) that it has to set up a TDMoIP PW, with the
proper parameters (for instance, the IP address of the other end/AGW). 
This is a similar case to the Megaco messages indicating the IP address 
and UDP ports
for RTP-based monocanal flows.

3º AGW sets up the TDMPW with the other AGW. NxB channels from one ISDN 
terminals are convey to the other ISDN TE through this TDMPW.

Without the MeGaCo/SDP indication (step "2º"), the AGW will not know 
what to do with the incoming ISDN B channels.

So far, there are three different groups that may normalize this 
SDP/MeGaCo dialogue:

- The IETF Megaco work group, as a H.248 profile
- The IETF PWE3, as a SDP description of each PW payload type proposal.
- The ITU-T, as H.248.x Recomendation or an Annex to Y.1453

Javi

> ..

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 6 Feb 2011 13:00:03 +0000

Javi,

I was indeed the editor of Y.1413, Y.1418, Y.1452, and Y.1453.

These were pure "network interworking" documents
(or as the IETF would call them "encaps")
and did not deal with any signaling issues,
assuming that any control plane used for the native service 
would work equally well when the native service was transported across an IP or MPLS network.

In ITU terms, these Recommendations were part of a migration scenario,
where IP or MPLS networks could be used to transport existing services.

In parallel the ITU developed the "Next Generation" services,
that run over IP and MPLS but use new control planes.

Y(J)S

-----Original Message-----
From: Javi [mailto:[email-masked]] 
Sent: Thursday, February 03, 2011 02:11
To: [email-masked]
Subject: RE: [PWE3] TDMPW terminated at terminal equipment

Sahsa, Yaakov and all,

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 6 Feb 2011 13:08:56 +0000

Javi

SAToP, CESoPSN, and TDMoIP-AAL1 TDM PWs are usually set up before they are needed, 
and remain up as long as they may be needed.
The individual channels are then set up using native signaling.

The scenario you mention (setting up bandwidth as needed) is handled in Y.1414 and Y.1452, 
and is not in the spirit of Y.1413 or Y.1453.
There are mechanisms in RFC 5287 for the TDMoIP AAL2 mode,
that help map individual voice channels.
Once an AAL2 mode PW is set up, you needn't signal for every channel up/down event,
since the BW is not consumed if not used.

Y(J)S

-----Original Message-----
From: Javi [mailto:[email-masked]] 
Sent: Thursday, February 03, 2011 02:33
To: [email-masked]
Subject: RE: [PWE3] TDMPW and MeGaCo/SDP

Yaakov, Sahsa, and all,

* TE: Terminal equipment

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Wed, 09 Feb 2011 20:09:29 +0100

Yaakov, setting-up a full mesh of PW does not scale well in
this scenario (in fact, we have also faced this problem in L2VPN
services). It is not a matter of BW, but of number of PW at every Access
Gateway (AGW). It will require the establishment of a PW to every
potential destination AGW (which may be in the numbers of tens of
thousands for a single PNO).

Native signalling is OK for individual channels inside the PW,
and the PW control plane is OK for negotiating PW features end-to-end,
but we (the MGC) still need to tell the AGW to trigger the PW
establishment to a given destination AGW. The IP address of the
destination AGW (and perhaps other parameters) should be communicated to
the source AGW (by the MGC), so that the former can start the PW
establishment procedure.

And, even in the case you mention (pre-established PW), we (the MGC)
still need to tell the AGW wich PW to use. It is not the AGW who knows
the final destination, but the MGC (where the high-level signaling
terminates).

In fact I believe that the VPN example mentioned above has some
similarities with the AGW scenario: in the BGP-based L3VPN (rfc 4364,
was 2547bis) you do use an extra control plane (iBGP) to tell the
VRF (access node) which PW to use, using an iBGP attribute (the "label")
that may be thought as an "SDP description"

May be I'm wrong, but, if I were right and you finally agree with
my point, I would like to know your opinion on which standard
body should specify the SDP description of the PW parameters:

- will it be the IETF?. Some examples of similar cases where the
   IETF defines an SDP description to be used by a third
   signalling protocol may be IETF RFC4733 (SDP description for
   codec "telephone-event") or RFC4733 (event codes).

- will if be the ITU? Some examples of similar cases where the
   ITU-T defines SDP atributes to be used by other protocols are
   V.152 (attribute "a=gpmd"), T.38 (SDP description for the
   protocol "udptl" and "tcptl"),
   V.150.1 ("a=sprtmap:<dynamicPort> v150mr/8000") and
   V.151 (codec "a=rtpmap:<dynamicPort> t140c/8000").

  - will it be any other?

Javi

---

From: Javi Muñoz <[email-masked]>
Date: Thu, 24 Feb 2011 12:58:01 +0100

Hi Yaakov and all,

Setting-up a full mesh of PW does not scale well in

  - will it be any other?

Javi