PAR for Media Converters r2IEEE 802.1 interim, October, 2004 1 PAR for Media Converters revision 2 Norman Finn Cisco Systems

PAR for “Media Converters” r2 IEEE 802.1 interim, October, 2004 1

PAR for “Media Converters”revision 2

Norman Finn

Cisco Systems


What is a “Media Converter”

33PAR for “Media Converters” r2 IEEE 802.1 interim, October, 2004

• A demarcation device on the Customer’s premises is useful for defining and verifying services.

• This is inherently a two-port function.

• Shared media are never present, at least on the up-link.

Why invent a “Media Converter”?Why not use a two-port Bridge?


• So, neither of a bridge’s two most obvious functions, MAC address filtering and loop prevention, are needed.

• Almost all other bridge functions are extensions of the filtering and loop prevention functions.

• Every one of those bridge functions begs for options, configuration, and management.

Why invent a “Media Converter”?Why not use a two-port Bridge?

(continued)


• As suggested by the name, a “Media Converter” often converts between different media, e.g. SONET or DSL, and Ethernet.

• A “Media Converter” sometimes converts between different-speed media.

• Management of a Repeater would be visible to, and could be subverted by, the Customer.

Why invent a “Media Converter”?Why not use a Repeater (Hub)?


• Existing “Media Converters” have serious faults, and correcting them is difficult in the absence of any standard.

(The primary fault is that a failure of one link is not relayed to the other link.)

• IEEE 802 knows Ethernet best.

• This standard must be medium independent.

Why invent a “Media Converter”?Why should 802.1 become involved?


• It is a two-MAC relay device.

• It is as transparent as possible, both to Bridges and to Layer 2 Stations.

• It does not make forwarding decisions except, perhaps, to support its “brain” and to support IEEE Std. 802.3ah OAM.

• It must be remotely diagnosable, but only through the Provider port.

• A failure of one link must be signaled to the other link.

So, what is a Media Converter?


Two-MAC Relay Device


• Media Converter is a “Relay/Brain” function with two MAC/PHYs.

• A “MAC/PHY” may be an 802 medium (typically 802.3) or an emulated 802 medium (e.g. Ether-over-SONET).

• 802.1 must supply the hooks for other organizations to fit their Ether-over-XYZ specifications into this model.

Two-MAC Relay Device

UpPHY

UpMAC

DownMAC

DownPHY

Relay /Brain


Transparent to Bridges and Stations


• All 802.1 protocols (Spanning Tree, GARP, 802.1X, LLDP, LinkSec, KeySec) must pass through.

• All higher layer protocols must pass through.

• Media Converter’s own MAC address (if used) must be intercepted.


UpPHY

UpMAC

DownMAC

DownPHY

Relay /Brain


• 802.3X Pause cannot pass through transparently. We must decide what role Pause plays. (None? Speed matching? Uplink only?)

• 802.3ah OAM should manage at least the Up link, and perhaps the Down link.

• We must decide whether LinkAgg passes through. (Transparent? Drop? Play?)


UpPHY

UpMAC

DownMAC

DownPHY

Relay /Brain


Must Support a “Brain” Function


• Handling 802.3X Pause and 802.3ah OAM takes a certain amount of intelligence.

• We must decide whether access to the MAC address of at least one of the ports, for unicast traffic, should be allowed by the standard.

This would allow better control of the device.

However, this might open too many doors to extensions. Do we really want a spectrum of devices between Bridges and Repeaters?

Must Support a “Brain” Function


Remotely Diagnosable


• IEEE Std. 802.3ah OAM can easily manage Link 1.

• We must manage Link 2.

Tunnel .3ah OAM over .3ah OAM?

Use Layer 2 SNMP to control MC’s MIBs?

Probably not CFM MIP between PB and CE.


MediaConverter

ProviderBridge

CustomerEquipment

1 2


• Loopback is required.

A and B paths, at least.

C path is very desirable, if Customer cooperates.

• Extending 802.3ah OAM fills this requirement nicely.


MediaConverter

ProviderBridge

CustomerEquipment

A B C


Signaling Link Failures


• A failure of Link 2 must be reported to the Provider Bridge. A failure of Link 1 must be reported to the Customer Equipment.

• How?

Dropping the link (Link Integrity Clauses of IEEE 802.3) is guaranteed to work.

Might 802.3ah OAM be extended as an alternative? For one or both problems?

Signaling Link Failures

MediaConverter

ProviderBridge

CustomerEquipment

1 2


Other Possibilities


• Adding 802.1p queues are possible, but …

This would require 802.1Q or 802.1ad tags. Which?

How many queues? What draining algorithm?

• Making the device symmetrical would allow its use in more scenarios, but …

Making it symmetrical might make it unfit for the Provider – Customer use.

Other Possible Functions


Project Authorization Request


This standard specifies the function of a Two-Port MAC Relay, and the protocols and procedures to support its operation. A TPMR is transparent to all frame-based protocols except some or all of those defined by IEEE Std. 802.3, is remotely diagnosable via 802.3ah OAM through one of its ports, and signals a failure of either MAC’s link to the other MAC.

PAR: Scope


The wide and growing deployment of Ethernet Provider Services has created a demand for simple two-port demarcation devices that connect two 802 media or 802 media emulations. The lack of standards for such devices, and particularly for link-loss signaling and remote diagnosis, is impeding the growth of this industry. A Two-Port MAC Relay standard will greatly improve this situation.

PAR: Purpose


Public networks represent a new and very broad application space for IEEE 802 technologies and specifically for Provider Bridges (P802.1ad) and Ethernet in the First Mile (802.3ah). Numerous vendors and potential users (the Service Providers) have expressed the need to integrate Ethernet link technologies with their existing infrastructure at a low cost, while providing the manageability and remote diagnostic capabilities traditionally offered by circuit switched technologies.

Five Criteria: Broad Market Potential


The Two-Port MAC Relay will be compatible with other point-to-point 802 LANs and stations, and with all 802.1 Bridge standards. A minimum set of managed objects, compatible with the minimized functionality of the TPMC, will be defined.

Five Criteria: Compatibility


Existing 802 standards define Repeaters, which are transparent and have no MACs, and Bridges, which are less transparent, and have MAC address filtering and loop prevention capabilities. The TPMR has MACs and frame buffers, intermediate transparency, and no address filtering or loop prevention. As a separate document from media standards and from the 802.1 Bridge standards, it will be easily found.

Five Criteria: Distinct Identity


Numerous vendors supply devices with either more or less functionality than the Two-Port MAC Relay. The few novelties in the definition of the various functions are straightforward extensions of existing capabilities.

Five Criteria: Technical Feasibility


The existence of relatively low-volume Media Converters and high-volume two-port Home Routers demonstrates that the TPMR should be economically viable. Installation cost is known to outweigh unit cost in Home Routers; the elimination of required configuration in the TPMR promises to reverse this imbalance.

Five Criteria: Economic Feasibility


Documents

PAR for Media Converters r2IEEE 802.1 interim, October, 2004 1 PAR for Media Converters revision 2 Norman Finn Cisco Systems