Subject: Re: Bridge or LAN/Ethernet emulation

From: "Cheng-Yin Lee" <[email-masked]>
Date: 25 Nov 2002 18:33:27 -0500

Muneyoshi,
You've presented good arguments that what has been defined in PWE3 sounds more
like  _transport_ of Ethernet MAC frames over PSN, not Ethernet service
emulation.
I think you're also responding to my email to PWE3 on Ethernet emulation:
http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I
believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet
emulation. I've added to your diagram below where I think Ethernet emulation
spans to contrast with the PW defined in PWE3.

If PWE3 WG decides it is specifying the transport of Ethernet frames (not
Ethernet emulation, otherwise we need the functions spanning the Ethernet
emulation in the diagram below), then  it's easier to simply said in PWE3 docs
that we are defining transport of Ethernet frames, rather than emulating
Ethernet or defining it as some kind of  Ethernet "wire" service. I hope your
example of "wireless LAN" below would convince the WG not go down the path of
defining a new "wire" service.

> And I also don't understand that someone claimed that today's LAN consists
>   of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore,
>   IEEE 802.11 WG specifies "wireless LAN" :-)
>

I think we have stated our concerns, the rest is up to WG consensus.

thanks
cheng-yin

Muneyoshi Suzuki wrote:

> Cheng-Yin,
>
> It seems to me, draft-ietf-pwe3-ethernet-encap-01.txt specifies refence
> model and protocol for Ethernet MAC frame transport over GRE/LSP tunnel.
> It does not emulate anything.
>
> Please refer section 3.
>
> >3. Requirements for Ethernet Pseudo-Wire Emulation
> >   An Ethernet PW emulates a single Ethernet link between exactly two
> >   endpoints. The mechanisms described in this document are agnostic to
> >   that which is beneath the "Pseudo Wire" level in Figure 2, concerning
> >   itself only with the "Emulated Service" portion of the stack.
> >
> >   The following reference model describes the termination point of each
> >   end of the PW within the PE:
> >           +-----------------------------------+
> >           |                PE                 |
> >   +---+   +-+  +-----+  +------+  +------+  +-+
> >   |   |   |P|  |     |  |PW ter|  | PSN  |  |P|
> >   |   |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
> >   |   |   |y|  |     |  |on    |  |      |  |y|
> >   | C |   +-+  +-----+  +------+  +------+  +-+
> >   | E |   |                                   |
> >   |   |   +-+  +-----+  +------+  +------+  +-+
> >   |   |   |P|  |     |  |PW ter|  | PSN  |  |P|
> >   |   |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
> >   |   |   |y|  |     |  |on    |  |      |  |y|
> >   +---+   +-+  +-----+  +------+  +------+  +-+
> >           |                                   |
> >           +-----------------------------------+
> >                       ^        ^
> >                       |        |
> >                       A        B
> >           Figure 3: PW reference diagram
> >
> >   The PW terminates at a logical port within the PE, defined at point A
> >   in the above diagram. This port provides an Ethernet MAC service that
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The above description clearly addresses that the PW provides Ethernet MAC
> service.
>
> >   will deliver each Ethernet packet that is received at point A,
> >   unaltered, to the point A in the corresponding PE at the other end of
> >   the PW.
> >
> >   The "NSP" function includes packet processing needed to translate the
> >   Ethernet packets that arrive at the CE-PE interface to/from the
> >   Ethernet packets that are applied to the PW termination point. Such
> >   functions may include stripping, overwriting or adding VLAN tags,
> >   physical port multiplexing and demultiplexing, PW-PW bridging, L2
> >   encapsulation, shaping, policing, etc.
> >
> >   The points to the left of A, including the physical layer between the
> >   CE and PE, and any adaptation (NSP) functions between it and the PW
> >   terminations, are outside of the scope of PWE3 and are not defined
> >   here.
>
> The above two paragraphs clearly defines that the NSP terminates Ethernet
> MAC frame between PE-CE.
>
> Therefore, form a viewpoint of protocol architecture, PW reference
> mode is interpreted as shown in the following figure.
>
>                    Bridge                   Bridge
>                 +-----------+            +-----------+
>                 |\         /|            |\         /|
>                 | \ Relay / |            | \ Relay / |
>                 |  \     /  |            |  \     /  |
>                 |   \   /   |            |   \   /   |
>                 |    \ /    |            |    \ /    |
>                 |     V     |            |     V     |
>                 | MAC |  E  |            |  E  | MAC |
>                 +--+--+--+--+            +--+--+--+--+
>                    |     |                  |     |
>       : Ethernet   |     |  GRE/LSP tunnel  |     |   Ethernet    :
> +--+  :LAN segment |     |                  |     |  LAN segment  :    +--+
> |CE|==:==============    +------------------+    =================:====|CE|
> +--+  :                                                           :    +--+
>       :               |<---------PW----------->|                  :
>     Customer          A                        A          Customer
>     Interface                                              Interface

                                    <---------Ethernet Emulation----------->

>
>
> The above figure shows a "Bridged LAN". Two big boxes are "Brides" and
> it is a special kind of 1982-style Bridge, because it supports only
> two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay"
> in a box are "MAC Entity" and "MAC Relay Entity" respectively.
>
> "E" is an Entity that provides MAC service to the upper layer and the
> service is compatible with the MAC service defined in IEEE 802.3-2002.
> In summery, it seems to me, draft-ietf-pwe3-ethernet-encap-01.txt does
> not define any emulation technology, it specifies protocol for Ethernet
> MAC frame transport over GRE/LSP tunnel and the protocol Entity is
> refeed as "E" in the above figure.
>
> It does not emulate any LAN, because in IEEE 802 context, a LAN means
> a LAN segment or LAN segments interconnected with repeaters, and LAN
> segment means the medium connection, e.g., 1000BASE-T, between Medium
> Dependent Interfaces in a LAN. I think the PW is not intended to support
> medium dependent service such as 100Mbps-to-100Mbps LAN service, because
> this kind of service may not make sense.
>
> And I also don't understand that someone claimed that today's LAN consists
> of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore,
> IEEE 802.11 WG specifies "wireless LAN" :-) If it means an LAN segment,
> as I described in the above, such service does not make sense.
>
> And finally, I think, the following specification in
> draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not address
> in the document.
>
> >3.1.6. IEEE 802.3x Flow Control Interworking
> >   In a standard Ethernet network, the flow control mechanism is
> >   optional and typically configured between the two nodes on a point-
> >   to-point link (e.g.  between the CE and the PE). IEEE 802.3x PAUSE
> >   frames MUST NOT be carried across the PW. See Appendix A for notes on
> >   CE-PE flow control.
>
> This is because, Ethernet PAUSE frame must be terminated in the MAC Entity
> in the above figure. However, it is clearly addressed in IEEE 802.3-2002 and
> it is purely Ethernet dependent issue, thus it is out of scope of PWE3.
> In the PW section, there is no PAUSE frame, because E entity does not
> generate PAUSE frame because it is not Ethernet. So the draft need not
> specify anything for PAUSE frame.
>
> Thanks,
>
> Muneyoshi Suzuki

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Tue, 26 Nov 2002 10:38:50 +0900

Cheng-Yin,

> spans to contrast with the PW defined in PWE3.

How about Bridged (Ethernet) LAN Emulation instead Ethernet emulation?
As shown in the following figure, from a viewpoint of service customer,
the service capability provided between customer interfaces is equivalent
to a Bridged LAN. So, I think "Bridged (Ethernet) LAN Emulation" is not 
incorrect naming for customers.

                   Bridge                   Bridge
      :                                                           :

> I think we have stated our concerns, the rest is up to WG consensus.

Agreed.

Thanks,

Muneyoshi Suzuki

---

From: Heiles Juergen <[email-masked]>
Date: Tue, 26 Nov 2002 10:33:47 +0100

Basically,
 
this is the case for all the PWE3 activities in my view. PWE3 defines the transport of L1/L2 client signal over a packet switched server layer network (speaking in ITU G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. In case of SONET/SDH the client is the STS-SPE/VC. We can today transport SONET STS/VT-SPEs or SDH VCs over various physical signals like PDH signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every server layer transport/mapping has to take the specific requirements of the client signal into account.
 
Juergen

-----Ursprüngliche Nachricht-----
Von: Cheng-Yin Lee [mailto:[email-masked]]
Gesendet: Dienstag, 26. November 2002 00:33
An: Muneyoshi Suzuki
Cc: IETF PPVPN list; [email-masked]
Betreff: Re: Bridge or LAN/Ethernet emulation

Muneyoshi, 
You've presented good arguments that what has been defined in PWE3 sounds more like  _transport_ of Ethernet MAC frames over PSN, not Ethernet service emulation. 
I think you're also responding to my email to PWE3 on Ethernet emulation: 
http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html <http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html> , I believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet emulation. I've added to your diagram below where I think Ethernet emulation spans to contrast with the PW defined in PWE3. 

If PWE3 WG decides it is specifying the transport of Ethernet frames (not Ethernet emulation, otherwise we need the functions spanning the Ethernet emulation in the diagram below), then  it's easier to simply said in PWE3 docs that we are defining transport of Ethernet frames, rather than emulating Ethernet or defining it as some kind of  Ethernet "wire" service. I hope your example of "wireless LAN" below would convince the WG not go down the path of defining a new "wire" service. 

thanks 
cheng-yin 

Muneyoshi Suzuki wrote: 

Cheng-Yin, 

Please refer section 3. 

>   |   |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== >From PSN 

                   Bridge                   Bridge 

  

Thanks, 

Muneyoshi Suzuki

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 26 Nov 2002 08:27:00 -0500

Thanks for articulating this clearly, Juergen. I too think this is
within the scope of PWE3, and it is in the charter too, but there were
some opposition to this when this issue was first brought up. I thought
the next best option is to clarify what PWE3 is doing.

thanks
cheng-yin
> 
> Basically,
>  
> this is the case for all the PWE3 activities in my view. PWE3 defines the transport of L1/L2 client signal over a packet switched server
> layer network (speaking in ITU G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. In case of SONET/SDH the client
> is the STS-SPE/VC. We can today transport SONET STS/VT-SPEs or SDH VCs over various physical signals like PDH signals or OTN
> (OTU) signals, not only via OC-N/STM-N signals. Every server layer transport/mapping has to take the specific requirements of the
> client signal into account.
>  
> Juergen
> 
>        You've presented good arguments that what has been defined in PWE3 sounds more like 
>        _transport_ of Ethernet MAC frames over PSN, not Ethernet service emulation. 
>        http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I believe we are
>        in agreement here wrt Ethernet MAC frame transport vs Ethernet emulation. I've added to your
>        diagram below where I think Ethernet emulation spans to contrast with the PW defined in PWE3. 
> 
>        If PWE3 WG decides it is specifying the transport of Ethernet frames (not Ethernet emulation,
>        otherwise we need the functions spanning the Ethernet emulation in the diagram below), then  it's
>        easier to simply said in PWE3 docs that we are defining transport of Ethernet frames, rather than
>        emulating Ethernet or defining it as some kind of  Ethernet "wire" service. I hope your example of
>        "wireless LAN" below would convince the WG not go down the path of defining a new "wire"
>        service. 
>          
> 
>         +--+  :                                                          
>         :    +--+

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 27 Nov 2002 15:01:01 -0500

Muneyoshi,
I am fine with (Ethernet)LAN emulation or Bridged (Ethernet) LAN Emulation as long
as the latter does not mean Bridge Emulation.

I think Juergen Heiles said it most succinctly about what is within PWE3 WG scope:

> this is the case for all the PWE3 activities in my view. PWE3 defines the transport of L1/L2 client signal over a packet switched server layer network (speaking in ITU
> G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. In case of SONET/SDH the client is the STS-SPE/VC. We can today transport SONET
> STS/VT-SPEs or SDH VCs over various physical signals like PDH signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every server layer
> transport/mapping has to take the specific requirements of the client signal into account.
>
I hope your example of wireless LAN demonstrates why  trying to emulate an Ethernet
physical wire is not such a good idea.

thanks
cheng-yin

Muneyoshi Suzuki wrote:

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

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Thu, 28 Nov 2002 13:19:32 +0900

Cheng-Yin,

> I am fine with (Ethernet)LAN emulation or Bridged (Ethernet) LAN Emulation 
> as long as the latter does not mean Bridge Emulation.

Agreed.

> > this is the case for all the PWE3 activities in my view. PWE3 defines 
> > the transport of L1/L2 client signal over a packet switched server layer 
> > network (speaking in ITU
> > G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. 
> > In case of SONET/SDH the client is the STS-SPE/VC. We can today transport 
> > SONET STS/VT-SPEs or SDH VCs over various physical signals like PDH 
> > signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every 
> > server layer transport/mapping has to take the specific requirements 
> > of the client signal into account.

I'm not sure the reason why the PWE3 wg people think they are discussing
emulated Ethernet as well as pseudo ATM/FR/PDH/SDH wires. A series of ITU-T
recommendations for ATM/FR/PDH/SDH essentially define UNI/NNI protocols
for these. Therefore, if PE-CE protocol conforms to ATM UNI recommendations,
it provides "ATM" service, not logical/virtual/emulated/pseudo ATM.

I fully agree Juergen's view. It seems to me PWE3 WG is discussing foo 
transport over GRE/LSP tunnel.

Thanks,

Muneyoshi Suzuki