Subject: adding BPDU bit to RFC2878 frame format

From: Tawei Liao <[email-masked]>
Date: Wed, 13 Mar 2002 10:37:42 -0800 (PST)

We're proposing a new bit definition in the RFC2878 Bridge Control
Protocol frame format.  I ran this by Fred Baker first.  He's in
agreement with me but wants some discussion on this topic first.

The problem has to do with the treatment of Bridged PDUs in RFC2878.
In the IEEE world, all BPDUs have MAC addresses starting with
01-80-C2-00-00-00-xx.  The problem is that there are other frame
types that are also BPDUs.   For instance,

09-00-2B-01-00-01  DEC STP
AB-00-00-01-00-00  DEC MOP
01-00-0c-cc-cc-cd  Cisco SSTP

There are many many more.  These control protocol frames should into
a separate "high priority" control queue.  That way they won't get
mixed up with the data frames.

Since the RFC2878 frame format doesn't tell us whether a frame is
BPDU, we have to resort to parsing the DA MAC.  And here lies the
problem.  Parsing the DA MAC is not a clean and extensible solution
because there will always be new control protocols.

Rather than relying on the ingress router/switch to "know" about the
different layer 2 control protocols, we're proposing adding a new
BPDU bit in the FLAGS field in the frame format.  The egress box
always knows what type of traffic it's sending.  If it's sending
BPDU control packets, the BPDU bit should be set.  The ingress box
can then look at that one bit and immediately know that it's a BPDU
without parsing the DA MAC.

The flags field is currently defined as the following.  We have two
bits available.  We're proposing making "bit 0" currently reserved
and set to 0 to become the BPDU bit.

          +-+-+-+-+-+-+-+-+
          |F|0|Z|0| Pads  |
          +-+-+-+-+-+-+-+-+
	         ^
		 proposed BPDU bit

        Flags

           bit F:  Set if the LAN FCS Field is present
           bit Z:  Set if IEEE 802.3 Pad must be zero filled to minimum size
           bit 0:  reserved, must be zero

        Pads

           Any PPP frame may have padding inserted in the "Optional Data Link
           Layer Padding" field.  This number tells the receiving system how
           many pad octets to strip off.

-tawei

--
Tawei Liao                                       ||        ||
Cisco Systems                                    ||        ||
(408) 853-8905                                  ||||      ||||
[email-masked]                             ..:||||||:..:||||||:..

---

From: "Mitsuru Higashiyama" <[email-masked]>
Date: Thu, 14 Mar 2002 20:42:27 +0900

Tawei,

I understand your motivation to do this.

But I would like to point out two problems.

1) Backward compatibility.
The devices which are implemented RFC2878 or RFC1638 can not handle
new flag bit in BCP header. Probably, the BPDU indicator flag should be
optional
and need negotiation between peer to peer.

2) Two implementations models.
I can show two different implementations models.

A: Back-end operation for BPDU

       +------------+   +----------+   +-------------+   +----------+
 ====| Line framer   |---| PPP and    |--| MAC operation |--|BPDU Filter |
       |                    |     | BCP entity |   |                      |
| and Switching
       +------------+   +----------+   +-------------+   +----------+
                                         |
|
                                      PPP
STP

B: Front-end operation for BPDU

       +------------+   +----------+   +--------- -+  +--------------+
 ====| Line framer   |---| PPP and    |--| BPDU Filter |--| MAC operation |
       |                    |     | BCP entity |   |                  |   |
and Switching   |
       +------------+   +----------+   +----- -----+  +--------------+
                                         |                       |
                                      PPP                   STP

In the Front-end operation model, it is easy to mark on BPDU packets.
In the other hand, in Back-end operation model, the PPP and BCP entity
have to snoop and check all packets and mark on found BPDU packets.

I don't have good idea to solve this problem.

Best regards,
Mitsuru Higashiyama

---

From: Tawei Liao <[email-masked]>
Date: Thu, 14 Mar 2002 10:34:00 -0800 (PST)

> and need negotiation between peer to peer.

Mitsuru, thanks for the quick reply.  I'm aware of the compatibility
issue.  RFC2878 currently requires the reserved bit to be set to 0.
We could make this BPDU bit optional like you described.

> A: Back-end operation for BPDU

I'm not certain I understand the two models that you're describing
below.  I'll draw what I believe to be the two common cases of
operation (no tabs in text drawings please :-).

This is the case where we have a single box that can switch between
LAN links like ethernet or fdddi and ppp-encapsulated ethernet/fddi.
STP runs on this box of course.  The box knows when it's sending BPDUs
and can mark the egress BCP packets accordingly.  I believe that this is
the most common scenario.  This kind of operation that integrates
LAN and WAN is what defines the typical edge router.

                +-----------+
--- PPP/BCP --- | Switching |-----ethernet/fddi
                |   PPP     |
                |   STP     |-----ethernet/fddi
                +-----------+

This second scenario is the case where we have one box that just
does L2 switching and another WAN box that does PPP.  I believe that
this is a less common scenario because any box that can take input
from a LAN interface typically can also perform the LAN operations
like L2 switching and STP.

               +--------+                     +------------+
--- PPP/BCP ---| WAN    |--- ethernet/fddi ---| LAN switch |-- ether/fddi
               | router |                     |   STP      |-- ether/fddi
               +--------+                     +------------+

The WAN router makes no L2 switching decision.  It takes ether/fddi as
input and sends it out of the PPP/BCP link.   It has to look at every
single frame and do the proper encap/decap.  The marking of the BPDU
bit happens here.

In order for the WAN router to properly queue the frames, it has to be
able to distinguish between data frames and BPDU frames.  The parsing
of DA MAC has to happen on the ingress ether/fddi link.  On the egress
PPP link, the BPDU bit would be set.

At the other end of the PPP/BCP link, the WAN router doesn't need to
parse the DA MAC yet again, it can look at the BPDU bit and
immediately decide to put the BPDU frames into a control queue and
put the non-BPDU frames into one or more data queues.

The burden of marking the BPDU bit is always on the egress box.
With a BPDU bit, this operation doesn't need to happen yet again on
the ingress box.

-tawei

---

From: "Mitsuru Higashiyama" <[email-masked]>
Date: Fri, 15 Mar 2002 16:32:49 +0900

Hello Tawei,

> On Thu, 14 Mar 2002, Mitsuru Higashiyama wrote:
(CUT)

> operation (no tabs in text drawings please :-).

Sorry for my shortage of explanation.
The models I draw are device internal architectures.

The lines in the drawing are internal BUS instead of networks.

In the backend model, network cable/fiber is connected to line

framer like as Modem LSI or SONET Framer. The processor (CPU

or FPGA) receive PPP format packet and process PPP.

LCP and BCP control packets are terminated at there.

All Ethernet/FDDI frame include BPDU are forwarded to MAC

entity. MAC entity process FCS / Learning and filtering /

Link Aggregation load-balance / Tag-Untag operation

and multicast copy. In the MAC entity or back of MAC entiry

may parse DA MAC and distinguish between data frames and

BPDU frames.

---
Mitsuru

> >        |                    |     | BCP entity |   |
|
|
> > >            bit Z:  Set if IEEE 802.3 Pad must be zero filled to
minimum
> > size
> > >            Any PPP frame may have padding inserted in the "Optional
Data
> > Link
> > >            Layer Padding" field.  This number tells the receiving
system
> > how

---

From: Tawei Liao <[email-masked]>
Date: Fri, 15 Mar 2002 14:18:03 -0800 (PST)

Mitsuru and I will take this discussion offline so as to not spam
everybody with the gory details.  If you'd like to participate
reply to me only.

thanks,

-tawei

---

From: Tawei Liao <[email-masked]>
Date: Tue, 19 Mar 2002 10:28:10 -0800 (PST)

To give everybody an update on what's happening with this proposal...

Mitsuru called me from the meeting in Minneapolis and we went over
this.  We're in agreement that this is a good idea, but we should
make this change backward compatible with RFC2878.  Meaning that the
marking of BPDUs will be optional.  It's just another option to be
negotiated at init time.

One person asked whether QoS is really necessary for L2.  My answer
is absolutely yes.  STP is a control protocol just like BGP or OSPF.
IP routing packets has an IP precendence of 6 or 7 and gets high
priority queuing (as per RFC2474) based on those markings.  BPDUs
should get preferential treatment in the same manner in the L2 world.

We will draft something up and send it out for review soon.

thanks,

-tawei