headers
Javi Muñoz | 30 Dec 2011 13:10
Picon

Emulation of basic ISDN interfaces using TDMPWs

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
Permalink | Reply | 0 comments |
headers
Javi Muñoz | 13 Dec 2011 13:15
Picon

Set up of TDMPWs after the establishment of a call

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
Permalink | Reply | 0 comments |
headers
Javi Muñoz | 12 Dec 2011 19:34
Picon

PWs in the NGN network

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
Permalink | Reply | 0 comments |
headers
Javi Muñoz | 12 Dec 2011 18:27
Picon

Different manipulation of channels in a Nx64 service

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
Permalink | Reply | 0 comments |
headers
Javi Muñoz | 1 Dec 2011 17:37
Picon

Payload needs to align with a 32-bit boundary

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
Permalink | Reply | 1 comment |
headers
Javi | 20 Nov 2011 14:32
Picon

FR over PWs

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?
Permalink | Reply | 0 comments |
headers
Javi Muñoz | 13 Oct 2011 13:57
Picon

TDMoIP AAL2 and TSSI/RDTD structures

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?
Permalink | Reply | 0 comments |
headers
Javi | 8 Aug 2011 20:58
Picon

FRPW: LAPF or Core-LAPF

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?
Permalink | Reply | 2 comments |
headers
RFC Errata System | 4 Apr 2011 16:19
Favicon

[Editorial Errata Reported] RFC3931 (2766)


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
Permalink | Reply | 4 comments |
headers
jmillan | 25 Mar 2011 07:48
Picon

L2TPV3

 

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

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

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
Permalink | Reply | 0 comments |
headers
Ignacio Goyret | 17 Sep 2010 02:06
Favicon

Fwd: NomCom 2010-2011: Call for More Nominations


>Date: Thu, 16 Sep 2010 18:32:59 -0500
>Subject: Fwd: NomCom 2010-2011: Call for More Nominations
>From: Mary Barnes <mary.ietf.barnes <at> gmail.com>
>To: IETF WG Chairs <wgchairs <at> ietf.org>
>
>Hi folks,
>
>If you could please forward this email to your WG mailing list, it
>would be much appreciated. As Tom notes below, there have been very
>few nominations thus far and there are only 2 weeks left in the
>nominations period.
>
>Thanks,
>Mary
>Nomcom 2010-2011 Advisor
>
>---------- Forwarded message ----------
>From: NomCom Chair <nomcom-chair <at> ietf.org>
>Date: Thu, Sep 16, 2010 at 6:26 PM
>Subject: NomCom 2010-2011: Call for More Nominations
>To: IETF Announcement list <ietf-announce <at> ietf.org>
>
>Hi Folks,
>
>Nominations have slowed down dramatically, so this update is to enlist
>the community in an effort to pick up the pace.
>
>We are very far behind in nominations for all the open positions but in
>particular we need nominations for the IESG and IAOC open positions.
>There have been no nominations received (other than for the incumbents)
>in INT, RAI, and RTG, and only 1 for OPS.  Likewise, in IAOC there have
>been no nominations submitted other than the incumbent.
>
>The acceptance rates of those nominated has also been very slow. In
>order to initiate the open list of willing nominees we are in need of a
>reasonable number of acceptances, and due to the low number of nominees
>and acceptances have delayed the start date for publishing the first
>open list to September 20.  So if you have been nominated and are
>willing to serve, but have not yet confirmed this by email back to the
>NomCom, please do so as soon as possible.
>
>We need Community input and participation! We cannot properly execute
>the task of selecting the best candidates for these positions with so
>few nominations and acceptances. So, please consider making
>nominations for the open positions, in particular those for which we
>have so few nominations ­ it takes just a few minutes of your time.
>Right now, we just need the names/email addresses.
>
>Why do we need more nominations?  Well, even if you think a willing
>incumbent is doing a very good job and should be returned, his or her
>ability to serve again might be impacted by unforeseen circumstances
>between now and March. NomCom needs to consider multiple nominees to be
>prepared in the event one or more candidates is unable to serve come next
>March and to ensure we have chosen the best candidate.
>
>There are several ways you can help the IETF Nominating Committee.
>
>- You may nominate yourself.
>- You can nominate someone you know whom you think would do a good job.
>
>Do not worry about whether they might already be nominated. We would
>much prefer to receive the same nomination several times rather than
>miss a good person we should consider.
>
>How to submit Nominations:
>--------------------------
>The list of positions we need to fill, and the provided Job
>Descriptions, and forms for nominations, can be found in the call for
>nominations at: https://datatracker.ietf.org/ann/nomcom/2468/
>
>You may enter a nomination by going to the following URL
>https://wiki.tools.ietf.org/group/nomcom/10/nominate
>
>You may also nominate someone by sending an email to nomcom10 <at> ietf.org
>and giving us their name, email address and the open position you are
>nominating them for. We will take care of the rest.
>
>If you are asked for a user name and password, use an existing ietf login
>and password. If you need a login and password, request one from the tools
>page at the following URL http://trac.tools.ietf.org/newlogin
>
>
>Open List:
>----------
>As you already know, NomCom 2010-2011 will follow the policy for "Open
>Disclosure of Willing Nominees" described in RFC 5680.
>
>Feedback Collection:
>--------------------
>Once the open list is available, the entire community will be invited
>to provide feedback. I will send a further announcement requesting
>feedback on the nominees, describing how to submit feedback, and how to
>view the open list of nominees.
>
>Thank you,
>
>Thomas Walsh
>Chair, NomCom 2010-2011
>nomcom-chair <at> ietf.org
>twalsh <at> juniper.net
Permalink | Reply | 0 comments |

Gmane