PAR for “Media Converters”
revision 2
Norman Finn
Cisco Systems
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
1
What is a “Media Converter”
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
2
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
3
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
4
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
5
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
6
So, what is a Media Converter?
• 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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
7
Two-MAC Relay Device
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
8
Two-MAC Relay Device
Up
PHY
Up
MAC
Relay /
Brain
Down
MAC
Down
PHY
• 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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
9
Transparent to Bridges and Stations
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
10
Transparent to Bridges and Stations
Up
PHY
Up
MAC
Relay /
Brain
Down
MAC
Down
PHY
• 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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
11
Transparent to Bridges and Stations
Up
PHY
Up
MAC
Relay /
Brain
Down
MAC
Down
PHY
• 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?)
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
12
Must Support a “Brain” Function
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
13
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?
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
14
Remotely Diagnosable
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
15
Remotely Diagnosable
Provider
Bridge
1
Media
Converter
2
Customer
Equipment
• 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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
16
Remotely Diagnosable
Provider
Bridge
A MediaB
Converter
Customer
C
Equipment
• 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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
17
Signaling Link Failures
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
18
Signaling Link Failures
Provider
Bridge
1
Media
Converter
2
Customer
Equipment
• 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?
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
19
Other Possibilities
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
20
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 for “Media Converters” r2
IEEE 802.1 interim, October, 2004
21
Project Authorization Request
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
22
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 for “Media Converters” r2
IEEE 802.1 interim, October, 2004
23
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 linkloss signaling and remote diagnosis, is
impeding the growth of this industry. A
Two-Port MAC Relay standard will greatly
improve this situation.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
24
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
25
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
26
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
27
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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
28
Five Criteria: Economic Feasibility
The existence of relatively low-volume
Media Converters and high-volume twoport 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.
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
29
PAR for “Media Converters” r2
IEEE 802.1 interim, October, 2004
30