Internet DRAFT - draft-gai-perlman-trill-encap
draft-gai-perlman-trill-encap
TRILL Working Group S.Gai
Internet Draft Nuova Systems
R. Perlman
Sun Microsystems
Dinesh G. Dutt
Cisco Systems
Ed Bowen
IBM
Expires: April 2007 October 10, 2006
An encapsulation for TRILL
draft-gai-perlman-trill-encap-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 10, 2007.
Abstract
A new layer of encapsulation is required with RBridges. A previous
Internet Draft [2] (draft-bryant-perlman-trill-pwe-encap-00) proposes
an encapsulation header that contains a Nickname, a flag, TTL and
CoS. This document introduces additional fields, and gives arguments
for their usefulness. As a result the encapsulation header needs to
be expanded and will no longer be able to be in MPLS format. The WG
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 1]
Internet-Draft An encapsulation for TRILL October 2006
will need to decide on the tradeoffs between this additional
functionality, and compatibility with an existing (MPLS) format.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction...................................................2
2. Encapsulation Format...........................................3
2.1. Encapsulation format over Ethernet........................4
3. FTag...........................................................4
4. Hop Limit......................................................6
5. RBridge addresses..............................................6
5.1. Egress RBridge Address....................................8
5.2. Ingress RBridge Address...................................8
6. Local Identifier (LID).........................................8
6.1. Egress RBridge LID........................................8
6.2. Ingress RBridge LID.......................................9
7. Other considerations related to Ethernet Encapsulation.........9
8. Security Considerations........................................9
9. IANA Considerations...........................................10
10. References...................................................10
10.1. Normative References....................................10
10.2. Informative References..................................10
Author's Addresses...............................................11
Intellectual Property Statement..................................11
Disclaimer of Validity...........................................12
Copyright Statement..............................................12
Acknowledgment...................................................12
1. Introduction
Previous work [2], [3] has clearly identified that TRILL
encapsulation requires a TTL, an RBridge ID, and a flag to indicate
if the frame is unicast or multicast. There has been a proposal to
also add a CoS field, but the consensus seems less strong.
This proposal expands the scope of the encapsulation to:
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 2]
Internet-Draft An encapsulation for TRILL October 2006
o Allow both the ingress and egress RBridge ID to be carried in the
frame;
o Support multiple forwarding topologies over the same TRILL network
by adding an FTag (Forwarding Tag);
o Support a simplified RBridge lookup architecture by adding a LID
(Local Identifier).
2. Encapsulation Format
The proposed encapsulation format is agnostic to the data link layer
used and it is depicted in Figure 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FTag | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress RBridge Address | Ingress RBridge LID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Address | Egress RBridge LID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 TRILL Encapsulation
o FTag (Forwarding tag): 10-bit selector. See Section 3.
o Hop Limit: 6-bit unsigned integer. See Section 4.
o Ingress RBridge Address: 16-bit address. See Section 5.2
o Egress RBridge Address: 16-bit address. See Section 5.1
o Ingress RBridge LID: 16-bit address. See Section 6.2
o Egress RBridge LID: 16-bit address. See Section 6.1
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 3]
Internet-Draft An encapsulation for TRILL October 2006
2.1. Encapsulation format over Ethernet
The most common encapsulation for TRILL will be the Ethernet
encapsulation shown in Figure 2. This encapsulation has the advantage
of aligning the original Ethernet frame at 64 bit boundaries.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | FTag | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress RBridge Address | Ingress RBridge LID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Address | Egress RBridge LID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Original Ethernet frame without FCS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 TRILL Encapsulation over Ethernet
The frame has a single FCS that is recomputed to cover the entire
frame. This has become standard practice in IEEE 802.1: the tagging
structure effectively requires FCS recomputation at the boundaries of
the network. Additionally, the IETF (with diffserv, ECN, routing)
have also effectively required FCS recomputation at all boundaries of
the network.
3. FTag
10-bit unsigned integer. The Forwarding Tag (FTag) identifies the
forwarding topology assigned to a given frame.
In current enterprise networks, for a given frame it is possible to
pick from multiple topologies on which the frame can be forwarded.
More specifically, in existing Ethernet bridges:
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 4]
Internet-Draft An encapsulation for TRILL October 2006
o For unicast, it is possible to range from the solution where all
the VLANs share the same spanning tree (default 802.1D behavior),
to individual spanning tree per VLAN (per-VLAN spanning tree), to
spanning trees shared by a set of VLANs (Multiple Spanning Tree).
o For multicast, it is possible to have a single tree, or one tree
sourced in each bridge, or a set of N shared trees.
To provide similar functionality for TRILL an FTag is assigned to
each frame by the ingress RBridge and it is honored by all subsequent
RBridges within that TRILL cloud.
These different forwarding topologies are characterized by different
metrics. The link state protocol must carry for each link metrics
specified in term of pairs {FTag, value}.
FTag allows forwarding based on more than just destination address.
For example, FTag assignment may be based on criteria such as
protocol, VLAN, or ingress interface.
The alternative of not carrying an explicit FTag in the frame, but
assign it Hop-by-Hop, is not recommended, since it can easily cause
loops and prevent frames from being delivered correctly, especially
in the case of multicast, when misconfigured.
There are two possible approaches to building multicast trees, as
stated earlier:
o Source-Rbridge based multicast trees: in this case, a multicast
tree is built per Rbridge. The distribution tree used by a
multicast group is the first-hop Rbridge's tree. The main
advantage of this proposal is optimal forwarding. However, if
sources are concentrated behind a few Rbridges, not all links are
effectively utilized. Further, all multicast groups, independently
of the VLAN, use the same tree. This same tree is used for
broadcast originating from behind a Rbridge as well.
o Shared Trees: in this case, one or more multicast trees are
constructed, one for each of a few well-located Rbridges. The
distribution tree used by a {multicast source, multicast group} is
determined by hashing the tuple {multicast source, multicast
group}. This has the advantage of effectively using all links of
the network. One of these trees can be chosen per VLAN as the
broadcast tree.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 5]
Internet-Draft An encapsulation for TRILL October 2006
Thus, if there are N unicast forwarding topologies (i.e. metrics), M
Rbridges and, P multicast trees where P <= M, (N+P) <= 1024 and 1 <=
N <= (1024-P).
One value of FTag (probably zero) should be reserved to be the
default (single topology) and all links must have a metric implicitly
or explicitly assigned for that FTag value.
4. Hop Limit
6-bit unsigned integer. This is decremented by 1 at each node that
forwards the frame. The frame is discarded if Hop Limit is
decremented to zero. This field was previously referred to as TTL
(Time To Live). In IPv6 the IETF has replaced the concept of TTL with
Hop Limit. TRILL aligns with this newer definition.
5. RBridge addresses
16-bit address. This is also referred to as "RBridge nickname". It is
not the MAC address of the Rbridge, it is the TRILL address of the
RBridge.
The current TRILL proposal has a single field that sometimes contains
the ingress, and sometimes the egress RBridge address, indicated by a
flag in the 20-bit field. Unicast packets indicate egress RBridge,
and non-unicast indicates ingress RBridge. This may be confusing and,
in protocol design it is common practice to have both the ingress and
egress addresses. This is particularly true when security is taken
into account.
In particular, in the case of unicast, if only the egress RBridge is
in the header, there is no information about where the packet entered
the backbone (the ingress RBridge). This information might be useful
for policy/filtering decisions. Also, if in the future we want to
allow learning of endnode locations based on seeing data frames, it
is useful to have the ingress RBridge address in the header, so that
RBridges can learn the tuple {ingress RBridge address, ingress
RBridge LID, endnode}.
In the case of multicast/broadcast, currently only the ingress
RBridge is in the header. The egress RBridge address can be used to
encode information so that the RBridges does not need to look inside
the header to find out, for instance, what the VLAN tag is.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 6]
Internet-Draft An encapsulation for TRILL October 2006
This document proposes instead two 16-bit fields, one for ingress,
and one for egress.
The following types of packets need to be considered:
o unicast (where the egress RBridge is known)
o unicast flooding (where the destination is unknown so the packet
must be flooded to all egress RBridges)
o Registered multicast (where receivers have registered, through
IGMP or GARP)
o Non-registered multicast (where receivers have not registered, and
so data must be delivered to all links in the VLAN).
o VLAN broadcast
The most significant bits of the address have the meaning specified
in Figure 3.
+------------------+------------
| 0xxxxxxxxxxxxxxx | Unicast
+------------------+------------
| 100ryyyyyyyyyyyy | Unicast Flooding
+------------------+------------
| 101ryyyyyyyyyyyy | Registered Multicast
+------------------+------------
| 110ryyyyyyyyyyyy | Non-Registered Multicast
+------------------+------------
| 111ryyyyyyyyyyyy | VLAN Broadcast
+------------------+------------
Figure 3 Format of RBridge addresses
Where:
o xxxxxxxxxxxxxxx is the 15 bit identifier of an RBridge
o r is 1 bit reserved field
o yyyyyyyyyyyy is a 12 bit VLAN identifier. The VLAN identifier is
taken by the 802.1Q tag if present and different from zero, or by
the Interface VLAN parameter in the other cases.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 7]
Internet-Draft An encapsulation for TRILL October 2006
This assignment allows addressing up to 32K RBridges.
5.1. Egress RBridge Address
The egress RBridge address may assume all formats listed in Figure 3.
In particular:
o For known-unicast it assumes the unicast format where
xxxxxxxxxxxxxxx contains the identifier of the egress RBridge.
o For unknown-unicast, registered multicast, non-registered
multicast, and broadcast, yyyyyyyyyyyy is the VLAN identifier.
5.2. Ingress RBridge Address
The ingress RBridge address may assume only the unicast format (see
Figure 3). xxxxxxxxxxxxxxx contains the identifier of the ingress
RBridge.
6. Local Identifier (LID)
This 16-bit number is of significance to the ingress/egress RBridge
inserting/removing the encapsulation. The most common use is as a
hint to the egress Rbridge of the output interface. The LIDs are
ignored by intervening RBridges.
The implication on the design is to change slightly how endnodes are
reported in the endnode report LSP (the per-VLAN instance which
reports attached endnodes). Each RBridge must report the tuple {MAC-
address, RBridge Address, LID} for each MAC address.
This does not add computational overhead in the RBridge, since the
LIDs are not part of the topology.
6.1. Egress RBridge LID
The egress LID simplifies significantly the forwarding decision of
the egress RBridge.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 8]
Internet-Draft An encapsulation for TRILL October 2006
The ingress RBridge looks up the endnode MAC address, identify an
adjacency table entry that contains the pair {egress RBridge address,
egress RBridge LID) and insert them in the TRILL header.
Each RBridge looks at the Egress RBridge address to decide if it is
the egress RBridge.
The egress RBridge remove the encapsulation and can send the frame
out to the correct interface, by using the LID from the packet,
without requiring additional lookups of the inner MAC address.
6.2. Ingress RBridge LID
This is to provide the capability to learn the information (ingress
RBridge, LID) from data packets, rather than reporting this
information in link state reports.
7. Other considerations related to Ethernet Encapsulation
The current TRILL architecture assumes all links are shared-media
Ethernet. The outer header is really link-specific, and although the
document specifies only shared-media Ethernet links, it ought to be
clear that other links are allowed. In particular, if there is a
direct RBridge-to-RBridge point-to-point link, there is no need for
the outer header. However, if the link is Ethernet point-to-point
sending an Ethernet frame without MAC addresses is probably not a
good idea, it is better to set them to a predefined value in
transmission and ignore them in reception.
8. Security Considerations
No matter what the format of the encapsulation header is, an RBridge
can modify the value in the encapsulation header, and cause packet
misrouting. This format should not change the security implications
of RBridges.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 9]
Internet-Draft An encapsulation for TRILL October 2006
9. IANA Considerations
This format requires a new Ethertype in the outer header, to indicate
this encapsulation format. Even with the MPLS format, an Ethertype
needed to be assigned to RBridges, so this does not require
additional values to be assigned.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[2] S. Bryant, R. Perlman, A. Atlas, D. Fedyk, "TRILL using Pseudo-
Wire Emulation (PWE) Encapsulation", draft-bryant-perlman-
trill-pwe-encap-00, October 16, 2005
[3] R. Perlman, J. Touch, "RBridges: Base Protocol Specification,"
draft-ietf-trill-RBridge-protocol-00.txt, May 10, 2006
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 10]
Internet-Draft An encapsulation for TRILL October 2006
Author's Addresses
Silvano Gai
Nuova Systems
Email: sgai@nuovasystems.com
Radia Perlman
Sun Microsystems
Email: Radia.Perlman@sun.com
Dinesh G. Dutt
Cisco Systems
Email: ddutt@cisco.com
Ed Bowen
IBM
Email: edbowen@us.ibm.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 11]
Internet-Draft An encapsulation for TRILL October 2006
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 12]
