Subject: RE: [L2CP] L2C Encapsulation using GSMP RFC3293 Framework

From: "Jerome Moisand" <[email-masked]>
Date: Mon, 27 Feb 2006 13:09:34 -0500

In any case, I think we should stick to an IP-based encapsulation. This
would provide proper independence from whatever is deployed between the
Access Node and the BRAS. And foresee other scenarios where the
controlled device might be something else than an Access Node, and maybe
located more than one IP hop away. 

Then whether we use UDP (which would imply more GSMP logic for
reliability), TCP, SCTP or else is open for discussion. Yes, a form of
negotiation might become necessary if we settle on too many variants,
but we're not there yet! ;-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 27, 2006 6:22 AM
To: Pramod Kaluskar
Cc: Haag, T; Busser,M; [email-masked]; Meyer04,Klaus
Subject: RE: [L2CP] L2C Encapsulation using GSMP RFC3293 Framework

Hi all, 

[email-masked] wrote: 
> (2) can be used if we know that the packet is going to be "tunneled"
across an ATM network into an 
> Ethernet network and that the switch has an Ethernet interface.  If
this is not known or if the switch 
> uses some other L2 protocol but has a known IP-address, we could use
the routed encapsulation over 
> ATM. 

Today, L2CP is only envisaged with GSMP on top of TCP/IP. 
I understand that other GSMP encapsulation modes are desirable as well:
not only existing standard ones 
but also possibly new ones. Reasons for this can be multiple, e.g.
better scaling on BRAS... 

When several GSMP encapsulations are possible, I assume that settling
about which one will be used 
between a "switch" and a "controller" is a normal business issue for
GSMP implementations - nothing special 
for L2CP - right ? 

Not sure what usual GSMP practices are in general but I can think about
the following alternatives: 

1) for "switch" and "controller" supporting only one encapsulation: 
       -> having the operator(s) just deploying compatible machines... 

2) for "switch" and "controller" supporting several GSMP encapsulations,

     a) -> having the operator(s) statically configuring "switch" and
"controller" with a 
          unique & common encapsulation 
     b) -> automatic selection: "switch" and "controller" try to
establish adjacency using 
         all their supported encapsulations until they hook with each
other. 

I think that the 1),  2)a) and 2)b) alternatives can safely be left to
vendor featuring and operator 
selection - no need for standardization here. 

If we agree on this, I guess we'll have free hands to elaborate any
additional/new GSMP encapsulation 
when used for L2CP, without fear for compatibility problem... 

What is your opinion, is my view correct ? 

Thanks, 
Kind regards, 
Robert 

"Pramod Kaluskar" <[email-masked]> 

02/24/2006 08:45 PM 

        To:        "Haag, T" <[email-masked]>,
<[email-masked]> 
        cc:        "Busser, M" <[email-masked]>, "Meyer04,
Klaus" <[email-masked]> 
        Subject:        RE: [L2CP] L2C Encapsulation using GSMP RFC3293
Framework

Thomas, 
  
I agree that in order to converge between ATM and Ethernet networks - it
might be a good idea to have a single consistent encapsulation over ATM
(as defined in RFC 2684). 
  
I checked RFC2684 and find that there are indeed two ways possible ways
of encoding this: 
  
1.        Routed with LLC / SNAP of 0xAA-AA-03-00-00-00 followed by
Ethertype of 0x88-0C 
2.        Bridged as a Ethernet packet with Ethertype of 0x88-0C 
  
(2) can be used if we know that the packet is going to be "tunneled"
across an ATM network into an Ethernet network and that the switch has
an Ethernet interface.  If this is not known or if the switch uses some
other L2 protocol but has a known IP-address, we could use the routed
encapsulation over ATM. 
  
Regards, 
Pramod 
____________________________________________ 
Pramod Kaluskar                                                 Tel:
732-345-6234 
Conexant Systems, Inc.  100 Schulz Dr, Red Bank, NJ 07701, USA 

________________________________

From: Haag, T [mailto:[email-masked]] 
Sent: Friday, February 24, 2006 11:20 AM
To: [email-masked]
Cc: Busser, M; Meyer04, Klaus
Subject: [L2CP] L2C Encapsulation using GSMP RFC3293 Framework 

All, 

Running Layer 2 Control in ATM and Ethernet based networks should base
on common requirements like RFC3293. 

The document talks about three different types of encapsulation which
have different draw backs. 

 - GSMP Packet Encapsulation for ATM (section 2)

  VPI=0/VCI=15; preferred value would be VPI=254; VCI=32...
  No MAC address needed 

- GSMP Packet Encapsulation for Ethernet (section 3)
 MAC Address needed 

- GSMP Packet Encapsulation for TCP (section 4)
 No MAC Address needed; But additional IPsec for security 

To be consistent by operating parallel ATM and Ethernet in networks the
encapsulation should be done similar for all Types. 

I think it should be investigated to run GSMP packets over bridged
encapsulation via ATM according RFC2684 using MAC addresses for
detection of Layer 2 Control sender instance, and receiver instance.
This would enable to run GSMP Ethernet Packet Encapsulation on Top of
ATM using the same sender and receiver assignment. 

Regards 

Thomas Haag 
********************** Legal Disclaimer **************************** 
"This email may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or
distribution by others is strictly prohibited. If you have received the
message in error, please advise the sender by reply email and delete the
message. Thank you." 
**********************************************************************
_______________________________________________
L2cp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2cp

_______________________________________________
L2cp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2cp

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 27 Feb 2006 11:46:25 -0800

Whatever transport is used, it needs:
- message framing
   TCP does not provide this, hence the header in rfc3293, sec 4.1.
   ATM and Ethernet provide this.
- reliable transmission
   If GSMP messages are not delivered, the peers will get out
   of sync. TCP provides this feature, but Ethernet and ATM do not.
- congestion control
   On session establishment, the DSLAM sends all port up/down messages.
   This requires congestion control. TCP provides it, but not
   Ethernet or ATM.

Any feature that is provided by one of the transports should
not be duplicated in GSMP. Eg. reliable transmission should
not be built into GSMP, but in a separate layer. This reliability
layer should be used only when using an unreliable transport,
not when using TCP.

If a reliability layer is used on top of TCP, TCP will transmit
and acknowledge (and possibly retransmit) acknowledgements of
that higher layer. That is an ugly waste of bandwidth.

Jerome Moisand wrote:
> but we’re not there yet! ;-)
> 
>  
> 
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Monday, February 27, 2006 6:22 AM
> *To:* Pramod Kaluskar
> *Cc:* Haag, T; Busser,M; [email-masked]; Meyer04,Klaus
> *Subject:* RE: [L2CP] L2C Encapsulation using GSMP RFC3293 Framework
> 
>  
> 
> 
> Hi all,
> 
>>  (2) can be used if we *know* that the packet is going to be “tunneled” 
> *"Pramod Kaluskar" <[email-masked]>*
> 
> 02/24/2006 08:45 PM
> 
> 	
> 
>        
>         To:        "Haag, T" <[email-masked]>, <[email-masked]>
> I agree that in order to converge between ATM and Ethernet networks – it 
> (2) can be used if we *know* that the packet is going to be “tunneled” 
> ____________________________________________ */
> Pramod Kaluskar                                                 Tel: 
> 732-345-6234/*
> */Conexant Systems, Inc.  100 Schulz Dr, Red Bank, NJ 07701, USA/*
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> 
> *From:* Haag, T [mailto:[email-masked]] *
> Sent:* Friday, February 24, 2006 11:20 AM*
> To:* [email-masked]*
> Cc:* Busser, M; Meyer04, Klaus*
> Subject:* [L2CP] L2C Encapsulation using GSMP RFC3293 Framework
>  
> 
> All,
> 
> ------------------------------------------------------------------------
>