TRILL Working Group H. Zhai
Internet-Draft F. Hu
Intended status: Standards Track ZTE
Expires: November 16, 2012 R. Perlman
Intel Labs
D. Eastlake 3rd
Huawei
MAY 15, 2012
RBridge: Pseudo-Nickname
draft-hu-trill-pseudonode-nickname-02
Abstract
At the edg of TRILL campus, some RBridges provide end-station
services to their attached end stations, these RBridges are called
edge RBridges. To avoid potential frame duplication or loops in
TRILL campus, only one edge RBridge is permitted to provide end-
station services in a VLAN x at all times for its attached end
stations. However, in some application scenarios, for example in
Link Aggregation Group (LAG), more than one edge RBridge is required
to provide end-station services to an end stations even in a VLAN,
which causes the flip-flopping of the egress RBridge nickname for
such an end node in remote RBridges' forwarding tables if nothing to
do. In this document, the concept of Virtual RBridge, along with its
pseudo-nickname, is introduced to fix the above problem.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 16, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Zhai, et al. Expires November 16, 2012 [Page 1]
Internet-Draft Pseudo-Nickname MAY 2012
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
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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Appointed Forwarders on Shared Links . . . . . . . . . . . 4
2.2. Multi-homing and Link Aggregation to TRILL Network . . . . 5
3. Concept of Virtual RBridge and Pseudo-nickname . . . . . . . . 6
3.1. VLAN-x Appointed Forwarder for member interfaces in RBv . 7
3.2. Announcing Pseudo-Nickname of RBv . . . . . . . . . . . . 7
4. Distribution Trees for Member RBridges in RBv . . . . . . . . 7
5. Frame Processing . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Native Frames Ingressing . . . . . . . . . . . . . . . 8
5.1.2. TRILL Data Frames Egressing . . . . . . . . . . . . . 9
5.1.2.1. Unicast TRILL Data Frames . . . . . . . . . . . . 9
5.1.2.2. Multi-Destination TRILL Data Frames . . . . . . . 10
5.2. OAM Frames . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhai, et al. Expires November 16, 2012 [Page 2]
Internet-Draft Pseudo-Nickname MAY 2012
1. Introduction
The IETF TRILL protocol [RFC6325] provides optimal pair-wise data
frame forwarding without configuration, safe forwarding even during
periods of temporary loops, and support for multi-pathing of both
unicast and multicast traffic. TRILL accomplishes this by using
[IS-IS] [RFC1195] link state routing and encapsulating traffic using
a header that includes a hop count. The design supports VLANs and
optimization of the distribution of multi-destination frames based on
VLANs and IP derived multicast groups. Devices that implement TRILL
are called RBridges.
In TRILL protocol, RBridges are identified by nicknames (16-bits).
Different RBridge has different nickname(s). At the edge of TRILL
network, some RBridges connect to legacy networks on one side and to
TRILL network on the other side. These RBridges are called edge
RBridges. For the connectivity between the two types of network,
edge RBridges provide end-station services to end stations located in
legacy networks. When receiving a native frame from such a local end
station S, the servicing edge RBridge RB1 encapsulates the frame in a
TRILL header, addressing the packet to RBridge RB2 which the
destination end station D is attached to. The TRILL header contains
an "ingress RBridge nickname" field (RB1's nickname), an "egress
RBridge nickname" field (RB2's nickname), and a hop count. On
receiving such a frame, RB2 removes the TRILL header and forwards it
onto D in its native form. Meanwhile, based on the de-capsulation of
such a frame, RB2 learns the (ingress RBridge nickname, source MAC
address, VLAN ID) triplet. Edge RBridges maintain such triplets in
their forwarding table for the potential following transmission of
native frames.
Due to failures, reconfiguration and other network dynamics,
servicing edge RBridge for S may change, i.e., no longer is RB1. In
this event, remote traffic addressed to S will be still forwarded to
RB1 by remote RBridge RB2 before perceiving this change, and then the
traffic gets dropped at R1, causing traffic disruption. Furthermore,
to improve resiliency and maximize the available network bandwidth,
an end station typically is multi-homed to several edge RBridges and
treats all the uplink links as a Link Aggregation Group (LAG) buddle.
In this scenario, all those edge RBridges work in an active-active
load sharing model to provide end-station services for an end station
even in same VLAN. When remote RBridge RB2 receives different
frames, which are originated by such an end station S and ingressed
into TRILL campus by different such edge RBridge, flip-flopping of
ingress RBridge nickname for MAC of S will be observed by RB2 during
de-capsulating such frames. This flip-flopping will cause disorder
of different frames in traffic, worsening the traffic disruption.
Zhai, et al. Expires November 16, 2012 [Page 3]
Internet-Draft Pseudo-Nickname MAY 2012
In this document, concept of Virtual RBridge group, together with its
Pseudo-nickname, is introduced to address the above issues. For a
member RBridge in such a group, it uses the pseudo-nickname of this
group, instead of its own device nickname, as ingress RBridge
nickname when encapsulating a frame to its TRILL form with a TRILL
header. So, in a RBridge Group, even if there are more than one
RBridge providing end-station services for a end station or the
servicing RBridge changes over from one member RBridge to another in
same set of VLANs, the ingress RBridge nickname for the MAC of this
end station will still remain unchanged in remote RBridges'
forwarding tables.
This document is organized as following: Section 2 is problem
statement, which describes why virtual RBridge and its pseudo-
nickname are required. Section 3 gives the concept of virtual
RBridge. Section 4 describes the consideration for pseudo-nickname
used in ingressing multi-destination frames. Section 5 covers
processing of transit frame traffic when considering pseudo-nickname.
Familiarity with [RFC6325] is assumed in this document.
1.1. Terminology and Acronyms
This document uses the acronyms defined in [RFC6325] and the
following additional acronym:
AF - Appointed Forwarder
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].
When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in
[RFC2119].
2. Problem Statement
2.1. Appointed Forwarders on Shared Links
In TRILL, RBridges can co-exist with legacy bridges in a traditional
Ethernet. A set of links connected by bridges will be perceived by
RBridges as a single shared link connecting the RBridges on that
link. If there are multiple RBridges on a shared link, together with
end stations, only one RBridge is permitted to provide end-station
services in a VLAN x at all times for the end stations to avoid
possible frame duplication or loops in TRILL campus. The service
Zhai, et al. Expires November 16, 2012 [Page 4]
Internet-Draft Pseudo-Nickname MAY 2012
RBridge is called VLAN-x Appointed Forwarder (AF) on a shared link.
However, AF for any set of VLANs on a shared link may change over
from one RBridge to another, due to failure, configurations and other
network dynamics, etc. If such change occurs, local end stations may
not perceive it, so the end station cannot timely notify remote
RBridges to update the correspondence between ingress RBridge
nickname and the MAC of this end station in their forwarding tables.
As a result, remote RBridges may continue to forward traffic to the
previous AF and the traffic may be dropped at the previous egress
RBridge, causing traffic disruption.
2.2. Multi-homing and Link Aggregation to TRILL Network
In order to improve the reliability of connection to TRILL network,
multi-homing technique may be employed by a legacy device, such as a
switch or end host. For example, in Figure 1, switch SW1 multi-homes
to TRILL network by connecting to both RBridge RB1 and RB2 with
respective links. Then the end stations (e.g., S1), attached to SW1,
still get end-station services from TRILL network even if one
connection of SW1 to TRILL network, e.g., SW1-RB1, fails. That is to
say, the service RBridge for S1 changes over from RB1 to RB2 after
the connection of SW1-RB1 fails, which causes traffic disruption
temporarily (e.g., traffic from Sx to S1), similar to AF changing in
Section 2.1.
..........................................
: TRILL Network :
: +-----+ /\-/\-/\-/\-/\ :
+------| RB1 |-----/ \ :
| : +-----+ / \ :
+-----+ : | / Transit \ +-----+ :
S1 o--| SW1 | : | < RBridges >---| RBx |---o Sx
+-----+ : | \ Campus / +-----+ :
| : +-----+ \ / :
+------| RB2 |-----\ / :
: +-----+ \/\-/\-/\-/\-/ :
: :
...........................................
Figure 1 Multi-homing to TRILL Network
Furthermore, SW1 may treat the two links as a LAG (Link Aggregation
Group) bundle, so that the two links form active-active load sharing
model instead of previous active-stanby model. That is to say, in
Figure 1, two service RBridges (e.g., RB1 and RB2) provide end-
station services simultaneously to S1 in that VLAN. And this will
Zhai, et al. Expires November 16, 2012 [Page 5]
Internet-Draft Pseudo-Nickname MAY 2012
result in flip-flopping of the ingress RBridge for the MAC of S1 in
remote RBridges' (e.g., RBx) forwarding tables. AS a result, this
flip-flopping will cause much more disorder packets and worsen the
traffic disruption.
Besides switches, end stations can also directly multi-home to TRILL
network and treat the multi-homing links as a LAG bundle. The issue
of traffic disruption also occurs in this scenario if such an end
station balances different traffic load in a same VLAN among the
member links.
In the following sections, concept of RBridge Group, together with
its nickname, is introduced to fix these issues.
3. Concept of Virtual RBridge and Pseudo-nickname
A Virtual RBridge (RBv) represents a group of different ports on
different edge RBridges, on which these RBridges end-station service
provide to a set of their attached end stations. After joining RBv,
such an RBridge port is called a member port of RBv, and such an
RBridge becomes a member RBridge of RBv. in TRILL campus, an RBv is
identified by its virtual nickname in TRILL campus, and virtual
nickname is also described as pseudo-nickname in this specification.
After joining an RBv, a member RBridge will announce its connection
to RBv by including the information of this RBv, e.g., the pseudo-
nickname of RBv, in its self-originated LSP. From such LSPs, a
remote RBridge that is not a member of RBv can obtain that, through
one or more of such member RBridges, one or more shortest paths are
available from itself to RBv by running Shortest-Path-First (SPF)
algorithm.
When receiving a native frame on such a port, the member RBridge uses
the RBv's nickname, instead of its own nickname, as ingress nickname
in TRILL header if necessary to encapsulate the frame into TRILL data
form. By de-capsulating such a TRILL-encapsulated data frame, a
remote RBridge learns that S is reachable through RBv.
NOTES: An RBridge port can join at most one RBv at any time, but
different ports on the same RBridge can join the same RBv or
different RBvs. After joining an RBv, such a port becomes a member
port of the RBv, and the RBridge becomes a member RBridge of the RBv.
Furthermore, for a member RBridge, it MUST move out of RBv and clear
the RBv's information from its self-originated LSPs when it loses the
last member port from this group, due to port down, configuration,
etc.
Zhai, et al. Expires November 16, 2012 [Page 6]
Internet-Draft Pseudo-Nickname MAY 2012
3.1. VLAN-x Appointed Forwarder for member interfaces in RBv
If member RBridges in RBv cannot see each others' Hellos on their
member interfaces (e.g., in the LAG scenario), then each RBridge
becomes Designated RBridge (DRB) for that interface and appoints
itself as AF for all VLANs as it does not see any TRILL hellos on
that interface.
However, if they can see each others' Hellos on the member interfaces
in RBv (e.g., in the shared link scenario), the TRILL Hello protocol
in RFC 6325 is used for DRB election and for VLAN-x AFs appointment
for those interfaces. Then the DRB appoints different member
interfaces as AFs for different VLANs.
Among the member RBridges of RBv, when receiving a local native frame
in VLAN-x, only the AF for this VLAN can ingress the frame into TRILL
campus if necessary. However, in this specification, when receiving
a TRILL data frame addressed to RBv, an member RBridge that is not AF
for the inner VLAN of the frame can de-capsulate the frame and
forward it in native form directly to the destination end station.
3.2. Announcing Pseudo-Nickname of RBv
Each member RBridge advertises the RBv's pseudo-nickname using the
nickname sub-TLV [rfc6326bis], along with its regular nickname or
nicknames, in its LSPs. When a member RBridge leaves from RBv due to
losing its last member ports in RBv, it MUST clear RBv's pseudo-
nickname from its LSPs.
4. Distribution Trees for Member RBridges in RBv
In TRILL, RBridges use distribution trees to forward multi-
destination frames. When a native frame either to destinations whose
location is unknown or to multicast/broadcast groups is necessary to
be ingressed into TRILL campus, the ingress RBridge encapsulates it
into multi-destination TRILL data frame with a TRILL header and
forwards the TRILL frame along a chosen distribution tree. In the
TRILL header, the ingress nickname identifies the ingress RBridge,
the egress nickname represents the root of the chosen tree. After
receiving a multi-destination TRILL data frame, the RBridge performs
Reverse Path Forwarding (RPF) check, along with other checks, on the
multi-destination frame to further control potentially looping
traffic.
RPF specifies that a multi-destination TRILL data frame ingressed by
an RBridge and forwarded along a distribution tree can only be
received by an RBridge from an expected port. If not from that port,
Zhai, et al. Expires November 16, 2012 [Page 7]
Internet-Draft Pseudo-Nickname MAY 2012
this frame MUST be dropped by the receiving RBridge.
However, member RBridges in RBv employs RBv's pseudo-nickname other
than their own nicknames as ingress nickname when they ingress a
native frame, regardless unicast or multicast frame, into TRILL
campus. So if different member RBridges chose same distribution
tree(s) to forward different multi-destination TRILL data frames,
these frames may reach a remote RBridge from different ports, which
violates the RPF check. Then some of these frames will be dropped by
the remote RBridge.
To fix the above issue, a scalable and resilient approach is proposed
in [cmt], where different member RBridges are assigned different
distribution trees for forwarding the multi-destination TRILL data
frames that using RBv's pseudo-nickname as ingress nickname in their
TRILL header. And a new TLV, named Affinity sub-TLV, is also
introduced for a member RBridge to announce its assigned distribution
tree for RBv in its self-originated LSPs. After receiving such LSPs,
a remote RBridge can calculate RPF check information for RBv on those
specified trees.
In this specification, the approach proposed in [cmt] is employed for
RBv to assign different distribution trees to different member
RBridges (more exactly, to member ports on different member RBridges)
and for these members to announce their assigned trees in LSPs.
5. Frame Processing
Although, there are five types of Layer 2 frames in [RFC6325], e.g.,
native frame, TRILL data frame, TRILL control frames, etc., pseudo-
nickname of RBv is only used for native frame and TRILL data frame in
this specification.
5.1. Data Frames
5.1.1. Native Frames Ingressing
When RB1 receives a native frame on one of its valid member ports of
RBv, it uses the pseudo-nickname of RBv, instead of its own nickname,
as ingress nickname of TRILL header in doing necessary TRILL-
encapsulation on the frame if it is uninhibited appointed forwarder
for the VLAN of the frame on the port. If the frame is not received
on such a port, RB1 MUST NOT use RBv's pseudo-nickname as ingress
nickname when encapsulating the frame with a TRILL header.
Otherwise, the reverse traffic may be forwarded to another member
RBridge that does not connect to the link containing the destination,
which may cause the traffic disruption.
Zhai, et al. Expires November 16, 2012 [Page 8]
Internet-Draft Pseudo-Nickname MAY 2012
If the above native frame is ingressed by RB1 as a multi-destination
TRILL data frame, e.g., its destination is unknown to RB1 or it is
non-unicast frame, RB1 can only choose one of its assigned
distribution trees for RBv to distribute the TRILL-encapsulated
frame[cmt]. If not so, the multi-destination TRILL data frame will
fail RPF check on another RBridge and be dropped.
5.1.2. TRILL Data Frames Egressing
This section describes egress processing of the received TRILL data
frames on member RBridges RBn in virtual RBridge group of RBv.
Section 5.1.2.1 describes unicast TRILL data frames egress
processing. Section 5.1.2.2 covers multi-destination TRILL data
fames egress processing.
5.1.2.1. Unicast TRILL Data Frames
When receiving a unicast TRILL data frame, RBn checks the egress
nickname in the TRILL header of the frame. If the egress nickname is
one of RBn's own nicknames, the frame is processed as Section 4.6.2.4
in [RFC6325].
If the egress nickname is the pseudo-nickname of RBv's in which RBn
is a valid member RBridge, the Inner.MacSA and Inner.VLAN ID are, by
default, learned as associated with the ingress nickname unless that
nickname is unknown or reserved or the Inner.MacSA is not unicast.
If the learned {Inner.MacSA, Inner.VLAN ID, ingress nickname} triplet
is a new one or updated the locally stored one, this triplet is
shared among the members RBridges in virtual RBridge group RBv (See
Appendix A for more details for the triplet sharing).
Then the frame being forwarded is de-capsulated to native form. The
Inner.MacDA and Inner.VLAN ID are looked up in RBn's local address
cache, and one of the three following cases occurs:
o If the destination end station identified by the Inner.MacDA and
Inner.VLAN ID is on a local links to RBv, this frame is sent onto
the link containing the destination.
o else if RBn can reach the destinaiton through another RBridge RBm,
it re-encapsulate the native frame into a unicast TRILL data frame
and sends it to RBk. RBn uses RBk's own nickname, instead of
RBv's pseudo-nickname for the re-encapsulation, and remains the
ingress nickname unchanged.
o Else, RBn does not know how to reach the destination; it sends the
native frame out of all its member ports of RBv.
Zhai, et al. Expires November 16, 2012 [Page 9]
Internet-Draft Pseudo-Nickname MAY 2012
NOTE: In the first and third case, whether RBn is the appointed
forwarder for the frame's VLAN on the link(s) or not, it sends the
unicast frame onto the link(s).
5.1.2.2. Multi-Destination TRILL Data Frames
If the RBn is an appointed forwarder for the Inner.VLAN ID of the
frame, the Inner.MacSA and Inner.VLAN ID are, by default, learned as
associated with the ingress nickname unless that nickname is unknown
or reserved or the Inner.MacSA is not unicast. If the learned
{Inner.MacSA, Inner.VLAN ID, ingress nickname} triplet is a new one
or updated the locally stored one, this triplet is shared among the
members RBridges in virtual RBridge group RBv (See Appendix A for
more details for the triplet sharing).
Then a copy of the frame is de-capsulated into its native form.
Before the native frame is sent out of ports on which RBn is
appointed forwarder for the frame's VLAN, the following extra check
is performed:
o Assigned Distribution Trees Check (ADT)GBPoIf the flag for this
check (ADT_flag) is not zero on such a port, the distribution tree
T on which the TRILL data frame arrives at RBn is checked. Only
if T is one of RBn's assigned distribution trees in RBv, the
native frame can be send out of this port. If not, the frame
cannot be sent out of this port.
The value of ADT_flag on a RBridge's end-station-servicing port
depends on whether the port is a member port of RBv and RBn is the
appointed forwarder for all VLANs on this port or not. If so, the
ADT_flag on this port MUST be set zero. Otherwise, ADT_flag MUST NOT
be set zero.
5.2. OAM Frames
For member RBridges, when they originate TRILL OAM frames, they MUST
NOT use RBv's pseudo-nickname as ingress nickname in this frame's
TRILL header. Otherwise, it is possible that the reverse OAM message
is not able to return to the original member RBridge, resulting in
the OAM session disruption.
6. IANA Considerations
TBD.
Zhai, et al. Expires November 16, 2012 [Page 10]
Internet-Draft Pseudo-Nickname MAY 2012
7. Security Considerations
TBD.
8. Acknowledgements
We would like to thank Mingjiang Chen for his contributions to this
document. Additionally, we would like to thank Erik Nordmark, Les
Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Mingui Zhang,
Janardhanan Pathang, Jon Hudson, and Tissa Senevirathne for their
good questions and comments.
9. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[cmt] Senevirathne, T., Pathangi, J., and J. Hudson,
"Coordinated Multicast Trees (CMT)for TRILL",
draft-ietf-trill-cmt-00.txt Work in Progress, April 2012.
[rfc6326bis]
Eastlake 3rd, D., Banerjee, A., Ghanwani, A., and R.
Perlman, "Transparent Interconnection of Lots of Links
(TRILL) Use of IS-IS",
draft-eastlake-isis-rfc6326bis-07.txt Work in Progress,
March 2012.
Zhai, et al. Expires November 16, 2012 [Page 11]
Internet-Draft Pseudo-Nickname MAY 2012
Authors' Addresses
Hongjun Zhai
ZTE
68 Zijinghua Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Phone: +86 25 52877345
Email: zhai.hongjun@zte.com.cn
Fangwei Hu
ZTE
889 Bibo Road, Pudong District
Shanghai, Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Radia Perlman
Intel Labs
2200 Mission College Blvd
Santa Clara, CA 95054-1549
USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Donald Eastlake 3rd
Huawei
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Zhai, et al. Expires November 16, 2012 [Page 12]