Requirements for 802.1AD Provider Bridges

1. Requirements for 802.1AD Provider Bridges June 2003 Muneyoshi Suzuki NTT

2. Reference Model User Bridged LAN Provider Bridged Network User Site of user A User Site of user A CE PEB PEB CE PCB PCB PCB CE User Site of user B User Site of user B CE PEB PEB CE User Bridged LAN PEB: Provider Edge Bridge PCB: Provider Core Bridge CE: Customer Equipment

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

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

5. 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 amechanism for loop prevention • User Bridged LAN should deploy amechanism for loop prevention • Provider Bridged Network should deploy mechanisms that protect the network from loops caused by users

6. (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 user-xSTP

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

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

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

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

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