PAR for “Media Converters”revision 2 Norman Finn Cisco Systems
Why invent a “Media Converter”?Why not use a two-port Bridge? • 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? (continued) • 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 Repeater (Hub)? • 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 should 802.1 become involved? • 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.
So, what is a Media Converter? • It is a two-MACrelay 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.
Two-MAC Relay Device UpPHY UpMAC Relay /Brain DownMAC DownPHY • 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.
Transparent to Bridges and Stations UpPHY UpMAC Relay /Brain DownMAC DownPHY • 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.
Transparent to Bridges and Stations UpPHY UpMAC Relay /Brain DownMAC DownPHY • 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?)
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?
Remotely Diagnosable ProviderBridge MediaConverter CustomerEquipment 1 2 • 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.
Remotely Diagnosable ProviderBridge MediaConverter CustomerEquipment A B C • 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.
Signaling Link Failures ProviderBridge MediaConverter CustomerEquipment 1 2 • 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?
Other Possible Functions • 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.
PAR: Scope 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: Purpose 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.
Five Criteria: Broad Market Potential 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: Compatibility 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: Distinct Identity 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: Technical Feasibility 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: Economic 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.
30 PAR for “Media Converters” r2 IEEE 802.1 interim, October, 2004