TRILL H. Zhai
Internet-Draft F. Hu
Intended status: Standards Track ZTE Corporation
Expires: January 5, 2012 Radia. Perlman
Intel Labs
Donald. Eastlake 3rd
Huawei technology
Jul 4, 2011
RBridge: Pseudonode Nickname
draft-hu-trill-pseudonode-nickname-00.txt
Abstract
The Appointed Forwarder on a link for VLAN-x is the RBridge that
ingresses native frames from the link and egresses native frames to
the link in VLAN-x. If the appointed forwarder for an end station is
changed, the remote data traffic to the end station could fail. This
document is proposed to assign a nickname for pseudonode identifying
a multi-access link to solve the issue. When any appointed forwarder
encapsulates a packet, it uses the pseudonode nickname as "ingress
nickname" rather than its own nickname. If it does, then if the
appointed forwarder changes, or the DRB changes, and the pseudonode
still uses the same nickname, then the remote RBridge caches won't
need to change, and the data traffic to the end station would reach
the link uninterruptedly.
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 January 5, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Zhai, et al. Expires January 5, 2012 [Page 1]
Internet-Draft Pseudonode Nickname Jul 2011
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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Pseudonode Nickname . . . . . . . . . . . . . . . . . . . . . 4
3. LSP Announcement . . . . . . . . . . . . . . . . . . . . . . . 4
4. Unicast TRILL Data Frames Processing . . . . . . . . . . . . . 5
4.1. Ingress processing . . . . . . . . . . . . . . . . . . . . 5
4.2. Egress processing . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Unicasting to VLAN-x Forwarder . . . . . . . . . . . . 6
4.2.2. Multicasting to VLAN-x forwarder . . . . . . . . . . . 6
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . . 7
5. TLV Extensions for Pseudonode Nickname . . . . . . . . . . . . 8
5.1. Pseudonode Nickname Capability in Hellos . . . . . . . . . 8
5.2. Pseudonode Nickname TLV . . . . . . . . . . . . . . . . . 9
5.2.1. Pseudonode Nickname TLV in Hellos . . . . . . . . . . 10
5.2.2. Pseudonode Nickname TLV in DRB's LSPs . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative references . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhai, et al. Expires January 5, 2012 [Page 2]
Internet-Draft Pseudonode Nickname Jul 2011
1. Problem Statement
The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data
frame forwarding without configuration, safe forwarding even during
periods of temporary loops, and support for multipathing 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.
The AF (Appointed Forwarder) on a link for VLAN-x is the RBridge that
ingresses native frames from the link and egresses native frames to
the link in VLAN-x. If the appointed forwarder for an end station
goes down and a different RBridge is appointed as appointed forwarder
on the link, the end station will not perceive the changes.Therefore,
the cache in remote RBridge could not be correct until it receives
the data traffic from the end station, and the traffic from the
remote RBridge to the end station could fail for a while. It is even
worse for the Swap Nickname Field approach in multi-level TRILL
network, for the egress RBridge of remote level 1 area cannot update
the correspondence of MAC/VLAN-x and the pair of {ingress nickname,
swap ingress nickname} until it receives the data traffic from end
station [MultilevelTrill].
Pseudonode nickname is proposed in this document to solve the above
issue. Pseudonode nickname is assigned by DRB and used to identify a
multi-access link. With pseudonode nickname, the data traffic to the
end station can reach the destination link uninterruptedly and be
forwarded to the end station by other RBridge even if the appointed
forwarder for the VLAN on the link is changed.
The pseudonode nickname is only used in unicast data traffic and not
used in multicast data traffic in this document. For the multicast
data traffic, the data traffic goes through the distribution tree,
and all the RBridge with the same VLAN can receive the multicast
traffic.
This document is organized as following: Section 2 is the concept of
pseudonode nickname. Section 3 introduces the LSP announcement
mechanism for the pseudonode nickname. Section 4 describes the
ingress, transit and egress RBridge processing of the TRILL data
traffic when considering pseudonode nickname. Section 5 specifies
pseudonode nickname capability TLV and pseudonode nickname TLV
format.
Zhai, et al. Expires January 5, 2012 [Page 3]
Internet-Draft Pseudonode Nickname Jul 2011
2. Pseudonode Nickname
Pseudonode nickname is used to identify a link. It is assigned by
DRB on the link. When the RBridge becomes DRB and it doesn't find
the pseudonode nickname from TRILL Hello of other RBridges, DRB
assigns and announces a pseudonode nickname in its TRILL Hello on the
link. If the new DRB obtains the pseudonode nickname from the TRILL
Hellos of adjacent RBridges on the link, it reuses this nickname.
The nickname for the pseudonode should keep unchanged even if the DRB
or AF changed.
All the RBridges on the link should support pseudonode nickname,
otherwise the RBridges that don't understand pseudonode nickname on
the link cannot forward the encapsulated TRILL frame with pseudonode
nickname. Each RBridge on the link announces its pseudonode nickname
capability in its TRILL Hello. Only if DRB checks that all the
adjacencies in Report state support and enable the pseudonode
nickname capability, DRB assigns pseudonode nickname on the link. If
not, DRB MUST NOT announce the pseudonode nickname in its pseudonode
LSP in the TRILL campus network, otherwise, the remote data traffic
may be forwarded to the RBridge without pseudonode nickname
capability, and be discarded in the RBridge.
The bypass pseudonode bit is used to determine whether DRB should
generate the pseudonode LSP. When bypass pseudonode bit is reset,
the DRB should support pseudonode function and generate the
pseudonode LSP [TrillAdj]. So if DRB assigns pseudonode nickname on
the link, the bypass pseudonode bit MUST be reset in its TRILL Hello.
3. LSP Announcement
Pseudonode nickname is only announced in the DRB's pseudonode LSP in
the TRILL Network. If one of the RBridges on the link is disabled of
the pseudonode nickname function, that is, DRB receives a TRILL Hello
without pseudonode nickname capability from the port on the link, the
pseudonode nickname function should be disabled on the link, and then
DRB updates its pseudonode LSP which doesn't include pseudonode
nickname TLV in the TRILL campus network. While if an RBridge (not
DRB) supporting pseudonode nickname joins into or exits from the link
, it is no influence to the pseudonode nickname LSP originated by
DRB. If an RBridge is selected as new DRB and the pseudonode
nickname capability on the link is confirmed, it will generate and
flood pseudonode LSP including the pseudonode nickname TLV in the
TRILL campus network.If DRB finds that the pseudonode nickname
function is disabled on the link, it will updates its pseudonode LSP
which doesn't include pseudonode nickname TLV in the TRILL campus
network.
Zhai, et al. Expires January 5, 2012 [Page 4]
Internet-Draft Pseudonode Nickname Jul 2011
The pseudonode nickname is participated in path computing. The
procedure of path computing of pseudonode nickname is same as the
routing computing of IPv4 or IPv6 address in layer 3 IS-IS
network[RFC1195].
4. Unicast TRILL Data Frames Processing
The processing of TRILL data frames on ingress and egress RBridges
will be influenced when the pseudonode nickname capability is enabled
on the link. However, the processing on transit RBridges remains
unchanged.
Section 4.1 covers the changes of processing TRILL data frames on a
pseudonode nickname participated ingress RBridge. Section 4.2
describes two methods to process TRILL data frames on egress RBridge.
4.1. Ingress processing
When a VLAN-x tagged native frame is sent onto a multi-access link,
only the appointed forwarder for that VLAN-x can ingress this frame
into TRILL campus. If the pseudonode nickname capability is enabled
on the link, the forwarder will encapsulate the frame with a TRILL
header, where the ingress nickname is the pseudonode nickname rather
than RBridge's nickname on the link. The encapsulation of the native
frame is as same as Section 4.1 in [RFCtrill] except for the ingress
nickname in TRILL header.
4.2. Egress processing
On receiving a unicast TRILL data frame, the egress nickname in the
TRILL header is examined, and if it is unknown or reserved, the frame
is discarded. Then the Inner.VLAN ID, i.e., VLAN-x, is checked. If
it is 0x0 or 0xFFF, the frame is discarded.
This RBridge will be the egress RBridge for the TRILL data frame, if
the egress nickname is one of the RBridge's nicknames or one of the
pseudonode nicknames of the connected links. If the egress RBridge
is the VLAN-x forwarder on the destination link for this TRILL data
frame, the frame is processed and the original self-learning is
performed by this RBridge as described in [RFCtrill]. Otherwise, the
frame will be re-encapsulated and transmitted on the link by the
egress RBridge. Only the VLAN-x forwarder can decapsulate the TRILL
data frame to native form and forward it to the end station on the
link, which is consistent with the principle of ingressing and
egressing native frame into and out of TRILL campus, i.e., there is
only a single RBridge on each link that is in charge of ingressing
and egressing native frames from and to that link[TrillAdj].
Zhai, et al. Expires January 5, 2012 [Page 5]
Internet-Draft Pseudonode Nickname Jul 2011
There are two methods for the egress to transmit the re-encapsulated
TRILL data frame to VLAN-x forwarder on the link. In section 4.2.1,
the egress unicasts the re-encapsulated TRILL data frame to the
VLAN-x forwarder, and in 4.2.2, the egress multicasts the TRILL data
frame on the link.
4.2.1. Unicasting to VLAN-x Forwarder
To make the final hop, i.e., the egress RBridge (not VLAN-x
forwarder), work for a frame addressed to the pseudonode, the
forwarding table has to be based on {nickname, VLAN}, instead of
{nickname} currently. In the couple of {nickname, VLAN}, nickname is
the pseudonode nickname, and VLAN is the VLAN Id of VLAN-x forwarder
on this link. If there are several appointed forwarders, each for a
VLAN, on this link, several entries exist in the forwarding table,
each for a forwarder. In the couple of {nickname, VLAN}, the VLAN
will be ignored if the nickname is not a pseudonode nickname on one
of local links, and will be set to invalid value(such as 0x0 or
0xFFF). In other words, if the VLAN in an entry is invalid, the
nickname is not a pseudonode nickname.
If the RBridge is not VLAN-x forwarder on the link, it goes to its
forwarding table that says, based on the pseudonode nickname and
VLAN-x Id, which of its RBridge neighbors, i.e., VLAN-x forwarder on
this link, to forward to. The forwarder is identified by the next
hop MAC address in the found entry from the above table, which is one
of the unicast MAC addresses on one of its ports connected directly
on this link. The TRILL data frame is discarded if no entry is
found. Otherwise, the outer frame header of the TRILL data frame is
stripped, the TRILL header remains unchanged, and a new outer frame
header is prepended before the frame is forwarded to the VLAN-x
forwarder on the link. For the forwarded frame, the Outer.MacSA is
the MAC address of the transmitting port on the destination link, the
Ouer.MacDA is the next hop MAC address in the found entry and the
Outer.VLAN is the designated VLAN on the destination link.
If the above re-encapsulated TRILL data frame is received by a stale
VLAN-x forwarder on the destination link, it will be dropped by the
RBridge. Otherwise, the re-encasulated frame is processed as
[RFCtrill], and the Inner.MacSA and Inner.VLAN ID are, by default,
learned as associated with the ingress nickname unless that nickname
is unknown.
4.2.2. Multicasting to VLAN-x forwarder
Alternatively, a special multicast MAC address, named "AF RBridges on
this link", can be introduced for the final hop to forward such a
TRILL data frame. The scope of the above MAC is limited to local
Zhai, et al. Expires January 5, 2012 [Page 6]
Internet-Draft Pseudonode Nickname Jul 2011
link, just as the MAC for IS-IS hello PDUs. If a TRILL data frame is
addressed to this special MAC and transmitted on a link, all the
Appointed Forwarder (AF) RBridges on the link will process it to some
extent.
With "AF RBridges on this link", the forwarding table remains
unchanged in form, i.e., still based {nickname}. For an entry, the
next hop MAC address will be "AF RBridges on this link", if the
nickname is the pseudonode nickname on one of local links. In other
words, if the nickname is a pseudonode nickname, the next hop MAC
MUST be "AF RBridges on this link".
If not VLAN-x forwarder, the final hop RBridge, RBn, looks up its
forwarding table, based on the egress nickname in TRILL header of the
received frame. The frame will be discarded if no entry is found.
Otherwise, RBn will re-encapsulate the frame, i.e., strip the outer
frame header, remain the TRILL header unchanged, prepend a new outer
frame header before the frame is transmitted onto the link. For the
forwarded frame, the Outer.MacSA is one unicast MAC address on the
transmitting port connected to the link, the Ouer.MacDA is the next
hop MAC address in the found entry and the Outer.VLAN is the
designated VLAN on the link. If the egress nickname is pseudonode
nickname, the Outer.VLAN is "AF RBridges on this link" and the re-
encapsulated TRILL data frame is multicasted onto the link.
The TRILL data frame with "AF RBridges on this link" as Ouer.MacDA is
discarded by other RBridges, which are not AF RBridges, on the link.
Otherwise, the Inner.VLAN ID, i.e., VLAN-x, is checked. If the VLAN
ID is not valid or the receiving RBridge, RBi, is not VLAN-x
forwarder on this link, the frame is also discarded. Else, the TRILL
data frame is decapsulated into native form and forwarded to the
destination end station, and the Inner.MacSA and Inner.VLAN ID are
also, by default, learned as associated with the ingress nickname
unless that nickname is unknown by RBi.
4.2.3. Comparison
With the Unicasting method described in Section 4.2.1 above, the re-
encapsulated TRILL data frame by the final hop RBridge is only
processed by the VLAN-x forwarder on the link, which can reduce the
burden of other RBridges as much as possible. But the forwarding
table on ingress/egress SHOULD be changed to be based on {nickname,
VLAN}, instead of {nickname}, where each AF Rbridge on a local link
is identified by the pseudonode nickname and the vlan id of the AF on
the link.
With Multicasting method described in Section 4.2.1 above, although
all the AF RBridges, except for the final hop RBridge, on the link
Zhai, et al. Expires January 5, 2012 [Page 7]
Internet-Draft Pseudonode Nickname Jul 2011
are required to process, to some extent, the re-encapsulated TRILL
data frame, only the VLAN-x forwarder decapsulates the frame to its
native form and forwards it to the destination end station. However,
the forwarding table can remain the same as current table in form,
i.e., only based on {nickname}.
5. TLV Extensions for Pseudonode Nickname
5.1. Pseudonode Nickname Capability in Hellos
The Pseudonode nickname capability of an RBridge MUST be included in
one subTLV of Port Capability TLV in the RBridge's TRILL Hello PDUs.
This capability is included in Special VLANs and Flags (subTLV Type
#1) [TrillISIS]. This subTLV MUST appear exactly once in a Port
Information TLV in every TRILL Hello PDU. The length of the value is
four octets.
Pseudonode Nickname capability TLV
+-+-+-+-+-+-+-+-+
|Type=VLAN Flags| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+---------------+---------------+
| Port ID | (2 bytes)
+-------------------------------+
| Sender Nickname | (2 bytes)
+--+--+--+--+-------------------+
|AF|AC|VM|BY| Outer.VLAN | (2 bytes)
+--+--+--+--+-------------------+
|TR|PN|R |R | Desig.VLAN | (2 bytes)
+--+--+--+--+-------------------+
Figure 1
The PN bit, if one, indicates that the sending RBridge supports and
enables the pseudonode nickname capability. If an RBridge does not
support or not enable this capability, the PN bit MUST be set zero.
Other bits and fields refer to [TrillISIS].
When receiving this subTLV from other RBridges on the link, the DRB
can confirm whether all the adjacencies, in Report state [TrillAdj],
support and enable this capability. If not, DRB MUST NOT announce
pseudonode nickname in its pseudonode LSPs to the TRILL campus, which
can avoid the issue that remote traffic is forwarded to a RBridges
without pseudonode nickname capability.
Zhai, et al. Expires January 5, 2012 [Page 8]
Internet-Draft Pseudonode Nickname Jul 2011
5.2. Pseudonode Nickname TLV
If the DRB has confirmed that pseudonode nickname capability can be
enabled on this link, it will announce the pseudonode nickname to be
used on this link in its hello PDUs and in its pseudonode nickname.
The pseudonode nickname is carried in Pseudonode Nickname TLV, which
is formatted as following:
Pseudonode Nickname TLV
+-+-+-+-+-+-+-+-+
|Type= PSEU-NICK| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSEUDONODE NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSEUDONODE NICKNAME RECORDS (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each pseudonode nickname record is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname.Pri |SType| Reserved| (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
o Type: Pseudonode Nickname Type, TBD (NICKNAME).
o Length: 4*N, where N is the number of pseudonode nickname records
present.
o SType: An 3-bit unsigned integer sub-type for nickname. If this
nickname is pseudonode nickname, value of this field is 1.
o Nickname.Pri: An 8-bit unsigned integer priority to hold a nickname
as specified in Section 3.7.3 of [RFCtrill].
o Nickname: This is an unsigned 16-bit integer as specified in
Section 3.7 of [RFCtrill].
Zhai, et al. Expires January 5, 2012 [Page 9]
Internet-Draft Pseudonode Nickname Jul 2011
5.2.1. Pseudonode Nickname TLV in Hellos
For an RBridge enabled pseudonode nickname capability on this link,
it announces one pseudonode nickname TLV in Hellos if it knows
nickname for the pseudonode, otherwise, it MUST NOT announce
pseudonode nickname in its Hellos. If DRB has confirmed that
pseudonode nickname capability is enabled on this link, the
Nickname.Pri in the nickname record MUST be 255, otherwise the
Nickname.Pri MUST NOT be 255, and SHOULD be 100 by default.
For an RBridge that is not DRB, it only processes the pseudonode
nickname announced by DRB, and MUST overwrite its own pseudonode
nickname with the DRB's pseudonode nickname if the two nicknames are
different and the Nickname.Pri of DRB is 255.DRB should process the
pseudonode nickname TLV from all the adjacencies in the Report state
on the link in order to obtain the pseudonode nickname that was being
used on this link.
This TLV MUST appear no more than once in a Port Information TLV in
every Hello PDU. Only one nickname record can be contained in this
TLV, if this subTLV appears in Hello PDUs.
5.2.2. Pseudonode Nickname TLV in DRB's LSPs
For a DRB on a link, it MUST originate and flood a pseudonode LSP for
this link if the bypass pseudonode bit is reset. All the adjacencies
in the Report state on this link are contained in its pseudonode LSP.
Furthermore, if a pseudonode nickname capability is enabled on this
link, a Pseudonode Nickname TLV MUST be contained in its pseudonode
LSP.
For a pseudonode LSP, the only one record in this TLV contains the
nickname for the pseudonode standing for the link. In this case, the
value of Nickname.Pri varies from 1 to 255, which describes the DRB's
priority to hold this nickname as specified in [RFCtrill] Section
3.7.3.
6. Security Considerations
7. Acknowledgements
8. References
Zhai, et al. Expires January 5, 2012 [Page 10]
Internet-Draft Pseudonode Nickname Jul 2011
8.1. Normative references
[MultilevelTrill]
Perlman, R., Eastlake, D., and A. Ghanwani, "RBridges:
Multilevel TRILL",
draft-perlman-trill-rbridge-multilevel-02.txt, work in
process, April 2011.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[RFCtrill]
Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "RBridges: Base Protocol Specification",
draft-ietf- trill-rbridge-protocol-16.txt, in RFC Editor's
queue, Mar 2010.
[TRILLisis]
Eastlake, D., Dutt, D., Perlman, R., and A. Ghanwani,
"TRILL Use of IS-IS", draft-ietf-isis-trill-05.txt work in
process, Feb 2011.
[TrillAdj]
Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V.
Manral, "RBridges: Adjacency",
draft-ietf-trill-adj-02.txt, work in process, Feb 2011.
[TrillAf] Perlman, R., Eastlake, D., Banerjee, A., and F. Hu,
"RBridges: Appointed Forwarders",
draft-ietf-trill-rbridge-af-03.txt work in process,
May 2011.
8.2. Informative References
Zhai, et al. Expires January 5, 2012 [Page 11]
Internet-Draft Pseudonode Nickname Jul 2011
Authors' Addresses
Hongjun Zhai
ZTE Corporation
68 Zijinghua Road
Nanjing 200012
China
Phone: +86-25-52877345
Email: zhai.hongjun@zte.com.cn
Fangwei Hu
ZTE Corporation
889 Bibo Road
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 technology
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-634-2066
Email: d3e3e3@gmail.com
Zhai, et al. Expires January 5, 2012 [Page 12]