Javi | 16 Jun 2010 17:00
Picon

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

Carlos,

Thanks for your clarification.
>
> 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).
What CE to CE signalling would you use to match DLCIs?, Q.933?

Thanks

Javi
>
> Thanks,
>
> -- Carlos.
>
>
> On 6/16/2010 7:29 AM, Javi wrote:
>> 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
(Continue reading)

Ignacio Goyret | 18 Jun 2010 21:20
Favicon

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

[due to an error on my part, this response didn't go to the list -
  please, accept my apologies if you get a duplicate]

Javi wrote:
> Carlos,
> 
> Thanks for your clarification.
>>
>> 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).
> What CE to CE signalling would you use to match DLCIs?, Q.933?
> 
> Thanks
> 
> Javi

Javi,
May be a diagram may help clarify the idea:

             C1                            C2
    [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

                <------ L2TP HDLCoPW ---->

            <------------- FR traffic ------->

In other words, the above set of devices will behave exactly
the same (bit for bit on cables C1 and C2) as if C1 and C2
were the same physical cable, eg:
(Continue reading)

Javi | 18 Jun 2010 21:37
Picon

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

Ignacio,

Thanks for the diagram.

The doubt is about FRoPW:

            C1                            C2
   [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

               <------ L2TP FRoPW ---->

           <------------- FR traffic ------->

 From the CE point of view, FR link is finished by remote system?:

   [ FR A ]----..........................----[ FR B ]

           <------------- FR traffic ------->

or by its LCCE?:

            C1                            C2
   [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

               <------ L2TP FRoPW ---->

           <---->                       <---->
         FR traffic                   FR traffic

Thanks,
(Continue reading)

Ignacio Goyret | 18 Jun 2010 21:46
Favicon

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

Javi wrote:
> Ignacio,
> 
> Thanks for the diagram.
> 
> The doubt is about FRoPW:

Ok, this is a different question. You were asking earlier about FR in 
"port mode" which is HDLCoPW, not FRoPW.

For FRoPW, the correct drawing is this:

>            C1                            C2
>   [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]
> 
>               <------ L2TP FRoPW ---->
>           <---->                       <---->
>         FR traffic                   FR traffic

where "FR traffic" here means Q933 exchanges. The actual data traffic
for each PVC is obviously transported end to end (ie, FR A to FR B
and viceversa).

  >  From the CE point of view, FR link is finished by remote system?:

Yes, because the DLCIs in _this_ mode have local significance.
In other words, Q933 exchanges happen between "FR A" and "LCCE 1" in
one end and between "FR B" and "LCCE 2" on the other end.

In this mode, the L2TP cloud behaves as if it were a FR switch,
(Continue reading)

Javi Muñoz | 22 Jul 2010 13:19
Picon

RFC 4591 and RFC 4349

Ignacio,

Some yeras ago, you explained me the next working of the HDLCPWs and FRPWs:

===
a) HDLCPWs (port mode):

             C1                            C2
    [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

<------ L2TP HDLCoPW ---->

<------------- FR traffic ------->

The above set of devices will behave exactly
the same (bit for bit on cables C1 and C2) as if C1 and C2
were the same physical cable, eg:

    [ FR A ]----..........................----[ FR B ]

<------------- FR traffic ------->

where the series of dots above represents the transparent PW
between LCCE 1 and LCCE 2.

b) FRoPW (DLCI mode):

            C1                            C2
   [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

(Continue reading)

Javi Muñoz | 22 Jul 2010 13:35
Picon

RFC 4591 and RFC 4349

[I resend the e-mail with the graphics fixed. Sorry the inconvenience]

Ignacio,

Some yeras ago, you explained me the next working of the HDLCPWs and FRPWs:

===
a) HDLCPWs (port mode):

             C1                            C2
    [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]

               <------ L2TP HDLCoPW ---->

             <------------- FR traffic ------->

The above set of devices will behave exactly
the same (bit for bit on cables C1 and C2) as if C1 and C2
were the same physical cable, eg:

    [ FR A ]----..........................----[ FR B ]

            <------------- FR traffic ------->

where the series of dots above represents the transparent PW
between LCCE 1 and LCCE 2.

b) FRoPW (DLCI mode):

            C1                            C2
(Continue reading)

Ignacio Goyret | 22 Jul 2010 21:50
Favicon

Re: RFC 4591 and RFC 4349

At 01:35 PM 7/22/2010 +0200, Javi Muñoz wrote:

>b) FRoPW (DLCI mode):
>
>           C1                            C2
>  [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ]
>
>               <------ L2TP FRoPW ---->
>         <---->                        <---->
>        FR traffic                   FR traffic
>
>...
>In this mode, the L2TP cloud behaves as if it were a FR switch.
>
>===

>b) FRPWs: according with your explanation, I would understand the next one:
>
>                                           ¿ ?
>                                            |
>                                            |
>                                           \ /
>DTE - PE/DCE <== FRPW ==> PE/DCE - ¿DTE? <== Data Network ==> DCE - DTE
>  <Q.933>                     <Q.933>                          <Q.933>
>  <-------------------------- FR VC -------------------------------->
>  <DLCI_1> [DLCI switching] <DLCI_2>     [ DLCI switching ]   <DLCI_3>
>           [DLCI_1 => DLCI_2]            [DLCI_2 => DLCI_3]
>
>    However, it would not be possible, due to the access nodes to the data network must be DCEs.

(Continue reading)

Javi Muñoz | 23 Jul 2010 10:59
Picon

Re: RFC 4591 and RFC 4349

Hi Ignacio,

b) FRoPW (DLCI mode): C1 C2 [ FR A ]----[ LCCE 1 ]------[ LCCE 2 ]----[ FR B ] <------ L2TP FRoPW ----> <----> <----> FR traffic FR traffic ... In this mode, the L2TP cloud behaves as if it were a FR switch. ===
b) FRPWs: according with your explanation, I would understand the next one: ¿ ? | | \ / DTE - PE/DCE <== FRPW ==> PE/DCE - ¿DTE? <== Data Network ==> DCE - DTE <Q.933> <Q.933> <Q.933> <-------------------------- FR VC --------------------------------> <DLCI_1> [DLCI switching] <DLCI_2> [ DLCI switching ] <DLCI_3> [DLCI_1 => DLCI_2] [DLCI_2 => DLCI_3] However, it would not be possible, due to the access nodes to the data network must be DCEs.
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.

I need to detail this scenario for an specific application of the FRPWs (to ISDNs).

According to the working of the FRPWs, I think that the DTE/DCE funcionality of each CEs and PEs would be:

CE1(DTE) - PE1(DCE) <== FRPW(DLCI switching) ==> PE2(DCE) - CE2(DTE) However, when I consider a back to back comunication between tww FR terminals, that behaviour is not coherent with the classical FR working:

CE1(DTE,FR terminal) - PE1(DCE) <=FRPW=> PE2(DCE) - CE2(DTE) <=Data Network=> DCE - DTE (FR terminal) From the point of view of the "Data network", it would be:

CE1(DTE,FR terminal) - PE1(DCE) <=FRPW=> PE2(DTE) - CE2(DCE) <=Data Network=> DCE - DTE (FR terminal)


but it would not coincide with the "DLCI swithing" working of the FRPWs.


Could you help me to assign the DTE or DCE behaviour of each equipment in this back-to-back communication?


Thanks,

Javi

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

Gmane