Subject: [L2tpext] Pseudo-wires: uni-directional o bi-directional?

From: Javi <[email-masked]>
Date: Fri, 18 Jun 2010 17:48:55 +0200

A pseudo-wire is: uni-directional o bi-directional?

I thought that it was necessary to set up two symmetrical TDMoMPLS 
pseudo-wires (one for each direction) for emulating a bidirectional TDM 
circuit o HDLC/FR link.

However, I found confusing references:

RFC 4591 (L2TPv3 FRoPW), clause 5
There is a one-to-one mapping between a Frame Relay PVC and *an
FRPW, supporting bi-directional **transport *of variable length frames.

RFC 3985 (PWE3 Architecture)
7.3.1.  Pseudo Wire Up/Down Notification
    If a native service requires bi-directional connectivity, the
    corresponding emulated service can only be signaled as being up when
    the *PW* and PSN tunnels (if used), are *functional in both directions*.

RFC 5087 (TDMoIP PWs), clause 3
Since TDM is inherently bidirectional, the *association of two PWs in 
opposite directions is required*

RFC 5087 (TDMoIP PWs), clause 6
Since TDM *PWs are inherently bidirectional*

RFC 4591 (PWE3 Requirements), clause 5.1
If a native circuit is bi-directional, the corresponding emulated
circuit can be signaled "Up" only when the associated PW and PSN
tunnels *in both directions are functional*.

Javi

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 18 Jun 2010 12:39:32 -0700

[cross-posting since you posted the same question in PWE3 as well]

> pseudo-wires (one for each direction) for emulating a bidirectional TDM 

I'm not an MPLS expert (wrong WG) so I can't answer that part of the
question.

But I can tell you that all L2TP sessions are always capable of
bidirectional traffic, regardless of the type of data they may carry.
This is an intrinsic feature of L2TP.

-Ignacio

---

From: Javi <[email-masked]>
Date: Fri, 18 Jun 2010 22:21:03 +0200

Ignacio,

RFC 3931 (L2TPv3), clause 5.4.4
Note that a Session ID value is *unidirectional*.  Because each LCCE
chooses its Session ID independent of its peer LCCE, the value
does not have to match *in each direction* for a given session.

I understand each session is unidirectional, and two sessions (one for 
each direction) are needed for bidirectional traffic.

A Session ID is a possible PW label. So, a L2TPv3 session is really a 
L2TPv3 PW.

Thanks,

Javi

Ignacio Goyret escribió:
>> pseudo-wires (one for each direction) for emulating a bidirectional 
>> TDM circuit o HDLC/FR link.
>

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 18 Jun 2010 15:06:36 -0700

> each direction) are needed for bidirectional traffic.

No, an L2TP session is always 100% bidirectional: traffic can flow
in both directions.

It is only the IDs used to identify incoming packets at each end that
happen to be independent.

In other words, if you have an L2TP session opened between LCCE1
and LCCE2, traffic going from LCCE1 to LCCE2 will have a Session ID
that is independent (and potentially different) from the Session
ID used on traffic going from LCCE2 to LCCE1.

Although both directions have different IDs, they are halves of
the _same_ L2TP session. L2TP does not have the capability to create
unidirectional sessions.

If you like to think in physical terms, imagine a cable (session)
with a red connector in one end and a black connector in the other.
Although the ends have different colors, they are still ends of the
same cable. Any signal you send from either end will show up at
the other end of the cable, regardless of the connector color.

> A Session ID is a possible PW label. So, a L2TPv3 session is really a 

You are confusing terms and concepts.
Don't confuse labels with sessions with traffic within a session.
They are all very different concepts.

-Ignacio

---

From: Javi <[email-masked]>
Date: Mon, 21 Jun 2010 12:51:23 +0200

Ignacio,

Ok. I agree, L2TPv3 Session is bidirectional.

> They are all very different concepts.

I don't understand. I think a L2TPv3 PW is a pseudo-wire which "PW 
Label" is a "L2TPv3 Session ID". Why not?

Then, why is a L2TPv3 session not a "L2TPv3 PW"?, which would be the 
difference?

And, finally, is a PW bidirectional, like a L2TPv3 Session?

Javi

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 21 Jun 2010 19:14:14 -0700

> Label" is a "L2TPv3 Session ID". Why not?

Why not what? That question is not clear to me.

But note I didn't use the term "PW label". That is a term typically
used with MPLS and not all PWs are carried over MPLS.

So, let's clarify some terms: what do you call a "PW label"?
Because that term is not really used in L2TP terminology.

> Then, why is a L2TPv3 session not a "L2TPv3 PW"?, which would be the 

Be careful using a term like "L2TPv3 PW". That term can have two
potential meanings: either a PW built using L2TPv3 services or
an L2TPv3 session carried over some sort of PW.
Which do you mean?

At any rate, the difference is a matter of layers.

L2TPv3 is used to build PWs, but not the other way around.

> And, finally, is a PW bidirectional, like a L2TPv3 Session?

That's a question what should be asked on the PWE3 WG.
This WG (l2tpext) concerns itself only with L2TP.

-Ignacio

---

From: Javi <[email-masked]>
Date: Tue, 22 Jun 2010 12:49:11 +0200

> Because that term is not really used in L2TP terminology.

I don't agree. "PW label" is a general term for any PW (L2TPv3, MPLS, 
UDP/IP, Ethernet, ...)

See RFC 3985 "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", 
clause "5.4.1.  PWE3 over an IP PSN"

    PW Demultiplexing is provided by the PW label, which may take the
    form specified in a number of IETF protocols;  e.g., an MPLS label
    [MPLSIP], an L2TP session ID [RFC3931], or a UDP port number
    [RFC768].

> an L2TPv3 session carried over some sort of PW.

I understand a "L2TPv3 PW" is a PW which "PW Demultiplexer layer" (or PW 
label) is based on a L2TPv3 Session ID, using the L2TPv3 control plane.

An L2TPv3 session carried over some sort of PW (like a MPLS PW) would be 
different. Over a PW you may carry on any network service, such as 
L2TPv3, but in that case, the L2TPv3 session would not be part of the PW.

> L2TPv3 is used to build PWs, but not the other way around.

Ok, I agree with this.

> This WG (l2tpext) concerns itself only with L2TP.

I did, but I have not received any answer yet :-)

Thanks,

Javi