Internet Working Group Ali Sajassi
Internet Draft Samer Salam
Chris Metz
Cisco
Nabil Bitar
Verizon
Dinesh Mohan
Nortel
Expires: February 2008 July 2007
VPLS Interoperability with Provider Backbone Bridges
draft-sajassi-l2vpn-vpls-pbb-interop-01.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-
Sajassi, et. al. [Page 1]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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.
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.....................................................3
2. Overview........................................................4
3. Background: Provider Backbone Bridges...........................5
3.1. S-Tagged Service Interface....................................7
3.2. I-Tagged Service Interface....................................8
3.3. B-Tagged Service Interface....................................8
4. H-VPLS with PBB Access Network..................................8
4.1. Network Topologies............................................9
4.1.1. Topology Variant A..........................................9
4.1.2. Topology Variant B.........................................10
4.2. Service Interfaces & Interworking Options....................11
4.2.1. PBBN-VPLS Type I Service Interface.........................12
4.2.2. PBBN-VPLS Type II Service Interface........................14
4.2.3. PBBN-VPLS Type III Service Interface.......................16
5. H-VPLS with mixed Q-in-Q and PBB Access Networks...............19
5.1. Supported Services...........................................20
5.1.1. Single Administrative Domain Operation.....................21
5.1.2. Multiple Administrative Domains Operation..................21
5.2. Pseudowire Requirements......................................22
5.2.1. Requirements with B-VID as Service Delimiter...............22
5.2.2. Requirements with I-SID as Service Delimiter...............22
6. H-VPLS with MPLS Access Network................................22
6.1. Supported Services...........................................23
6.2. U-PE Operation in a Single Domain............................24
6.3. U-PE Operation in Multiple Domains...........................24
6.4. Pseudowire Requirements......................................25
6.4.1. Requirements with B-VID as Service Delimiter...............25
6.4.2. Requirements with I-SID as Service Delimiter...............25
7. Security Considerations........................................25
8. Intellectual Property Considerations...........................25
Sajassi, et al. [Page 2]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
9. Full Copyright Statement.......................................25
10. IPR Notice....................................................26
11. Normative References..........................................26
12. Informative References........................................27
13. Authors' Addresses............................................27
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
B-MAC: The backbone source or 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
Sajassi, et al. [Page 3]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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 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
Sajassi, et al. [Page 4]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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. These issues
are also highlighted in the [VPLS-Bridge].
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 service 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 Q-in-Q access
network respectively. Section 5 discusses PBB interoperability for
H-VPLS with MPLS access network.
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. 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
Sajassi, et al. [Page 5]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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
Sajassi, et al. [Page 6]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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. 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 I-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.
Sajassi, et al. [Page 7]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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-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 sections 4 and 5. Then, in
section 6, 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.
Sajassi, et al. [Page 8]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
At this point, it is important to define the notion of 'service
domains' as being used in the context of this discussion: Two (or
more) networks are considered to be in the same service 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 service 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 service 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 service domains by employing I-SID (and B-
VLAN) translations.
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
Sajassi, et al. [Page 9]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
Given that the VPLS PE is part of the access PBBN, it will be
connected to a BCB directly. In scenarios where different 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.
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 MPLS
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 MPLS core network
Sajassi, et al. [Page 10]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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 service 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.
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
Sajassi, et al. [Page 11]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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
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, though it is transparent to I-
SID.
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. As such, Type I service interface is only
applicable for the scenario where the access and MPLS core networks
all belong to the same service domain. If those networks were to
belong to multiple domains, then I-SID translation becomes mandatory
and the VPLS PE is required to have I-SID level visibility.
One of 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. Another advantage is the MAC address
scalability in the core since the core is not exposed to C-MACs. The
disadvantage of this interface, on the other hand, is the comparably
Sajassi, et al. [Page 12]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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. This, however, can be mitigated via
the use of P2MP LSP [VPLS-MCAST] for VPLS multicast/broadcast
traffic.
4.2.1.1. Operational 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.
It is assumed that the assignment of B-VLANs is ubiquitous across
the network for both port and vlan bundling modes of operation.
In theory, any VPLS PE supporting VLAN or Port Mode interfaces
should be able 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 [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
Sajassi, et al. [Page 13]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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. However, the number of full-mesh psuedowires can still be less
than those required by H-VPLS without PBBN. 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 set up 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: I-SID and
I-SID bundle. We note that Port mode for Type II interface is, in
practice, indiscernible from Port mode for Type I interface. As
such, it is not considered as a stand-alone mode of operation for
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
Sajassi, et al. [Page 14]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
All traffic associated with a group or range of I-SID values are
mapped to a single VPLS instance N.
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.
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.
A new pseudowire type is used for the I-SID mode where the I-tagged
frame (802.1ah frame without a B-VID) is transported over the
pseudowire and the I-SID is used as a service delimiter. This
pseudowire mode is analogous to tagged mode except the fact that I-
SID instead of 802.1Q VLAN-ID is used as service delimiter. This new
pseudowire type is defined in [PBB-PW]. It should be noted that the
addition of B-VLAN tag (B-Tag) to an I-tagged frame is considered a
local function and it may or may not be required. If it is required,
then the PE is configured so that it adds a B-tag to the frame
received over the pseudowire.
For this mode, two cases are to be considered:
i) Access and MPLS core networks belong to the same service
domain. In this case, I-SID translation is not required, and
therefore I-SID translation need not be performed on the I-
tagged frames received over the pseudowire at the egress PE.
ii) Access and MPLS core networks belong to different service
domains. In this scenario, I-SID translation is required.
Therefore, the egress PE should rewrite the I-SID value of an
I-tagged frame, received over the pseudowire, with a locally
configured I-SID value. In order to simplify the new pseudowire
operation and avoid any unnecessary negotiation, the I-SID
rewrite MUST always be performed at the egress PE.
4.2.2.2.2 I-SID Bundle Mode Requirements
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
Sajassi, et al. [Page 15]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
whether the access and core networks lie within or across service
domain boundaries:
i) Access and core networks belong to the same service 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 service 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 MPLS 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 service domains, then it will be
covered under I-SID bundling mode as all-to-one bundling.
Sajassi, et al. [Page 16]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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.
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) can
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 service 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 service domains, then I-SID translation is necessary, and
I-SID all-to-one bundling mode should be used instead.
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 service domain;
hence, I-SID translation is not needed. In this scenario the
new pseudowire type per section 4.2.2.2.1 is used but without
the need for any I-SID rewrite at the egress PE.
ii) Access and core networks correspond to different service
domains; hence, it is required to perform I-SID translation. In
this scenario, the translation is performed at the Attachment
Circuits of the VPLS PEs or at the Customer Backbone Ports of
Sajassi, et al. [Page 17]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
the B-BEBs (the interfaces that connect the B-BEBs to the VPLS
PEs). This translation is symmetric, in a sense that it applies
to both ingress and egress frames. In this scenario, the new
pseudowire type per section 4.2.2.2.1 is also used. Note that
there is no need for any I-SID rewrite at the egress of the
pseudowire because I-SID translation is performed at the
Attachment Circuits or at the Customer Backbone Ports. We note
that this scheme has the advantage of allowing a single VPLS PE
to support multiple access network domains. If, for a given
VPLS instance, the VPLS PE only needs to interface to a single
PBBN service domain, then I-SID translation can be performed at
the egress of the pseudowire and, thus, the requirement for I-
SID translation table at the Attachment Circuit (or Customer
Backbone Port) can be lifted.
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 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 MPLS core networks are under the same service
domain. In this case, the I-SID is ubiquitous and passes
transparently end to end.
ii) Access and MPLS core networks belong to different service
domains. In this scenario, it is assumed that the MPLS core
network is one service domain and uses a single I-SID space.
The I-SID translation should be performed either on the
Attachment Circuit of the VPLS PE or on the Customer Backbone
Port of the B-BEB (the port that connects to the VPLS PE). In
either case, the translation must be symmetric, i.e. applied to
both ingress and egress frames.
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
Sajassi, et al. [Page 18]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
different PEs, then I-SID mode should be chosen over I-SID bundling
mode, for it provides maximum flexibility.
In the next section, we will look into another flavor of H-VPLS with
Ethernet access networks where at least one of the access networks
employs Provider Bridges (Q-in-Q or IEEE 802.1ad) whereas the others
are PBBNs.
5. H-VPLS with mixed Q-in-Q and PBB Access Networks
It is foreseeable that service providers will want to interoperate
their existing Q-in-Q access networks with PBBNs over VPLS. Figure 5
below shows the high-level network topology.
+--------------+
| |
+---------+ | IP/MPLS | +---------+
+----+ | | +----+ +----+ | | +----+
| CE |--| | |VPLS| |VPLS| | |--| CE |
+----+ | Q-in-Q |---| PE1| | PE2|--| PBBN | +----+
+----+ | 802.1ad | +----+ +----+ | 802.1ah | +----+
| CE |--| | | Backbone | | |--| CE |
+----+ +---------+ +--------------+ +---------+ +----+
Figure 5: H-VPLS with Mixed Q-in-Q and PBB Access Networks
Referring to the figure above, the operation of VPLS PE2 (connecting
to the PBB access network on the right) is no different from what
was discussed in section 4 above. It is the behavior of VPLS PE1
(connecting to the Q-in-Q access network on the left) that is the
subject and focus of this section. The specifics of the PE behavior
differ depending on whether the Q-in-Q access network is a stand-
alone service domain which is different from the MPLS network, or
whether the entire network is a single service domain. In either
case, we will only explore the scenario where the VPLS PE is
administratively part of the Q-in-Q access network. The case where
the VPLS PE is administratively not part of the Q-in-Q access
network will not be studied at this point as it is not common or
expected to be desirable by service providers. Figure 6 below shows
a more detailed network diagram, with associated frame formats.
Sajassi, et al. [Page 19]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
|C-MAC| |B-MAC|
|S-VID| |B-VID|
|C-VID| |I-SID|
|CUST | |CUST |
|DATA | |MAC |
|C-MAC| | | |FRAME|
|C-VID| | |
|CUST | | |
|DATA | | +---------+ |
| | | | |
| +------------|-------+| IP |+-------|------------+
v | Q-in-Q | || MPLS || | PBB Access |
| Access V || Core || V Network |
| Network +----+|| ||+----+ |
+--+ |+---+ +---+ |VPLS||| |||VPLS| +---+ +---+| +--+
|CE|-||PEB| |PCB|---| PE1||| ||| PE2|---|BCB| |BEB||-|CE|
+--+ |+---+ +---+ +----+|| ||+----+ ^ +---+ +---+| +--+
+--------------------+| |+-------|------------+
+---------+ |
|
Type I & II
Figure 6: VPLS PE part of Q-in-Q access network
In section 5.1, we describe the services supported by the VPLS PE,
and in section 5.2, we discuss the pseudowire requirements.
5.1. Supported Services
The VPLS PE offers an S-Tagged interface that can operate in one of
three modes:
i) Port Mode. In this mode, all frames ingress on the port are
mapped to the same I-SID.
ii) VLAN Mode. In this mode, every S-Tag is mapped to its own I-
SID.
iii) VLAN Bundling Mode. In this mode, a range or list of S-Tags are
mapped to a single I-SID.
Sajassi, et al. [Page 20]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
After performing the S-Tag to I-SID mapping, per one of the modes
above, the I-SIDs are multiplexed within a B-Tag. The PE, then, has
the option of either mapping a B-Tag to a VPLS instance or each I-
SID to a VPLS instance.
Note that depending on whether or not the entire network is a single
service domain, some of the above modes may not be applicable. We
will explore this in the following sub-sections.
5.1.1. Single Service Domain Operation
When the entire network comprises of a single service domain, all
three interface modes described above are applicable, namely: port
mode, vlan mode and vlan bundling mode.
In port mode of operation, the ingress PE retains the S-Tag on the
frames and adds a per-port I-SID. The PE, then, multiplexes the I-
SID over a B-Tag and either maps the B-Tag to a VPLS instance per
section 4.2.1, or maps the I-SID to a VPLS instance per the
procedures discussed in section 4.2.2. Note that the S-Tag is
retained on the frame to allow for proper de-multiplexing on the
egress PE.
In vlan mode of operation, the ingress PE translates the S-Tag on
the frame to a unique I-SID. The S-Tag is removed from the frame
when passed over the pseudowire, as it conveys no extra information.
The PE multiplexes the I-SID over a B-tag and then maps either the
B-Tag or the I-SID to a VPLS instance per the procedures of sections
4.2.1 and 4.2.2 respectively.
In vlan bundling mode of operation, the ingress PE bundles a range
or list of S-Tags over a single I-SID. The S-Tag is retained on the
frame to allow for de-multiplexing on the egress PE. The mapping of
B-Tag or I-SID to VPLS instance is similar to the previous two
modes.
5.1.2. Multiple Service Domains Operation
In this scenario, VPLS PE1 is in a different service domain than
VPLS PE2. Therefore, I-SID translation needs to be performed between
the two domains. In order to achieve this translation easily, a one-
to-one mapping between I-SID and VPLS instance is used as described
in section 4.2.2.2.1 case ii. If aggregation of I-SIDs inside a
single VPLS instance is required, then that would mandate the need
for an I-SID translation table for each pseudowire which is not
considered here because of its added complexity.
We note that if the Q-in-Q access network is a client network of the
VPLS, then all three interface modes (port, VLAN and VLAN bundling)
are applicable for multiple service domain operation. However, if
the Q-in-Q access network interprets the S-Tag as a local service
delimiter, then only VLAN mode of operation is allowed. This is
Sajassi, et al. [Page 21]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
because it is the only mode that does not require that the S-Tag be
transported over the pseudowire.
5.2. Pseudowire Requirements
The pseudowire requirements depend on whether the PE maps the B-VID
or I-SID to a VPLS instance; i.e., whether the B-VID or I-SID is a
service delimiter, respectively. The two cases are explored next.
5.2.1. Requirements with B-VID as Service Delimiter
There are no new pseudowire requirements for this case. Existing
pseudowire raw and tagged modes can be used as is.
5.2.2. Requirements with I-SID as Service Delimiter
For this case, a new pseudowire type is used to carry I-tagged frame
over the pseudowire with I-SID as service delimiter per section
4.2.2.2.1.
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.
6. H-VPLS with MPLS Access Network
In the previous two sections, 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), 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
Sajassi, et al. [Page 22]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
corresponding to a single I-SID. However, if one supports VPLS
multicast data via MPLS P2MP tunnels, then this drawback goes away.
Figure 7 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 7: 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 service
domain. However, different MPLS access networks can be part of the
same or separate service domains. We describe both cases below.
6.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.
Sajassi, et al. [Page 23]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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 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.
6.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. Alternatively, the new pseudowire
type described in section 4.2.2.2.1 can be utilized, without the
need for I-SID translation.
6.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 service domains.
At the ingress U-PE, during the PBBN encapsulation process, an I-SID
value is added. A new pseudowire type (described in section
4.2.2.2.1) 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
Sajassi, et al. [Page 24]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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.
6.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 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 service domains. These
scenarios are described next.
6.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.
6.4.2. Requirements with I-SID as Service Delimiter
For this case, a new pseudowire type is used to carry I-tagged frame
over the pseudowire with I-SID as service delimiter per section
4.2.2.2.1.
We note that the pseudowire type used should be uniform and
consistent across both the access and core networks. In other words,
the access pseudowires between the uPEs and nPEs as well as the full
mesh of core pseudowires between the nPEs should all share the same
pseudowire type.
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
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
Sajassi, et al. [Page 25]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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.
Sajassi, et al. [Page 26]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
[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.
[RFC4664] Andersson, L. and et al, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Proposed Standard, September 2006.
[P802.1ad] IEEE Draft P802.1ad, "Virtual Bridged Local Area
Networks: Provider Bridges", December 2005.
[P802.1ag] IEEE Draft P802.1ag/D8.1, "Virtual Bridge Local Area
Networks: Connectivity Fault Management", Work in Progress, June
2007
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".
[VPLS-Bridge] Sajassi, A. and et al, "VPLS Interoperability with CE
Bridges", Work in progress, November 2006
[PBB-PW] Martini, L. and et al, "802.1ah Ethernet Pseudowire", Work
in progress, May 2007
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
Sajassi, et al. [Page 27]
draft-sajassi-l2vpn-vpls-pbb-interop-01.txt July 2007
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 28]