headers
Javi | 15 Jun 2010 19:46
Picon

RFC 4591 and RFC 4349: DLCI at egress LCCE

+ Frame Relay traffic transported in a "virtual circuit-to-virtual 
circuit" mode by L2TPv3 FRPW: Due to local significance of the DLCI, the 
egress LCCE re-writes the DLCI.

     RFC 4591 (L2TPv3 FRPW), clause 5
     The Frame Relay frame is transported in its entirety, including the 
DLCI ...  The egress LCCE re-writes the DLCI...

+ Frame Relay traffic transported in a "port" mode by L2TPv3 HDLCoPW 
(RFC 4349): It's not mentioned any DLCI modification at the egress LCCE. 
Why is it not necessary here (similarly, DLCI significance is local)?

Javi
Permalink | Reply |
headers
Carlos Pignataro (cpignata | 15 Jun 2010 21:42
Picon
Favicon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

Javi,

Because the "port mode" does not have granularity/visibility into the
DLCI level.

Thanks,

-- Carlos.

-----Original Message-----
From: l2tpext-bounces <at> ietf.org [mailto:l2tpext-bounces <at> ietf.org] On
Behalf Of Javi
Sent: Tuesday, June 15, 2010 1:46 PM
To: l2tpext <at> ietf.org
Subject: [L2tpext] RFC 4591 and RFC 4349: DLCI at egress LCCE

+ Frame Relay traffic transported in a "virtual circuit-to-virtual 
circuit" mode by L2TPv3 FRPW: Due to local significance of the DLCI, the

egress LCCE re-writes the DLCI.

     RFC 4591 (L2TPv3 FRPW), clause 5
     The Frame Relay frame is transported in its entirety, including the

DLCI ...  The egress LCCE re-writes the DLCI...

+ Frame Relay traffic transported in a "port" mode by L2TPv3 HDLCoPW 
(RFC 4349): It's not mentioned any DLCI modification at the egress LCCE.

Why is it not necessary here (similarly, DLCI significance is local)?
(Continue reading)

Permalink | Reply |
headers
Javi | 16 Jun 2010 01:28
Picon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

Carlos,

I agree, but I don't understand why. If a Frame Relay circuit is 
transported over a L2TPv3 HDLCoPW, the egress LCCE builds a FR frame 
with the same DLCI as the FR frame received by the ingress LCCE. If DLCI 
has local significance, CE/ingress_LCCE may use a different DLCI as 
CE/egress_LCCE. Why is not required here that the egress LCCE re-writes 
the DLCI (although it's not visible to PW)?.

Thanks,

Javi

Carlos Pignataro (cpignata) escribió:
> Javi,
>
> Because the "port mode" does not have granularity/visibility into the
> DLCI level.
>
> Thanks,
>
> -- Carlos.
>
> -----Original Message-----
> From: l2tpext-bounces <at> ietf.org [mailto:l2tpext-bounces <at> ietf.org] On
> Behalf Of Javi
> Sent: Tuesday, June 15, 2010 1:46 PM
> To: l2tpext <at> ietf.org
> Subject: [L2tpext] RFC 4591 and RFC 4349: DLCI at egress LCCE
>
(Continue reading)

Permalink | Reply |
headers
Carlos Pignataro (cpignata | 16 Jun 2010 05:45
Picon
Favicon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

Javi,

If the DLCIs are different then you cannot use the HDLCoPW. Or a  
different way, for port mode DLCIs need to match (it is extending a  
port) and for different DLCIs you need FRoPW.

Thanks,

Thumb typed by Carlos Pignataro.

On Jun 15, 2010, at 7:29 PM, "Javi" <javi <at> trajano.us.es> wrote:

> Carlos,
>
> I agree, but I don't understand why. If a Frame Relay circuit is  
> transported over a L2TPv3 HDLCoPW, the egress LCCE builds a FR frame  
> with the same DLCI as the FR frame received by the ingress LCCE. If  
> DLCI has local significance, CE/ingress_LCCE may use a different  
> DLCI as CE/egress_LCCE. Why is not required here that the egress  
> LCCE re-writes the DLCI (although it's not visible to PW)?.
>
> Thanks,
>
> Javi
>
>
>
> Carlos Pignataro (cpignata) escribió:
>> Javi,
>>
(Continue reading)

Permalink | Reply |
headers
Javi | 16 Jun 2010 13:29
Picon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

Carlos,

Each CE decides the DLCI by itself (and dinamically for switched virtual 
circuits, sopported by HDLCoPW).

How may you know if both CEs use different DLCIs?. If you want to use 
HDLCoPW, you would need to ensure that.

Thanks,

Javi

El 16/06/2010 5:45, Carlos Pignataro (cpignata) escribió:
> Javi,
>
> If the DLCIs are different then you cannot use the HDLCoPW. Or a 
> different way, for port mode DLCIs need to match (it is extending a 
> port) and for different DLCIs you need FRoPW.
>
> Thanks,
>
> Thumb typed by Carlos Pignataro.
>
> On Jun 15, 2010, at 7:29 PM, "Javi" <javi <at> trajano.us.es> wrote:
>
>> Carlos,
>>
>> I agree, but I don't understand why. If a Frame Relay circuit is 
>> transported over a L2TPv3 HDLCoPW, the egress LCCE builds a FR frame 
>> with the same DLCI as the FR frame received by the ingress LCCE. If
(Continue reading)

Permalink | Reply |
headers
Carlos Pignataro | 16 Jun 2010 13:43
X-Face
Picon
Favicon

Re: RFC 4591 and RFC 4349: DLCI at egress LCCE

Javi,

Please note from RFC4349:

http://tools.ietf.org/html/rfc4349#section-4.1

   Since all packets are passed in a largely transparent manner over the
   HDLCPW, any protocol that has HDLC-like framing may utilize the
   HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay
   transport), X.25 (LAPB), etc.  In such cases, the negotiations and
   signaling of the specific protocols transported over the HDLCPW take
   place between the Remote Systems.  A non-exhaustive list of examples
   and considerations of this transparent nature include:
[...]
      o When the HDLCPW transports Frame-Relay traffic, PVC status
        management procedures (Local Management Interface) take place
        between Remote Systems, and LCCEs do not participate in LMI.
        Additionally, individual Frame-Relay virtual-circuits are not
        visible to the LCCEs, and the FECN, BECN, and DE bits are
        transported transparently.

Think of the HDLCoPW as a cable, with "CEs" connected back-to-back on
that port. Any configuration would need to use the same DLCIs, and any
potential signaling would be CE to CE (needing to match DLCIs).

So, again, if DLCIs are different then you cannot use the HDLCoPW.

Thanks,

-- Carlos.
(Continue reading)

Permalink | Reply |

Gmane