gmane.ietf.l2tpext

Emulation of basic ISDN interfaces using TDMPWs

Javi Muñoz — 2011-12-30T12:10:58

Is a TDMPW able to emulate a basic ISDN interface [I.430]?:

a) SAToP (or AAL1 without SDT): it includes E1/DS1 (125 us) or E3/DS3 
frames. Basic ISDN interfaces use frames of 250 us).

b) CESoPSN (or AAL1 with SDT): it includes E1/DS1 frames or 64-kbps 
channels. However, in the basic ISDN interfaces, D-channel is 16 kbps.

c) AAL2: I know it is able, such as MPLS forum includes in 
[af-vmoa-0145.001/Table-1]

Regards

Javi

A TDMPW per call o a TDMPW for multiple calls

Javi Muñoz — 2011-12-23T11:54:04

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

Set up of TDMPWs after the establishment of a call

Javi Muñoz — 2011-12-13T12:15:47

Recommendations [ITU-T Y.2262; Y.2012] proposes to support multichannel 
ISDN calls using TDMoIP (UDP/IP TDMPWs). However, they do not indicate 
what kind of TDMPW, or when it must be set up.

The scenario is:

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

* AGW (Access Gateway) would also be the PE (Provider Edge) of the TDMPW.


I understand that:

* Static TDMPWs (SAToP, CESoPSN, TDMoIP AAL1) must be set up before 
calls: so, they are not a good choice in this case for reasons of 
scalability (It will require the establishment of a PW with every 
potential destination AGW, which may be in the numbers of tens of 
thousands for a single PNO).

* TDMPW TDMoIP AAL2: I think it is possible to set up the TDMPW between 
two AGWs when the first call occurs between them. For second and 
subsequent calls, it would expand the number of CIDs of the TDMPW. The 
TDMPW would be

PWs in the NGN network

Javi Muñoz — 2011-12-12T18:34:02

In the ETSI or ITU-T NGN, is it possible the communication between two 
NGN TEs using a TDMPW?

TE NGN <---> PE <--  [NGN network]  --> PE <--> TE NGN


What NGN functional entity should be the PE (Provider Edge which 
terminates the PW)?

Regards,

Javi

Different manipulation of channels in a Nx64 service

Javi Muñoz — 2011-12-12T17:27:44

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,

Re: Payload needs to align with a 32-bit boundary

Ignacio Goyret — 2011-12-02T02:46:22

Can you provide any hints as to where did you read this requirement?

Payload needs to align with a 32-bit boundary

Javi Muñoz — 2011-12-01T16:37:32

The requeriment "PW payload must be an integer number of 4 octets" 
affects to:

* Any PW:
     + TDMPWs (any type -SAToP, CESoPSN, TDMoIP AA1/AAL2-  and 
with/without RTP header)
     + HDLCPWs
     + FRPWs, ...

* and for any PSN:
     + L2TPv3
     + MPLS
     + UDP/IP
     + Ethernet


or only some of them?

Regards,

Javi

FR over PWs

Javi — 2011-11-20T13:32:31

In the emulation of Core-LAPF links over PWs:

a) [RFC4591] (FRoPW L2TPv3):

     + FRPW Payload: Core-LAPF PDU is transported in its entirety, 
excluding flags and FCS, bit stuffing is undone. So, FRPW payload 
transports Core-LAPF "address and data" fields.

     + L2-Specific Sublayer: presents if sequencing or other features 
required. The Default format defined in Section 4.6 of [RFC3931] MUST be 
used.

     + Bits of the Core-LAPF Address:
        * C/R: conveyed transparently.  Its value MUST NOT be changed by 
the LCCE.
        * FECN, BECN, DE: MAY be set by the LCCE.



b) [RFC4619] (FRoMPLS):

     + FRPW Payload: Core-LAPF PDU is transported in its entirety, 
excluding bit/byte stuffing, frame relay header, and FCS. I understand 
"frame relay header" means "Core-LAPF address field". So, FRPW payload 
would ONLY transport Core-LAPF data field.

     + L2-Specific Sublayer (CW): always presents, with the bits C, D, F, B

     + Bits of the Core-LAPF Address:
        * C/R: copied unchanged in the

TDMoIP AAL2 and TSSI/RDTD structures

Javi Muñoz — 2011-10-13T11:57:14

ITU-T I.140 defines:

+ RDTD structure (restricted differential time delay): if two samples, 
for any two different channels of an aggregate of channels (B1 and 
B2),are transmitted at the same time, they must separate to the 
destination no more than "50 ms".

+ TSSI structure (time slot sequence integrity): if a sample "bi" is 
send and, later, a second sample "bk" (for any two different channels of 
an aggregate of channels, B1 and B2), "bi" always come first.


If we use a TDMoPW TDMoIP AAL2 to emulate the aggregate of that channels 
(B1 and B2), would TSSI and RDTD structures be guaranteed?

TDMoIP AAL2: Selection of channels

Javi — 2011-09-03T15:41:19

[RFC5611] indicates: "Using the variable-rate AAL2 mode, we may 
dynamically allocate channels to be transported (i.e. VAD), thus 
conserving bandwidth."

Is it possible to use the MeGaCo protocol to indicate to the PEs which 
channels may be transported by a TDMPW? (it would allow to select the 
channels to be transported based on any criteria, such as an external 
signalling protocol).

Re: FRPW: LAPF or Core-LAPF

Carlos Pignataro — 2011-08-11T14:19:41

Javi,

The response at
<http://www.ietf.org/mail-archive/web/pwe3/current/msg12573.html> is
applicable here to RFC 4349 and RFC 4591 respectively.

Thanks,

FRPW: LAPF or Core-LAPF

Javi — 2011-08-08T18:58:43

Does FRPW[RFC4591] support LAPF frames (with control field)[Q.933] or 
only Core-LAPF frames (without control field)[Q.933/Annex A]?

If FRPW supports LAPF frames, must the ingress PE read the control field 
or it must be carried transparently to the egress PE?

Re: [Editorial Errata Reported] RFC3931 (2766)

Ignacio Goyret — 2011-04-22T17:55:46

Hi Carlos,
I agree with you. There is no need to explicitly mention the
DF check: that is implied by the IPv4 fragmentation process
as described in RFC791.
I also reject the errata.
-Ignacio

At 12:08 AM 4/22/2011 -0400, Carlos Pignataro wrote:
>>

Re: [Editorial Errata Reported] RFC3931 (2766)

Carlos Pignataro (cpignata — 2011-04-22T12:10:37

Thank you, Teco. IMHO, using this as such example is stretching the meaning beyond reasonable. The text (or other similar ones) do not say that TTL/HL is decremented when forwarding a packet either... But I do not see a reason to add that explicitly. 

Carlos P.

On Apr 22, 2011, at 4:27 AM, "Teco Boot" <teco< at >inf-net.nl> wrote:

_______________________________________________
L2tpext mailing list
L2tpext< at >ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext

Re: [Editorial Errata Reported] RFC3931 (2766)

Teco Boot — 2011-04-22T08:27:20

Hello Carlos,

Thanks clearing this up. I agree on your argumentation that text already
is clear that IPv4 packets with DF=1 shall not be fragmented. That is why
I used type Editorial.
But others used this RFC as example that fragmenting DF=1 packets is legal.

Thanks, Teco


Op 22 apr 2011, om 06:08 heeft Carlos Pignataro het volgende geschreven:

>>

Re: [Editorial Errata Reported] RFC3931 (2766)

Carlos Pignataro — 2011-04-22T04:08:06

Hi,

Please find an initial comment on this erratum, my 2¢ as an individual:

I appreciate the need to precision, and just followed the discussion
about DF and ip.ident, in Int-area.

However, I do not agree with the interpretation that supports this
change, and I have a different read of the second para of S4.1.4 of RFC
3931. The text in question says:

   For
   example, if an IPv4 packet arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and IP,
   does not fit in the available path MTU towards its LCCE peer, the
   local LCCE may perform IPv4 fragmentation on the packet before tunnel
   encapsulation.

And the key here is "the local LCCE may perform IPv4 fragmentation".
Performing IPv4 fragmentation does not imply that the result is
fragmenting a datagram (or a fragment). The result of the fragmentation
procedure can just be check the DF and discard.

When RFC 791 describes the fragmentation procedures, the first step is
to compare the TL with the MTU

[Editorial Errata Reported] RFC3931 (2766)

RFC Errata System — 2011-04-04T14:19:32

The following errata report has been submitted for RFC3931,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3931&eid=2766

--------------------------------------
Type: Editorial
Reported by: Teco Boot <teco< at >inf-net.nl>

Section: 4.1.4

Original Text
-------------
   An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
   example, if an IPv4 packet arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and IP,
   does not fit in the available path MTU towards its LCCE peer, the
   local LCCE may perform IPv4 fragmentation on the packet before tunnel
   encapsulation. 

Corrected Text
--------------
   An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
   example, if an IPv4 packet with DF=0 arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and I

L2TPV3

jmillan — 2011-03-25T06:48:12

 

I am Juan Millán, member of R&D of Teltronic. We are a looking for routers
with L2TPV3 and we only are finding CISCO routers, are there any other
company that has the L2TPV3 implemented?

We are looking for a cheap, carril DIN L2TPV3 router, that is way we are not
interested in CISCO routers (very expensive anr rack19, 1/2 U)

 

Thank you very much in advanced

Kind regards

Juan

----------------------------------------------------------------------------
----------

Juan Millán  ( jmillan< at >teltronic.es )

Hardware Design Engineer/ Ingeniero de desarrollo de Hardware 

R&D Dept./ Dpto. I+D 

 

TELTRONIC, S.A.U.

Polígono Malpica. Calle F - Oeste - Parcela 12.

50057 ZARAGOZA (Spain)

Phone: +34 976 465656 / +34 902 418016    Ext. 344

Fax: +34 976 465722    <http://www.teltronic.es/> http://www.teltronic.es

----------------------------------------------------------------------------
--------------------------- 

P               Antes de imprimir este e-mail piense en el medioambiente.
Before print

Fwd: NomCom 2010-2011: Call for More Nominations

Ignacio Goyret — 2010-09-17T00:06:59

Re: RFC 4591 and RFC 4349

Javi Muñoz — 2010-07-23T08:59:08

_______________________________________________
L2tpext mailing list
L2tpext< at >ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext

Re: RFC 4591 and RFC 4349

Ignacio Goyret — 2010-07-22T19:50:32





I think you are overthinking this.

First, note that my drawings did not include any references to
DCE or DTE on purpose because that is an implementation issue
out of scope for L2TP.

I imagine that if someone wanted to use FR over an L2TP PW,
the LCCEs (or the devices feeding into the LCCEs) would have
to be DCE or DTE as needed. There are many devices out there
that can be configured as either DCE or DTE so this shouldn't
really be a problem.

HTH,
-Ignacio