[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DNA] Revised text for link-information Ethernet section forcomment
Greg,
I am the chair of the Ethernet MIB WG and co-chair of the Bridge MIB WG.
I do have experience with link state information in Ethernet and IEEE
802.1 bridges. I will read the proposed text and provide my individual
opinion.
I would recommend that you submit this text for review to the Ethernet
MIB WG list (hubmib@ietf.org) and to the Bridge MIB WG list
(bridge-mib@ietf.org) so that more experts have a look at the text. I
can also forward this mail to these lists and ask for opinions to be fed
back into the dna list.
Regards,
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: Monday, June 06, 2005 10:06 AM
> To: dna@eng.monash.edu.au; Alper Yegin
> Subject: [DNA] Revised text for link-information Ethernet
> section for comment
>
> 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
>
>