L2VPN Working Group Florin Balus
Internet Draft Pranjal Kumar Dutta
Intended Status: Proposed Standard Alcatel-Lucent
Expires: May 2010
Geraldine Calvignac
France Telecom
Olen Stokes
Extreme Networks
November 20, 2009
Extensions to LDP Signaling for PBB-VPLS
draft-balus-l2vpn-pbb-ldp-ext-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
This Internet-Draft will expire on September 20, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Balus, et al. Expires May 20, 2010 [Page 1]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Extensions to VPLS PE model to accommodate PBB components where
discussed in [PBB-VPLS Model]. This draft discusses optional
extensions to the LDP Signaling procedures in [RFC 4762] required to
further enhance the PBB-VPLS solution.
Table of Contents
1. Introduction...................................................2
2. General terminology............................................3
2.1. Conventions used in this document.........................4
3. PBB Blackholing issue..........................................4
4. PBB-VPLS Extensions to LDP.....................................5
5. Security Considerations........................................8
6. IANA Considerations............................................8
7. References.....................................................8
7.1. Normative References......................................8
7.2. Informative References....................................8
8. Acknowledgments................................................9
1. Introduction
[PBB-VPLS Model] describes how PBB can be integrated with VPLS to
allow for useful PBB capabilities while continuing to avoid the use
of MSTP in the backbone. The combined solution referred as PBB-VPLS
results in better scalability in terms of number of service
instances, PWs and C-MACs that need to be handled in the VPLS PEs.
This document describes optional extensions to LDP Signaling
procedures described in [RFC4762] required to add desirable
capabilities to PBB-VPLS solution.
Balus, et al. Expires May 20, 2010 [Page 2]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
Section 2 gives a quick terminology reference. Section 3 covers the
problem space. Section 4 describes the solution and required TLV
extensions.
2. General terminology
Some general terminology is defined here; most of the terminology
used is from [IEEE802.1ah], [RFC4762] and [RFC4026]. Terminology
specific to this memo is introduced as needed in later sections.
802.1ah: IEEE specification for "MAC tunneling" encapsulation and
bridging of frames across a provider backbone bridged network.
PBB: Provider Backbone Bridge
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.
BCB: A backbone core bridge positioned at the core of a provider
backbone bridged network. It contains only B-component.
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-MAC: The backbone source or destination MAC address fields defined
in the 802.1ah provider MAC encapsulation header.
B-component, referred here also as B-VPLS: A bridging component
contained in BEBs and BCBs that bridges in the provider backbone
space based on B-MAC and B-TAG information
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-SID: The 24-bit service instance field carried inside the I-TAG. I-
SID defines the service instance that the frame should be "mapped
to".
S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
conveys the service VLAN identifier information (S-VLAN).
Balus, et al. Expires May 20, 2010 [Page 3]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
S-VLAN: The specific service VLAN identifier carried inside an S-TAG
I-component: A bridging component contained in a backbone edge bridge
that bridges in the customer space based on customer MAC addresses
and S-TAG information
2.1. Conventions used in this document
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.
3. PBB Blackholing issue
In PBB-VPLS solution a B-component VPLS (B-VPLS) may be used as
infrastructure for one or more I-component instances. B-VPLS control
plane (LDP Signaling) replaces I-component control plane throughout
the MPLS core. This is raising an additional challenge related to
blackhole avoidance in the I-component domain as described in this
section. Figure 1 describes the case of a CE device (node A) dual-
homed to two I-component instances located on two PBB-VPLS PEs (PE1
and PE2).
IP/MPLS Core
+--------------+
|PE2 |
+----+ |
|PBB | +-+ |
_ |VPLS|---|P| |
S/+----+ /+-+\ |PE3
/ +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+
CMAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--CMAC Y
+---+ A +----+ +-+ +----+ +---+
A |PE1 | B
| |
+--------------+
Figure 1: PBB Blackholing Issue - CE Dual-Homing use case
The link between PE1 and CE A is active (marked with A) while the
link between CE A and PE2 is in Standby/Blocked status. In the
network diagram CMAC X is one of the MAC addresses located behind CE
A in the customer domain, CMAC Y is behind CE B and the BVPLS
Balus, et al. Expires May 20, 2010 [Page 4]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
instances on PE1 are associated with backbone MAC (BMAC) B1 and PE2
with BMAC B2.
As the packets flow from CMAC X to CMAC Y through PE1 of BMAC B1, the
remote PEs participating in the IVPLS (for example, PE3) will learn
the CMAC X associated with BMAC B1 on PE1. Under failure of the link
between CE A and PE1 and activation of link to PE2, the remote PEs
(for example, PE3) will black-hole the traffic destined for customer
MAC X to BMAC B1 until the aging timer expires or a packet flows from
X to Y through the PE B2. This may take a long time (default aging
timer is 5 minutes) and may affect a large number of flows across
multiple I-components.
A possible solution to this issue is to use the existing LDP MAC
Flush as specified in [RFC 4762] to flush in the BVPLS domain the
BMAC associated with the PE where the failure occurred. This will
automatically flush the CMAC to BMAC association in the remote PEs.
This solution though has the disadvantage of producing a lot of
unnecessary MAC flush in the B-VPLS domain as there was no failure or
topology change affecting the Backbone domain.
A better solution is required to propagate the I-component events
through the backbone infrastructure (B-VPLS) in order to flush only
the customer MAC to BMAC entries in the remote PBB-VPLS PEs. As there
are no IVPLS control plane exchanges across the PBB backbone,
extensions to B-VPLS control plane are required to propagate the I-
component MAC Flush events across the B-VPLS.
4. PBB-VPLS Extensions to LDP
The use of Address Withdraw message with MAC List TLV is proposed in
[RFC4762] as a way to expedite removal of MAC addresses as the result
of a topology change (e.g. failure of a primary link of a VPLS PE and
implicitly the activation of an alternate link in a dual-homing use
case). These existing procedures apply to B-VPLS and I-component
domains.
When it comes to reflecting topology changes in access networks
connected to I-component across the B-VPLS domain certain additions
should be considered as described below.
MAC Switching in PBB is based on the mapping of Customer MACs (CMACs)
to Backbone MAC(s) (BMACs). A topology change in the access (I-
domain) should just invoke the flushing of CMAC entries in PBB PEs'
FIB(s) associated with the I-component(s) impacted by the failure.
Balus, et al. Expires May 20, 2010 [Page 5]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
There is a need to indicate the PBB PE (BMAC source) that originated
the MAC Flush message.
These goals can be achieved by adding a PBB TLV in the LDP Address
Withdraw message to indicate the particular domain(s) requiring MAC
flush. At the other end, the receiving PBB PEs may use the
information from the PBB TLV to flush only the related FIB
entry/entries in the I-component instance(s).
A suggested PBB TLV structure is depicted below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| PBB TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Sub-TLV Length | Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UF bits are set to forward unknown so that potential intermediate
VPLS PEs that are unaware of PBB can just forward the TLV towards the
PBB aware PEs. The PBB TLV type values are to be assigned by IANA.
The Length field is used to define the length of the PBB TLV
including the type and the length itself. Processing of the sub-TLVs
should continue when unknown ones are encountered, and they MUST be
silently ignored.
The following sub-TLVs MUST be included in the PBB TLV:
- PBB BMAC List sub-TLV:
Type: 0x01
Length: value length in octets. At least one BMAC address must be
present in the list.
Flags: 1 Byte Flag field is required. Only the last flag N is used
for now to indicate whether a positive (N=0, Flush-all-but-mine) or
negative (N=1 Flush-all-from-me) MAC Flush is required. The rest of
the flags should be set to zero on transmission and ignored on
reception.
Value: one or a list of 48 bits BMAC address(es). These are the
source BMAC addresses associated with the B-VPLS instance(s) that
Balus, et al. Expires May 20, 2010 [Page 6]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
originated the MAC Withdraw message. It will be used to identify the
CMAC(s) mapped to the BMACs listed in the sub-TLV.
- PBB ISID List sub-TLV:
Type: 0x02
Length: value length in octets. Zero indicates an empty ISID list. An
empty ISID list means that the flush applies to all the ISIDs mapped
to the B-VPLS indicated by the FEC TLV.
Value: one or a list of 24 bits ISIDs that represent the I-VSI FIB(s)
where the MAC Flush needs to take place.
The following steps describe the details of the processing for the
related LDP Address Withdraw message:
. The LDP MAC Withdraw Message, including the PBB TLV is initiated
by the PBB PE(s) experiencing a Topology Change event.
. On reception of the LDP message, the B-VPLS instances related to
the FEC TLV from the LDP Address Withdraw message must interpret
the presence of the PBB TLV as an indication of a PBB Flush
message. As a result, the BCBs should not flush their BMAC FIBs.
If required the B-VPLS control plane may propagate the MAC Flush
indication following the split-horizon grouping and the
established BVPLS topology.
. The receiving BEBs use the sub-TLVs from the PBB TLV as follows:
o The PBB ISID List is used to determine the particular ISID
FIBs that need to be flushed. If the ISID List is empty all
the ISID FIBs associated with the receiving B-VPLS are
flushed.
o The PBB BMAC List is used to identify from the ISID FIBs
selected in the previous step just the entries that map
CMACs to the BMACs that are not listed in the sub-TLV.
. Next, depending on the N flag value in the BMAC List sub-TLV the
following actions apply:
Balus, et al. Expires May 20, 2010 [Page 7]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
o N=0, all the CMACs in the selected ISID FIBs should be
flushed with the exception of the resulted CMAC list
("Flush all but the CMACs associated with the BMAC(s) in
the BMAC List Sub-TLV from the FIBs associated with the
ISID list").
o N=1, the resulted CMAC list should be flushed ("Flush all
the CMACs associated with the BMAC(s) in the BMAC List Sub-
TLV from the FIBs associated with the ISID list")
5. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC4762].
6. IANA Considerations
IANA needs to assign PBB TLV type values.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
7.2. Informative References
[IEEE802.1ah] IEEE 802.1ah "Virtual Bridged Local Area Networks,
Amendment 6: Provider Backbone Bridges", Approved Standard
June 12th, 2008
[RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private
Network (VPN) Terminology", RFC 4026, March 2005.
Balus, et al. Expires May 20, 2010 [Page 8]
Internet-Draft Extensions to LDP Signaling for PBB-VPLS November 2009
[PBB-VPLS Model] F. Balus, et Al. "Extensions to VPLS PE model for
Provider Backbone Bridging", draft-ietf-l2vpn-pbb-vpls-pe-
model-00.txt, May 2009 (work in progress)
8. Acknowledgments
The authors would like to thank Wim Henderickx, Dimitri
Papadimitriou, Jorge Rabadan and Maarten Vissers for their insightful
comments and probing questions.
Authors' Addresses
Dutta Kumar Pranjal
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: dutta.pranjal@alcatel-lucent.com
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Geraldine Calvignac
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: geraldine.calvignac@orange-ftgroup.com
Olen Stokes
Extreme Networks
PO Box 14129
RTP, NC 27709
USA
Email: ostokes@extremenetworks.com
Balus, et al. Expires May 20, 2010 [Page 9]