Requirements for 802.1AD
Provider Bridges
June 2003
Muneyoshi Suzuki
NTT
Reference Model
User Bridged LAN
User Site
of
user A
CE
PEB
PEB
CE
User Site
of
user A
PCB
Provider Bridged Network
PCB
PCB
CE
User Site
of
user B
CE
PEB
PEB
User Bridged LAN
PEB: Provider Edge Bridge
PCB: Provider Core Bridge
CE: Customer Equipment
CE
User Site
of
user B
1. P-VID Space
 Problem: 12bit VID space defined in 802.1Q-1998 is too
small for public service
 Requirements:
If a P-VID identifies an User Bridged LAN, 24 bit (16M
users) ID space is needed
If a P-VID identifies an user site, 32 bit (4G sites) ID
space is needed
 Note: Providers need “ID space,” so solution does not need
to define a single 24-32 bit “P-VID format”
Hierarchical ID space (e.g., a P-VID consists of 2 VIDs)
MAC-in-MAC (e.g., a P-VID consists of single VID and a
portion of Provider Edge Bridge’s MAC address)
2. Maximum Bridge Diameter
Problem: Recommended value of the Maximum
Bridge Diameter is 7 (802.1D-1998, 802.1w-2001),
but it is too small for public service
The standards don’t address technical background
of the value (What happens if it exceeds 7? xSTP
does not converge in periodic time?)
Requirements:
The value should be extended tens for Provider
Bridged Network and 10 for User Bridged LAN
Diameter of a Provider Bridged Network should
not affect diameter of User Bridged LANs
3. Loop Prevention
 Problem: A loop fatally affects a Bridged LAN
 If an user sends broadcast or unknown destination frames
to the provider, then the frames are sent to the user sites
but back to the provider through a looped path, .......
 Requirements:
Provider Bridged Network should deploy a mechanism
for loop prevention
User Bridged LAN should deploy a mechanism for loop
prevention
Provider Bridged Network should deploy mechanisms
that protect the network from loops caused by users
(3.1) Loop Prevention
in Provider Bridged Network
It is provider’s responsibility to ensure loop-free
tree topology for the Provider Bridged Network
Thus, the topology is decided by the provider’s
policy and control
Therefore, it is quite unrealistic scenario to
change the topology based on user-xSTP
Requirements:
Provider Bridged Network should deploy
provider-xSTP for loop prevention
However, it is usually limited to the provider
and does not need to interwork with userxSTP
(3.2) Loop Prevention
in User Bridged LAN
 It is user’s responsibility to ensure loop-free tree topology for
the User Bridged LAN
 This is because, an user can cause a loop whether the
provider supports per-user-xSTP or not
 However, if xSTP is used in an User Bridged LAN and if the
provider forwards it transparently, loops can be prevented
 This is because, the provider ensures loop-free topology and a
single xSTP instance on a loop can detect and cut it
 Requirements:
User Bridged LAN should deploy user-xSTP for loop
prevention
Provider Bridged Network may support per-user-xSTP,
otherwise, it must forward user-xSTP BPDUs transparently
(3.3) Provider Bridged Network
Protection from Loops Caused by Users
 If Provider Bridged Network supports per-user-xSTP, it can
be protected from loops caused by users
 Only Provider Edge Bridges need to support it, because a
single xSTP instance on a loop can detect and cut it
 However, this is not perfect solution, but it does not mean
Providers don’t need protection
 Requirements:
Provider Edge Bridges optionally support per-user-xSTP
to protect the network
Development of an OAM tool that detects loop through
User and Provider Bridge Networks is indispensable
4. Unlearning User Addresses
 Problem: If topology of an User Bridged LAN is changed by
the user-xSTP, the Provider Bridges must clear related
entries in the FDB
 However, this is needed only if the User Site is multihomed
to the Provider Network
 Requirements:
Provider Edge Bridges should support per-user-xSTP or
a snooping mechanism for it.
Q-in-Q: If topology change is detected, clear related
entries in the FDB, then notify that the fact to the other
Provider Bridges using Customer Change Notification
BPDU to be developed
MAC-in-MAC: If topology change is detected, clear
related entries in the FDB
5. Path Tracing
When a provider tests a path that forwards
frames for an user, the provider verifies
consistency of FDBs in the Provider Bridges
Problem: Verification is not easy in Q-in-Q case,
because, the Provider Bridged Network uses
user MAC addresses which subject to change
and are purged from FDBs in 5 minutes
Requirement: An OAM tool for path tracing is
indispensable in Q-in-Q case
Note: In MAC-in-MAC case, path tracing is easy,
because the Network uses Provider Edge
Bridge addresses
Summary of Requirements
24-32 bit “ID space” for P-VID
Extend Maximum Bridge Diameter
Provider-xSTP does not need to interwork with
user-xSTP
Support of per-user-xSTP in Provider Edge
Bridges
Development of an OAM tool for loop detection
Q-in-Q case:
Development of unlearn signaling protocol
Development of an OAM tool for path tracing