One document matched: draft-sajassi-l2vpn-vpls-pbb-interop-00.txt
Internet Working Group Ali Sajassi
Internet Draft Samer Salam
Chris Metz
Cisco
Nabil Bitar
Verizon
Dinesh Mohan
Nortel
Expires: September 2007 March 2007
VPLS Interoperability with Provider Backbone Bridges
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any applicable
patent or other IPR claims of which he or she is aware have been or will be
disclosed, and any of which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The scalability of H-VPLS (either with MPLS or Ethernet access network) can be
improved by incorporating Provider Backbone Bridge (PBB -
- 802.1ah) functionality
in PE devices. PBB is being worked on in IEEE as an amendment to 802.1Q to improve
the scalability of MAC addresses and service instances in Provider Ethernet
networks. This draft describes how IEEE 802.1ah functionality can be used in the
H-VPLS access network to attain better scalability in terms of number of customer
MAC addresses and number of service instances that can be supported. This draft
also describes the scenarios and the mechanisms for incorporating PBB
functionality within H-VPLS (with either MPLS or Ethernet access network) and
interoperability between them.
Sajassi, et. al. [Page 1]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119
Table of Contents
1. Terminology........................................................2
2. Overview..........................................................4
3. Background: Provider Backbone Bridges..................................4
3.1. S-Tagged Service Interface..........................................6
3.2. I-Tagged Service Interface..........................................6
3.3. B-Tagged Service Interface..........................................7
4. H-VPLS with PBB Access Network........................................7
4.1. Network Topologies................................................8
4.1.1. Topology Variant A...............................................8
4.1.2. Topology Variant B...............................................9
4.2. Service Interfaces & Interworking Options............................10
4.2.1. PBBN-VPLS Type I Service Interface................................10
4.2.2. PBBN-VPLS Type II Service Interface................................12
4.2.3. PBBN-VPLS Type III Service Interface...............................14
5. H-VPLS with MPLS Access Network......................................16
5.1. Supported Services...............................................17
5.2. U-PE Operation in a Single Domain...................................18
5.3. U-PE Operation in Multiple Domains..................................18
5.4. Pseudowire Requirements...........................................18
5.4.1. Requirements with B-VID as Service Delimiter........................19
5.4.2. Requirements with I-SID as Service Delimiter........................19
6. Acknowledgments....................................................19
7. Security Considerations.............................................19
8. Intellectual Property Considerations..................................19
9. Full Copyright Statement............................................19
10. 14. IPR Notice....................................................20
11. Normative References...............................................20
12. Informative References.............................................21
13. Authors' Addresses................................................21
1.
Terminology
802.1ad: IEEE specification for ‘‘Q-in-Q’’ encapsulation and bridging of Ethernet
frames
802.1ah: IEEE specification for ‘‘MAC tunneling’’ encapsulation and bridging of
frames across a provider backbone bridged network.
B-BEB: A backbone edge bridge positioned at the edge of a provider backbone
bridged network. It contains a B-component that supports bridging in the provider
backbone based on B-MAC and B-TAG information
Sajassi, et al. [Page 2]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
B-MAC: The backbone source and destination MAC address fields defined in the
802.1ah provider MAC encapsulation header.
BCB: A backbone core bridge running in the core of a provider backbone bridged
network. It bridges frames based on B-TAG information just as an 802.1ad provider
bridge will bridge frames based on a VLAN identifier (S-VLAN)
BEB: A backbone edge bridge positioned at the edge of a provider backbone bridged
network. It can contain an I-component, B-component or both I and B components.
B-TAG: field defined in the 802.1ah provider MAC encapsulation header that
conveys the backbone VLAN identifier information. The format of the B-TAG field is
the same as that of an 802.1ad S-TAG field.
B-Tagged Service Interface: This is the interface between a BEB and BCB in a
provider backbone bridged network. Frames passed through this interface contain a
B-TAG field.
B-VID: The specific VLAN identifier carried inside a B-TAG
I-component: A bridging component contained in a backbone edge bridge that bridges
in the customer space (customer MAC addresses, S-VLAN)
IB-BEB: A backbone edge bridge positioned at the edge of a provider backbone
bridged network. It contains an I-component for bridging in the customer space
(customer MAC addresses, service VLAN IDs) and a B-component for bridging the
provider’s backbone space (B-MAC, B-TAG).
I-BEB: A backbone edge bridged positioned at the edge of a provider backbone
bridged network. It contains an I-component for bridging in the customer space
(customer MAC addresses, service VLAN IDs).
I-SID: The 24-bit service instance field carried inside the I-TAG. The I-SID
defines the service instance that the frame should be ‘‘mapped to’’.
I-TAG: A field defined in the 802.1ah provider MAC encapsulation header that
conveys the service instance information (I-SID) associated with the frame.
I-Tagged Service Interface: This the interface defined between the I and B
components inside an IB-BEB or between two B-BEB. Frames passed through this
interface contain an I-TAG field
PBB: Provider Backbone Bridge
PBBN: Provider Backbone Bridged Network
S-TAG: A field defined in the 802.1ad QinQ encapsulation header that conveys the
service VLAN identifier information (S-VLAN).
S-Tagged Service Interface: This the interface defined between the customer (CE)
and the I-BEB or IB-BEB components. Frames passed through this interface contain
Sajassi, et al. [Page 3]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
an S-TAG field.
S-VLAN: The specific service VLAN identifier carried inside an S-TAG
2.
Overview
[RFC4762] describes a two-tier hierarchical solution for VPLS for the purpose of
improved pseudowire scalability. This improvement is achieved by reducing the
number of PE devices connected in a full-mesh topology through connecting CE
devices via the lower-tier access network which in turn is connected to the top-
tier core network. The RFC describes two types of H-VPLS network topologies - one
with MPLS access network and another with Ethernet access network. The later one
(Ethernet access network) is based on IEEE 802.1ad (QinQ) standards. In both types
of H-VPLS, MAC address learning and forwarding are done based on customer MAC
addresses (C-MACs) which poses scalability issues as the number of VPLS instances
(and thus customer MAC addresses) increases. Furthermore, since a set of
pseudowires is maintained on a per customer service instance, the number of
pseudowires that need to be maintained at N-PE devices is proportional to the
number of customer service instances multiplied by the number of N-PE devices in
the full-mesh set. This can result in scalability issues (in terms of pseudowire
management and OAM aspects) as the number of customer service instances grows.
In addition to the above scalability issues, H-VPLS with Ethernet access network
(based on 802.1ad), has another scalability issue in terms of the number of
service instances that can be supported in the access network as described in that
RFC. Since the number of provider VLANs (S-VLANs) is limited to 4K and each S-VLAN
represents a service instance in an 802.1ad network, the number of service
instances that can be supported is also limited to 4K.
This draft describes how IEEE 802.1ah (aka Provider Backbone Bridges) can be
integrated with H-VPLS to address these scalability issues. In case of H-VPLS with
MPLS access, 802.1ah functionality is used at the U-PE which results in reduction
of customer MAC addresses and number of pseudowires in the VPLS core network. And
in case of H-VPLS with Ethernet access, 802.1ah access network results in better
scalability in terms of both number of service instances and number of C-MACs in
both Ethernet access network and VPLS core network.
This draft describes possible PBB interoperability scenarios for H-VPLS with
Ethernet and MPLS access networks for both single and multiple administrative
domains.
Section 2 gives a quick background in Provider Backbone Bridges and sections 3 and
4 describe interoperability scenarios and mechanisms for H-VPLS with PBB access
network, and H-VPLS with MPLS access network respectively.
3.
Background: Provider Backbone Bridges
Provider Backbone Bridges (PBBs), as currently being defined in IEEE 802.1ah,
offer a scalable solution for service providers to build large bridged networks.
Sajassi, et al. [Page 4]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
The focus of PBB is primarily on improving two main areas with provider Ethernet
bridged networks:
i) MAC-address table scalability: in current provider networks that employ IEEE
802.1Q or IEEE 802.1ad bridging, the service provider equipment operating at
the Ethernet MAC layer is forced to learn all customer edge device MAC
addresses (when the CE is a router) and all customer end-station MAC
addresses (when the CE is a bridge). This clearly does not scale well as the
number of customers and customer equipment, served by a given provider,
increases. The service providers are often limited by the size of the
hardware MAC tables as they attempt to scale their networks.
ii)Service instance scalability: when building networks using IEEE 802.1Q or
IEEE 802.1ad technologies, a service provider is limited to 4094 service
instances per 802.1Q or 802.1ad network. This limitation is due to the fact
that the VLAN identifier is 12-bits in width which translates to 4096
possible values (and VLAN identifier values 0 and 4095 are reserved).
To obviate the above two limitations, PBB introduces a hierarchical network
architecture with associated new frame formats which extend the work completed by
Provider Bridges (IEEE 802.1ad). In the PBB architecture, customer networks (using
IEEE 802.1Q bridging) are aggregated into provider bridge networks (using IEEE
802.1ad). These, in turn, are aggregated into Provider Backbone Bridge Networks
(PBBNs) which utilize the IEEE 802.1ah frame format. The frame format employs a
MAC tunneling encapsulation scheme for tunneling customer Ethernet frames within
provider Ethernet frames across the PBBN. A VLAN identifier (B-VID) is used to
segregate the backbone into broadcast domains and a new 24-bit service identifier
(I-SID) is defined and used to associate a given customer MAC frame with a
provider service instance (also called the service delimiter). It should be noted
that in 802.1ah there is a clear segregation between provider service instances
(represented by I-SIDs) and provider VLANs (represented by B-VIDs) which was not
the case for 802.1ad. As such, the network designer for an 802.1ah network has the
freedom to define the number of VLANs which is optimum for network operation
without any dependency on the number of service instances.
PBBN bridges utilize existing IEEE control protocols (e.g. IEEE 802.1s MST) to
create a loop free topology for frame forwarding. A PBBN bridge can be categorized
as either a Backbone Core Bridge (BCB) or Backbone Edge Bridge (BEB). A BCB is a
plain IEEE 802.1ad Provider Bridge. A BEB is responsible for encapsulation and
decapsulation of customer Ethernet frames to/from PBB (802.1ah) frame format.
As shown in the following figure, a Backbone Edge Bridge (BEB) may consist of a
single B-component and one or more I-components. In simple terms, the B-component
provides bridging in provider space (B-MAC, B-VLAN) and the I-component provides
bridging in customer space (C-MAC, S-VLAN). The customer frame is first
encapsulated with the provider backbone header (B-MAC, B-tag, I-tag); then, the
bridging is performed in the provider backbone space (B-MAC, B-VLAN) through the
network till the frame arrives at the destination BEB where it gets decapsulated
and passed to the CE. If a PBB bridge consists of both I & B components, then it
is called IB-BEB and if it only consists of either B-component or I-component,
then it is called B-BEB or I-BEB respectively. The interface between an I-BEB or
IB-BEB and a CE is called S-tagged service interface and the interface between an
I-BEB and a B-BEB (or between two B-BEBs) is called I-tagged service interface.
Sajassi, et al. [Page 5]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
The interface between a B-BEB or IB-BEB and a Backbone Core Bridge (BCB) is called
B-Tagged service interface. These service interfaces, for Provider Backbone
Bridges, are described next.
+-------------------------------+
| 802.1ah Bridge Model |
| |
+---+ | +------+ +-----------+ |
|CE |---------|I-Comp|------| | |
+---+ | | | | |--------
| +------+ | | |
| o | B-Comp | |
| o | |--------
| o | | |
+---+ | +------+ | | |
|CE |---------|I-Comp|------| |--------
+---+ ^ | | | ^ | | | ^
| | +------+ | +-----------+ | |
| +------------|------------------+ |
| | |
| | |
S-tagged I-tagged B-tagged
Service I/F Service I/F Service I/F
Figure 1: 802.1ah Bridge Model
3.1.
S-Tagged Service Interface
This service interface connects a customer 802.1ad Provider Bridge to an I-BEB or
IB-BEB. Three modes are supported:
i) Port Mode. In this mode, traffic on all S-VLANs is mapped to the same SID.
ii)S-Tag Mode. In this mode, traffic associated with each S-VLAN is mapped to a
single I-SID.
iii) S-Tag Bundling Mode. In this mode, traffic associated with a group
or range of S-VLANs is mapped to a single I-SID.
3.2.
I-Tagged Service Interface
This service interface connects an I-BEB to a B-BEB or it connects two B-BEBs
together. Although, in figure 1, this interface is shown as an internal interface
between I-component and B-component within an IB-BEB, in practice this service
interface is an external interface connecting a customer I-BEB with a provider B-
Sajassi, et al. [Page 6]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
BEB or connecting two different providers B-BEBs across different administrative
domains.
3.3.
B-Tagged Service Interface
This service interface connects a B-BEB or an IB-BEB with a provider Backbone Core
Bridge (BCB).
Having provided a brief primer on PBB in this section, next we discuss how PBB
technology can be used in the Ethernet access network for H-VPLS. This is captured
in section 4. Then, in section 5, we describe interoperability mechanisms for PBB
with H-VPLS using MPLS access.
4.
H-VPLS with PBB Access Network
At a macro scale, a network that employs H-VPLS with PBBN access can be
represented as shown in figure 2 below. However, careful examination of the
administrative relationships that govern each of the access network, the VPLS PE
and the IP/MPLS core reveals two discernable network topologies. The topologies
differ by the logical or administrative placement of the VPLS PE with respect to
the access and core networks. Furthermore, the topology classification has a
direct bearing on the type of service interface through which the PBBN connects to
the VPLS PE.
+--------------+
| |
+---------+ | IP/MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| | |VPLS| |VPLS| | |--| CE |
+----+ | PBBN |---| PE | | PE |--| PBBN | +----+
+----+ | 802.1ah | +----+ +----+ | 802.1ah | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 2: PBBN and VPLS Networks
In subsection 4.1, we describe the network topologies in detail, and in subsection
4.2 the service interface(s) associated with each topology is(are) defined.
At this point, it is important to define the notion of ‘administrative domains’ as
being used in the context of this discussion: Two (or more) networks are
considered to be in the same administrative domain when they share the same global
I-SID space and use the same I-SID value for a given service instance. It is
possible for each network within the same administrative domain to run independent
spanning tree instances and thus operate with different B-VLANs. On the other
hand, two (or more) networks are considered in different administrative domains if
they have different I-SID spaces (and different B-VLAN spaces). It is possible to
achieve correct service connectivity spanning networks belonging to different
administrative domains by employing I-SID (and B-VLAN) translations.
Sajassi, et al. [Page 7]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
4.1.
Network Topologies
Two network topology variants are identified. The details of these are discussed
in the following subsections.
4.1.1.
Topology Variant A
In this topology, the VPLS PE is administratively part of the access network. One
example of this topology is a service provider with 802.1ah access network
connecting to another provider over an MPLS network. Another example is the case
where two access networks of the same service provider are being connected over
its MPLS core. This topology is shown in figure 3 below.
|B-MAC| |B-MAC|
|B-VID| |B-VID|
|I-SID| |I-SID|
|CUST | |CUST |
|MAC | |MAC |
|FRAME| |FRAME|
|CUST | | |
|MAC | | |
|FRAME| | +---------+ |
| | | | |
| +------------|-------+| IP |+-------|------------+
v | PBB Access | || MPLS || | PBB Access |
| Network V || Core || V Network |
| +----+|| ||+----+ |
+--+ |+---+ +---+ |VPLS||| |||VPLS| +---+ +---+| +--+
|CE|-||BEB| |BCB|---| PE ||| ||| PE |---|BCB| |BEB||-|CE|
+--+ |+---+ +---+ ^ +----+|| ||+----+ ^ +---+ +---+| +--+
+------------|-------+| |+-------|------------+
| +---------+ |
| |
Type I & II Type I & II
Figure 3: Topology A -
- VPLS PE part of access network
Given that the VPLS PE is part of the access PBBN, it will be connected to a BCB
directly. In scenarios where the VPLS PEs are part of different administrative
domains, they will be required to perform functions that are the responsibility of
a B-type Backbone Edge Bridge (B-BEB): Basically B-VLAN and I-SID translations.
We note, here, that with this topology variant, the assumption is that a VPLS PE
will always be connected to a BCB and not to a BEB and thus shares the same
administrative domain with PBBN. The reason for that is straightforward: A BEB
demarks the edge of a PBBN. If a VPLS PE connects to a PBBN via a BEB then that PE
is logically outside the PBBN’s administrative boundaries.
Sajassi, et al. [Page 8]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
Two service interface types are applicable and associated with this topology
variant. These are Type I and Type II service interfaces discussed in sections
4.2.1 and 4.2.2 respectively.
4.1.2.
Topology Variant B
In this topology, the VPLS PE is administratively part of the core network. An
example of this topology is a service provider providing connectivity among
different independent 802.1ah networks over its MPLS core network. This is shown
in figure 4 below.
|B-MAC| |B-MAC|
|I-SID| |I-SID|
|CUST | |CUST |
|MAC | |MAC |
|CUST | |FRAME| |FRAME|
|MAC | | |
|FRAME| | +-------------------+ |
| | | | |
| +------------+ | | IP | | +------------+
| | PBB Access | V | MPLS | V | PBB Access |
V | Network | | Core | | Network |
| | |+----+ +----+| | |
+--+ |+---+ +---+| ||VPLS| |VPLS|| |+---+ +---+| +--+
|CE|-||BEB| |BEB||---|| PE | | PE ||---||BEB| |BEB||-|CE|
+--+ |+---+ +---+| ^ |+----+ +----+| ^ |+---+ +---+| +--+
+------------+ | | | | +------------+
| +-------------------+ |
| |
Type III Type III
Figure 4: Topology B -
- VPLS PE part of core network
The VPLS PE will connect to the PBBN via a BEB. This is the only connectivity
option for this topology variant. The rationale for that is as follows: If the PE
were to be connected to a BCB (as an alternative), the BCB does not have the
capability to perform B-VLAN or I-SID translation. As a matter of fact, it is an
802.1ad bridge that cannot even parse the 802.1ah frame beyond the B-VLAN. Hence,
the BCB cannot sit at the edge of an administrative domain. Which leads us to
conclude that the administrative domain boundary must be beyond the BCB - VPLS PE
interconnect and, therefore, this resolves back to topology variant A.
In the case where the MPLS and PBBN networks are not ubiquitously part of the same
administrative domain, the VPLS PE is required to perform the I-SID translation
functions of a BEB B-Component.
A single service interface, Type III, is associated with this topology variant. It
is described in details in section 4.2.3.
Sajassi, et al. [Page 9]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
4.2.
Service Interfaces & Interworking Options
Customer devices or networks will interface with PBBN edge bridges using existing
Ethernet interfaces including IEEE 802.1Q and IEEE 802.1ad. At the PBBN edge,
customer MAC frames are encapsulated in a PBBN header that includes a service
provider source and destination MAC addresses (B-MAC) and bridged up to the VPLS
PE. The PBBN-encapsulated customer MAC frame is then injected into the VPLS
backbone network, delivered to the remote VPLS PE node(s) and switched onto the
remote PBBN network. From there, the PBBN bridges the encapsulated frame to a PBBN
edge bridge where the PBBN header is removed and the customer frame is sent on its
way.
Interoperating between PBBN devices and VPLS PE nodes will certainly leverage work
already completed. When I-SID visibility is required at the VPLS PE nodes, new
service interfaces based on I-SID tag will need to be defined; as well as a new
pseudowire type to transport certain types of PBBN-encapsulated frames across a
pseudowire. The use of the B-MAC address space will ease the provider’s
provisioning tasks and better scale the overall system for the simple reason that
MAC processing is based on the provider’s backbone MAC addressing space, not the
many customer MAC addresses serviced. Furthermore, the larger I-SID space (24-
bits) defined in 802.1ah, compared to the 12-bit VID space defined in
802.1ad/802.1Q, scales the number of service instance identifiers available to a
single access network by many orders of magnitude. Instead of being limited to
4094 service instances per access network, the service provider can now, in
theory, accommodate 2^24 service instances. Of course, physical device limitations
(in terms of memory and processing power) will be reached before this identifier
space is exhausted. Moreover, by mapping a B-VLAN to a VPLS instance, and bundling
multiple end-customer service instances over the same B-VLAN, service providers
will be able to significantly reduce the number of full-mesh pseudowires required
in the core. In this case, I-SID visibility is not required on the VPLS-PE and the
I-SID will serve as the means of multiplexing/de-multiplexing individual service
instances in the PBBN over a bundle (B-VLAN). Thus, instead of maintaining a full
mesh of pseudowires per individual service instance, it is possible to maintain a
full mesh per group or collection of service instances. In addition, the scaling
advantages of H-VPLS including reduced pseudowire signaling overhead remain in
effect.
When I-SID visibility is expected across the service interface at the VPLS PE,
VPLS PE can be considered to offer service-level interworking between PBBN and
MPLS domain. Similarly, when PE is not expected to have visibility of I-SID at the
service interface, VPLS PE can be considered to offer network-level interworking
between PBBN and MPLS domain.
PBBN-VPLS service interfaces may differ depending on the topology variants
identified earlier. The following sub-sections describe the different PBBN -
- VPLS
service interfaces and their expected behavior.
4.2.1.
PBBN-VPLS Type I Service Interface
Sajassi, et al. [Page 10]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
This is B-tagged service interface with B-VID as the service delimiter. This
service interface is applicable to Topology Variant A only. It connects a PBBN
backbone core bridge (BCB) to a VPLS PE and is illustrated in figure 3. The VPLS
PE is administratively part of the access network, which means it shares the same
I-SID and B-VID space as its PBBN access network.
The BCB and VPLS PE will exchange PBBN encapsulated frames that include source and
destination B-MAC addresses, a B-VID and I-SID. The service delimiter, from the
perspective of the VPLS PE, is the B-VID; in fact, this interface operates exactly
as a current 802.1Q interface into a VPLS PE does today. With Type I service
interface, VPLS PE can be considered as providing network-level interworking
between PBBN and MPLS domains, since VPLS PE does not have visibility of I-SIDs.
The main advantage of this service interface, when compared to other types, is
that it allows the service provider to save on the number of full-mesh pseudowires
required in the core. This is primarily because multiple service instances (I-
SIDs) are bundled over a single full-mesh, instead of requiring a dedicated full-
mesh per service instance. The disadvantage of this interface, on the other hand,
is the comparably excessive replication required in the core: Since a group of
service instances share the same full-mesh of pseudowires, an unknown unicast,
multicast or broadcast on a single service instance will result in a flood over
the core.
4.2.1.1. O
perational Modes
There are three modes supported by this service interface:
4.2.1.1.1 Port Mode
In this mode, all Ethernet traffic arriving on an Ethernet port is mapped into a
single VPLS instance N. Another name for this is unqualified mode.
4.2.1.1.2 VLAN Mode
In this mode, all traffic associated with a particular VLAN identified by the B-
VID is mapped to a single VPLS instance N. This is known as qualified mode.
4.2.1.1.3 VLAN-bundle Mode
In this mode, all traffic associated with a group or range of VLANs or B-VIDs are
mapped to a single VPLS instance N.
In theory, any VPLS PE supporting VLAN or Port Mode interfaces should be able to
to support PBBN-VPLS Type I service interfaces. Indeed the fact that the PBBN
frame is transporting an encapsulated customer MAC frame is completely transparent
to the VPLS PE.
The forwarding table for a particular VPLS instance is built using the procedures
described in [RFC4762]. We note, however, that forwarding and learning is
performed based on B-MAC addresses and not customer addresses as is the case with
Sajassi, et al. [Page 11]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
[RFC4762]. We also observe that the use of B-MAC address space can lead to a
reduction in the size of the MAC tables maintained on the PE. This is accomplished
by encapsulating a larger pool of customer MAC addresses inside a smaller set of
provider MAC addresses (B-MACs). This is effectively a form of hierarchical MAC
address summarization where the mapping between customer MACs and provider B-MACs
is maintained at the backbone edge bridges directly connected to customer devices.
4.2.1.2.
Pseudowire Requirements
Existing pseudowire signaling and encapsulation modes defined in
[RFC4447][RFC4448] can be applied to PBBN frames sent and received over the type I
service interface. Ethernet raw mode (0x0005) and VLAN tagged mode (0x0004)
pseudowire types are supported for this service interface just like current VPLS.
4.2.2.
PBBN-VPLS Type II Service Interface
This is B-tagged service interface with I-SID as service delimiter. Similar to the
type I service interface, as shown in figure 3, this service interface is
applicable to Topology Variant A only. It connects a PBBN backbone core bridge
(BCB) to a VPLS PE which is administratively part of the access network. The BCB
and VPLS PE will exchange PBBN encapsulated frames that include source and
destination B-MAC addresses, a B-VID and I-SID. What distinguishes this from type
I service interface is the fact that the VPLS PE interprets I-SID as service
delimiters (rather than B-VID). With Type II service interface, VPLS PE provides
service-level interworking between PBBN and MPLS domains, since VPLS PE has
visibility of I-SIDs.
The disadvantage of this service interface, compared to type I, is that it may
require a larger number of full-mesh pseudowires in the core. On the other hand,
the advantage that this interface type has compared to type I is the potentially
less replication in the core. This is mainly due to the increased segregation of
service instances over disjoint full-meshes of pseudowires. It is expected that
this interface type to be used for customers with significant multicast traffic so
that a separate VPLS instance is setup per customer (per I-SID instance). It
should be noted that a VPLS PE may support both type I & II service interface
types over the same physical interface.
4.2.2.1.
Operational Modes
There are two modes supported by this service interface:
4.2.2.1.1 I-SID Mode
In this mode, all traffic associated with a particular I-SID value is mapped to a
single VPLS instance N.
4.2.2.1.2 I-SID Bundle Mode
All traffic associated with a group or range of I-SID values are mapped to a
single VPLS instance N.
Sajassi, et al. [Page 12]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
The forwarding table requirements for this service interface are similar to those
of type I service interface described earlier. We note that for I-SID and I-SID
bundle modes, the larger I-SID space vis-à-vis the VLAN ID or B-VID enables the
provider to potentially create a much larger set of VPLS instances.
4.2.2.2.
Pseudowire Requirements
It was noted earlier that with this interface type, I-SIDs are interpreted by the
VPLS PE as service delimiters: Basically, for frames ingress from the PBBN, the I-
SID is used to uniquely identify a VPLS instance on the PE and to uniquely
identify the full-mesh of Pseudowires. Note that the fact that the I-SID space is
global across B-VLANs makes it unnecessary to utilize (B-VID, I-SID) tuple as the
VPLS instance identifier. It should be noted that, from the perspective of
Pseudowires, the B-VID is considered to be the service delimiter while the I-SID
is treated as part of the Ethernet payload. However, from the perspective of the
PE, the I-SID is the actual service delimiter. This interpretation of I-SID and B-
VID in the PE, makes it possible to reuse existing pseudowire types and only
define a new type when absolutely required.
4.2.2.2.1 I-SID Mode Requirements
In I-SID mode, each I-SID uniquely maps to a single VPLS instance. The B-VIDs are
locally significant to a given PBBN access network; hence, they need not be
transported in the pseudowire over the core. For this mode, two cases are to be
considered:
i) Access and core networks belong to the same administrative domain. In this
case, I-SID translation is not required, and therefore existing pseudowire
types can be used. In Ethernet raw mode (0x0005), the B-VLAN is removed by
the VPLS PE on ingress to the pseudowire and added by the egress VPLS PE(s).
In Ethernet tagged mode (0x0004), the B-VLAN is passed along by the ingress
VPLS PE and rewritten by the egress VPLS PE(s), per normal tagged mode
operation.
ii)Access and core networks belong to different administrative domains. In this
scenario, I-SID translation is required. To accommodate this, a new
pseudowire type is defined that performs the following two functions on
frames that exit the pseudowire: (1) translate the I-SID of the frames to
the local I-SID value based on the associated service instance. And (2) add
a B-VLAN to the frames based on the associated service instance. This scheme
obviates the need to maintain an I-SID translation table per pseudowire as
along as there is a single I-SID per pseudowire. We note here that
performing I-SID translation at the egress point of the pseudowire is the
only viable option if a single I-SID translation is to be performed in a
given flow direction: It is not possible to perform the translation at the
attachment circuit on the ingress VPLS PE simply because the translation is
dependent on the destination network. Furthermore, it is not possible to
perform the translation at the attachment circuit of the egress VPLS PE
because the received I-SID can only be interpreted in the context of the
pseudowire on which it was received.
4.2.2.2.2 I-SID Bundle Mode Requirements
Sajassi, et al. [Page 13]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
In I-SID bundle mode, a group or range of I-SIDs map to a single VPLS instance.
Again here, two cases are distinguished depending on whether the access and core
networks lie within or across administrative domain boundaries:
i) Access and core networks belong to the same administrative domain. In this
case, I-SID translation is not required and I-SID bundling can be achieved
via grouping I-SIDs within a B-VLAN and associating a VPLS instance with
that B-VLAN. The pseudowire requirements for this scenario are similar to
type I service interface.
ii)Access and core networks belong to different administrative domains. Since
I-SID translation is required in this case, bundling of I-SIDs over a single
pseudowire mandates the use of a per-pseudowire I-SID translation table. The
overhead associated with this approach is considerable; therefore, we shall
not consider it any further.
4.2.3.
PBBN-VPLS Type III Service Interface
This is simply I-tagged service interface with I-SID as service delimiter. This
service interface applies to Topology Variant B only. It connects a PBBN B-type
backbone edge bridge (B-BEB) to a VPLS PE and is illustrated in figure 4. The VPLS
PE is administratively part of the core network. By definition the B-BEB will
remove any B-VLAN tags for frames exiting the PBBN domain because it is local to
that domain. So what is exchanged between the B-BEB and VPLS PE are PBBN-
encapsulated frames composed of source and destination B-MAC addresses and an I-
SID. The service delimiter, as observed by the VPLS PE, in this case is the I-SID.
This interface mode shares the same set of advantages and disadvantages as type II
service interface.
4.2.3.1.
Operational Modes
There are three modes supported by this service interface:
4.2.3.1.1 Port Mode
In this mode, all Ethernet traffic arriving on an Ethernet port is mapped into a
single VPLS instance N. This exhibits the same behavior as a port mode type I
service interface described earlier. In this mode, VPLS PE provides network-level
interworking between PBBN and MPLS domains, since VPLS PE does not require
visibility of I-SIDs. If I-SID visibility is required for the purpose of I-SID
translation across different administrative domains, then it will be covered under
I-SID bundling mode as all-to-one bundling.
4.2.3.1.2 I-SID Mode
In this mode, all traffic associated with a particular I-SID value is mapped to a
single VPLS instance N. In this mode, VPLS PE provides service-level interworking
between PBBN and MPLS domains, since VPLS PE requires visibility of I-SIDs.
4.2.3.1.3 I-SID Bundle Mode
In this mode, all traffic associated with a group or range of I-SID values are
mapped to a single VPLS instance N. In this mode, VPLS PE provides service-level
interworking between PBBN and MPLS domains, since VPLS PE requires visibility of
I-SIDs.
Sajassi, et al. [Page 14]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
4.2.3.2.
Pseudowire Requirements
The pseudowire type signaled depends on the services configured across the type
III service interface.
4.2.3.2.1 Port Mode Requirements
Port Mode can re-use the existing raw mode pseudowire type (0x0005) as is; so
nothing new is needed here. VLAN tagged mode (0x0004) might also be used but with
B-VID as the service delimiter, from the VPLS PE perspective. We note that in
either case, the frame appearing on the wire between the PE and B-BEB will not
contain a B-VID value. If both the access and core networks are under the same
administrative domain, then I-SID consistency across the various networks
eliminates any need for visibility or processing by the PEs of the I-SID values.
If, on the other hand, the access and core networks fall into disparate
administrative domains, then I-SID translation should be performed at the
attachment circuits of the VPLS PEs (the Customer Backbone Ports connecting the
VPLS PEs to the B-BEBs). As such, the PE is required to have B-Component
functionality for I-SID remapping. Note that, even in this case, the I-SIDs
continue to pass transparently over the pseudowire, and the existing pseudowire
modes (raw and tagged) are applicable.
4.2.3.2.2 I-SID Mode Requirement
In the case of I-SID mode where traffic belonging to a particular I-SID is mapped
to a single VPLS instance, two scenarios are observed:
i) Access and core networks fall under the same administrative domain; hence,
I-SID translation is not needed. The existing Ethernet raw (0x0005) or
tagged (0x0004) mode can be used in this case. If raw mode is used, the I-
SIDs are passed transparently over the pseudowire. If tagged mode is used,
the ingress PE should append a local B-VID that may correspond to the I-SID.
This B-VID is removed by the egress PE. We note here that even though tagged
or raw mode pseudowire operation is based on the B-VLAN, the VPLS instance
and associated full-mesh of pseudowires corresponds to a unique I-SID.
ii)Access and core networks correspond to different administrative domains;
hence, it is required to perform I-SID translation. In this scenario, the
translation should be performed at the attachment circuits of the VPLS PEs
(the Customer Backbone Ports connecting the VPLS PEs to the B-BEBs). This
translation is symmetric, in a sense that it applies to both ingress and
egress frames. As such, no I-SID translation is required on egress from the
pseudowire. We note that this scheme has two advantages: (1) The existing
Ethernet raw and tagged pseudowire modes can be employed, with the
procedures described in the previous scenario; and (2) a single VPLS PE will
be capable of supporting multiple access network domains.
4.2.3.2.3 I-SID Bundle Mode Requirements
In the case of I-SID bundling mode where a range or group of I-SID values are
mapped to a single VPLS instance, the PE maintains a local mapping of each I-SID
group or range to a single B-VID. The VPLS instance, with associated full mesh of
pseudowires, is then associated with that B-VID. For this mode, no new pseudowire
Sajassi, et al. [Page 15]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
type is required. There’s a choice of using either the Ethernet raw or tagged
mode. If raw mode is used, the local B-VIDs are not carried over the pseudowires
and the I-SIDs pass transparently. If tagged mode is employed, then the ingress PE
appends its local B-VID that corresponds to the group or range of I-SIDs, and the
egress PE remaps it to its local value. Note that the egress PE will send frames
towards the B-BEB without the local B-VID. We observe two scenarios here:
i) Access and core networks are under the same administrative domain. In this
case, the I-SID is ubiquitous and passes transparently end to end.
ii)Access and core networks belong to different administrative domains. In this
scenario, it is assumed that the core network is one administrative domain
and uses a single I-SID space. For purpose of maintaining consistency with
IEEE 802.1ah, the I-SID translation should be performed on the attachment
circuit of the VPLS PE for traffic ingress onto the core network; and, on
the B-BEB port that connects to the VPLS PE for traffic ingress onto the
access network.
This mode assumes that bundling is homogeneous between the ingress and egress VPLS
PEs. In other words, I-SIDs are divided along the same bundle boundaries. For the
case where non-homogeneous bundling is required, and I-SIDs are to be mapped to
different B-VLANs on different PEs, then I-SID mode should be chosen over I-SID
bundling mode, for it provides maximum flexibility.
This concludes the discussion of PBB in H-VPLS with Ethernet access. In the next
section, we will shift focus to look into how PBB technology interoperates with H-
VPLS in the case of MPLS access network.
5.
H-VPLS with MPLS Access Network
In the previous section, we described various interoperability scenarios for H-
VPLS with PBBN as Ethernet access network. We now shift focus to the case where
the access network is MPLS and U-PE nodes support PBB function. The objective for
incorporating PBB function at the U-PE is to improve the scalability of H-VPLS
networks in terms of the numbers of MAC addresses and service instances that are
supported.
In current H-VPLS, the N-PE must learn customer MAC addresses (C-MACs) of all VPLS
instances that it participates in. This can easily add-up to hundreds of thousands
or even millions of C-MACs at the N-PE. When the U-PE performs 802.1ah
encapsulation, the N-PE only needs to learn the MAC addresses of the U-PEs, which
is a significant reduction. Furthermore, when 802.1ah encapsulation is used, many
I-SIDs are multiplexed within a single B-VLAN. If the VPLS instance is set up per
B-VLAN (instead of per I-SID), then one can also achieve a significant reduction
in the number of pseudowires. It should be noted that this reduction in
pseudowires comes at the cost of potentially increased replication over the
pseudowire full-mesh: A given customer multicast and/or broadcast frames are
effectively broadcasted within the B-VLAN. This may result in additional frame
replication because the full-mesh of pseudowires corresponding to a B-VLAN is most
likely bigger than the full-mesh of pseudowires corresponding to a single I-SID.
Sajassi, et al. [Page 16]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
However, if one supports VPLS multicast data via MPLS P2MP tunnels, then this
drawback goes away.
Figure 5 below illustrates the scenario for H-VPLS with MPLS access. As it can be
seen, customer networks or hosts (CE) connect into the U-PE nodes using standard
Ethernet interfaces [802.1D], [802.1Q], or [802.1ad]. The U-PE is connected
upstream to one or more VPLS N-PE nodes by MPLS pseudowires (per VPLS instance).
These, in turn, are connected via a full-mesh of pseudowires (per VPLS instance)
traversing the IP/MPLS backbone. The U-PE is outfitted with PBB BEB functions
where it can encapsulate/ decapsulate customer MAC frames in provider B-MAC
addresses and perform I-SID translation if needed.
PBB PBB
BEB +----------+ BEB
| | | |
| +-----------+ | IP | +-----------+ |
| | MPLS | | MPLS | | MPLS | |
V | Access +----+ | Core | +----+ Access | V
+--+ +----+ |VPLS|-| |-|VPLS| +----+ +--+
|CE|--|U-PE| |N-PE| | | | PE | |U-PE|--|CE|
+--+ +----+ +----+ | | +----+ +----+ +--+
| | | | | |
+-----------+ +----------+ +-----------+
Figure 5: H-VPLS with MPLS Access Network and PBBN U-PE
We also note that the U-PE and N-PE are members of the same administrative domain.
However, different MPLS access networks can be part of the same or separate
administrative domains. We will describe both cases shortly.
5.1.
Supported Services
The U-PE still provides the same type of services toward its customers as before
and they are:
i) Port mode (either 802.1D, 802.1Q, or 802.1ad)
ii)VLAN mode (either 802.1Q or 802.1ad)
iii) VLAN-bundling mode (either 802.1Q or 802.1ad)
By incorporating PBB function, the U-PE maps each of these services (for a given
customer) onto a single I-SID based on the configuration at the U-PE. Many I-SIDs
are multiplexed within a single B-VLAN. The U-PE can, then, either map a single I-
SID into a VPLS instance or it can map a B-VLAN onto a VPLS instance, according to
its configuration. Next, the encapsulated frames are sent over the pseudowire
associated with that VPLS instance.
If the B-VID is used as the service delimiter, then the entire Ethernet bridging
operation over VPLS network is performed as defined in [RFC4762]. In other words,
MAC forwarding is based on the B-MAC address space and service delimiter is based
Sajassi, et al. [Page 17]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
on VLAN ID, which is B-VID in this case. There is no need to inspect or deal with
I-SID values.
If the I-SID is used as the service delimiter, then the single and multiple domain
cases must be considered as described in the following sections. This is primarily
because I-SID values are assigned on a per-domain basis.
In summary, the ingress U-PE receives a customer MAC frame. It imposes the
appropriate PBB header information and then performs standard bridge-capable U-PE
processing functions, including switching the frame locally or forwarding it to
the N-PE. The egress U-PE will remove the pseudowire label, perform any relevant
processing of the PBB header (e.g. I-SID translation if required) and then hand
the frame to the PBB bridge component for 802.1ah processing.
5.2.
U-PE Operation in a Single Domain
In this scenario, I-SID assignment is performed globally across all MPLS access
networks. Thus there is no need to perform any sort of I-SID translation at the U-
PE.
The pseudowire type established between the U-PE and N-PE can be raw or tagged
mode with the corresponding B-VID rewrite or translation performed at the various
PE nodes.
5.3.
U-PE Operation in Multiple Domains
In this scenario, I-SID assignment is performed on a per-MPLS access network
basis. The U-PE nodes are the only nodes that are I-SID aware; so, it will be up
to them to perform the translation as frames are forwarded between different
administrative domains.
At the ingress U-PE, during the PBBN encapsulation process, an I-SID value is
added. A new pseudowire type (described in section 3.2.2.2.2) will be required to
transport I-SID tagged payloads between the U-PE and N-PE. The one-to-one mapping
between this I-SID value and the pseudowire enables the receiving N-PE and U-PE to
infer which VPLS instance the frame belongs to.
When the encapsulated PBBN frames reach the egress U-PE, the pseudowire label is
removed and then the appropriate I-SID translation is performed. In this case, it
is taking the I-SID originally assigned and imposed by the U-PE nodes (in MPLS
access network #1) and translating it to the I-SID value assigned to MPLS access
network #2. Once this is completed, the frame is handed off to the PBBN BEB for
normal processing.
5.4.
Pseudowire Requirements
This section summarizes the pseudowire requirements that were identified in the
three previous sub-sections. To recap, these requirements differ depending on
Sajassi, et al. [Page 18]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
whether the U-PE uses the B-VID or I-SID as a service delimiter; and, in the
latter case, the requirements can be further distinguished based on whether the
network comprises of a single or multiple administrative domains. These scenarios
are described next.
5.4.1.
Requirements with B-VID as Service Delimiter
In this scenario, existing pseudowire raw and tagged modes can be used. There are
no new requirements.
5.4.2.
Requirements with I-SID as Service Delimiter
In this case, the requirements differ depending on whether the network comprises
of a single or multiple administrative domains. The details of each are described
in the following subsections.
5.4.2.1.
Single Administrative Domain Network
In this case, I-SID translation is not required. Therefore, existing pseudowire
raw and tagged modes can be used. There are no new requirements for this case.
5.4.2.2.
Multiple Administrative Domain Network
In this scenario, I-SID translation is required. Therefore, the pseudowire
requirements are similar to those identified in section 3.2.2.2.2.
6.
Acknowledgments
7.
Security Considerations
There are no additional security aspects beyond that of VPLS/H-VPLS that needs to
be discussed here.
8.
Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
9.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
Sajassi, et al. [Page 19]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF
TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
10.
IPR Notice
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11.
Normative References
[RFC4762] Lasserre, M. and et al, ‘‘Virtual Private LAN Service (VPLS) Using Label
Distribution Protocol (LDP) Signaling’’, Proposed Standard, January
2007.
[RFC4447] Martini, L. and et al, ‘‘Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)’’, Proposed Standard, April 2006.
[RFC4448] Martini, L. and et al, ‘‘Encapsulation Methods for Transport of Ethernet
over MPLS Networks’’, Proposed Standard, April 2006.
[RFC4665] Agustyn, W. et al, "Service Requirements for Layer-2 Provider
Provisioned Virtual Provider Networks", Proposed Standard, September
2006.
Sajassi, et al. [Page 20]
draft-sajassi-l2vpn-vpls-pbb-interop-00.txt March 2007
[RFC4664] Andersson, L. and et al, "Framework for Layer 2 Virtual Private Networks
(L2VPNs)", Proposed Standard, September 2006.
[P802.1ad] IEEE Draft P802.1ad/D2.4 ‘‘Virtual Bridged Local Area Networks: Provider
Bridges’’, Work in progress, September 2004
[P802.1ag] IEEE Draft P802.1ag/D0.1 ‘‘Virtual Bridge Local Area Networks:
Connectivity Fault Management’’, Work in Progress, October 2004
12.
Informative References
[802.1D-REV] IEEE Std. 802.1D-2003 ‘‘Media Access Control (MAC) Bridges’’.
[802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area Networks".
13.
Authors' Addresses
Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1
Email: ssalam@cisco.com
Chris Metz
Cisco
170 West Tasman Drive
San Jose, CA 95134
Email: metz@cisco.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Dinesh Mohan
Nortel Networks
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Sajassi, et al. [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 00:21:36 |