[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DNA] (For reference) text with unconfirmed modifications to L2indications Ethernet/802.3 section
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: owner-dna@ecselists.eng.monash.edu.au
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley
> Sent: Tuesday, June 07, 2005 8:50 AM
> To: dna@eng.monash.edu.au
> 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.
>
>
>