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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 06 Jun 2005 10:58:54 +0300

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 ([email-masked]) and to the Bridge MIB WG list
([email-masked]) 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Greg Daley
> Sent: Monday, June 06, 2005 10:06 AM
> To: [email-masked]; 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
> 
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 07 Jun 2005 09:59:55 +1000

Hi Dan,

> can also forward this mail to these lists and ask for opinions to be fed

Thanks for this.

We know there's a need to cover these technologies in the
document (which is why it has been attempted), but real
expertise would certainly help.

Greg