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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 07 Jun 2005 13:01:33 +0300

Greg,

One comment:

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

This is not accurate. LLDP may tell you that on the other end of the
link there is a bridge or repeater, but not whether frame forwarding is
immediately available. I suggest to wipe out this paragraph. 

Could you send me a 'clean' version, without editorial brackets to
forward to the Ethernet and Bridge MIB lists for further scrutiny? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Greg Daley
> Sent: Tuesday, June 07, 2005 8:50 AM
> To: [email-masked]
> Subject: [DNA] (For reference) text with unconfirmed 
> modifications to L2 indications Ethernet/802.3 section
> 
> 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: Greg Daley <[email-masked]>
Date: Wed, 08 Jun 2005 08:53:20 +1000

Hi Dan,

I'll take your suggestion.

There's a little iteration to be done from Tom's guidance,
but I'm agreeing with his text suggestions, so I'll send
the text which has been merged.

Greg