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

From: "Haag, T" <[email-masked]>
Date: Fri, 24 Feb 2006 22:37:57 +0100

Pramud,

Thanx for your response.

I had in mind what you mentioned. It will be the case if you terminate two different DSLAM - Types  (ATM and Ethernet) to one BRAS.  

Regards

Thomas Haag 

Project Manager and Consultant 
Broadband-Access & -Transport; Local Loop Spectrum Management 

T-Systems Enterprise Services GmbH 
Technology Center 
Engineering Networks, Products & Services 

Address: Deutsche Telekom Allee 7, 64295 Darmstadt 
Phone: +49 6151/937- 53 47 
Fax: +49 6151/937- 30 47 
E-Mail:  <mailto:[email-masked]> [email-masked] 
Internet:  <mailto:[email-masked]> http://www.t-systems.com 

-----Ursprüngliche Nachricht-----
Von: Pramod Kaluskar [mailto:[email-masked]] 
Gesendet: Freitag, 24. Februar 2006 20:45
An: Haag, Thomas; [email-masked]
Cc: Busser, Michael; Meyer, Klaus
Betreff: 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

---

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Tue, 28 Feb 2006 09:10:01 +0100

Hi Thomas,
 
I think we have the opportunity to simplify matters here. I for one do
not see why one would find it desirable to ever run rfc2684 bridged mode
for L2CP control sessions. Using standard IPoA (routed) mode is much
simpler and efficient, especially since we are talking of a dedicated
per DSLAM point to point control channel. 
Also, since we are likely to be addressing some of the GSMP transport
issues, the option of encapsulating GSMP over ATM is equally
unattractive since it possibly means that a transport layer needs to be
defined to run on ATM. Why would we want to do something different than
running straight IP over the given medium when all we're talking of here
is nodes that do have an IP address, ie IPoA or IPoE for ATM and
ethernet respectively. 
 
I would thus propose to focus only on IP based transports, with IP
encapsulated over the medium using routed/native format.
 
Regards,
Woj.

________________________________

From: Haag, T [mailto:[email-masked]] 
Sent: 24 February 2006 17:20
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.

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