[DNA] Revised text for link-information Ethernet section for comment

[Greg Daley <greg.daley@eng.monash.edu.au>]

Dear Alper and WG,

Here is an update of the text provided before last IETF
for Ethernet in the link-information document.

I'm not sure how useful the recommendations are to people,
and apparently there was some difficulty even amongst
DNA illuminati in understanding what I was getting at in
the last version.

So if you have any opinions or experience, please comment
on-list, in order that forward progress can be made.

Greg


Text follows, potentially to be inserted as a section
in the draft-ietf-dna-link-information.

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

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],
and a bridging specification used for connecting different
ethernet LAN segments together [802.1d].

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, Ethernet specifies its own link monitoring mechanism.
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 copper, light levels
in fibre).

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

Such indications do not definitively ensure that packets will be able
to be received through the switching infrastructure which composes
a broadcast domain, though.  Such operations are governed by bridging.

Subsection: 802.1d Bridging and its effects on link indications
--------------------------------------------------------------

Ethernet networks are commonly bridged.
Bridging is a mechanism which provides loopless paths across a series
of link-segments.

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 switches within a broadcast domain.

The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit
(BPDU) frames in order to pass information about which switches are
connected to others.
By default, the spanning tree protocol does not know whether a
particular newly connected piece of ethernet will cause a bridge loop.
Therefore it typically blocks all traffic from a port until
spanning tree operations can determine if a loop exists.

For these technologies, even though the link-layer appears available,
no forwarding will occur until the network is satisfied that
the connected is not another bridge or repeater port.

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.

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.

If no bridge configuration messages are received within
the default Bridge_Max_Age interval (20s), then it is unlikely that
the peer device is a bridge, since at least two BPDU hello messages
have been lost.
Upon this 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.

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.

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.  This would allow an authoritative link-layer
indication to be sent to upper-layers about the availability of
packet transfer.

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.


Greg