Transparent Interconnection of Lots of Links (TRILL) over an MPLS PSN (Packet Switched Network)
draft-yong-trill-trill-o-mpls-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Donald E. Eastlake 3rd , Jon Hudson , Lucy Yong , Sam Aldrin | ||
| Last updated | 2011-10-23 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yong-trill-trill-o-mpls-00
Network Working Group L. Yong
Internet Draft D. Eastlake
Intended status: Informational S. Aldrin
Huawei
J. Hudson
Brocade
Expires: April 2012 October 23, 2011
Transparent Interconnection of Lots of Links (TRILL) over an MPLS
PSN (Packet Switched Network)
draft-yong-trill-trill-o-mpls-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the DNSEXT working group mailing list: <rbridge@postel.org>.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Yong & Eastlake Expires April 23, 2012 [Page 1]
Internet-Draft TRILL over MPLS October 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
Abstract
This informational document describes ways to interconnect TRILL
RBridges over WAN connections by using MPLS Pseudo Wire (PW) or
Virtual Private LAN Service (VPLS) with existing TRILL and MPLS
standards. It also describes the combination of RBridge and MPLS to
provide a hierarchical scalable L2VPN.
Table of Contents
1. Introduction...................................................2
2. Use Cases......................................................3
2.1. Point-To-Point Interconnection............................3
2.2. Multi-Access Link Interconnection.........................6
2.3. Hierarchical L2VPN with RBridges and MPLS.................8
3. RBridge Behavior for MPLS Pseudo Wire.........................10
4. Security Considerations.......................................11
5. IANA Considerations...........................................11
6. Acknowledgements..............................................11
7. References....................................................11
7.1. Normative References.....................................11
7.2. Informative References...................................13
1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links)
standard [RFC6325] [RFC6326] provides optimal pair-wise data frame
forwarding without configuration in multi-hop networks with
arbitrary topology, and support for multipathing of both unicast and
multicast traffic. TRILL enables a new method to construct a campus
or data center network. Devices that implement TRILL are called
RBridges.
This document describes the use cases of TRILL over an MPLS PW or
VPLS, and introduces a new hierarchical L2VPN architecture that uses
RBridges and IP/MPLS and documents the related configurations and
references for the proper interworking.
Yong & Eastlake Expires April 23, 2012 [Page 2]
Internet-Draft TRILL over MPLS October 2011
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 [RFC2119].
Acronyms used in this document include the following:
AC - Attachment Circuit
CE - Customer Edge
IS-IS - Intermediate System to Intermediate System
MPLS - Multi-Protocol Label Switching
PE - Provider Edge
PPP - Point to Point Protocol
PW - Pseudo Wire
RBridge - Routing Bridge
TRILL - Transparent Interconnection of Lots of Links
VPLS - Virtual Private LAN Service
VSI - Virtual Service Instance
2. Use Cases
RBridge campuses at different locations may interconnect by networks
that are implemented with different technologies to form one RBridge
campus. This section describes use cases assuming that IP/MPLS
technology is available. From the MPLS network view, an RBridge
device acts as a Customer Edge (CE) device and connects to PE via an
attachment circuit (AC). RBridges [RFC6325] support both point-to-
point links and multi-access links. Section 2.1 describes point-to-
point link, i.e. TRILL over either Ethernet or PPP point-to-point
link that is over an MPLS network. Section 2.2 describes TRILL over
a bridged LAN that is implemented by MPLS/VPLS. Section 2.3
introduces a new hierarchical L2VPN solution that uses the RBridges
and MPLS tiered architecture.
2.1. Point-To-Point Interconnection
Two RBridges are interconnected by either Ethernet or PPP link that
is over a MPLS network. A Pseudo wire (PW) is configured between a
Yong & Eastlake Expires April 23, 2012 [Page 3]
Internet-Draft TRILL over MPLS October 2011
pair of PEs to provide part of the point-to-point link between two
RBridges. Figure 1 illustrates this architecture. Each RBridge
device connects to a PE via AC and acts as a CE device. MPLS PSN is
bordered at the PEs. The TRILL link across the IP/MPLS PSN makes the
left site and right site into one RBridge campus.
MPLS already supports many pseudo wire transport encapsulations.
[RFC4446] Two types of TRILL links between RBridges have been
standardized: Ethernet [RFC6325] and PPP [RFC6361]. PW
encapsulations for these two interfaces are specified in [RFC4448]
and [RFC4618], respectively. When an RBridge port connecting to AC
is configured with a point-to-point Ethernet link type, two PEs can
be configured as a PW with Ethernet encapsulation [RFC4448]. The PW
between two PEs can be auto-configured [RFC4447] or manually
configured; the two RBridges then appear directly interconnected
with an Ethernet link. When an RBridge port connecting to AC is
configured with the PPP link type, two PEs MUST be configured as a
PW with PPP encapsulation.[RFC4618] After the PW is established
between two PEs, the two RBridges then appear directly
interconnected with a PPP link. The TRILL link is automatically
configured over an Ethernet link or PPP link. The PW provides
transparent transport between ACs.
Note: 1) For Ethernet link configuration, PE SHOULD use the Raw mode
and non-service-delimiting, which provides a transparent transport.
2) The PPP link configuration will be more efficient than the
Ethernet point-to-point configuration; it saves about 16 bytes per
frame by replacing the TRILL Outer.MacDA, Outer.MacSA, Outer.VLAN,
and outer Ethertype with a PPP code point. [RFC6361]
<----------TRILL Link---------->
*-------* <----------PW----------> *-------*
| | AC +----+ +---+ +----+ AC | |
| RB +----| PE |----| P |---| PE |----+ RB |
|Site A | +----+ +---+ +----+ |Site B |
| | { PSN } | |
*-------* *-------*
{ One RBridge Campus }
Figure 1 P2P TRILL Link over IP/MPLS PSN Use Case I
An RBridge is a router and could support PE capabilities. As the
networks converg, it is possible that one operator runs both an
RBridge campus as well as the core MPLS network. Figure 2
Yong & Eastlake Expires April 23, 2012 [Page 4]
Internet-Draft TRILL over MPLS October 2011
illustrates this use case, in which RBridges are also MPLS PE
enabled devices. The interworking between the RBridge network and
the MPLS PSN is within the device. This has a similar architecture
to MPLS/VPLS [RFC4762]. In this case, a virtual Ethernet interface
is configured at the RBridge component; an Ethernet encapsulated PW
is configured between two interfaces, which brings up an TRILL link
between two RBridge components. The outer MAC address can be a local
Ethernet address. In this case, the Campus RBridges run in the
client layer and MPLS runs in the Server Layer; RB/PE devices
support both client and server layer control plane and data plane
functions.
*---------* *---------*
| |<---- TRILL Link------->| |
|RB Site A| (Client Layer) |RB Site B|
| +-------+ +---+ +-------+ |
| | RB/PE |-----| P |------| PE/RB | |
| +-------+ +---+ +-------+ |
| |<---------PW ---------->| |
| | (Server Layer) | |
*---------* *---------*
{ PSN }
{ One RBridge Campus }
Figure 2 P2P TRILL-Link over IP/MPLS PSN Use Case II
In both case I and II, the PE treats an RBridge as a generic CE and
has no awareness of TRILL capability on the CE. Use case I enables
the business models when the RBridge campus and Core MPLS may be
operated by different operators or the same operator. In the case of
different operators, the core MPLS operator can sell a VPWS service
to RBridge operator. Use case II provides the model when the RBridge
campus and the core network are operated by the same operator but
use different technologies in each network.
Technically speaking, it is possible to create a specially
designated TRILL encapsulated pseudo wire for point-to-point TRILL
over MPLS. However, the authors think that this is not worth the
effort because of available technologies as mentioned above,
particularly the highly-efficient PPP link technology.
A PW may cross multiple MPLS domains.[RFC5659] In this case,
RBridges connect to T-PEs and it works in the same way as a single
domain. The PSN can provide transport resiliency for a PW. The dual
homing (two ACs) can be used for AC protection. In this case, two
Yong & Eastlake Expires April 23, 2012 [Page 5]
Internet-Draft TRILL over MPLS October 2011
TRILL links are established; RBridge device perform load balance
over two links.
2.2. Multi-Access Link Interconnection
Multiple RBridges may interconnect via an 802.1Q Bridged LAN that
acts as a hub. The bridged LAN simply forwards on the outer Ethernet
header of the TRILL frames. This configuration creates what appears
to each connected RBridge as a multi-access link. In other words,
each RBridge connecting to a bridged LAN has connectivity to every
other RBridges connecting to the same LAN.
MPLS/VPLS can provide the same capability when multiple parts of an
RBridge campus are interconnected over an IP/MPLS PSN and make each
RBridge attaching to the VPLS to appear as having a multi-access
TRILL link. Figure 3 shows the use of MPLS/VPLS for RBridge
interconnection. One RBridge campus is split between three different
sites. One VPLS instance is configured on three PEs and the PWs are
configured for the VPLS instance. Each RBridge Site connects to the
VSI on a PE via an AC (Ethernet Type). The VSI on a PE forwards
TRILL frames based on the outer Ethernet header of the frames.
[RFC6325] Either BGP [RFC4761] or LDP [RFC4762] protocol can be used
to automatically construct the VPLS instance on the PEs. A PE may
connect to several different RBridge campuses that belong to
different customers. Separated VPLS instances are configured for
individual customers and customer traffic is completely isolated by
VPLS instance. The PE treats an RBridge as a generic CE and has no
awareness of TRILL.
Yong & Eastlake Expires April 23, 2012 [Page 6]
Internet-Draft TRILL over MPLS October 2011
*-------* ........................... *-------*
| | . MPLS/VPLS . | |
| RB |AC +----+ PW +----+AC| RB |
| Site 1+---|VSI ********************** VSI|--+ Site 2|
| | | PE ***** ***** PE | | |
| | +----+ **** **** +----+ | |
| | . +*--*+ . *-------*
*-------* ..........|VSI |...........
| PE |
+----+
|AC
|
*---------*
| |
|RB Site 3|
| |
*---------*
Figure 3 Multi-Access TRILL Link over MPLS/VPLS
The outer Ethernet MAC of TRILL frames may be either a next-hop
RBridge MAC address (for unicast frames) or one of TRILL defined
multicast addresses (ALL-IS-IS-RBridges and All-RBridges).[RFC6325]
The VSI at each PE learns the source MAC addresses on each VSI
interface and forward the frame based on the destination MAC. For
the multicast frames, the VSI replicates the frames to all PWs it
associates. If a VPLS is configured with some optimization
capability [VPLS-BCAST], the multicast frames can be delivered over
a point-to-multipoint PW while unicast frames are carried over a
point-to-point PW.
The scenario in Figure 3 can also be extended to multiple RBridges
interconnections when a device serves both RBridge and PE functions.
This use case is discussed in the following section.
Note: If the CEs associated with one VPLS instances happen to
include some RBridges and some end stations or IEEE 802.1Q bridges
to end stations, TRILL will, by default, be able to handle this by
providing both through service and end station service. However, the
end station addresses will be visible to the VPLS instance. If, in
such a case, all the RBridge ports connected to the VPLS are
configured as trunk ports (see Section 4.9.2 of [RFC6325]), then
they will not provide any end station service.
Yong & Eastlake Expires April 23, 2012 [Page 7]
Internet-Draft TRILL over MPLS October 2011
2.3. Hierarchical L2VPN with RBridges and MPLS
H-VPLS in [RFC4762] describes a two-tier hierarchical solution for
the purpose of pseudo wire (PW) scalability improvement. 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. However, H-VPLS solutions in [RFC4762]
require learning and forwarding based on customer MAC addresses,
which poses scalability issues as the number of VPLS instances and
customer MAC addresses increase. [PBB-VPLS] describes how to use PBB
(Provider Backbone Bridges) at the lower-tier access network to
solve the scalability issue, in which the transit network nodes only
learn and forward on PBB port MAC addresses instead of customer MAC
addresses.
RBridges over IP/MPLS provide an alternative solution for a scalable
L2VPN over WAN networks. Figure 4 depicts the hierarchical L2VPN
architecture with RBridge/MPLS technologies. An IP/MPLS network
serves as the top-tier core network function while an RBridge campus
serves as the low-tier access network function. A RB/PE enabled
device is placed at the boundary between the two-tier networks. A PW
is configured between each pair of PE components in the top-tier
IP/MPLS network, which constructs a full mesh TRILL links among the
RB/PE devices. The RBridge component on a RB/PE device and other
RBridges at the same site serves as the low-tier access network.
Customer CEs connect to RBridges at each site directly. This
architecture provides E-LAN or E-VLAN connectivity among customer
CEs connecting to the RBridge campus sites. The transit RBridge node
only forwards and learns other RBridge addresses and the number of
PWs in the top-tier core network is not relate to the number of
devices connecting to Customer CEs. This makes the solution scale
very well. In addition, TRILL technology already supports multi-
TRILL links from one RBridge to one or multiple RBridges and
prevents loops, which provides the flexibility to construct the
networks based on their network condition. Figure 4 shows that one
RBridge in site 1 connects two RB/PE devices and one RB/PE device
connects two RBridges at Site 2 via Ethernet links.
Yong & Eastlake Expires April 23, 2012 [Page 8]
Internet-Draft TRILL over MPLS October 2011
+---------+ ........................... +--------+
| | . IP/MPLS Core . | |
| | . . | +--
CE--+ |Eth+----+ PW +----+ | |
| RBridge +---| RB/|********************| RB/|--+RBridge |CEs
. --+ +-+ | PE |**** ****| PE |\ | +--
. | Site 1 | | +----+ **** **** +----+ -+ Site 2 |
. --+ | | . +*--*+ . | |
| | | ..........| RB/|........... +--------+
CE--+ | +--------------| PE |
| | Eth. Itfc +----+
+---------+ |Eth. Itfc
|
+---------+
| RBrdige |
| |
| Site 3 |
+-+----+--+
|... |
CEs
Figure 4 Hierarchical L2VPN with RBridge and MPLS
The following advantages of using RBridge/MPLS based L2VPN: 1)
Scalability improvement; 2) Auto-configuration; 3) Good efficiency
and loop prevention; and 4) Multipath support.
The solution also has the following advantages: 1) Since RBridge
terminates customer spanning tree protocol (STP), individual STPs in
attached customer bridged LANs will be separated and will converge
faster. 2) low over head per frame in number of added bytes and
scalable routing computations; 3) MPLS just provides P2P PWs, MAC
forwarding and learning does not exist within the MPLS network, thus
multi-homing issue does not exist.
Note: it is good to mention another scenario when the device has
both RB/PE capabilities, i.e. configure a VPLS instance among PE
components in the top-tier network to provide a multi-access link to
RBridge component on the RB/PE devices. Although this solution can
also provide scalability, it requires both the RBridge component and
VSI/PE component on a device to perform the same MAC forwarding and
learning functions, which is redundant. The number of PWs configured
in this case is the same as of the number of PWs in Figure 4. Thus,
authors do not recommend this configuration. For the same reason,
the use case in Section 2.2 is not viewed as the recommended L2VPN
solution for the WAN networks. Instead, it is useful when a Core
Yong & Eastlake Expires April 23, 2012 [Page 9]
Internet-Draft TRILL over MPLS October 2011
Service Provider provides a VPLS service to the customer who needs
to interconnect the RBridge campus sites over IP/MPLS PSN.
It is possible to construct a Tiered L2VPN in the combination of
Figure 4 and 3, i.e. some locations use RB/PE enabled device and
some location use separated RBridge and PE devices in a Hierarchical
L2VPN. When using separated RBridge and PE devices at some
locations, the MPLS network has to run a VPLS instance, which makes
RB/PE devices perform MAC forwarding and learning function two
times. In addition, it becomes operator responsibility to ensure
that the top tiered MPLS core is fully surrounded by an RBridge
campus. Missing configuration may increase the scalability problem
in the core network.
Auto configuration for the Hierarchical L2VPN will be addressed in
another draft.
3. RBridge Behavior for MPLS Pseudo Wire
This section describes RBridge behaviors for TRILL Ethernet or TRILL
PPP links over MPLS pseudo wire (PW) as described in Sections 2.1 .
1. For two RBridge ports connecting via a PPP PW, the ports MUST be
configured as IS-IS point-to-point. Thus TRILL will use IS-IS P2P
Hellos that, per "Point-to-Point IS to IS Hello PDU" (section 9.7
of [IS-IS]), do not use Neighbor TLVs in the same manner as on a
multi-access link. However, per section 4.2.4.1 of [RFC6325],
three-way IS-IS handshake using extended circuit IDs is required.
2. For two RBridge ports connecting via an Ethernet PW, it is
RECOMMENED that the ports be configured as IS-IS point-to-point
for the same reason able. Note: an RBridge port by default
supports multi-access links.
3. Any MPLS forwarder within an MPLS PSN does not change the TRILL
Header Hop Count. RBridges is never aware of the packet
forwarders in MPLS PSN.
4. If it is desired for MPLS PSN to perform QoS in the same way as
in the RBridge campus, RBridges MUST be configured to send an
Outer.VLAN tag on the RBridge port. The PE can then copy the
priority value from the Outer.VLAN tag to the COS filed of the PW
label prior to the forwarding. [RFC5462]
Yong & Eastlake Expires April 23, 2012 [Page 10]
Internet-Draft TRILL over MPLS October 2011
5. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of
[RFC6325]) are not needed on a pseudo wire link. Implementations
MUST NOT send MTU-probe and SHOULD NOT reply to these messages.
The MTU pseudo wire interface parameter SHOULD be used instead.
PE Must configure the MTU size as the originating RBridges Size
specified in Section 4.3.1 of [RFC6325].
4. Security Considerations
The IS-IS authentication mechanism [RFC5304] [RFC5310], at the TRILL
IS-IS layer, can be used to prevent fabrication of link-state
control messages over TRILL links including those discussed in this
document.
For general TRILL protocol security considerations, see [RFC6325].
The use case does not introduce any security considerations for MPLS
network.
5. IANA Considerations
No IANA action is required by this document.
6. Acknowledgements
The authors sincerely acknowledge the contributions of Ben Mack-
Crane and Sue Hares.
7. References
7.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14 and RFC 2119, March 1997
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4447] Martini, L., etc, "Pseudowire Setup and Maintenance Using
the Label Distribution Protocol (LDP)", RFC4447, April
2006.
[RFC4448] Martini, L., "Encapsulation Methods for Transport of
Ethernet over MPLS Networks", BCP 116, RFC 4446, April
2006.
Yong & Eastlake Expires April 23, 2012 [Page 11]
Internet-Draft TRILL over MPLS October 2011
[RFC4618] Martini, L., "Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC) over MPLS
Networks", BCP 116, RFC 4618, September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[RFC4762] Lasserre, M. and Kompella, V, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC4762, January 2007
[RFC5304] Li, T. and Atkinson, R, "IS-IS Cryptographic
Authentication," RFC 5304, October 2008
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009
[RFC5462] Andersson, L. and Asati, R., "Multiprotocol Label
Switching (MPLS)Label Stack entry: "Exp" Field Rename to
"Traffic Class" Field", RFC5462, February 2009
[RFC5659] Bocci, M and Bryant, S, "An Architecture for Multi-Segment
Pseudowire Emulation Edge-to-Edge", RFC 5659, October
2009.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and
A.Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC6325, July 2011.
[RFC6326] Eastlake 3rd, D., Banerjee, A., Dutt, D., Perlman, R., and
Ghanwani, A. "Transparent Interconnection of Lots of Links
(TRILL) Use of IS-IS", RFC6326, July 2011.
[RFC6361] Carlson, J., and D. Eastlake, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC6361, August 2011.
Yong & Eastlake Expires April 23, 2012 [Page 12]
Internet-Draft TRILL over MPLS October 2011
7.2. Informative References
[IS-IS] International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/IEC
10589:2002, Second Edition, Nov 2002
[VPLS-BCAST] Delord, S, and Key, R., "Extension to LDP-VPLS for
Ethernet Broadcast and Multicast", draft-ietf-l2vpn-ldp-
vpls-broadcast-exten-02, work in progress, 2011.
[PBB-VPLS] Sajarssi, A, etc, "VPLS Interoperability with Provider
Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop, work
in progress, 2011
Yong & Eastlake Expires April 23, 2012 [Page 13]
Internet-Draft TRILL over MPLS October 2011
Authors' Addresses
Lucy Yong
Huawei Technologies (USA)
5340 Legacy Drive
Plano, TX 75025
Phone: +1-469-277-5837
Email: lucy.yong@huawei.com
Donald E. Eastlake, 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Sam Aldrin
Huawei Technologies
2330 Centeral Expressway
Santa Clara, CA 95050
Phone: +1-408-330-4517
Email: sam.aldrin@huawei.com
Jon Hudson
Brocade
130 Holger Way
San Jose, CA 95134
Phone: +1-408-333-4062
jon.hudson@brocade.com
Yong & Eastlake Expires April 23, 2012 [Page 14]