IEEE 802.1ah Issues
Paul Bottorff, Mark Holness, Michael Chen, Dinesh Mohan, Glenn
Parsons
January 10, 2005 Sacramento
Agenda
> Introduction
> Terminology
• Terminology in agreement
• Terminology needing consistent use
> Frame Format
• Basic Format Primatives in agreement
• Extended Service VLAN ID address size
• OAM Frames & Format Variations
> “Baggy pants” and peer reference model
3
P802.1ah - Provider Backbone Bridges
Task
Force
Proposals
05
N D
J
Sponsor
ballot
06
F M A M J J A S O N D
PAR
D1.0
D1.5
Legend
802 Plenary
802.1 Interim
IEEE-SA Standards Board
4
WG
ballot
TF ballot
D2.0
J
Standard!
07
F M A M J J A S N D
D2.5
D3.0
D4.0
J
F M A M
IEEE 802.1ah (Provider Backbone Bridge) Context
802.1ad
Interfaces
Provider Backbone Bridge
Network (802.1ah)
Provider Bridge Network
(802.1ad)
Provider Bridge Network
(802.1ad)
Provider Bridge Network
(802.1ad)
802.1aj
CFM(802.1ag) Runs
End-to-end
MRP(802.1ak) Runs in
802.1ad & 802.1ah
5
Provider Backbone Bridge Network (PBBN)
PB
PB
PBB
PBB
PB
PB
PB
PBB
PBB
• PB: Provider Bridge (as defined by 802.1ad)
• PBB: Provider Backbone Bridge Edge (as defined by 802.1ah)
6
Provider Network Example
Customer
Equipment
Provider Bridged
Network
C
CE
PB
A
PB
C
CE
P
P
PB
PB
CE
Provider Backbone
Bridged Network
A
PB
C
D
B
B
B
PB
B
PBB
CE
Customer
Equipment
PB
Provider
Bridge
PBB
P
C
PEB
Customer
LAN
A
Access
LAN
CE
Legend:
7
C
PBB
Provider
Backbone
Bridge
A
PB
P
Provider
LAN
PEB
Provider
Edge
Bridge
D
Boundary
LAN
B
Backbone
LAN
Provider Network Port
Customer Network Port
D
B
PB
B
P
P
PBB
B
B
P
PB
PBB
P
P
A
D
D
PBBN Provides Multi-Point tunnels between PBNs
PBN
PBN
B-VLANX
PBB
S-VLAN4
BBN
PBB
PBB
PBB
S-VLAN3
PBN
PBB
PBB
PBN
S-VLAN1
S-VLAN2
B-VLANY
• BB PB: Provider Backbone Bridge Edge
• Each B-VLAN carries many S-VLANs
• S-VLANs may be carried on a subset of a B-VLAN (i.e. all P-P
S-VLANs could be carried on a single MP B-VLAN providing
connection to all end points.
8
Agenda
> Introduction
> Terminology
• Terminology in agreement
• Terminology needing consistent use
> Frame Format
• Basic Format Primatives in agreement
• Extended Service VLAN ID address size
• OAM Frames & Format Variations
> “Baggy pants” and peer reference model
9
Terminology
> IEEE 802.1ad Terminology
•
•
•
•
•
•
C-TAG
C-VLAN
C-VID
S-TAG
S-VLAN
S-VID
Customer VLAN TAG
Customer VLAN
Customer VLAN ID
Service VLAN TAG
Service VLAN
Service VLAN ID
> Additional Provider Backbone Bridge Terminology
•
•
•
•
•
•
•
10
XS-TAG
XS-VID
C-MAC
B-MAC
B-VLAN
B-TAG
B-VID
Extended Service VLAN TAG (I-TAG/ES-TAG)
Extended Service VLAN ID (SID/ES-VID)
Customer MAC Address
Backbone MAC Address
Backbone VLAN (tunnel)
Backbone TAG Field
Backbone VLAN ID (tunnel)
Extended Service Tag
> Extended Service Tag is the field added in the PBB Encapsulation
which carries the Extended VLAN ID.
> Proposed names are:
• ES-TAG for Extended S-TAG
• I-TAG for Service ID TAG
• XS-TAG for Extended S-TAG
> Comments:
• ES-TAG can be confused with End Station
• XS-TAG is longer than I-TAG
• XS-TAG could be shortened to X-TAG
> Proposal:
• Agree on one of I-TAG or X-TAG so we can have consistent presentations
11
Extended Service VLAN
> Extended Service VLAN is the larger VLAN ID used to carry the S-VID
over a Provider Backbone Bridge Network
> Proposed names are:
• ES-VID for Extended Service VLAN ID
• SID for Service ID
• XS-VID for Extended Service VLAN ID
> Comments:
•
•
•
•
•
ES-VID can be confused with End Station
SID does not have clear VLAN definition
XS-VID can be shortened to X-VID
XS-VID is longer than X-VID
Another option would be to use I-VID for consistency with I-TAG
> Proposal:
• Agree on one of I-VID or X-VID
12
Agenda
> Introduction
> Terminology
• Terminology in agreement
• Terminology needing consistent use
> Frame Encapsulation Format
• Basic Format Primatives in agreement
• Extended Service VLAN ID address size
• OAM Frames & Format Variations
> “Baggy pants” and peer reference model
13
802.1ah Encapsulation Format
•
802.1ah Bridges encapsule frames with a BBN header
•
802.1ah header contains
a) Extended Service VLAN identifier (I-VID)
− Identifies the Provider Bridge S-VLAN within the BBN
− Is carried within an I-TAG which is 32 bits long and identified by an 802.1ah
Ethertype
− Requires at least 2^20 bits to identify 1M services
− Proposals for 2^20, 2^24, and 2^28 bits
b) Site Connectivity identifier (B-VID)
− Identifies a B-VLAN (or tunnel) that is used to transport the BBN S-VLANs
− Site connectivity (i.e., tunnel) can be point-to-point or multi-point in nature
− B-VLAN is carried in a B-TAG with the 802.1ad Ethertype and S-TAG format
c) Backbone POP Address (B-MAC)
MAC Address for POPs within Site Connectivity
•
802.1ad Service VLAN IDs (S-VIDs) map to 802.1ah Extended Service
VLAN IDs (I-VIDs)
−
−
14
PBN S-VIDs are local to the PBN
BBN I-VIDs are local to the BBN
Encapsulation Frame Header
1
2
6
10
14
18
22
26
30
32
•
2
3
4
Backbone Destination Address
Backbone Source Address
.1ad Ethertype
.1ad B-TAG TCI
B-DA
B-SA
B-TAG
.1ah Ethertype
.1ah I-TAG TCI
Encapsuled Destination Address
I-TAG
Encapsuled Source Address
The B-TAG is identical to and S-TAG and optional in the frame
15
Extended Service VLAN ID Size
Octets
1
Reserved
20 Bit I-VID
Bits
Octets
1 8
1
2
Rsv
Bits
8
Octets
28 Bit I-VID
4 3
4
3
I-VID
1
1 3
2
PRE/DE
Bits
4 3
Rsv - Reserved
PRE/DE – Priority/Drop Eligible
I-VID – Extended Service VLAN ID
16
1
4 3
PRE/DE
1
8
I-VID
PRE/DE
8
24 Bit I-VID
4
3
2
3
4
I-VID
1
I-VID Size Considerations
> 20 bit format is similar to MPLS label where EXP/S bits are replaced
with PRE/DE and TTL field is reserved
> 20 bit format may be short sighted. Residential applications will
increase the service demand by 10X. 20 bits allows 1 million S-VLAN,
however we could have more.
> The I-VID is not a label. The I-VID limits the number of S-VLANs in a
backbone region rather than link (as in a label).
> Having 8 reserved bits leaves a lot open to abuse.
> The 24 bit format provides more address space for residential and
sparse address usage
> The 28 bit format takes up all the extra bits
> Recommendation: Assign 28 bits for I-VID for first draft. If we need
some additional control bits we can shrink the I-VID as needed placing
the control bits in the high order area. This will result in a I-TAG TCI
with no un-used bits and give the maximum possible I-VID address
size.
17
OAM Frame Header
1
2
6
10
14
18
22
26
18
2
3
4
Backbone Destination Address
Backbone Source Address
.1ad Ethertype
.1ad S-TAG TCI
.1ag Ethertype
Version, ME Level, OpCode, HeaderLen
Transaction ID/ Sequence #
Agenda
> Introduction
> Terminology
• Terminology in agreement
• Terminology needing consistent use
> Frame Encapsulation Format
• Basic Format Primatives in agreement
• Extended Service VLAN ID address size
• OAM Frames & Format Variations
> “Baggy pants” and peer reference model
19
Dual Relay PBB Model
PB Topology Element
BB Topology Element
PB PEER
CFM
UP
CFM
UP
BB PEER
CFM
UP
CFM
DOWN
EISS
CFM
DOWN
.1Q “Y”
CFM
UP
CFM
DOWN
.1Q “Y”
CFM
DOWN
.1Q “Y”
.1Q “Y”
PBB SHIM
ISS
MAC
MAC
BB LAN
20
PB LAN
PBB Shim Functions
802.1ad
Relay
MIF
802.1ad
MCF
MAC
(802.3)
PBB
Shim
MCF
Virtual MAC
Backbone Edge
21
>
Maps S-VID from 802.1ad into
larger Extended Service VID
(XS-VID)
MCF
>
Learns and Correlates
Backbone POP and Customer
MAC addresses
>
Filters L2 control packets
sourced by core relays or by
provider bridge relays (divides
spanning trees)
MIF
BB
MCF
Does encap/decap of 802.1ad
frame
PB
Relay
MIF
MIF
>
MAC
(802.3)
PBB Peer Model
Backbone
Core
Backbone Edge
Provider
Bridge
Network
MIF
8.5,6.7,9.5
MCF
(D 6.5)
MAC
(802.3)
PB
PBI
Relay
Backbone Edge
MIF
MIF
8.5,6.7,9.5
8.5,6.7,9.5
PBB
SHIM
MIF
Relay
MCF
Imaginary MAC
Relay
MIF
MIF
MCF
MCF
MCF
MAC
(802.3)
MAC
(802.3)
MAC
(802.3)
MIF
MIF
MCF
MAC
(802.3)
Relay
MIF
PBB
SHIM
MCF
Relay
MIF
8.5,6.7,9.5
MCF
(D 6.5)
MAC
(802.3)
Imaginary MAC
PB
PBB
PB
PB
22
PBB
PB
PBB
PB
PBI
PB
PBB
Provider
Bridge
Network
Single Relay Outside PBB Shim Model
CFM
UP
CFM
UP
CFM
UP
CFM
DOWN
CFM
DOWN
.1Q “Y”
MAC
23
CFM
DOWN
.1Q “Y”
MAC
BB LAN
CFM
UP
.1Q “Y”
CFM
DOWN
.1Q “Y”
PBB SHIM
MAC
MAC
PB LAN
Single Relay Inside PBB Shim Model
CFM
UP
CFM
DOWN
.1Q
“Y”
CFM
UP
CFM
UP
CFM
DOWN
CFM
DOWN
.1Q
“Y”
CFM
UP
CFM
DOWN
.1Q
“Y”
.1Q
“Y”
PBB SHIM
MAC
BB LAN
24
MAC
MAC
MAC
PB LAN
Backup Slides
802.1ah PAR
>
1. ASSIGNED PROJECT NUMBER: 802.1ah
>
2. SPONSOR DATE OF REQUEST: 2004-10-07
>
3. TYPE OF DOCUMENT: Standard
>
4. TITLE OF DOCUMENT: Standard for Local and Metropolitan Area Networks –
Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges
>
5. LIFE CYCLE: Full-Use
>
6. TYPE OF PROJECT: Amendment P802.1Q
>
11. TYPE OF SPONSOR BALLOT: Individual
Expected Date of Submission for Initial Sponsor Ballot: 2006-12-31
>
12. PROJECTED COMPLETION DATE FOR SUBMITTAL TO REVCOM: 2007-09-31
26
Scope
The scope of this standard is to define an architecture and bridge
protocols compatible and interoperable with Provider Bridged(1)
Network protocols and equipment allowing interconnection of multiple
Provider Bridged Networks, to allow scaling to at least 2^20 Service
Virtual LANs, and to support management including SNMP.
Completion of this document contingent? Yes
1)This standard is designed to support Provider Bridges (IEEE
P802.1ad).
27
Purpose & Reason
Purpose: This standard will complete the future work identified by
P802.1ad, by providing a specific means for interconnecting Provider
Bridged Networks. It will enable a Service Provider to scale the
number of Service VLANs in a Provider Network by interconnecting
the Service VLANs, and provide for interoperability and consistent
standards based management.
Reason: This project is intended to facilitate the scaling of Provider
Bridged P802.1ad networks using existing Bridged and Virtual
Bridged LAN technologies. Despite user demand and initial
deployment of LAN-based backbones for connecting P802.1ad
networks, there is currently no interoperability between different
vendors, nor a coherent management framework for different
techniques. Most major carriers, who will be the users of this
standard, are currently deploying LAN-based service networks that
need to be scaled to meet the demands both of transition from
existing leased line service and expansion of multipoint services.
28
Broad Market Potential
A standards project authorized by IEEE 802 shall have a broad
market potential. Specifically, it shall have the potential for:
a) Broad sets of applicability.
b) Multiple vendors and numerous users.
c) Balanced costs (LAN versus attached stations).
This project is intended to facilitate the scaling of Provider Bridged
P802.1ad networks using existing Bridged and Virtual Bridged LAN
technologies. Despite user demand and initial deployment of LANbased backbones for connecting P802.1ad networks, there is
currently no interoperability between different vendors, nor a coherent
management framework for different techniques.
Most major carriers are currently deploying LAN-based service
networks which need to be scaled to meet the demands both of
transition from existing leased line service and expansion of
multipoint services.
The costs related to this technology should be broadly similar to
those of existing Bridging technology based on
802.1D/802.1w/802.1Q/802.1s.
29
Compatibility
IEEE 802 defines a family of standards. All standards shall be in
conformance with the IEEE 802.1 Architecture, Management and
Interworking documents as follows: 802. Overview and Architecture,
802.1D, 802.1Q, and parts of 802.1f. If any variances in conformance
emerge, they shall be thoroughly disclosed and reviewed with 802.
Each standard in the IEEE 802 family of standards shall include a
definition of managed objects which are compatible with systems
management standards.
This standard will be compatible with 802.1Q as amended by
P802.1ad and P802.1ag. This project will be compatible with existing
802.1 Architecture, Management and Interworking standards.
The Provider Backbone Bridge will rely on extensions to 802.3 frame
size for additional header space. Work on frame size extension is
currently under study at 802.3.
30
Distinct Identity
Each IEEE 802 standard shall have a distinct identity. To achieve this,
each authorized project shall be:
a) Substantially different from other IEEE 802 standards.
b) One unique solution per problem (not two solutions to a problem).
c) Easy for the document reader to select the relevant specification.
There is no other IEEE standard or project that allows scaling of a
Provider Bridge network to support large numbers of Service VLANs.
No existing solution provides a multipoint LAN backbone for
interconnection of Provider Bridges. The document reader will have
an easy reference to scaling of Provider Bridge networks.
31
Technical Feasibility
For a project to be authorized, it shall be able to show its technical
feasibility. At a minimum, the proposed project shall show:
a) Demonstrated system feasibility.
b) Proven technology, reasonable testing.
c) Confidence in reliability.
The proposed standard will be based on existing, proven,
standardized, Bridged LAN and Virtual Bridged LAN technology.
These technologies are widely implemented and highly reliable.
32
Economic Feasibility
For a project to be authorized, it shall be able to show economic
feasibility (so far as can reasonably be estimated), for its intended
applications. At a minimum, the proposed project shall show:
a) Known cost factors, reliable data.
b) Reasonable cost for performance.
c) Consideration of installation costs.
The technology that will be developed in the proposed standard will
not differ significantly from the economic factors associated with
existing Bridged LAN and Virtual Bridged LAN technologies. The cost
factors for Virtual Bridged LAN technology are favorable when
compared to existing provider networks based on MPLS or SONET.
33
A Provider Bridge Scaling Solution
“Provider Backbone Bridging”
802.1ad
Interfaces
Provider Backbone Bridge
Network (802.1ah)
Provider Bridge Network
(802.1ad)
Provider Bridge Network
(802.1ad)
Provider Bridge Network
(802.1ad)
802.1aj
802.1ag Runs
End-to-end
802.1ak Runs in
802.1ad & 802.1ah
34
Ethernet Service Types
MEF Ethernet Virtual Connections (EVCs)
E-LINE
Router Mesh
E-TREE
Hub & Spoke
E-LAN
Multi-Site
35
Pt-Pt, Like
Duplex Ethernet
Any-to-any
Pt-MPt, Like
EPON Ethernet,
Root-to-Leaf and
Leaf-to-Root
MPt, Like VLAN,
Any-to-any
E-LINE Dominates Today
> E-LINE is a natural leased line replacement for subscribers
•
•
•
•
Ethernet leased lines offer high bandwidth
Lines provide bandwidth on demand
Interfaces are compatible with off the shelf Ethernet switches/routers
Best for router mesh
> E-LINE provides natural migration for carriers
•
•
•
•
•
Consistent with current operations model
Allows carrier equipment reductions
Bill models can follow well understood FR services
Current QoS models allow both traffic control and service monitoring of ELINE service offerings
Service OAM models for E-LINE are relatively straightforward
> Each E-LINE service instance requires 1 S-VLAN
36
E-TREE Ideal For ISP Connect
> E-TREE Future Service With Great Promise
•
•
Useful as a multiplexed connection to an application service provider like an ISP
Service is unlike traditional Ethernet since leaf nodes can not talk with each other
> E-TREE has deployment issues
•
No clear billing model
• For instance if one leaf is disconnected is the circuit down?
• What is the distance of the tree?
•
•
37
OAM management not fully understood
QoS model non-existant, SLAs can only provide Best Effort
E-TREE S-VLAN Mapping
Pt-MPt, Like
EPON Ethernet,
Root-to-Leaf and
Leaf-to-Root
E-TREE
Hub & Spoke
Hub
Port
Spoke
Ports
> Each E-TREE service instance requires 2 S-VLANs
> Both S-VLANs comprising an E-TREE S-VLANs are unidirectional
> The S-VLANs of and E-TREE service instance are typically on the
multiplexed on the same port
38
Some Carriers Will Use E-LINE in Hub and
Spoke Arrangement
Pt-Pt
Root-to-Leaf and
Leaf-to-Root
E-LINE
Hub & Spoke
Hub
Port
Spoke
Ports
> Hub port would usually be multipexed to allow the multiple Pt-Pt
attachments.
> Each E-LINE is a seperate managed S-VLAN
> This arrangement allows use of E-LINE management, billing, and QoS
> Many more S-VLANs are required
39
E-LAN Many Future Applications
> E-LAN is deployed for broad connectivity in select network
•
•
•
•
Interconnect of multiple corporate sites
Multi-player gaming
Ubiquitous any-to-any connectivity
E-LAN has many future applications
> E-LAN has deployment issues
•
•
Deployments are very spotty
Unclear billing model
• How is availability defined?
• No definitions for QoS or performance measurement
• What is the distance of a E-LAN
•
•
Unclear management models
Unlike existing carrier service offerings
> Each E-LAN service instance is a single S-VLAN
40
Prototypical Major Metro Area
> Business Subscriber Population 100K-2M
• San Jose Yellow Pages ~100K businesses
• The SF Bay Area lists ~1M businesses
> Large Business Sites 500-5,000
> Residential Subscriber Population 1M-20M
> Leased Line Density 10K-200K
• Roughly 1/10 Yellow Page Listings
> Application Service Provider Sites 100-2000
• Large APSPs sites may service residental
41
Major MSA Networks
Typical SP
Access
Business
Small Office
Medium Office
Large Office
CLE
Network Scale
>10,ooo Remotes
>10,ooo CLEs
>500 COs
100-200 COs
10-60 COs
Metro Scale
>4,ooo Remotes
>1,ooo CLEs
>50 COs
>20 COs
>4 COs
Typical Metropolitan Serving
Area – MSA
> MSA example shown
> ASIA/PAC more CO/MSA
> Europe less
42
CO/MSA
Support 1,000,000 Service Instances
>
Must be able to support E-LINE service for leased line replacement for entire MSA
•
•
>
Must support E-LINE for APSP to Subscribers
•
•
•
•
>
200K E-LINE S-VLANs for leased line replacement
200K E-LINE S-VLANs for APSP
20K E-TREE S-VLANs
? E-LAN Service Instances
Designing Into A Corner Will Not Instill Confidence In Future
•
•
•
43
Advanced peer applications
Number of service instances speculative, however could be large
Totals
•
•
•
•
>
Not all service providers will allow E-TREE because of deployment problems
The objective of an additional 200K E-LINE is adequate for transition until E-TREE
Requirements for around 10K E-TREE instances
Requires 20K S-VLANs
Must support E-LAN for APSP and B-B
•
•
>
This is the way Ethernet is entering the markets
The objective is 200K E-LINE instances
Set Objectives to at least 1,000,000 service instances E-LINE, E-TREE, E-LAN
E-LAN service will eventually become important for coupling small groups
Allow E-TREE and E-LAN service scaling to at least 100,000 for future growth
Proposed Project Objectives
> Interconnect Provider Bridge (802.1ad) Networks in a
manner that allows scaling of the Carrier Bridged Network
to support at least 2^20 S-VLANs
> Support at least 2^16 multipoint S-VLANs
> Interconnect at least 256 Provider Bridged Networks
44
Provider Backbone Bridge Technology Principles
45
A Provider Bridge Scaling Solution
“Provider Backbone Bridging”
802.1ad
Interfaces
Provider Backbone Bridge
Network (802.1ah)
Provider Bridge Network
(802.1ad)
Provider Bridge Network
(802.1ad)
Provider Bridge Network
(802.1ad)
802.1aj
802.1ag Runs
End-to-end
802.1ak Runs in
802.1ad & 802.1ah
46
Provider Backbone Bridge Network
PB
PB
BB PB
BB PB
BB
PB
PB
BB PB
• PB: Provider Bridge (as defined by 802.1ad)
• BB PB: Provider Backbone Bridge Edge
• BB: Provider Backbone Bridge
47
BB PB
Terminology
> IEEE 802.1ad Terminology
•
•
•
•
•
•
C-TAG
C-VLAN
C-VID
S-TAG
S-VLAN
S-VID
Customer VLAN TAG
Customer VLAN
Customer VLAN ID
Service VLAN TAG
Service VLAN
Service VLAN ID
> Additional Provider Backbone Bridge Terminology
•
•
•
•
•
•
•
48
XS-TAG
XS-VID
C-MAC
B-MAC
B-VLAN
B-TAG
B-VID
Extended Service VLAN TAG (I-TAG/ES-TAG)
Extended Service VLAN ID (SID/ES-VID)
Customer MAC Address
Backbone MAC Address
Backbone VLAN (tunnel)
Backbone TAG Field
Backbone VLAN ID (tunnel)
BBN Provides Multi-Point B-VLANs Between PBNs
PBN
PBN
B-VLANX
BB
PB
S-VLAN4
BBN
BB
PB
BB
PB
BB
PB
BB
PB
PBN
S-VLAN1
S-VLAN3
PBN
BB
PB
S-VLAN2
B-VLANY
• BB PB: Provider Backbone Bridge Edge
• Each B-VLAN carries many S-VLANs
• S-VLANs may be carried on a subset of a B-VLAN (i.e. all P-P
S-VLANs could be carried on a single MP B-VLAN providing
connection to all end points.
49
Provider Backbone Bridge Model
Provider Bridge Relays
Backbone Bridge Relays
MIF
8.5,6.7,9.5
PB
PBI
MCF
(D 6.5)
MAC
(802.3)
Relay
PB
MIF
MIF
8.5,6.7,9.5
8.5,6.7,9.5
S-VLAN
Map
Shim
Relay
MIF
MCF
Imaginary MAC
BB
MIF
MIF
MCF
MCF
MAC
(802.3)
MAC
(802.3)
Relay
BB
MIF
MIF
MCF
MCF
MAC
(802.3)
MAC
(802.3)
Relay
BB
Backbone Bridge Interfaces
Provider Bridge Interfaces
50
MIF
S-VLAN
Map
Shim
MCF
Imaginary MAC
Relay
PB
MIF
8.5,6.7,9.5
MCF
(D 6.5)
MAC
(802.3)
PB
PBI
Backbone Core Relays Can be 802.1ad
Provider
Bridge
Network
PB
PBI
MIF
8.5,6.7,9.5
MCF
(D 6.5)
MAC
(802.3)
Relay
Backbone
Core
MIF
8.5,6.7,9.5
PB S-VLAN
Map
MIF
MCF
Relay
BB
Imaginary MAC
MIF
MIF
MCF
MCF
MAC
(802.3)
MAC
(802.3)
Relay
MIF
8.5,6.7,9.5
MIF
MIF
MCF
MCF
MAC
(802.3)
MAC
(802.3)
BB
Relay
BB
MIF
MCF
Relay
MIF
8.5,6.7,9.5
S-VLAN PB MCF
Map
(D 6.5)
MAC
(802.3)
Imaginary MAC
Provider
Bridge
Network
PB
PBI
Backbone Edge
Backbone Edge
PB
PB
BB PB
BB PB
BB
PB
51
BB PB
PB
BB PB
>
Backbone Core can be single 802.1ad relay
>
Backbone Edge is a dual 802.1ad relay and an encap/decap between the two
relays.
Customer, PB, BB Spanning Trees
Customer Spanning Trees
QB
QB
QB
PB
PB
PB-BB
PB-BB
PB
QB
QB
QB
QB
PB
BB
QB
QB
PB
PB
PB Spanning
Trees
52
PB
PB
PB
PB-BB
QB
PB
BB
BB
Spanning
Trees
PB Spanning
Trees
>
Customer spanning trees may extend over Provider Network
>
PB Network and BB Network spanning trees must be decoupled to scale the
provider network
>
Provider Backbone Bridge may conform to the requirements for an Interconnect
Medium
Provider Bridge Island BPDUs Delivery Inside
Provider Backbone Bridge
BB
PB
BBN
BB
PB
BB
PB
BB
PB
BB
PB
PBN2
BPDU2
BPDU1
PBN1
BB
PB
• BB PB: Provider Backbone Bridge Edge
• Each Provider Bridge Island may be connected to multiple Provider
Backbone Bridge ports
• Provider Bridge Islands may not connect directly to each other
• Provider Backbone Bridge delivers Island BPDUs to all ports of that Island
• Island BPDUs are never delivered to other Islands by the BBN
53
BB Functions In Map Shim
802.1ad
Relay
802.1ad
MAC
(802.3)
8.5,6.7,9.5
8.5,6.7,9.5
MCF
(D 6.5)
S-VLAN
Map
Shim
MCF
Virtual MAC
Backbone Edge
54
>
Maps S-VID from 802.1ad into
larger Extended Service VID
(XS-VID)
MCF
(D 6.5)
>
Learns and Correlates
Backbone POP and Customer
MAC addresses
>
Filters L2 control packets
sourced by core relays or by
provider bridge relays (divides
spanning trees)
MIF
BB
MCF
MIF
Does encap/decap of 802.1ad
frame
PB
Relay
MIF
MIF
>
MAC
(802.3)
Map Shim Encap
•
BBN encapsulates PBN frames with BBN header
•
BBN header consists of
a) Extended Service VLAN identifier
− Identifies the Provider Bridge S-VLAN within the BBN
− Requires 2^20 bits to identify 1M services
b) Site Connectivity identifier
− Identifies a B-VLAN (or tunnel) that is used to transport the BBN service
instance
− Site connectivity (i.e., tunnel/domain) can be point-to-point or multi-point in
nature
c) Backbone POP Address
MAC Address for POPs within Site Connectivity
•
PBN Service VLAN IDs (S-VIDs) map to BBN Extended Service VLAN
IDs (XS-VIDs)
−
−
55
PBN S-VIDs are local to the PBN
BBN XS-VIDs are local to the BBN
Backbone Frame Format
BBN Frame Header
PB Frame Format
BBN Frame Format
MAC DA
MAC SA
B-MAC DA
B-MAC SA
BBN Frame
Header
B-TAG
S-TAG
Payload
MAC DA
FCS
MAC SA
Payload
BBN FCS
> Removing S-Tag is most efficient encode
> Since FCS is also most efficient encode
> Un B-Tagged frames could be used
> B-Tag format should be identical to 802.1ad
56
XS-TAG
MAP Shim on Ingress or Egress
802.1ad
802.1ad
Relay
Relay
MIF
MCF
MIF
BB
MAC
(802.3)
MIF
8.5,6.7,9.5
PB
MCF
MCF
(D 6.5)
S-VLAN
Map
Shim
S-VLAN
Map
Shim
MAC
(802.3)
MAC
(802.3)
Backbone Edge
> Both work
> Best if located in one or the other
57
MIF
8.5,6.7,9.5
MCF
(D 6.5)
MAC
(802.3)
Backbone Access
S-VLANs Multiplex into B-VLANs
B-VLANs
S-VLANs
PBI
BBI
Backbone
Bridge
(802.1ad)
BB Relay MAP Shim PB Relay
Provider Backbone Edge Bridge
Provider
Bridge
(802.1ad)
> MAP Shim performs encap/decap of frames to/from Provider
Bridge Networks
58
Extended Service VLAN IDs In Backbone
BB
PB
S-VLAN4
S-VID41
BB
PB
XS-VID4
S-VID32
B-VLANX
BBN
S-VLAN3
BB
PB
XS-VID3
S-VID31
BB
PB
S-VID33
BB
PB
BB
PB
B-VLANY
S-VID42
S-VLAN1
S-VLAN2
• BB PB: Provider Backbone Bridge Edge
• An XS-VID uniquely identifies a S-VLAN within the Backbone
• The MAP Shim translates between S-VID and XS-VID
• The XS-VID to(from) S-VID mapping is provisioned when a new
service instance is created
59
Single XS-VID per S-VLAN
S-VID2
BB
PB
BB
PB
BBN
S-VID3
BB
PB
XS-VID
S-VID1
BB
PB
> Regardless of the XS-VID address size the map tables only have 4096
entries since only one XS-VID exists per S-VLAN and only 4096 SVLANs exist per Provider Bridge.
> A different S-VID in each PBN maps to the XS-VID
60
Site Connectivity B-VLAN ID
B-VLANX
BB
PB
S-VLAN4
BBN
BB
PB
BB
PB
S-VLAN3
BB
PB
BB
PB
S-VLAN1
BB
PB
S-VLAN2
B-VLANY
>
B-VLANs are addressed like regular VLANs with a 12 bit B-VID
>
B-VID and XS-VID need to be separate ID spaces to allow many S-VLANs to be
carried in a single B-VLAN
61
Backbone POP MAC Address
BB PB
BBN
BB PB
B-MAC4
BB PB
Frame
B-MAC1
BB PB
Frame
DA <- B-MAC4
SA <- B-MAC1
Frame
62
>
B-MAC Addresses identify the Edge Provider Backbone Bridges (BB PB)
>
B-MAC Addresses are learned by other Edge Backbone Edge Bridges
>
The backbone edge MAC address determines which edge on the B-VLAN will receive the
frame.
>
Frames may be flooded by sending with broadcast or multicasts DA B-MACs to the B-VLAN.
>
Map shims filter based on the XS-VID removing any misaddressed frames
Customer/Provider Addresses
Customer
MAC
Addresses
Provider
MAC
Addresses
Relay
MCF
(D 6.5)
MAC
(802.3)
S-VLAN
Map
Shim
MCF
Virtual MAC
Backbone Edge
63
MCF
(D 6.5)
MIF
BB
MCF
MIF
8.5,6.7,9.5
PB
Relay
MIF
MIF
8.5,6.7,9.5
> PB Relay Learns Customer
Address Per S-VLAN
> BB Relay Learns Provider
Addresses Per B-VLAN
> MAP Shim Learns Correlated
Customer and Provider MAC
Addresses per S-VLAN
MAC
(802.3)
Customer/Provider
MAC Address
Correlation
MAP Shim Correlation Table
Provisioned
Provider
Addresses
S-VID
XS-VID
0x001
0x010090
0x0c0
B-MAC Addresses
Customer
Addresses
0x002
0x070707
0x007
0x999999999999
C-MAC Addresses
0x111111111111
0x888888888888
B-VID
0x222222222222
0xfff
0x808080
0x0c0
C-MAC Address
0x777777777777
0xdddddddddddd
> In the beginning the MAP Shim is provisioned with the correlation between the
S-VID, XS-VID, and B-VID
> During operation the MAP Shim learns both B-MAC addresses and C-MAC
addresses
> The MAP Shim keeps track of which C-MAC addresses are behind which BMAC
> The correlation data is used to encapsulate frames from the PBNs
64
Basic MAP Shim Operation
> Frames received from PB Relay are encaped
•
•
•
S-VID is looked up in correlation table to get XS-VID and B-VID
C-DA is looked up in C-MAC table to get B-MAC for encapsulation
If C-DA is not present in C-MAC table then multicast to B-VLAN
> Frames received from BB Relay are de-encaped
•
XS-VID is looked up in correlation table to get a new S-VID
> B-MAC and C-MAC addresses are learned when frames are received
from BB relay
> B-MAC and C-MAC addresses are aged
65
Summary
> A Provider Backbone Bridge standard needs to define the
functions of the MAP Shim
> The 802.1ad control plane may be used on both sides of
the MAP Shim
> Connection Fault Management 802.1ag should be
supported by the Provider Backbone Bridges
66
Backup Material
68
Terminology
> IEEE 802.1ad Terminology
•
•
•
•
•
•
C-TAG
C-VLAN
C-VID
S-TAG
S-VLAN
S-VID
Customer VLAN TAG
Customer VLAN
Customer VLAN ID
Service VLAN TAG
Service VLAN
Service VLAN ID
> Additional Provider Backbone Bridge Terminology
•
•
•
•
•
•
•
69
XS-TAG
XS-VID
C-MAC
B-MAC
B-VLAN
B-TAG
B-VID
Extended Service VLAN TAG Field (I-TAG)
Extended Service VLAN ID (SID)
Customer MAC Address
Backbone MAC Address
Backbone VLAN (tunnel)
Backbone TAG Field
Backbone VLAN ID (tunnel)
Service Instance Address Space Size Options
> Carriers need to separate the service address space to
allow administration of networks
• Allocation of address blocks to offices
• Merging network elements
> The address space usually needs to be 10-100 times
larger than the number of services supported
> Should have an address space around 2^24
> Use of 2^20 address space would match MPLS
> Need to resolve this issue
70
Provider Backbone Bridges May Apply the 5
IM Rules.
1. Each 802.1ad island is responsible for preventing internal forwarding
loops.
2. The 802.1ad islands connect to other only through Provider Backbone
Bridge.
3. Each 802.1ad island ensures that no customer data frame passes
through more than one Provider Backbone Bridge attachment into or
out of the island.
4. Each 802.1ad island ensures that it attaches any given S-VLAN to no
more than one Provider Backbone Bridge network.
5. A Provider Backbone Bridge network ensures that if an attached port
can talk to any other attached port, it can talk to all of the ports
attached to the Backone network.
71