PAR%20for%20

1
PAR for Media Convertersrevision 2

• Norman Finn
• Cisco Systems

2
What is a Media Converter
3
Why invent a Media Converter?Why not use a
two-port Bridge?

• A demarcation device on the Customers 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.

4
Why invent a Media Converter?Why not use a
two-port Bridge?
(continued)

• So, neither of a bridges 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.

5
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.

6
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.

7
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.

8
Two-MAC Relay Device
9
Two-MAC Relay Device
UpPHY
UpMAC
DownMAC
DownPHY
Relay /Brain

• 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.

10
Transparent to Bridges and Stations
11
Transparent to Bridges and Stations
UpPHY
UpMAC
DownMAC
DownPHY
Relay /Brain

• All 802.1 protocols (Spanning Tree, GARP,
  802.1X, LLDP, LinkSec, KeySec) must pass through.
• All higher layer protocols must pass through.
• Media Converters own MAC address (if used) must
  be intercepted.

12
Transparent to Bridges and Stations
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?)

13
Must Support a Brain Function
14
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?

15
Remotely Diagnosable
16
Remotely Diagnosable
MediaConverter
ProviderBridge
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 MCs MIBs?
• Probably not CFM MIP between PB and CE.

17
Remotely Diagnosable
MediaConverter
ProviderBridge
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.

18
Signaling Link Failures
19
Signaling Link Failures
MediaConverter
ProviderBridge
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?

20
Other Possibilities
21
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.

22
Project Authorization Request
23
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
  MACs link to the other MAC.

24
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.

25
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.

26
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.

27
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.

28
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.

29
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
30
PAR for Media Converters r2
IEEE 802.1 interim, October, 2004