Subject: [DNA] (For reference) text with unconfirmed modifications to L2 indications Ethernet/802.3 section

From: Greg Daley <[email-masked]>
Date: Tue, 07 Jun 2005 15:50:04 +1000

Hi DNA WG,

After Tom and Dan's reviews of the 802.3 section
for the link information draft, here's a summary
of the text proposals:

These have not been confirmed on-list, but are placed
here for reference in order that the potential changes
can be all seen together.

Greg

-------------------------------------------------------

Section title:   IEEE 802.3 CSMA/CD
------------------------------------

(begin revised)
   IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the
   most commonly deployed Local Area Network technology in use today.
   As deployed today, it is specified by both a physical layer/medium
   access control (MAC) layer specification[802.3].
   In order to provide connection of different LANs together into
   a larger network, 802.3 LANs are often bridged together[802.1d].

   In this section, the terms 802.3 and Ethernet are used
   interchangeably.  This section describes some issues in providing
   link-layer indications on Ethernet networks, and shows how bridging
   affects these indications.
(end revised)

In Ethernet networks, hosts are connected by wires or by optic fibre
to a switch (bridge), a bus (e.g. co-axial cable), a repeater (hub),
or directly to another ethernet device.  Interfaces are symmetric,
in that while many different physical laters may be present, medium
access control is uniform for all devices.

(begin revised)
   In order to determine whether the physical medium is ready for
   frame transfer, IEEE 802.3 Ethernet specifies its own link
   monitoring mechanism, which is defined for some, but not all
   classes of media.
   Where available, this Link Integrity Test operation is used
   to identify when packets are able to be received on an
   Ethernet segment.  It is applicable to both wired and optical
   physical layers, although details vary between technologies
   (link pulses in twisted pair copper, light levels in fibre).
(end revised)

Subsection: Link Integrity Tests in 802.3 networks.
---------------------------------------------------

The status of the link as determined by the Link Integrity
Test is stored in the variable 'link_status'.  Changes to the
value of link_status (for example due to Link Integrity Test
failure) will generate link indications if the technology
dependent interface is implemented on an ethernet device [802.3].

The link_status has possible values of FAIL, READY and OK.
When an interface is in FAIL state, Link Integrity Tests have failed.
Where status is READY, the link segment has passed integrity
tests, but autonegotiation has not completed.  OK state
indicates that the medium is able to send and receive packets.

Upon transition to a particular state the Physical Medium
Attachment subsystems generates a PMA_LINK.indicate(link_status).
Indications of OK state may be used as Link-Up indications for DNA.
PMA_LINK.indicate(FAIL) may be used as a Link-Down indication
reliably by DNA[802.3].

(begin revised)
   Such indications do not definitively ensure that packets will
   be able to be received through the bridge domain, though.  Such
   operations are governed by bridging.
(end revised)

Subsection: IEEE 802.1D Bridging and its effects on link indications
--------------------------------------------------------------

(begin revised)
   Ethernet networks are commonly bridged.  Bridging is a mechanisms
   which provides loopless paths across LANs interconnected by
   IEEE 802.1D bridges.

   Due to its necessity in preventing bridge loops, bridging has
   become synonymous with the spanning tree protocol.
   The spanning tree protocol and its variants provide loopless
   forwarding between ethernet-like bridges within a bridging domain.

   The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit
   (BPDU) frames in order to pass information about which
   bridges are connected to others.

   By default, the spanning tree protocol does not know whether
   a particular newly connected piece of ethernet will cause a
   loop.

   Therefore it will block all traffic from and to a newly connected
   ports with the exception of some unbridged management frames.
   The STP will determine if the port can be connected to the network in
   a loop-free environment.

   For these technologies, even though the link-layer appears
   available, no forwarding will occur until it is determined that
   the port can be connected to the network in a loop-free
   environment.
(end revised)

(start added context)
   For host which are providing indications to upper layer protocols,
   even if the host itself does not implement bridging or STP,
   packet delivery across the network can be affected by their
   directly adjacent LAN peer which may be a bridge, or if this is
   a repeater, by the presence of STP bridges upon that LAN.
(end added context)

(start revised)
   Where the host is not running STP itself, no explicit indication
   that forwarding has begun is sent from a switch to its peer devices.
   Therefore, a host may not know when STP operations have completed,
   and when it is safe to inform upper layers to transmit packets.
(end revised)

As described in (Subsection on 802.1AB LLDP) explicit
knowledge may be available through the new Link-Layer
Discovery Protocol as to whether frame forwarding operation
is immediately available.

Where it is not known that forwarding operations are
available, a host needs to assume that STP is being
performed, and may indicate full connectivity only based on
reception of BPDUs or timeouts.

Upon learning that an adjacent port is running STP or RSTP,
the host may send a Link-Up indication with a 'forwarding available'
parameter upon expiry of calculated delays to indicate that
general packet transfer is available across the LAN.

(begin revised)
   If no bridge configuration messages are received within the
   default Bridge_Max_Age interval (20s), then it is likely that
   the peer's port is Disabled for bridging (S8.4.5 of [802.1D]),
   or the device is not a bridge, since at least two BPDU hello
   messages have been lost.

   It is not easy for a non-STP host to distinguish between
   Disabled ports and non-bridge ports with no IP nodes on them,
   as Disabled ports will have no traffic on them, and incur
   100% sender loss.

   Upon this Bridge_Max_Age timeout, a host may (re)-send a
   link-layer indication showing that packets sent within the prior
   interval were likely to have traversed the forwarding path
   (unless the port is disabled).
(end revised)

If a BPDU is received, and the peer is running the original
Spanning Tree Protocol, then host cannot successfully send
packets until at least the peer's ForwardDelay timer has expired
twice.   This timeout defaults to 30 seconds (2 * 15 seconds)
[802.1d].  After this time, the host can send a link-layer up
indication showing that the previous interval after the
PMA_LINK.indicate(OK) event was one of loss.

If the switch is identified as performing Rapid Spanning Tree
Protocol (RSTP), it instead waits Bridge_Max_Age after packet
reception (advertised in the BPDU's Max Age field), before forwarding.
For ports which are known to be point-to-point through
autonegotiation, this delay is abbreviated to 3 seconds after
autonegotiation completes [802.1d].
After either of these delays, a link-layer indication updating the
PMA_LINK.indicate(OK) can show that the interval between
indications was a lossy interval.

Subsection: 802.1AB Link-Layer Discovery Protocol.
-------------------------------------------------

The recently defined 802.1AB Link-Layer Discovery Protocol
(LLDP) provides information to directly connected devices
about its MAC peer[802.1AB].

LLDP sends information periodically, and at link status
change time to indicate the configuration parameters of the device.
Devices may either send or receive these messages, or both.

(begin revised)
   The LLDP message may a System Capabilities TLV, which
   describes the MAC and IP layer functions which a device is
   currently using. Where a host receives the
   Systems Capabilities TLV which indicate that no Bridging or
   Repeating is occurring on the link-layer peer, then no delays
   for STP calculation will be applied to packets sent from this
   host, if does not perform STP itself.  This would allow the
   host's link-layer to indicate that to its knowledge the link
   is available for packet transfer.
(end revised)

Additionally, if a host receives a Systems Capabilities TLV
which indicates that the peer is a switch or repeater, the
host's advertisement that it is an (end-host) Station-Only,
may tell the peer switch not to run STP, and immediately
allow forwarding.

Proprietary extensions may also indicate that data forwarding
is already available on such a port.  Discussions of such
optimizations is out-of-scope for this document.

Due to the protocol's newness and lack of deployment, it is
unclear how this protocol will eventually affect DNA in IPv4
or IPv6 networks.

Summary
-------

Link-Layer indications in Ethernet-like networks are
complicated by additional unadvertised delays due to Spanning
Tree calculations.  This may cause re-indication or retraction
of indications previously sent to upper layer protocols.

---

From: Tom Petch <[email-masked]>
Date: Tue, 07 Jun 2005 20:43:57 +0200

Some more comments in line.  I do find that my style is somewhat different to
yours, so it may not be helpful to interpose my words directly between yours.

Two semantic concerns, I have not encountered hosts (ie not bridge/switches)
that listen to BDPU to find out what is happening but that may be just my
ignorance; certainly technically feasible and sensible for DNA, but do boxes
actually do it?  You make several references to it.  (By contrast, I do
encounter boxes which listen to routing protocol traffic to find out what is
happening at layer three).

And this peer thingy; I don't get it (except in the case of two boxes directly
connected by one piece of UTP or fibre).  I don't see repeater or bridge as
peer.  Repeater is physically repeating, passive except in so far as it
propagates collisions and participates in Link Integrity.  Bridge is also
(usually) transparent; you don't see it, apart from added delays, until it
decides not to forward, for up to 50s, as part of a topology change (or unless
you listen in to BPDU which, as I said, I only see bridges doing).  I struggle
to see it as peer in any meaningful sense.

Tom Petch

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 07, 2005 7:50 AM
Subject: [DNA] (For reference) text with unconfirmed modifications to L2
indications Ethernet/802.3 section

(suggest this instead of the subsequent three paragraphs)

Ethernet networks commonly  consist of LANs joined together by transparent
bridges (usually implemented as switches).  Tranparent bridges require the
active topology to be loop free.  The
Spanning Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
Data Unit (BPDU), as defined in [802.1D], which leads to, where required, the
blocking of ports (ie not forwarding).

>    a repeater, by the presence of STP bridges upon that LAN.

(I've still got problems with peer - this could be coax, no LAN peer; and any
bridge anywhere can block packet delivery on a temporary basis as you describe
below; I would say
'Packet delivery across the network can be affected by the presence of bridges'
and leave it at that)
>    or the device is not a bridge, since at least two BPDU hello

(suggest)
If no bridge configuration messages are received within the
Bridge_Max_Age interval (default 20s), then it is likely that ...

(but then the reference to peer still confuses me; no BPDU for me means no
bridge in the topology or a failure)

>    messages have been lost

---

From: Greg Daley <[email-masked]>
Date: Wed, 08 Jun 2005 11:13:58 +1000

Hi Tom,

> yours, so it may not be helpful to interpose my words directly between yours.

I've done that.  Thanks for the text.

> happening at layer three).

I think that what is not expressed properly is that devices which can't
inspect BPDU frames need to either:

a) Accept that up to 50 s of packets can be lost if they transmit
    immediately upon link arrival

b) Accept an induced delay of up to 50s (but probably 30s) before
    transmission of packets.

This has to be indicated to upper layer protocols.

The inspection of BPDU frames would have to be an optimization.

Here's my text proposal:

"...
   Where it is not known that forwarding operations are
   available, a host needs to assume that STP is being
   performed, and may indicate full connectivity only based on
   timeouts or reception of BPDUs.

(added)
   Most hosts today do not listen to BPDU frames.  For these hosts,
   connectivity to the a port which is potentially bridged (any
   Ethernet port) carries the potential of frame loss if transmissions
   occur before any bridges' ForwardDelay timers have expired twice.
   This timeout defaults to 30 seconds (2 * 15 seconds), but may be
   as high as 60s[802.1d].  When sending indications to upper
   layers, the period where frame forwarding is potentially unavailable
   should be indicated to upper-layer protocols.

   Alternatively, a host can listen for BPDUs and use them to
   determine the length of port blockage which will occur in their
   particular circumstances.
(end added)

..."

This brings forward discussion of Forward Delay parameters
Which means that the same gets removed from a later paragraph.

"...
  If a BPDU is received, and the adjacent switch is running the original
   Spanning Tree Protocol, then host cannot successfully send
   packets until at least twice the ForwardDelay value in the received
   BPDU has elapsed.  After this time, the host can send a link-layer up
   indication showing that the previous interval after the
   PMA_LINK.indicate(OK) event was one of loss.
..."

> to see it as peer in any meaningful sense.

You're right about the peers.  They're misleading.  Any bridge on
the path between a host and its destination will block frames.

In addition to your suggestions, I've removed the references to
peers with the following two paragraphs.

------------
Replace:

"...
..."

With:

"...
   Where the host is not running STP itself, no explicit indication
   that forwarding has begun is sent from a switch.
   Therefore, a host may not know when STP operations have completed,
   and when it is safe to inform upper layers to transmit packets.
..."

-----------
Replace:
"...
..."

With:

"...
   If no bridge configuration messages are received within the
   Bridge_Max_Age interval (default 20s), then it is likely that
   there is no visible bridge whose port is enabled for bridging
   (S8.4.5 of [802.1D]), since at least two BPDU hello messages would
   have been lost.
..."

-----------
Replace:

"...
..."

With:

"...
   The recently defined 802.1AB Link-Layer Discovery Protocol
   (LLDP) provides information to devices which are directly
   adjacent to them on the local LAN[802.1AB].
..."

-----------

Replace:

"...
..."

With:

"...
   The LLDP message may a System Capabilities TLV, which
   describes the MAC and IP layer functions which a device is
   currently using. Where a host receives the
   Systems Capabilities TLV which indicate that no Bridging or
   Repeating is occurring on the LLDP transmitter, then no delays
   for STP calculation will be applied to packets sent through this
   transmitter, if the host does not perform STP itself.  This
   would allow the host's link-layer to indicate that to its
   knowledge the link is available for packet transfer.
..."

---------

Replace:

"...
..."

With:
"...
   Additionally, if a host receives a Systems Capabilities TLV
   which indicates that the LLDP transmitter is a switch,
   the host's advertisement that it is an (end-host) Station-Only,
   may tell the switch not to run STP, and immediately
   allow forwarding.
..."

----------

I'll send a completed revision off-list.

Thanks once again for your input.

Greg.