Request for discussion: proposed 802.3 section for draft-ietf-dna-link-information

Dear Bridge-mib working group,

In order to complete its milestones, the DNA working group has been
developing a document cataloguing possible link-layer indications
able to be sent between a host's link-layer and its network layer,
upon connection to a new bridge port, or wireless cell.

As part of the feedback received for this document, support for
802.3/Ethernet networks was indicated as a "must-have" in order
to complete the document.

As such here is an 'ethernet' section of the document to be
incorporated into the document:

http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-01.txt

Your assistance is greatly desired in order to incorporate further
802 specific knowledge into the section.

Please read the below text, to see if it makes sense, or if there are
any behaviours claimed which aren't reasonable or possible.

Any assistance you can provide will be greatly appreciated.

Yours Faithfully,

Greg Daley


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

   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.

   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.

   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).


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

   Link Integrity Tests in 802.3 networks typically occur at initial
   physical connection time (for example, at the auto-negotiation stage),
   and periodically afterwards.   It makes use of physical-layer specific
   operations to determine if a medium is able to support link-layer
   frames [802.3].


   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].

   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.


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

   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).

   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.

   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 the
   presence of bridges.

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

   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.

   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.

   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.

   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.

   It is not easy for a non-STP host to distinguish between
   Disabled bridge 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).

   If a BPDU is received, and the adjacent bridge 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.

   If the bridge 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: IEEE 802.1AB Link-Layer Discovery Protocol.
-------------------------------------------------------

   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].

   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.

   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.

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

   Proprietary extensions may also indicate that data forwarding
   is already available on such a port.  Discussion 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.

Subsection: 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.