One document matched: draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt
Internet Working Group Ali Sajassi
Internet Draft Samer Salam
Intended Status: Standards Luyuan Fang
Cisco
Nabil Bitar
Verizon
Dinesh Mohan
Nortel
Raymond Zhang
British Telecom
Expires: January 2009 July 2008
Customer MAC Address Flushing Mechanisms for Provider Backbone
Bridging over VPLS
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-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
Sajassi, et. al. [Page 1]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
(PBB) functionality in VPLS access.
PBB introduces the notion of Backbone MAC (B-MAC) addresses vs.
Customer MAC (C-MAC) addresses, thereby leading to the requirement
for having MAC address flushing mechanisms for each.
This document discusses a C-MAC address flushing notification
mechanism to be used in VPLS networks that employ PBB technology.
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. Introduction....................................................2
2. Terminology.....................................................3
3. C-MAC vs. B-MAC Address Flushing in PBB Networks................4
4. C-MAC Address Flushing Mechanisms for H-VPLS with PBB Components6
4.1. H-VPLS with PBBN Access.......................................7
4.2. H-VPLS with MPLS Access: PBB U-PE.............................8
4.3. H-VPLS with MPLS Access: PBB N-PE.............................9
5. Message Format..................................................9
6. Advantages of Mechanism........................................11
7. Security Considerations........................................12
8. IANA Considerations............................................12
9. Intellectual Property Considerations...........................12
10. Full Copyright Statement......................................12
11. IPR Notice....................................................12
12. Normative References..........................................13
13. Informative References........................................13
14. Authors' Addresses............................................14
1.
Introduction
[P802.1ah] introduces a hierarchical network architecture where
customer MAC frames are encapsulated in "backbone" MAC frames before
being forwarded in the Provider Backbone Bridged Network (PBBN).
Customer MAC address (C-MAC) learning is performed only at the edge
of the PBBN (by I-Components) whereas all forwarding and learning in
the core of the network is performed on Backbone MAC addresses (B-
MACs). This gives rise to two independent MAC address spaces: the C-
MAC address space and the B-MAC address space. Consequently, MAC
Sajassi, et al. [Page 2]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
address flushing mechanisms are required for each address space,
independently.
[VPLS-PBB] analyzes the interoperability of Provider Backbone Bridge
(PBB) technology with VPLS. It also describes the scenarios and the
mechanisms for incorporating PBB functionality within H-VPLS with
existing MPLS access or IEEE 802.1ad (aka Q-in-Q) Ethernet access
and interoperability among them.
This document discusses the C-MAC address flushing notification
mechanism for VPLS networks that employ PBB technology, for both H-
VPLS with native PBBN access and H-VPLS with MPLS access. Section 2
provides a summary of the terminology used throughout the document.
Section 3 discusses the difference between C-MAC address and B-MAC
address flushing in the context of PBB technology. Section 4 depicts
the C-MAC address flushing mechanisms for three representative
network use-case scenarios. Then, section 5 captures the message
formats. Finally, section 6 summarizes the advantages of the
solution.
2.
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 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.
Sajassi, et al. [Page 3]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
B-VID: The specific VLAN identifier carried inside a B-TAG
C-MAC: Customer source or destination address used in a customer MAC
frame.
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.
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-VLAN: The specific service VLAN identifier carried inside an S-TAG
3.
C-MAC vs. B-MAC Address Flushing in PBB Networks
In PBB networks, C-MAC address learning is confined to the edge of
the network, and performed on Backbone Edge Bridges that host an I-
Component (i.e. I-BEBs and IB-BEBs) only. The I-Component builds a
mapping of C-MAC addresses to B-MAC addresses based on traffic
received from the PBB core. The core of the network forwards and
learns based only on B-MAC addresses; thus, it is completely
transparent to C-MAC addresses.
Any topology change in the customer's network, or its connection(s)
to the PBB network, that results in the reachability of a given C-
MAC address moving from one I-Component to another I-Component
should trigger a C-MAC address flush notification for the affected
Sajassi, et al. [Page 4]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
service (I-SID). This is required to prevent potential traffic
black-holing due to a remote I-Component maintaining a stale C-MAC
to B-MAC address association. Such notification is only of interest
to remote bridges that host an I-Component for the service in
question (i.e. I-BEBs or IB-BEBs), but it is not of any value to
Backbone Core Bridges (BCBs). Furthermore, as long as the C-MAC
address flushing notification signals a topology change for a single
I-SID, it can be made completely transparent to B-BEBs as well. This
limits the scope of devices that need to transmit and/or handle C-
MAC address flushing notifications to the edge of the PBB network,
and more precisely only to Backbone Edge Bridges with an I-Component
function (I-BEBs and IB-BEBs). This is shown as "Zone C" in Figure 1
below.
On the other hand, topology changes within the PBB network, which
result in the reach-ability of a given B-MAC address moving from one
port to another, should trigger a B-MAC address flushing
notification. This is of interest only to devices that learn and
forward based on B-MAC addresses. Hence, B-MAC address flushing
notifications can be confined to devices that implement BCB or B-
Component (IB-BEB or B-BEB) functions in the PBB or the MPLS
network. This is depicted as "Zone B" in Figure 1. I-Components are
completely transparent to B-MAC address flushing mechanisms.
C-MAC Flushing Scope --+
|
+-------------------------------------|------------------+
| Zone C V |
| +----------------------------------------+ |
| | +----------------------------------+ | |
| | | | | |
| +---+ | | +---+ +---+ +---+ +---+ | | +---+ |
| |I- | | | |B- | |BCB| |BCB| |B- | | | |I- | |
| |BEB|-------|BEB|---| |----| |---|BEB|-------|BEB| |
| +---+ | | +---+ +---+\ /+---+ +---+ | | +---+ |
| | | \/ | | |
| +---+ | | +---+ +---+ /\ +---+ +---+ | | +---+ |
| |I- | | | |B- | |BCB|/ \|BCB| |B- | | | |I- | |
| |BEB|-------|BEB|---| |----| |---|BEB|-------|BEB| |
| +---+ | | +---+ +---+ +---+ +---+ | | +---+ |
| | | | | | | |
| +------+ | | +------+ |
| | IB- | | | | IB- | |
| | BEB |---------+ +----------| BEB | |
| +------+ +------+ |
| | | Zone B ^ | | |
+-------+ +-------------------------|--------+ +-------+
|
Sajassi, et al. [Page 5]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
B-MAC Flushing Scope --+
Figure 1: C-MAC and B-MAC Address Flushing Scope in PBB Networks
It is worth noting that devices which implement IB-BEB functions
will have to participate in both C-MAC as well as B-MAC address
flushing mechanisms because the subtended I-Component operates on C-
MAC addresses whereas the subtended B-Component operates on B-MAC
addresses. This is the reason why IB-BEBs are shown to be part of
both Zones B and C in Figure 1 above.
For H-VPLS with PBB technology, including MPLS access and PBBN
access, both B-MAC address as well as C-MAC address flushing
notification mechanisms are required. In this context, B-MAC address
flushing notification can be accomplished via the use of LDP Address
Withdraw Message, as described in [RFC4762]. This is independent of
C-MAC flushing mechanisms, and as such, is considered outside the
scope of this document.
Having established the differentiation between C-MAC address and B-
MAC address flushing in this section, we will now sharpen our focus
in the next section on C-MAC address flushing mechanisms for H-VPLS
with PBB technology.
4.
C-MAC Address Flushing Mechanisms for H-VPLS with PBB Components
As discussed in the previous section, C-MAC address flushing
notification need only be generated or processed by devices that
employ an I-Component function. Given that these devices are
confined to the edge of the PBB or the MPLS network, it is possible
to tunnel C-MAC address flushing messages transparently through the
PBB core bridges or N-PE devices without any loss of functionality.
As a matter of fact, this is indeed the preferred behavior for the
following reasons:
i) Devices operating on B-MAC addresses do not care about C-MAC
address flushing notification messages, and need not process
them. Actually having these devices process the C-MAC address
flush messages as control traffic places unnecessary burden on
the processors of these network nodes.
i
i) Passing C-MAC address flushing notifications as regular data
frames (as opposed to control frames) within the PBB core
speeds up convergence, primarily because the forwarding can be
performed in the hardware that takes care of data traffic
switching.
Given the above, an in-band MAC address flushing notification
mechanism, that is native to the Ethernet layer, proves better
suited for C-MAC address flushing than an out-of-band mechanism. The
Sajassi, et al. [Page 6]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
C-MAC address flush notification message should be generated by the
device which hosts an I-Component that detects the topology change.
The message is encapsulated in a PBB frame that is tunneled as
regular data through the PBB core. The message must be flooded to
all edge devices that host an I-Component for the service
experiencing the topology change. These devices should remove the
PBB encapsulation from the frame and process the encapsulated C-MAC
address flush notification message. The processing involves flushing
the C-MAC address table entries for the affected service (I-SID).
In the following subsections, we demonstrate how the C-MAC address
flushing notification mechanism works in three representative
network architectures: section 4.1 focuses on H-VPLS with native
Ethernet PBBN access; whereas, sections 4.2 and 4.3 describe H-VPLS
with MPLS access and with PBB functions on the U-PE and N-PE,
respectively.
4.1.
H-VPLS with PBBN Access
Consider the network architecture of Figure 2 where native Ethernet
PBB aggregation networks are connected over a VPLS core. The CE
connected to the aggregation network on the left is dual-homed to
two PBB backbone edge bridges (IB-BEB1 and IB-BEB2). Assume that
initially the link to IB-BEB1 was the active CE uplink. If this link
fails, the CE will failover to the uplink connected to IB-BEB2 and
the latter will detect the topology change by virtue of the
redundancy mechanism running between the CE and the IB-BEB. The
details of this redundancy mechanism are outside the scope of this
document. The key point here is that the detection of the topology
change on IB-BEB2 will trigger that device to transmit C-MAC address
flushing notification messages for the affected services (I-SIDs). A
single C-MAC address flushing notification message should be
generated per I-SID. The message is encapsulated with the PBB
header, and is flooded to all other IB-BEBs that participate in the
affected I-SID, by using the multicast "Backbone Service Instance
Group Address" for that I-SID, as defined in [P802.1ah] section
26.4. The C-MAC flush notification message will be forwarded
transparently, like a regular data frame, by the bridges in the core
of the PBBN aggregation networks as well as by the VPLS PEs. When a
remote IB-BEB (e.g. IB-BEB3 and IB-BEB4), which participates in the
I-SID in question, receives the C-MAC flushing notification message,
it would process the frame by flushing the corresponding C-MAC
address table for the affected service (I-SID).
Sajassi, et al. [Page 7]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
+----------+
+----+ | | +----+
-|IB- |-------+ | IP/MPLS | +-------|IB- | +--+
/ |BEB1| | +----+ +----+ | |BEB3|--|CE|
+--+ +----+ PBBN | |VPLS| |VPLS| | PBBN +----+ +--+
|CE| | 802.1ah|---| PE | | PE |--| 802.1ah |
+--+ +----+ | +----+ +----+ | +----+ +--+
\ |IB- | | | Backbone | | |IB- |--|CE|
-|BEB2|-------+ +----------+ +-------|BEB4| +--+
+----+ +----+
Figure 2: H-VPLS with PBBN Access
4.2.
H-VPLS with MPLS Access: PBB U-PE
In this architecture, MPLS access networks are connected over a VPLS
core, and PBB Backbone Edge Bridge functionality is embedded into
the U-PEs. Refer to Figure 3 below for an example. The CE in the
left access network is dual-homed to two U-PEs (U-PE1 and U-PE2). A
redundancy mechanism, the details of which are beyond the scope of
this document, determines that the CE uplink to U-PE1 is active
initially. A failure, e.g. of this uplink, triggers the redundancy
mechanism to activate the CE uplink to U-PE2 and to notify the
latter of the topology change. U-PE2 reacts to this notification by
transmitting C-MAC address flushing notification messages, similar
to what was described in Section 4.1. The C-MAC address flushing
notification message is forwarded by U-PE2 towards the N-PE, which
transparently floods the message over the full-mesh of pseudowires
in the VPLS core (for the VSI in question). Remote N-PEs which
receive those messages will again forward them as regular data
frames over the spoke pseudowires to the U-PEs. The U-PEs that
participate in the affected I-SID would respond to these messages by
flushing their local C-MAC address tables. Effectively, the C-MAC
address flush notification messages are treated as normal data
frames throughout the H-VPLS network, except at the U-PE nodes.
PBB
BEB PBB
| +----------+ BEB
V +----------+ | | |
+-----+ MPLS | | IP | +-----------+ |
/|U-PE1| Access| | MPLS | | MPLS | |
/ +-----+ +----+ | Core | +----+ Access | V
+--+ | |VPLS|-| |-|VPLS| +-----+ +--+
|CE|\ +-----+ |N-PE| | | |N-PE| |U-PE3|--|CE|
+--+ \|U-PE2| +----+ | | +----+ +-----+ +--+
+-----+ | | | | |
^ +----------+ +----------+ +-----------+
|
PBB
BEB
Sajassi, et al. [Page 8]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
Figure 3: H-VPLS with MPLS Access Network and PBB U-PE
4.3.
H-VPLS with MPLS Access: PBB N-PE
Referring to Figure 4 below, in this network architecture the PBB
BEB functionality is implemented on the VPLS N-PE. Operation of the
C-MAC address flushing mechanism is similar to what was discussed in
the previous section, except that the messages are generated and
processed by the N-PEs instead of the U-PEs.
PBB
BEB PBB
| BEB
V |
+-----+ +----------+ |
+--------|VPLS | | | |
| |N-PE1|-| IP | | +-----------+
| +-----+ | MPLS | V | MPLS |
+--+ +-----+ MPLS | | Core | +-----+ Access|
|CE|--|U-PE | Access | | |-|VPLS | +-----+ +--+
+--+ +-----+ | | | |N-PE3| |U-PE |--|CE|
| +-----+ | | +-----+ +-----+ +--+
| |VPLS |-| | | |
+--------|N-PE2| +----------+ +-----------+
+-----+
^
|
PBB
BEB
Figure 4: H-VPLS with MPLS Access Network and PBB N-PE
5.
Message Format
The format of the C-MAC address flushing notification message is
based on a PBB-encapsulated Multi-VLAN Registration Protocol (MVRP)
PDU, as defined in [802.1ak]. This is shown in Figure 5 below. It
should be noted that generation or reception handling of this
message does NOT require a VPLS PE device (with PBB I-Component
functionality) to necessarily run the IEEE 802.1ak protocol stack.
This is primarily because all the fields of the encapsulated MVRP
PDU are fixed. It is sufficient for the VPLS PE device to
encapsulate the PDU with the right PBB header on transmission, and
react to the message by flushing the appropriate C-MAC address table
for the I-SID on reception.
Sajassi, et al. [Page 9]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
+--------------------+
| B-DA |
+--------------------+
| B-SA |
+--------------------+
| EtherType = 0x88a8 |
+--------------------+
| B-VLAN |
+--------------------+
| EtherType = 0x88e7 |
+--------------------+
| I-SID |
+--------------------+
| C-DA |
+--------------------+
| C-SA |
+--------------------+
| EtherType = 0x88f5 |
+--------------------+
| |
~ MVRP PDU ~
| |
+--------------------+
Figure 5: C-MAC Address Flushing Notification Message Format
B-DA: The Backbone Service Instance Group Address for the I-SID that
is experiencing the topology change, as defined in [P802.1ah]
section 26.4
B-SA: The B-MAC source address of the I-Component generating the
message.
B-VLAN: The B-VLAN used for the I-SID for which C-MAC addresses
should be flushed.
I-SID: The I-SID for which C-MAC addresses should be flushed.
C-DA: This should be set to 01-80-C2-00-00-21 if the Customer
Instance Ports (CIPs) encountering the topology change for the I-SID
in question are 802.1Q interfaces, and set to 01-80-C2-00-00-0D if
the CIPs are 802.1ad / Q-in-Q interfaces. Refer to [802.1ak] Table
8-1 and Table 10-1.
C-SA: The C-MAC address that uniquely identifies the I-Component.
This should not be the same as the B-SA in order to avoid any
confusion that may arise from using the same address value in both
Sajassi, et al. [Page 10]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
C-MAC and B-MAC address spaces. The value for this field can be set
to the port MAC address of any of the CIPs associated with the I-
Component generating the C-MAC address flushing notification
message.
MVRP PDU: This is an MVRP PDU declaring "new" registrations for all
VLANs (1 to 4094). The format of this PDU is as shown in Figure 6
below.
No. Bits Field Value
+--------------------+
8 | Protocol Version | 0x00
+--------------------+
8 | AttributeType | 0x01
+--------------------+
8 | AttributeLength | 0x02
+- +--------------------+ -+
| | LeaveAllEvent | |
16 -+ +--------------------+ +- 0x0ffe
| | NumberofValues | |
+- +--------------------+ -+
16 | FirstValue | 0x01
+--------------------+
10920 | Vector | 0x00 (repeated 1365 times)
+--------------------+
16 | EndMark | 0x0000
+--------------------+
Figure 6: MVRP PDU Format
The various fields of this PDU are standardized by IEEE as outlined
in [802.1ak].
6.
Advantages of Mechanism
The C-MAC address flushing notification mechanism described in this
document has the following advantages:
i) It is completely transparent to all devices that operate on B-
MAC addresses; e.g., is transparent to VPLS PE and N-PE in the
case of H-VPLS with PBBN access and the case of H-VPLS with
MPLS access (PBB on U-PE), respectively.
i
i) Treating C-MAC address flushing notifications as regular data
frames (as opposed to control frames) within the PBB core and
the on the VPLS PEs / N-PEs speeds up convergence, primarily
because the forwarding can be performed in hardware, and no
software-based control-plane processing is involved.
Sajassi, et al. [Page 11]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
i
i
i) The mechanism applies to Tightly Coupled, Loosely Coupled as
well as Different Service Domains [VPLS-PBB]. This is because
each message carries a flush indication for a single I-SID, and
the value of the I-SID is encoded in the PBB header only.
Furthermore, I-SID translation, in the case of Different
Service Domains, can be performed in the normal data-path by
the hardware that handles regular data traffic.
7.
Security Considerations
There are no additional security aspects beyond those of VPLS/H-VPLS
that need to be discussed here.
8.
IANA Considerations
None.
9.
Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
10.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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
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.
11.
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
Sajassi, et al. [Page 12]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
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.
12.
Normative References
[P802.1ah] IEEE P802.1ah/D4.2, "Draft Standard for Local and
Metropolitan Area Networks - Virtual Bridged Local Area Networks
- Amendment 6: Provider Backbone Bridges", IEEE 802.1
Interworking Task Group, March, 2008.
[RFC4762] "Virtual Private LAN Service (VPLS) Using Label
Distribution Protocol (LDP) Signaling", RFC4762, January 2007
[802.1ak] IEEE Std. 802.1ak-2007, "IEEE Standard for Local and
metropolitan area networks - Virtual Bridged Local Area Networks
- Amendment 7: Multiple Registration Protocol", IEEE Computer
Society, June, 2007.
[802.1ad] IEEE Std. 802.1ad-2005, "IEEE Standard for Local and
metropolitan area networks - virtual Bridged Local Area Networks,
Amendment 4: Provider Bridges", IEEE Computer Society, May, 2006.
13.
Informative References
[VPLS-PBB] Sajassi et al., "VPLS Interoperability with Provider
Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop-02.txt,
work in progress, November, 2007.
Sajassi, et al. [Page 13]
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00.txt July 2008
14.
Authors' Addresses
Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134, US
Email: sajassi@cisco.com
Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com
Luyuan Fang
Cisco
300 Beaver Brook Road
Boxborough, MA 01719, US
Email: lufang@cisco.com
Nabil Bitar
Verizon Communications
Email : nabil.n.bitar@verizon.com
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Raymond Zhang
British Telecom
2160 E. Grand Avenue
El Segundo, CA 90245
Email: raymond.zhang@bt.com
Sajassi, et al. [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 00:24:41 |