Download Residential Ethernet Overview

Residential Ethernet
Overview
Michael Johas Teener
Plumblinks
[email protected]
Digital Home Media Distribution
2
What is the problem in Home CE
Network?

The lack of standard interface that is all things to all people





Firewire/1394 has limited reach (1394c does but has other
issues).
Ethernet and Ethernet Switches does not support isochronous
connections
Without standard, CE devices needs more connectors, not
fewer.
The next generation contents are all digital and DRMenabled.
ISP needs compatible service class mapping to home

Broadband delivery of the digital contents over Cable, xDSL,
Satellite, needs an interface that guarantees the quality of
experience.
3
What are the residential challenges?

Wiring – distribution Medium

Existing Wiring & Wireless
• Phone (old and Cat 5), Coax (CATV), Powerline, Wireless
• HomePNA & Ethernet , MoCA, HomePlug, WiFi & UWB


Cost – zero incremental cost over time


Regional Differences - Asia, North America, Europe
Reduce the # of connector types, leverage volume
Configuration Ease – no new configuration.

uPnP, intelligent defaults, transparent (to the user) DRM.
4
What are the possible solutions?

Wired







Ethernet FE and GE – Works, but if there are no other traffic and overprovisioned.
Residential Ethernet – add isochronous support so that it works.
Firewire/1394a – works, but limited reach. 1394c requires GigE PHY’s
USB – Master/Slave peripheral connection, short reach. Not fit for
multi-point.
MoCA – proprietary protocol over RG59 coax – medium-high cost.
HomePlug – proprietary protocol over power line – high cost
Wireless



802.11a/b/g – 802.11e makes it work. Not ready for multiple HD
contents.
802.11n – Sufficient bandwidth, longer reach. Best solution for wireless.
UWB – Suffers from short reach (see 1394/USB). “wireless 1394/USB”
Best of the class solutions. The rest are supplementary technologies
5
Why Residential Ethernet?


Ethernet is already the grand unifier in all other technologies

WiFi, HomePlug, MoCA, HomePNA, all terminate to an Ethernet port.

High-end media devices already has Ethernet.

Enable these Ethernet interfaces with synchronous service class
Wired + Wireless solution required.

Reliable guaranteed services are only available over wire.

All wireless benefits and suffers from coverage
• 802.11n increases range by 2X or more, but
• Its bandwidth affected by interferences (other wireless & the neighbors’)


Residential Ethernet MAC, once done, provides all future Ethernet
interface with isochronous services.

Ethernet Volume

Power over Ethernet Option

Ethernet Roadmap (10/100/1000/10G, PoE Plus, MAC Security, etc.)
But Cat 5 is not installed in every home.

Residential Ethernet is adoptable to other medium (at higher cost).

Good reason that the solution must include wireless option.

Much of Asia and new homes in N America do have Cat 5.
6
What are CE Technical
Challenges?
Audio-Video Sync to multiple
devices
 Low-latency for interactive
 Low Cost
 Plug & Play


really!
7
Residential Ethernet
Technical Overview
Michael Johas Teener
Plumblinks
[email protected]
Technical Challenges and
Solutions

Bounded Jitter (multi-room Video/Audio
sync)


Bounded Latency (real-time apps).




Interactive Voice and Video over IP
Audio JAM session
Control/Mgmt (channel/volume selection)
Guaranteed session bandwidth


End-point synchronization
QoS/CoS, over-provisioned BW does NOT do
this.
IEEE 1394 mechanisms work well and
adoptable to Res Ethernet.
9
IEEE 802.3 Residential Ethernet
Study Group Status

Call for Interest in July 2004

Overwhelming support for Residential Ethernet Work
• Interest vote result: 30+ companies 80+ individuals



Study Group Charter is to justify new standard not
writing the standard, but





Held two meetings, September and November.
Next meeting in January 2004, the week of 23rd.
Two workable proposals on the table
Both would meet the requirements
Both are compatible with IEEE 1394 (Firewire) services.
One leverages from commodity Ethernet switches
Link: http://www.ieee802.org/3/re_study
10
Proposal 1: Spyder LAN

Introduces real-time data distribution function
overlay in Ethernet Switches



Looks more like Ethernet Repeater than Switch
TDM service similar to IEEE1394 and IEEE 802.3af EFM’s
EPON
Synchronous traffic serviced via network admission
control.
Spider
Element
1000BASE-T PHY
DTE
MACS
And
DTE
1000BASE-T PHY
DTE
1000BASE-T PHY
DTE
1000BASE-T PHY
UTP Links
802.1 D Bridge
Core
GMII
11
Proposal 2: Modified Ethernet
Switch

Introduces real-time traffic queue in Ethernet Switch




Adds time-sync aware scheduler in addition to CoS/QoS aware
scheduler.
Backward compatible to any installed Ethernet Switch
Small cost adder to Ethernet Switch.
Only solution that offers commodity silicon and adoption upon
introduction.
Simplified Ethernet Switch Block Diagram
GE/FE
MAC
GE/FE
MAC
GE/FE
MAC
GE/FE
MAC
FIFO
Shared
Memory
Frame
Buffer
Queue
Sched.
Sync
Queue
Sched.
Switching
Decision
data
ctrl
FIFO
(retry)
GE/FE
MAC
GE/FE
MAC
GE/FE
MAC
GE/FE
MAC
12
Common Solutions

Clock Synchronization



Link PnP


Adopt 802.3 auto-negotiation. Need to add ResE to the
selection code.
Device PnP


Adopt 802.1D STP-like master selection (based on MAC &
Device Class)
8 KHz clock sync, and 64 bit resolution (like 1394)
Adopt 802.1ab LLDP protocol (MAC/Link Discovery Protocol) as
is.
Synchronous Control Protocol



Adopt 802.1 GARP (Generic Attribute Registration –widely used
for VLAN registration in form of GVRP)
Path BW reservation
Multicast/Broadcast group and path control could use GMRP
as is.
Very few new protocols need to be invented!
13
Res Ethernet End-Point Model


Choose the most compatible interface model to
existing drivers.
Sensible to support both models to minimize time
to market.
Unified Res Ethernet Driver
Ethernet Driver
Synchronous Driver
e.g. ResE, 1394
ResE support at the MAC
ResE support above the MAC
14
Call for Action

Residential Ethernet is a study group, and
will to transition to a task force soon


Will require updates to 802 architecture


Your participation is appreciated
802.1D updates for isochronous
routing/admission control
Best if updates are useful for 802.11 and
802.15 as well


Want to allow all QoS capabilities preserved as
data moves through Ethernet backbone!
Need to start working on harmonization ASAP!
15
Backup Slides
Many slides and content
lifted from
Residential Ethernet
Study Group
Presentations
Clock Synchronization
Bursting causes jitter
rx0
1 kHz
rx1
1 kHz
rx2
1 kHz
rx3
8 kHz
tx4
delay
time
18
Bunching causes jitter
rx0
time
rx1
time
rx2
time
rx3
time
tx4
delay
time
19
Bridge re-clocking bounds jitter
bridge
(etc.)
isochronous
…
asynchronous
…
cycle-stamp
receive
cycleCount
gate
high
transmit
low
20
Synchronized
reception/presentation
clockA
clockB
clockC
No long-term drift: clockA, clockB, clockC
Clock jitter: sub nanosecond (after PLL)
21
Synchronization services for
client

Clock synchronization direction
control

From/to network
Clock to network
 Clock from network


Higher level scheduling of services
• Need to know current time to know when in
the future an event can be scheduled

Time stamping of streaming data
22
Synchronization in bridge

Protocol to select master clock in network




if no bridge, just uses “highest” MAC address
Accept clock from port connected to network
master
Forward clock to other ports
Re-use 802.1 STP precedence to select clock
source.
23
Admission Control
Admission controls for client

Request channel number



Release channel number
Request bandwidth from path to talker





Bytes/cycle … makes reservation in output queue of self,
if no resources, tags request
Respond to bandwidth request from listener


Bytes/cycle … makes reservation in output queue of
talker (and all output queues in path from talker)
Talker address is channel (multicast address)
Release bandwidth from path to talker
Accept bandwidth request from listener


Multicast address to use as DA
Sent to listener that made request
Accept bandwidth response from talker
Release local bandwidth reservation
25
Admission controls in bridge
Allocate channel using GMRP
 Forward bandwidth requests to talker
if first request



respond directly without forwarding if
already routing channel
Forward bandwidth responses to
listener
26
Isochronous transport

Request transmit of isochronous packet


DA, SA, data, cycle “n”
Receive isochronous packet

DA, SA, data, cycle “n”
27
Clock Synchronization
Adjacent-station
synchronization
Timing snapshots
Station B
Station A
local
offset
local
offset
add
(t1)
(t3)
add
global
(t4)
(t2)
global
29
Adjacent-station
synchronization
Snapshot value distribution
Station B
Station A
local
offset
add
(t1)
global
(t4)
(t1, t4-t2)
local
offset
(t3)
add
(t2)
global
(t2, t3-t1)
30
Adjacent-station
synchronization
Offset value adjustments
Station B
Station A
local



offset
add
(t1)
global
(t4)
(t1, t4-t2)
local
offset
(t3)
add
(t2)
global
(t2, t3-t1)
clockDelta = ((t3 – t1) – (t4 – t2)) / 2;
cableDelay = ((t3 – t1) + (t4 – t2)) / 2;
offsetB = offsetA – clockDelta;
31
Adjacent station synchronization
clockSync
Station B
Station A
local
offset
add
…
local
add
8 kHz
global
offset
…
global
125ms
32