Internet DRAFT - draft-ietf-trill-rbridge-extension
draft-ietf-trill-rbridge-extension
TRILL Working Group Donald Eastlake
INTERNET-DRAFT Huawei
Intended status: Proposed Standard Anoop Ghanwani
Updates: 6325 Dell
Vishwas Manral
HP
Yizhou Li
Huawei
Caitlin Bestler
Quantum
Expires: December 19, 2012 June 20, 2012
TRILL: Header Extension
<draft-ietf-trill-rbridge-extension-05.txt>
Abstract
The IETF TRILL (Transparent Interconnection of Lots of Links) base
protocol specifies minimal hooks to safely support TRILL Header
extensions. This document specifies an initial extension providing
additional flag bits and specifies some of those bits. It updates RFC
6325.
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 TRILL 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.
D. Eastlake, et al [Page 1]
INTERNET-DRAFT TRILL: Header Extension
Table of Contents
1. Introduction............................................3
1.1 Conventions used in this document......................3
2. TRILL Header Extensions.................................4
2.1 RBridge Extended Flag Handling Requirements............5
2.2 No Critical Surprises..................................5
2.3 Extended Header Flags..................................6
2.3.1 Critical Summary Bits................................7
2.4 Conflict of Extensions.................................8
3. Specific Extended Header Flags..........................9
3.1 The RBridge Channel Alert Extended Flags...............9
4. Additions to IS-IS.....................................10
5. IANA Considerations....................................10
6. Security Considerations................................11
7. Acknowledgements.......................................11
8. Normative References...................................12
9. Informative References.................................12
Change History............................................13
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL: Header Extension
1. Introduction
The base IETF TRILL (Transparent Interconnection of Lots of Links)
protocol [RFC6325] [RFC6326bis] provides a TRILL Header extension
feature and describes minimal hooks to safely support header
extension. (This feature is called "options" in Section 3.8 of
[RFC6325].) But, except for the first two bits, the TRILL base
protocol document does not specify the structure of extensions to the
TRILL Header nor the details of any particular extension.
This document is consistent with [RFC6325] and provides further
details. It specifies an initial extension word providing additional
flag bits and specifies some of those bits. Additional extensions,
including TLV (Type, Length, Value) encoded options, may be specified
in later documents, for example [Options].
Section 2 below describes some general principles of TRILL header
extensions and an initial extension. Section 3 specifies pair of
flags in this initial extension.
1.1 Conventions used in this document
The terminology and acronyms defined in [RFC6325] are used herein
with the same meaning. Devices implementing the TRILL protocol are
referred to as RBridges (Routing Bridges) or TRILL Switches.
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].
D. Eastlake, et al [Page 3]
INTERNET-DRAFT TRILL: Header Extension
2. TRILL Header Extensions
The base TRILL Protocol includes a feature for extension of the TRILL
Header (see [RFC6325] Sections 3.5 and 3.8). The 5-bit Op-Length
header field gives the length of the extensions to the TRILL Header
in units of 4 octets, which allows up to 124 octets of header
extension. If Op-Length is zero there are no header extensions
present; else, the extension area follows immediately after the
Ingress RBridge (Routing Bridge) Nickname field of the TRILL Header.
The first 32-bit word of the optional extensions area consists of an
extended flags area and critical summary bits as specified in this
document.
As described below, provision is made for
o hop-by-hop flags, which might affect any RBridge that receives
a TRILL Data frame with such a flag set,
o ingress-to-egress flags, which would only necessarily affect
the RBridge(s) where a TRILL frame is decapsulated,
o flags affecting an as yet unspecified class of RBridges, for
example border RBridges in a TRILL campus extended to support
multi-level IS-IS (Intermediate System to Intermediate System)
[MultiLevel], and
o both "critical" and "non-critical" flags.
Any RBridge receiving a frame with a critical hop-by-hop extension
that it does not implement MUST discard the frame because it is
unsafe to process the frame without understanding such a critical
extension.
Any egress RBridge receiving a frame with a critical ingress-to-
egress extension it does not implement MUST drop the frame if it is a
unicast frame (TRILL Header M bit = 0); if it is a multi-destination
TRILL Data frame (M=1), then it MUST NOT be egressed at that RBridge
but the egress RBridge still forwards such a frame on the
distribution tree.
Non-critical extensions can be safely ignored.
Any extended flag indicating a significant change in the structure or
interpretation of later parts of the frame which, if the extended
flag were ignored, could cause a failure of service or violation of
security policy MUST be a critical extension. If such an extended
flag affects any fields that transit RBridges will examine, it MUST
be a hop-by-hop critical extended flag.
Note: Most RBridges implementations are expected to be optimized
D. Eastlake, et al [Page 4]
INTERNET-DRAFT TRILL: Header Extension
for simple and common cases of frame forwarding and processing.
Although the hard limit on the header extensions area length, the
32-bit alignment of the extension area, and the presence of
critical extension summary bits, as described below, are intended
to assist in the efficient hardware processing of frames with a
TRILL header extensions area, nevertheless the inclusion of
extensions may cause frame processing using a "slow path" with
inferior performance to "fast path" processing. Limited slow path
throughput of such frames could cause some of them to be
discarded.
2.1 RBridge Extended Flag Handling Requirements
All RBridges MUST check whether there are any critical flags set that
are necessarily applicable to their processing of the frame. To
assist in this task, critical summary bits are provided that cover
not only the extended flags specified herein but will cover any
further extensions that may be specified in future documents, for
example [Options]. If an RBridge does not implement all critical
flags in a TRILL Data frame, it MUST treat the frame as having an
unimplemented critical extension as described in Section 2. A transit
or egress RBridge may assume that the critical summary bits are
correct.
In addition, a transit RBridge:
o MAY set or clear hop-by-hop flags as specified for such flags;
o MUST adjust the length of the extensions area, including changing
Op-Length in the TRILL header, as appropriate if it adds or
removes the word of extended header flags;
o MUST, if it adds the word of extended header flags or changes any
critical flags, correctly set the critical summary bits in the
extended header flags word;
o MUST NOT remove the extended header flags word unless it is all
zero (either on arrival or after permitted modifications);
o MUST NOT set or clear ingress-to-egress or reserved extended
header flags except as specifically permitted in the specification
of such flags.
2.2 No Critical Surprises
RBridges advertise the extended header flags they support in IS-IS
PDUs (Protocol Data Units) [RFC6326bis]. Unless an RBridge advertises
support for a critical extended header flag, it will not normally
receive frames with that flag set. An RBridge is not required to
support any extensions.
D. Eastlake, et al [Page 5]
INTERNET-DRAFT TRILL: Header Extension
An RBridge SHOULD NOT set a critical extended flag in a frame unless,
- for a critical hop-by-hop extended header flag, it has determined
that the next hop RBridge or RBridges that will accept the frame
support that flag,
- for a critical ingress-to-egress extended header flag, it has
determined that the RBridge or RBridges that will egress the frame
support that flag, or
- for a critical reserved extended header flag, it may set such a
flag only if it understands which RBridges it is applicable to and
has determined that those RBridges that will accept the frame
support that flag.
"SHOULD NOT" is specified above since there may be cases where it is
acceptable for those frames, particularly for the multi-destination
case, to be discarded or not egressed by any RBridges that do not
implement the extended flag.
2.3 Extended Header Flags
If any extensions are present in a TRILL Header, as indicated by a
non-zero Op-Length field, the first 32 bits of the extensions area
consist of Extended Header Flags, as described below. The remainder
of the extensions area, if any, after this initial 32 bits, may be
specified in later documents [Options].
Any RBridge adding an extensions area to a TRILL Header must set the
first 32 bits to zero except when permitted or required to set one or
more of those bits as specified. For TRILL Data frames with
extensions present, any transit RBridge that does not discard the
frame MUST transparently copy the extended flags word, except for
modifications permitted by an extension implemented by that RBridge.
The word of Extended Header Flags is illustrated below and the
meanings of these bits is further described in the list following the
figure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... additional optional 32-bit aligned words of extension |
| possibly including TLV extensions ...
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL: Header Extension
(The first two critical summary bits are as specified in [RFC6325].
In this document an "S", for Summary, has been added at the end of
their acronyms. A third critical summary bit is also specified herein
and its acronym also ends with an "S" for consistency.)
Bit(s) Description
---------------------
0-3 Crit.: Critical summary bits.
0 CHbHS: Critical Hop-by-Hop extension(s) are present.
1 CItES: Critical Ingress-to-Egress extension(s) are present.
2 CRSVS: Critical reserved extension(s) are present.
3-7 CHbH: Critical Hob-by-Hop extended Flag bits.
8-13 NCHbH: Non-critical Hop-by-Hop extended Flag bits.
14-16 CRSV: Critical Reserved extended Flag bits.
17-20 NCRSV: Non-critical Reserved extended Flag bits.
21-26 CItE: Critical Ingress-to-Egress extended Flag bits.
27-31 NCItE: Non-critical Ingress-to-Egress extended Flag bits.
2.3.1 Critical Summary Bits
The top three bits of the Extended Header Flags area, bits 0, 1, and
2 above, are called the critical summary bits. They summarize the
presence of critical extensions as follows:
CHbHS: If the CHbHS (Critical Hop by Hop Summary) bit is one, one or
more critical hop-by-hop extensions are present. These might be
critical hop-by-hop extended header flags or critical hop-by-hop
extensions after the first word in the extensions area. Transit
RBridges that do not support all of the critical hop-by-hop
extensions present, for example an RBridge that supported no
critical hop-by-hop extensions, MUST drop the frame. If the CHbHS
bit is zero, the frame is safe, from the point of view of
extensions processing, for a transit RBridge to forward,
regardless of what extensions that RBridge does or does not
support.
CItES: If the CItES (Critical Ingress to Egress Summary) bit is a
one, one or more critical ingress-to-egress extensions are
present. These might be critical ingress-to-egress extended header
flags or critical ingress-to-egress extensions after the first
word in the extensions area. If the CItES bit is zero, no such
extensions are present. If either CHbHS or CItES is non-zero,
egress RBridges that do not support all critical extensions
present, for example an RBridge that supports no critical
D. Eastlake, et al [Page 7]
INTERNET-DRAFT TRILL: Header Extension
extensions, MUST drop the frame. If both CHbHS and CItES are
zero, the frame is safe, from the point of view of extensions, for
an egress RBridge to process, regardless of what extensions that
RBridge does or does not support.
CRSVS: If the CRSVS (Critical Reserved Summary) bit is a one, one or
more critical extensions are present that are reserved to apply to
a class of RBridges to be specified in the future, for example
border RBridges in a TRILL campus extended to support multi-level
IS-IS. This class will be a subset of transit RBridges. RBridges
in this class MUST drop frames with the CRSVS bit set unless they
implement all critical hop-by-hop and all critical reserved
extensions present in the frame.
The critical summary bits enable simple and efficient processing of
TRILL Data frames by egress RBridges that support no critical
extensions, by transit RBridges that support no critical hop-by-hop
extensions, and by RBridges in the reserved class that support no
critical hop-by-hop or reserved extensions. Such RBridges need only
check whether Op-Length is non-zero and, if it is, the top one, two,
or three bits just after the fixed portion of the TRILL Header. Based
on those three bits, such RBridges can decide whether to discard or
forward / process the frame.
2.4 Conflict of Extensions
Defining TRILL extensions including Extended Header Flags that
conflict with each other would be undesirable. Should conflicting
extensions appear in the same packet, the results would be
unpredictable, if different implementations processed them in
different orders. While rules could be defined to specify how to
predictably process conflicting extensions, such rules would also
limit implementation flexibility and could impose substantial
processing burdens.
Conflicting extensions SHOULD NOT be defined, but if they are,
careful thought should be given as to whether and how to specify the
handling of conflicting extensions.
D. Eastlake, et al [Page 8]
INTERNET-DRAFT TRILL: Header Extension
3. Specific Extended Header Flags
The table below shows the state of TRILL Header extended flag
assignments. See Section 5 for IANA Considerations.
Bits Purpose Section
------------------------------------------------------
0-2 Critical Summary Bits 2.3.1
3-6 available critical hop-by-hop flags
7 Critical Channel Alert Flag 3.1
8 Non-critical Channel Alert Flag 3.1
9-13 available non-critical hop-by-hop flags
14-16 available critical reserved flags
17-20 available non-critical reserved flags
21-26 available critical ingress-to-egress flags
27-31 available non-critical ingress-to-egress flags
Table 1. Extended Header Flags Area
3.1 The RBridge Channel Alert Extended Flags
The RBridge Channel Alert Extended Flags indicates that the frame is
an RBridge Channel frame [Channel] that requests processing at each
hop.
If the critical Channel Alert flag (bit 7) is a one and the RBridge
does not implement the RBridge Channel feature or the particular
RBridge Channel protocol involved [Channel] or the frame does not
actually appear to be an RBridge Channel message, then the frame is
discarded. This permits implementation, for example, of a Channel
message requiring strict source routing or the like, with assurance
that it will be discarded rather than deviate from the directed path.
If the frame is not discarded as above then the presence of either
the Critical or Non-critical hop-by-hop Channel Alert flag alerts
transit RBridges to the presence of an RBridge Channel message
[Channel] that may require special handling. The non-critical alert
flag supports, for example, an RBridge Channel protocol message
including a "record route" function where not recording transit
RBridges that do not support this function is acceptable.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT TRILL: Header Extension
4. Additions to IS-IS
RBridges use IS-IS LSP PDUs to inform other RBridges which Extended
Header Flags they support. The IS-IS PDU(s), TLV(s), or sub-TLV(s)
used to encode and advertise this information are specified in a
separate document [RFC6326bis].
5. IANA Considerations
IANA is requested to create a subregistry within the TRILL Parameters
registry: The "TRILL Extended Header Flags" subregistry, that is
initially populated as specified in Table 1 in Section 3. References
in that table to sections of this document are to be replaced in the
IANA subregistry by references to this document as an RFC.
New TRILL Extended Header Flags are allocated by IETF Review
[RFC5226].
D. Eastlake, et al [Page 10]
INTERNET-DRAFT TRILL: Header Extension
6. Security Considerations
For general TRILL protocol security considerations, see [RFC6325].
For security considerations related to extended header flags, see the
document where the flag is specified.
It is important that the critical summary bits in the Extended Header
Flags word be set properly. If set when critical extensions of the
appropriate category are not present, frames may be unnecessarily
discarded. If not set when critical extensions are present, frames
may be mishandled or corrupted and intended security policies may be
violated.
The RBridge Channel Alert extended flags have the following security
considerations. Implementations should keep in mind that they might
be erroneously set in a frame. If either RBridge Channel Alert flag
is found set in a frame that is not an RBridge Channel message
[Channel], the flag MAY be cleared and should have no effect except,
possibly, delaying processing of the frame. If either Channel Alert
flag is erroneously omitted from a frame, desired per hop processing
for the frame may not occur.
7. Acknowledgements
The following, listed in alphabetic order, are thanked for their
valuable contributions: Ben Campbell, Adrian Farrel, Barry Leiba,
and Thomas Narten.
This document was produced with raw nroff. All macros used were
defined in the source file
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL: Header Extension
8. Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", July 2011.
[Channel] - draft-ietf-trill-rbridge-channel, work in progress.
[RFC6326bis] - draft-eastlake-isis-rfc6326bis, work in progress.
9. Informative References
[MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in
progress.
[Options] - draft-ietf-trill-rbridge-options, work in progress.
- draft-eastlake-trill-rbridge-more-options, work in progress.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT TRILL: Header Extension
Change History
The sections below summarize changes between successive versions of
this draft. RFC Editor: Please delete this section before
publication.
Version 00 of this draft is an extract and simplification of draft-
ietf-trill-rbridge-options-05.txt as discussed at the TRILL Working
Group meeting at IETF 81 and on the TRILL WG mailing list.
From -00 to -01
1. Update Author Addresses.
2. Assorted editorial changes.
From -01 to -02
1. Addition of the Critical RBridge Channel Alert Flag.
2. Assorted editorial and author changes.
From -02 to -03
1. Replacement of Section 2.4 to eliminate detailed constraints on
the processing of conflicting extensions and to warn against the
future specification of conflicting options.
2. Minor editorial changes.
From -03 to -04
Editorial changes including the deletion of Section 2.3.2 that was
completely redundant with earlier parts of Section 2.3.
From -04 to -05
1. Add "Updates: 6325" to the first page header as this document
provides more details on the TRILL Header options area.
D. Eastlake, et al [Page 13]
INTERNET-DRAFT TRILL: Header Extension
2. Expand first use of some acronyms and other editorial changes.
3. Change criteria for allocation of extended header flags from
Standards Action to IETF Review.
4. Editorial changes primarily based on IESG review.
D. Eastlake, et al [Page 14]
INTERNET-DRAFT TRILL: Header Extension
Authors' Addresses
Donald Eastlake
Huawei R&D USA
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
email: d3e3e3@gmail.com
Anoop Ghanwani
Dell
350 Holger Way
San Jose, CA 95134 USA
Phone: +1-408-571-3500
Email: anoop@alumni.duke.edu
Vishwas Manral
HP Networking
19111 Pruneridge Avenue
Cupertino, CA 95014 USA
Phone: +1-408-477-0000
EMail: vishwas.manral@hp.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Caitlin Bestler
Quantum
1650 Technology Drive , Suite 700
San Jose, CA 95110 USA
Phone: +1-408-944-4000
email: cait@asomi.com
D. Eastlake, et al [Page 15]
INTERNET-DRAFT TRILL: Header Extension
Copyright and IPR Provisions
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
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. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
D. Eastlake, et al [Page 16]
