Re: [DNA] (For reference) text with unconfirmed modifications to L2indications Ethernet/802.3 section

[Tom Petch <nwnetworks@dial.pipex.com>]

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" <greg.daley@eng.monash.edu.au>
To: <dna@eng.monash.edu.au>
Sent: Tuesday, June 07, 2005 7:50 AM
Subject: [DNA] (For reference) text with unconfirmed modifications to L2
indications Ethernet/802.3 section

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

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

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

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

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