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 deleted when all calls between the two AGWs are released.


Two questions:

(a) Is it valid this proposed use of TDMPWs?

(b) Each AGW/PE could belong to a different PNO. Is it possible to 
establish a TDMPW between two PEs that belong to different PNO?

Regards,

Javi

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

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, 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 AAL1, 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

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 CW (bit C)
        * FECN: copied in the CW (bit F). If it is not already set, it 
MAY be set as a result of ingress frame policing.
        * BECN: copied in the CW (bit B). If it is not already set, it 
MAY be set as a result of ingress frame policing.
        * DE: copied in the CW (bit D). If it is not already set, it MAY 
be set as a result of ingress frame policing.



Why these differences?.

In RFC4591, I understand FRPW payload transports "Core-LAPF address 
field", but egress LCCE does not use it (apart from "C/R" bit). Why?

Why does RFC4591 transports "Core-LAPF address field" in the FRPW 
payload insteed of using the L2-Specific Sublayer such as RFC4619?

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, and if the TL > MTU then check the DF,
and discard the datagram if DF is set. That is, check DF and discard is
part of the "fragmentation procedure". This means that "perform IPv4
fragmentation" can be: if the datagram is too big for the tunnel, then
check DF and if set then drop and send an ICMP3/4 to the source (with a
Next-Hop MTU that accounts for the tunnel encap). I am aware of
implementations that work like this. And this allows for PMTUD to work
as if the tunnel is just another link.

Excerpts of RFC 791 that support this are:

    An Example Fragmentation Procedure

      Procedure:

        IF TL =< MTU THEN Submit this datagram to the next step
             in datagram processing ELSE IF DF = 1 THEN discard the
        datagram ELSE
        To produce the first fragment:


The paragraph of RFC3931 describes pre-fragmentation (i.e.,
fragmentation before encapsulation). This is further covered in the
later S3.4 of RFC 4459:

http://tools.ietf.org/html/rfc4459#section-3.4

3.4.  Fragmentation of the Inner Packet

   A final possibility is fragmenting the inner packet, before
   encapsulation, in such a manner that the encapsulated packet fits in
   the tunnel's path MTU (discovered using PMTUD).  However, one should
   note that only IPv4 supports this "in-flight" fragmentation;
   furthermore, it isn't allowed for packets where the Don't Fragment
   bit has been set.  Even if one could ignore IPv6 completely, so many
   IPv4 host stacks send packets with the DF bit set that this would
   seem unfeasible.

Based on this, I'd recommend rejecting this erratum.

Thanks,

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

Notes
-----
Following RFC 791, IPv4 packets with the DF flag set shall not fragment such packets. RFC 3931 shall not make a precedent for fragmenting IPv4 packets with DF=1.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC3931 (draft-ietf-l2tpext-l2tp-base-15)
--------------------------------------
Title : Layer Two Tunneling Protocol - Version 3 (L2TPv3)
Publication Date : March 2005
Author(s) : J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.
Category : PROPOSED STANDARD
Source : Layer Two Tunneling Protocol Extensions
Area : Internet
Stream : IETF
Verifying Party : IESG

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 printing this e-mail please consider your environmental
responsibility. 

***** AVISO LEGAL  *****

Este mensaje es solamente para la persona a la que va dirigido.  Puede
contener informacion confidencial  o  legalmente  protegida.  La transmision
erronea de este mensaje no supone renuncia a su confidencialidad o a
cualquier privilegio. Si usted ha recibido este mensaje por error, le
rogamos que borre de su sistema inmediatamente el mensaje asi como todas sus
copias y que notifique al remitente.  No debe, directa o indirectamente,
usar, revelar, distribuir, imprimir o copiar ninguna de las partes de este
mensaje si no es usted el destinatario. Cualquier opinion expresada en este
mensaje proviene del remitente, excepto cuando el mensaje establezca lo
contrario y el remitente este autorizado para establecer que dichas
opiniones provienen de TELTRONIC. En el caso de que el destinatario de este
mensaje no consienta la utilizacion del correo electronico via Internet,
rogamos lo ponga en nuestro conocimiento de manera inmediata.

*****  DISCLAIMER  *****

This message is intended exclusively for the named person. It may contain
confidential, propietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. Your must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorised to state them to be the views of TELTRONIC. If the addressee of
this message does not consent to the use of internet e-mail, please
communicate it to us immediately.

 

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

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