Internet DRAFT - draft-zhai-esadi-extension-for-rbv
draft-zhai-esadi-extension-for-rbv
TRILL Working Group HJ. Zhai
Internet-Draft XH. Dai
Intended status: Standards Track ZTE Corporation
Expires: March 25, 2013 September 21, 2012
RBridge: ESADI-Extension
draft-zhai-esadi-extension-for-rbv-00
Abstract
In a virtual RBridge(RBv), traffic from end station ES1 to ES2 will
enter a TRILL campus through one member RBridge RB1 of RBv, but
reverse traffic might choose another member RBridge RB2 to leave
TRILL campus. If RB1 can't obtain the location of ES2 via other
means, it has to treat the traffic to ES2 as unknown destination
traffic and multicasts it in TRILL campus. However, if RB2 can share
its learned MAC addresses with RB1, the above problem can be
resolved.
Based on appropriate extensions of ESADI, this document proposes, in
control plane, an approach for informations synchronization within a
group of RBridges. Current informations mainly include end station
addresses, but may include other informations in the future.
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 March 25, 2013.
Copyright Notice
Copyright (c) 2012 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
Zhai & Dai Expires March 25, 2013 [Page 1]
Internet-Draft ESADI-Extension for RBv September 2012
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
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Contributing authors . . . . . . . . . . . . . . . . . . . . . 4
4. Problems Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. ESADI Extensions . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. General Extension . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Transmitting an Extended ESADI Frame . . . . . . . . . 7
5.1.2. Receiving an Extended ESADI Frame . . . . . . . . . . 8
5.2. Extension for MAC Address Sharing . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhai & Dai Expires March 25, 2013 [Page 2]
Internet-Draft ESADI-Extension for RBv September 2012
1. Introduction
In TRILL, MAC flip-flopping problem will occur in case of service
edge RBridge failure or other network unrest, this problem will be
worsened under LAG or multi-homing scenario, please see section 1 in
[DraftPN] for detailed descriptions. so virtual RBridge(RBv), along
with its pseudo-nickname(s), is introduced to TRILL to address these
problems. An RBv represents a group of different RBridge ports
through which member RBridges provide end-station services to a set
of their attached end stations, Member RBridges announce their
attachment to RBv in their LSP packets, then, based on these LSPs,
other RBridges can compute the optimal path(s) to RBv.
However, the RBv mechanism may cause new problems in frame
forwarding. For example, Native traffic from ES1 to ES2 will enter a
TRILL campus through RB1 in an RBv, but the reverse traffic (i.e.,
traffic from ES2 to ES1) leaves the TRILL campus through RB2 in this
RBv. Then RB1 loses the chance to learn where ES2 is in data plane.
If RB1 has no other ways to get the location of ES2, it will have to
always treat the traffic from ES1 to ES2 as unknown unicast traffic
and multicast it in TRILL campus. Furthermore, if RB2 does not know
the location of ES1 and its link to ES1 fails, ES1 can't receive
expected traffic even if RB1 has an active link to ES1.
So, we propose to share MAC address informations among member
RBridges in a group ,such as an RBv, to address the forwarding
problems above. Information shared may not limit to MAC addresses,
it may include other informations as the progressing of TRILL in the
future. On the other hand, this information sharing is not bound to
RBv , it may be used in other RBridge group cases, such as Border
RBridges of an area in multi-level [MultiTRILL] [DraftDefault].
Since ESADI protocol[RFC6325][ESADI] provides a way that an RBridge
can announce and learn end station addresses, we can reuse it for
information sharing. However, at current, it is VLAN scoped, if an
ESADI RBridge wants to share its end station addresses in several
VLANs, it must enable several ESADI instances, each per VLAN.
Furthermore, the current ESADI protocol can only be used to
distribute MAC addresses of local end stations connected to the
originating RBridge. In order to share informations within a group
of RBridges as well as information of remote end stations, ESADI
should be extended to some extent.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Zhai & Dai Expires March 25, 2013 [Page 3]
Internet-Draft ESADI-Extension for RBv September 2012
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.1. Abbreviations
ES: End Station
ESADI: End Station Address Distribution Information
LAG: Link Aggregation Group
3. Contributing authors
Thanks Ting Liao and Bo Wu for their discussions and inputting.
4. Problems Statement
With the introduction of virtual RBridge, MAC flip-flopping problem
in LAN or LAG can be resolved, for more informations on virtual
RBridge, please refer to [DraftPN]. However, some new problems may
occur with the introduction of RBv. For example, see Figure 1 shown
below.
Zhai & Dai Expires March 25, 2013 [Page 4]
Internet-Draft ESADI-Extension for RBv September 2012
ES2
O
|
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
^ | ^
^ +-------+ ^
^ | RBn | TRILL ^
^ +-------+ CAMPUS ^
^ | ^
^ * * * * * * * * * * * ^
^ * * ^
^ * other RBridges * ^
^ * * ^
^ * * ^
^ * * * * * * * * * * * ^
^ | | ^
^ +------+ +-----+ ^
^ | RB1 | | RB2 | ^
^ +------+ + ----+ ^
^ \............/ ^
^ ^ ^ ^ ^ ^:\ RBv /:^ ^ ^ ^ ^ ^ ^ ^
:\......../:
\ /
O
ES1
Figure 1 RBv in LAG scenario
Native frames from ES1 to ES2 will enter the TRILL campus through one
member RBridge of the RBv, such as RB1 in Figure 1, so RB1 has ES1's
MAC address; but with regard to traffic returns from ES2 to ES1, RBx
excutes SPF and finds that the shortest path to this RBv is through
RB2. If the link between RB2 and ES1 fails, and RB2 does not know
how to reach ES1 for lack of MAC address of ES1, the received traffic
will not be transmitted to ES1 properly by RB2.
Thus, the MAC addresses of locally attached end stations on a member
RBridge SHOULD be shared among all other member RBridges in an RBv.
With these shared informations, if RB2 receives native frames
destinationed to ES1, it can determine how to forward these frames to
ES1.
Furthermore, if the link between RB2 and ES1 is good, the reverse
traffic will be egressed out of TRILL by RB2. Then RB2 learns the
location of ES2 by decapsulating such traffic into its native form.
If RB1 has no other ways to get the location of ES2 and RB2 does not
share this information with RB1, RB1 will not know where ES2 is.
Then it has to always treat the traffic from ES1 to ES2 as unknown
Zhai & Dai Expires March 25, 2013 [Page 5]
Internet-Draft ESADI-Extension for RBv September 2012
unicast traffic and multicast it in TRILL if it is responsible to
ingress such traffic. Always multicasting such traffic adds
additional forwarding burden on TRILL network.
Therefore, in addition to local attached end station MAC addresses,
the learned remote MAC addresses should also be shared among all
member RBridges in an RBv. With the shared information, RB1 can
unicast traffic from ES1 to ES2 through the TRILL campus.
5. ESADI Extensions
As described before, current ESADI is based on VLAN, and only
destributes MAC addresses of locally attached end stations. In order
to be used to solve the above problems, ESADI defined in [RFC6325]
and [ESADI] should be extended to a certain extent. In the following
sections, we call ESADI defined in [RFC6325] and [ESADI] as base
ESADI.
Extended ESADI definded in this document is used on a group base,
such as an RBv, and can be used to distribute MAC address &VLAN
informations of locally attached end stations as well as learned MAC
addresses & VLAN of remote end stations. The following sections will
give detailed extensions on base ESADI.
5.1. General Extension
If member RBridges want to share informations (such as the learned
MAC addresses) within the scope of their RBridge group (such as an
RBv), each of them should create and enable a separate ESADI instance
for that group, we call this kind of ESADI instance as non-VLAN-
scoped ESADI instance. Then the shared informations can be carried
in the ESADI frames originated by that instance and be flooded to
other member RBridges. In the payload of those frames, the nickname
of the group is also carried to indicate the scope in which the
informations are expected to share.
When receiving such frames, if the RBridge is (1) interested in the
specified group, (2) implements this ESADI protocol extension, and
(3) has an enabled ESADI instance for that group, the inner frame is
decapsulated and provided to that local ESADI instance. Then the
shared informations carried in the frames are learned by the RBridge.
Otherwise, the shared informations carried in those frames SHOULD not
be learned.
Similar to ESADI instances for a VLAN, it appears to the instance for
a group at one RBridge that it is directly connected by a multi-
access virtual link to all other member RBridges in the group running
Zhai & Dai Expires March 25, 2013 [Page 6]
Internet-Draft ESADI-Extension for RBv September 2012
ESADI for that group. From all the instances on the virtual link,
one is selected as ESADI-DRB to send ESADI-CSNPs periodically to keep
Link State Database synchronized among its neighbors on that virtual
link. After receiving an ESADI-PSNP PDU, the DRB will send the
ESADI-LSPs requested by the ESADI-PSNP on the virtual link. The
winner is the instance with the highest ESADI priority with System ID
as tie-breaking.
5.1.1. Transmitting an Extended ESADI Frame
Transmitting an extended ESADI frame is similar to base ESADI
protocol, except differences described below.
First, there are two methods to send such extended ESADI frames, with
these methods, a receiving RBridge can distinguish such frames from
the base ESADI frames:
1. Unicast method:
In an ESADI frame originated by a VLAN-scoped ESADI instance,
the VLAN specified in the Inner.VLAN information is the VLAN
to which this ESADI frame applies, and neither 0x0 nor 0xFFF
is a valid value for Inner.VLAN. When a VLAN-scoped ESADI
instance receives an ESADI frame with an invalid Inner.VLAN,
it discards the frame. Maybe the two values might be used as
value of Inner.VLAN in the frame originated by a non-VLAN-
scoped ESADI instance. Since VLAN ID 0xFFF is reserved, we
proposed 0x0 is used as one method for this purpose in this
document.
For a non-VLAN-scoped ESADI instance, if 0x0 is used as
Inner.VLAN, ESADI frames can be only unicast to its neighbors;
since 0x0 is not a valid Inner.VLAN in multi-destination TRILL
frames (which include ESADI frames), ESADI frames with 0x0 as
Inner.VLAN may be discarded by a transit RBridge.
Except for Inner.VLAN, other fields in Inner Ethernet header
of such a frame are as same as those of VLAN-scoped ESADI
frame.
2. Multicast method:
In basic ESADI protocol, a VLAN-scoped ESADI instance MUST use
a globally unique unicast MAC address as the Inner.MacSA in
its originated multi-destination ESADI frames. Therefore, a
non-unicast MAC address can be employed by a non VLAN-scope
ESADI instance to indicate its multi-destination frames are
not VLAN-scoped. In this document, we propose the multicast
Zhai & Dai Expires March 25, 2013 [Page 7]
Internet-Draft ESADI-Extension for RBv September 2012
MAC address of ALL-Egress-Address for this purpose. For such
a frame, while any valid VLAN ID can be used as Inner.VLAN in
such a frame, we RECOMMEND that VLAN ID 1 is used as
Inner.VLAN since it is a default VLAN supported by all
RBridges. Then a non-VLAN-scoped ESADI instance can multicast
such ESADI frames to its neighbors for the necessary
informations sharing.
Except for proposed Inner.MacSA and the recommended VLAN ID,
other fields in Inner Ethernet header of such a frame are the
same as those of VLAN-scoped ESADI frame.
Notes: an RBridge may use unicast method to send extended
ESADI frames to each member in a same group if there are few
members in this group; otherwise, if there are larger numbers
of RBridgs in this group, we suggest using multicast method.
Second, an extended ESADI frame MUST carry a group TLV in its payload
to indicate the group to which the ESADI frame applies, and this TLV
contains the nickname of the group. This TLV MUST be the first TLV
in payload of each of such ESADI frames (such as ESADI-LSPs, ESADI-
PSNP and ESADI-CSNP if the originator believes it is ESADI-DRB), then
it is convenient for an RBridge to decide which the extended ESADI
instance is proper to process the frame when receiving it.
5.1.2. Receiving an Extended ESADI Frame
For an RBridge RBn, when receiving a TRILL frame, it does the general
examinations (specified in Section 4.6.2 of RFC6325) on the frame.
If it confirms the frame is an ESADI frame, that is, Inner.MacDA is
the ALL-Egress-Address multicast MAC address, and then the following
additional tests are done:
o If M=0 and the egress nickname is not that of RBn, the frame is
forwarded as known unicast TRILL data frame. If M=0 and the
egress nickname is that of the receiving RBridge, then the frame
is de-capsulated and processed locally. The Inner.VLAN is
examined, if being not 0x0, the frame is a VLAN-scoped ESADI frame
and provided to its associated local ESADI instance. If being
0x0, the frame is a non-VLAN-scoped ESADI frame, then the first
TLV in payload is checked. If it is a group TLV, the frame is a
group-scoped ESADI frame and the frame is provided to the
interested group-scoped ESADI instance.
o If M=1, the frame is a multicast ESADI frame and is forwarded down
the tree specified by the egress RBridge nickname. In addition,
the Inner.MacSA is examined. If it is a unicast MAC address, the
frame is a VLAN-scoped ESADI frame and provided to its associated
Zhai & Dai Expires March 25, 2013 [Page 8]
Internet-Draft ESADI-Extension for RBv September 2012
local ESADI instance. If Inner.MacSA is ALL-Egress-Address, the
frame is not a VLAN-scoped ESADI frame, then the first TLV in
payload is checked. If it is a group TLV, the frame is a group-
scoped ESADI frame and the frame is provided to the interested
group-scoped ESADI instance.
5.2. Extension for MAC Address Sharing
In order to realize MAC address sharing within a group of RBridges,
we reuse the MAC reachability TLV defined in [RFC6165] and [ESADI] to
carry MAC addresses of attached end stations. And the main
differences covers the nickname and the VLAN ID fields in the MAC
Reachability TLV, please see the following paragraph.
There are two cases on the MAC addresses in MAC Reachability TLV, one
is that the MAC addresses are addresses of local attached end
stations; the other is MAC addresses of end stations attached to a
remote RBridge. When transmitting an extended ESADI frame, for the
former case, a MAC Reachability TLV might not contain a nickname, if
must have one, this should be the device nickname of the originating
RBridge; For the latter case, the nickname in a MAC Reachability TLV
is the egress nickname of the end station identified by the MAC
address. So when an RBridge receives a group-scoped ESADI frame, it
can learn the location of the end station, i.e, if a MAC Reachability
TLV contains a nickname, then the end station is attached to the
RBridge identified by this nickname, otherwise, to the RBridge
identified by the ingress nickname in TRILL header.
In this document, it is RECOMMENDED that the preference of MAC
addresses learned through group-scoped ESADI instance frames is lower
than those learned from local native frames.
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
8. Acknowledgements
TBD
Zhai & Dai Expires March 25, 2013 [Page 9]
Internet-Draft ESADI-Extension for RBv September 2012
9. References
9.1. Normative References
[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.
[ESADI] Zhai, H., Hu, F., Eastlake 3rd, D., and R. Perlman, "TRILL
(Transparent Interconnection of Lots of Links): The ESADI
(End Station Address Distribution Information) Protocol",
draft-ietf-trill-esadi-00.txt Work in Progress, June 2012.
[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.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
9.2. Informative References
[DraftDefault]
Senevirathne, T., Pathangi, J., Hudson, J., Aldrin, S.,
Banerjee, A., and S. Merchant, "Default Nickname Based
Approach for Multilevel TRILL",
draft-tissa-trill-multilevel-00.txt Work in Progress,
February 2012.
[DraftPN] Zhai, H., Hu, F., Eastlake 3rd, D., and R. Perlman,
"RBridge: Pseudo-Nickname",
draft-hu-trill-pseudonode-nickname-03.txt Work in
Progress, Aug 2012.
[MultiTRILL]
Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai,
"Multilevel TRILL (Transparent Interconnection of Lots of
Links)",
draft-perlman-trill-rbridge-multilevel-04.txt Work in
Progress, May 2012.
Zhai & Dai Expires March 25, 2013 [Page 10]
Internet-Draft ESADI-Extension for RBv September 2012
Authors' Addresses
Hongjun Zhai
ZTE Corporation
68 Zijinghua Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: zhai.hongjun@zte.com.cn
Xuehui Dai
ZTE Corporation
Email: dai.xuehui@zte.com.cn
Zhai & Dai Expires March 25, 2013 [Page 11]
