TRILL Working Group Donald Eastlake
INTERNET-DRAFT Huawei
Intended status: Proposed Standard Anoop Ghanwani
Brocade
Vishwas Manral
IP Infusion
Caitlin Bestler
Quantum
Expires: September 9, 2011 March 10, 2011
RBridges: TRILL Header Options
<draft-ietf-trill-rbridge-options-04.txt>
Abstract
The TRILL base protocol standard specifies minimal hooks to safely
support TRILL Header options. This draft specifies the format for
options and some initial options.
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 Options
Table of Contents
1. Introduction............................................3
1.1 Conventions used in this document......................3
2. TRILL Header Options....................................4
2.1 RBridge Option Handling Requirements...................5
2.2 No Critical Surprises..................................6
2.3 Options Format.........................................6
2.3.1 Extended Header Flags Area...........................7
2.3.1.1 Critical Summary Bits..............................8
2.3.1.2 MEF, More Extended Flags...........................8
2.3.1.3 Specific Initial Bit Extended Flags................9
2.3.1.4 TLV Summary Bits...................................9
2.3.1.5 Flow ID............................................9
2.3.2 TLV Option Format...................................10
2.3.3 Marshaling of Options...............................11
2.4 Conflict of Options...................................11
3. Specific Extended Header Flag..........................13
3.1 The ECN Option........................................13
4. Specific TLV Option....................................16
4.1 Test/Pad Option.......................................16
5. Additions to IS-IS.....................................17
6. IANA Considerations....................................18
7. Security Considerations................................18
8. Acknowledgements.......................................18
9. References.............................................19
9.1 Normative References..................................19
9.2 Informative References................................19
Change History............................................20
Version 00 to 02..........................................20
Version 02 to 03..........................................20
Version 03 to 04..........................................20
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL Header Options
1. Introduction
The base TRILL protocol standard [RFCtrill] provides a TRILL Header
options feature and describes minimal hooks to safely support that
feature. But, except for the first two bits, it does not specify the
structure of the options extension to the TRILL Header nor the
details of any particular options. This draft specifies that format
and some initial options: a special Flow ID field, ECN (Explicit
Congestion Notification) extended header flags, and a test/pad
option.
Section 2 below describes the general principles of operation,
format, and ordering of TRILL Header Options. Other than the special
Flow ID option, TRILL Header options are of two kinds: extended
header flags and TLV (Type, Length, Value) encoded options.
Section 3 describes a specific extended flag option while Section 4
describes a specific TLV encoded option.
1.1 Conventions used in this document
The terminology and acronyms defined in [RFCtrill] are used herein
with the same meaning.
In this documents, "IP" refers to both IPv4 and IPv6.
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 Options
2. TRILL Header Options
The base TRILL Protocol includes an option feature for extension of
the TRILL Header (see [RFCtrill] Sections 3.5 and 3.8). The 5-bit
Op-Length header field gives the length of the extension to the TRILL
Header in units of 4 octets, which allows up to 124 octets of header
extension. If Op-Length is zero there is no header extension present;
else, this area follows immediately after the Ingress Rbridge
Nickname field of the TRILL Header. The optional extensions area
consists of an extended flags area possibly followed by TLV options.
Each TLV option present is 32-bit aligned. There is a special Flow ID
option that may also occur in the extended flags area.
As described below, provision is made for both hop-by-hop options,
which might affect any RBridge that receives a TRILL Data frame
containing such an extension, and ingress-to-egress options, which
would only necessarily affect the RBridge(s) where a TRILL frame is
decapsulated. Provision is also made for both "critical" and "non-
critical" options. Any RBridge receiving a frame with a critical hop-
by-hop option that it does not implement MUST discard the frame
because it is unsafe to process the frame without understanding the
critical option. Any egress RBridge receiving a frame with a critical
ingress-to-egress option it does not implement MUST drop the frame if
it is a known unicast frame; if it is a multi-destination TRILL Data
frame with a critical ingress-to-egress option that the RBridge does
not implement, then it MUST NOT be egressed at that RBridge but it is
still forwarded on the distribution tree. Non-critical options can be
safely ignored.
Any option indicating a significant change in the structure or
interpretation of later parts of the frame which, if the option were
ignored, could reasonably cause a failure of service or violation of
security policy MUST be a critical option. If such an extension
affects any fields that transit RBridges will examine, it MUST be a
hop-by-hop critical option.
TLV options also have a "mutability" flag that has a different
meaning for ingress-to-egress and for hop-by-hop.
For an ingress-to-egress option, the mutability flag indicates
whether the value associated with the option can change at a transit
RBridge (mutable options) or cannot so change (immutable options).
For example, an ingress-to-egress security option could protect the
value of an immutable ingress-to-egress option. But such a security
option generally could not protect a mutable value as a transit
RBridge could change that value but might not have the keys to
recompute a signature or authentication code to take a changed value
into account.
For a non-critical hop-by-hop option, the mutability flag indicates
D. Eastlake, et al [Page 4]
INTERNET-DRAFT TRILL Header Options
whether a transit RBridge that does not implement the option is
permitted (mutable) or not permitted (immutable) to remove the
option. A transit RBridge is not required to remove a hop-by-hop
option that it does not implement.
For critical hop-by-hop options, the mutability flag is meaningless.
If the RBridge does not implement the critical hop-by-hop option, it
MUST drop the frame. If it does implement the critical hop-by-hop
option, it will know whether or not it may/should/must remove it.
For critical hop-by-hop options, the mutability flag is set to zero
("immutable") on transmission and ignored on receipt.
Note: Most RBridges implementations are expected to be optimized
for simple and common cases of frame forwarding and processing.
Although the hard limit on the header options area length, the
32-bit alignment of TLV options, and the presence of critical
option summary bits, as described below, are intended to assist in
the efficient hardware based processing of frames with a TRILL
header options area, nevertheless the inclusion of options,
particularly TLV options, may cause frame processing using a "slow
path" with inferior performance to "fast path" processing. Limited
slow path throughput of such frames could cause them to be
discarded.
2.1 RBridge Option Handling Requirements
The requirements given in this section are in addition to the option
handling requirements in [RFCtrill].
All RBridges MUST be able to check whether there are any critical
options present that are necessarily applicable to their processing
of the frame as detailed below. If they do not implement all such
critical options present, they MUST discard the frame or, in some
circumstances as described above for certain multi-destination
frames, continue to forward the frame but MUST NOT egress the frame.
Transit RBridges MUST transparently forward all immutable ingress-to-
egress header options in frames that they forward. Any changes made
by a transit RBridge to a mutable ingress-to-egress option value MUST
be a change permitted by the specification of that option.
In addition, a transit RBridge:
o MAY add, if space is available, or remove hop-by-hop options as
specified for such options;
o MAY change the value and/or length of a mutable ingress-to-egress
TLV option as permitted by that option's specification and
provided there is enough room if lengthening it;
D. Eastlake, et al [Page 5]
INTERNET-DRAFT TRILL Header Options
o MUST adjust the length of the options area, including changing Op-
Length in the TRILL header, as appropriate for any changes it has
made;
o MUST NOT add, remove, or re-order ingress-to-egress options.
o with regard to any non-critical hop-by-hop options that the
transit RBridge does not implement, it MAY remove them if they are
mutable but MUST transparently copy them when forwarding a frame
if they are immutable.
2.2 No Critical Surprises
RBridges advertise the ingress-to-egress options they support in
their IS-IS LSP and advertise the hop-by-hop options they support at
a port on the link connected to that port. An RBridge is not
required to support any options.
Unless an RBridge advertises support for a critical option, it will
not normally receive frames with that option.
An RBridge SHOULD NOT add a critical option to a frame unless,
- for a critical hop-by-hop option, it has determined that the next
hop RBridge or RBridges that will accept the frame support that
option, or
- for a critical ingress-to-egress option, it has determined that
the RBridge or RBridges that will egress the frame support that
option.
"SHOULD NOT" is specified since there may be cases where it is
acceptable for those frames, particularly for the multi-destination
case, to be discarded by any RBridges that do not implement the
option.
2.3 Options Format
If any options are present in a TRILL Header, as indicated by a non-
zero Op-Length field, the first 32 or 64 bits of the options area
consist of extended header flags and the Flow ID, as described below.
The remainder of the options area, if any, after this initial 32 or
64 bits, consists of TLV (Type Length Value) options aligned on
32-bit boundaries. Section 2.3.2 specifies the format of a TLV
option. Section 2.3.3 describes the marshaling of TLV options.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL Header Options
2.3.1 Extended Header Flags Area
The first 32 bits of the Options Area are organized as follows:
| 0 1 2 3-4 5-7 8-10 11-12 13 14 15 | 16 - 31 |
+----+----+----+----+----+----+-----+----+----+----+---------+
|CHbH|CItE|MEF |CHHF|NHHF|CIEF|NIEF |NHHT|CIET|NIET| Flow ID |
+----+----+----+----+----+----+-----+----+----+----+---------+
Figure 1: Options Area Initial 32 Bits
Any RBridge adding an options area to a TRILL Header must set these
32 bits to zero except when permitted or required to set one or more
of them as specified. The meanings of these bits are listed in the
table below and then further described.
Bit(s) Description
---------------------
0 CHbH: Critical Hop-by-Hop option(s) are present.
1 CItE: Critical Ingress-to-Egress option(s) are present.
2 MEF: More Extended Flags, indicates that an additional 32-bit
extended flags area is present as described below.
3-4 CHHF: Critcial Hob-by-Hop extended Flag bits.
5-7 NHHF: Non-critical Hop-by-Hop extended Flag bits.
8-10 CIEF: Critical Ingress-to-Egress extended Flag bits.
11-12 NIEF: Non-critical Ingress-to-Egress extended Flag bits.
13 NHHT: Non-critical Hop-by-Hop TLV option(s) are present.
14 CIET: Critical Ingress-to-Egress TLV option(s) are present.
15 NIET: Non-critical Ingress-to-Egress TLV option(s) are
present.
16-31 Flow ID if non-zero.
All extended flags are considered mutable except the critical hop-by-
hop extended flags.
For TRILL Data frames with options present, any transit RBridge MUST
transparently copy bits 8 through 12, except as permitted by an
option implemented by that RBridge, but MAY either copy or clear any
of the bits 5 through 7. Even if a transit RBridge removes all TLV
options from a TRILL Header when allowed to do so, it MUST NOT
eliminate the options area in a forwarded frame if any of bits 3, 4,
or 8 through 12 remain non-zero; however, if there are no TLV options
and all of bits 2 through 31 are zero, then the summary bits will
also be zero and the transit RBridge MAY eliminate the Options area
in the frame, setting Op-Length to zero.
D. Eastlake, et al [Page 7]
INTERNET-DRAFT TRILL Header Options
2.3.1.1 Critical Summary Bits
The top two bits of the options area, bits 0 and 1 above, are called
the critical summary bits. They summarize the presence of critical
options as follows:
CHbH: If the CHbH (Critical Hop by Hop) bit is one, one or more
critical hop-by-hop options are present in the options area.
Transit RBridges that do not support all of the critical hop-by-
hop options present, for example an RBridge that supported no hop-
by-hop options, MUST drop the frame. If the CHbH bit is zero, the
frame is safe, from the point of view of options processing, for a
transit RBridge to forward, regardless of what options that
RBridge does or does not support. A transit RBridge that supports
none of the options present MUST transparently forward the options
area when it forwards a frame, except that it MAY remove mutable
hop-by-hop options.
CItE: If the CItE (Critical Ingress to Egress) bit is a one, one or
more critical ingress-to-egress options are present in the options
area. If it is zero, no such options are present. If either CHbH
or CItE is non-zero, egress RBridges that do not support all
critical options present, for example an RBridge that supports no
options, MUST drop the frame. If both CHbH and CItE are zero, the
frame is safe, from the point of view of options, for any egress
RBridge to process, regardless of what options that RBridge does
or does not support.
The critical summary bits enable efficient processing of TRILL Data
frames by RBridges that support no critical options and by transit
RBridges that support no critical hop-by-hop options. Such RBridges
need only check whether Op-Length is non-zero and, if it is, the top
one or two bits just after the fixed portion of the TRILL Header.
2.3.1.2 MEF, More Extended Flags
Bit 2, if set, indicates there are an additional 32 bits of extended
flags. They are organized as shown below. The start of the TLV
options, if any, is moved to after these additional bit options.
| 32 - 39 | 40 - 47 | 48 - 55 | 56 - 63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Critical HbH |NonCritical HbH| Critical ItE |NonCritical ItE|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Flag Bits 32 to 63
D. Eastlake, et al [Page 8]
INTERNET-DRAFT TRILL Header Options
2.3.1.3 Specific Initial Bit Extended Flags
CHHB, bits 3 and 4, are Critical Hob-by-Hop Bits.
NHHB, bits 5 through 7, are Non-critical Hop-by-Hop Bits.
CIEB, bits 8 through 10, are Critical Ingress-to-Egress Bits.
NIEB, bits 11 and 12, are Non-critical Ingress-to-Egress Bits.
The bits above are available for indicating extended header flags,
except for two NHHF allocated by Section 3.1 below.
2.3.1.4 TLV Summary Bits
It is anticipated that in most cases the interpretation of TLV
encoded options in TRILL data frames will be handled by slow path
software. To minimize unnecessary resort to the slow path, the TLV
summary bits, plus a special check for critical hop-by-hop TLV
options, enable an RBridge to quickly determine if any TLV encoded
options of the category or categories it implements are present.
Bits 13-15, the NHHT, CIET, and NIET bits, indicate the presence
later in the TRILL Header of TLV encoded Non-critical Hop-by-Hop,
Critical Ingress-to-Egress, and Non-critical Ingress-to-Egress TLV
options respectively.
There is no Critical Hop-by-Hop TLV flag bit because the presence of
one or more such TLV options can be determined by examining Op-Length
and, if Op-Length and the MEF bit indicate that there are TLV options
beyond the extended flags area, examining the top two bits of the
first options area byte after the extended flags area. The ordering
restrictions on TLV options require that, if any Critical Hop-by-Hop
TLV options are present, the appear first in the TLV options area.
Thus it is adequate to check only if the first TLV option present is
a Critical Hop-by-Hop option, which can be determined from the top
two bits of its first byte.
2.3.1.5 Flow ID
In connection with the multi-pathing of frames, frames that are part
of the same order-dependent flow need to follow the same path.
Methods to determine flows are beyond the scope of the this document;
however, it may be useful, once the flow of a unicast frame has been
determined, to preserve and transmit that information for use by
subsequent RBridges.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT TRILL Header Options
The Flow ID option is a specially encoded non-critical hop-by-hop
option that appears in bits 16 through 31 of the initial bit encoded
options area. Its presence is indicated by a non-zero value in that
field.
It is considered hop-by-hop because it can be added or changed by a
transit RBridge and transit RBridges can use it to make forwarding
decisions. Because the ingress RBridge may know the most about a
frame, it is expected that this option would most commonly be added
at the ingress RBridge. Once set non-zero in a frame, the option
SHOULD NOT be removed, set to zero, or changed unless, for example, a
campus is divided into regions such that different Flow IDs would
make sense in different regions.
2.3.2 TLV Option Format
TRILL Header options, other than the extended header flags and Flow
ID described above, are TLV encoded, with some flag bits in the Type
and Length octets, in the format show in Figure 3.
| 0 1 2 3 4 5 6 7 8 9|10| 11-15 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---
|IE|NC| Type |MT| Length | value...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+---
Figure 3. Option TLV Structure
The highest order bit of the first octet (IE) is zero for hop-by-hop
options and one for ingress-to-egress options. Hop-by-hop options
are potentially applicable to every RBridge that receives the frame.
Ingress-to-egress options are only inserted at the ingress RBridge
and are applicable at egress RBridges. Ingress-to-egress options MAY
also be examined and acted upon by transit RBridges as specified in
the particular option.
The second highest order bit of the first octet (NC) is zero for
critical options and one for non-critical options.
Bit 10 in the second octet (MT) is zero for immutable options and one
for mutable options. The IE, NC, Type, and MT fields themselves MUST
NOT be changed even for a mutable option.
The eight-bit Type code extends from bit 2 through bit 9. The option
Type may constrain the values of the IE, NC, and MT bits. For
example, a certain Type might require that the option be marked as a
hop-by-hop, non-critical, mutable option. If the IE, NC, or MT bits
have a value not permitted by the option Type specification for an
option that an RBridge must act on (any critical ingress-to-egress
D. Eastlake, et al [Page 10]
INTERNET-DRAFT TRILL Header Options
option at an egress RBridge and any critical hop-by-hop option), the
RBridge MUST discard the frame. If these bits have a value not
permitted by for the Type for an option that an RBridge may ignore
(any ingress-to-egress option at a transit RBridge and any non-
critical option), the RBridge MAY discard the frame. "MAY" is chosen
in this case to minimize the checking burden.
The Length field is an unsigned quantity giving the length of the
option value in units of four octets. It gives the size of the
option including the initial two Type and Length octets. The Length
field MUST NOT be such that the option value extends beyond the end
of the total options area as specified by the TRILL Header Op-Length.
Thus, the value 31 is reserved and, when such a value is noticed in a
frame, the frame MUST be discarded.
2.3.3 Marshaling of Options
In a TRILL Header with options, those options start immediately after
the Ingress RBridge Nickname and fill the options area. TLV options
are 32-bit aligned.
TLV options start immediately after the initial four or eight octets
of extended flags area and MUST appear in ascending order by the
value of the eleven high order bits (bits 0 through 10) of the Type
and Length octets considered as an unsigned integer in network byte
order. There MUST NOT be more than one option in a frame with any
particular value of this eleven high order bits. Thus the TLV options
MUST be ordered as follows: (1) critical hop-by-hop options, (2) non-
critical hop-by-hop options, (3) critical ingress-to-egress options,
and (4) non-critical ingress-to-egress options. Frames that violate
this paragraph are erroneous, will produce unspecified results, and
MAY be discarded. "MAY" is chosen to minimize the format-checking
burden on transit RBridges.
If any options are present, those options, both flag and TLV, MUST be
correctly summarized into the CHbH, CItE, and TLV summary bits.
2.4 Conflict of Options
It is possible for options to conflict. Two or more options can be
present in a frame that direct an RBridge processing the frame to do
conflicting things or to change its interpretation of later parts of
the frame in conflicting ways. Such conflicts are resolved by
applying the following rules in the order given:
1. Any frame containing options that require mutually incompatible
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL Header Options
changes in way later parts of the frame, after the options area,
are interpreted or structured MUST be discarded. (Such options
will be critical options, normally hop-by-hop critical options.)
2. Critical options override non-critical options.
2. Within each of the two categories of critical and non-critical
options, the option appearing first in lexical order in the frame
always overrides an option appearing later in the frame. Thus a
conflict between an extended flag and a TLV option is always
resolved in favor of the extended flag. Extended flags with lower
bit numbers are considered to have occurred before extended flags
with higher bit numbers.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT TRILL Header Options
3. Specific Extended Header Flag
The table below shows the state of TRILL Header extended flag
assignments and the location of the special Flow ID field. See
Section 6 for IANA Considerations.
Bits Purpose Section
---------------------------------------
0-1 Critical Summary Bits 2.3
2 More extended flags 2.
3-4 available for critical hop-by-hop flags
5 available for non-critical hop-by-hop flag
6-7 ECN 3.1
8-10 available for critical ingress-to-egress flags
11-12 available for non-critical ingress-to-egress flags
13-15 TLV Summary Bits 2.3.1.4
16-31 Flow ID
32-39 available for critical hop-by-hop flags
40-47 available for non-critical hop-by-hop flags
48-55 available for critical ingress-to-egress flags
56-63 available for non-critical ingress-to-egress flags
Table 1. Extended Flag Options
3.1 The ECN Option
RBridges MAY implement an ECN (Explicit Congestion Notification)
option [RFC3168]. If implemented, it SHOULD be enabled by default but
can be disable on a per RBridge basis by configuration.
RBridges that do not implement this option or on which it is disabled
simply (1) set bits 6 and 7 of the extended flags area to zero when
they add an options area to a TRILL Header and (2) transparently copy
those bits, if an options area is present, when they forward a frame
with a TRILL Header.
An RBridge that implements the ECN option does the following, which
correspond to the recommended provisions of [RFC6040], when that
option is enabled:
o When ingressing an IP frame that is ECN enabled (non-zero ECN
field), it MUST add an options area to the TRILL Header and copy
the two ECN bits from the IP header into extended header flags 6
and 7.
o When ingressing a frame for a non-IP protocol, where that protocol
has a means of indicating ECN that is understood by the RBridge,
it MAY add an options area to the TRILL Header with the ECN bits
set from the ingressed frame.
D. Eastlake, et al [Page 13]
INTERNET-DRAFT TRILL Header Options
o When forwarding a frame encountering congestion at an RBridge, if
an options area is present with extended flags 6 and 7 indicating
ECN-capable transport, the RBridge MUST modify them to the
congestion experienced value.
o When egressing an IP frame, the RBridge MUST set the outgoing
native IP frame ECN field to the codepoint at the intersection of
the values for that field in the encapsulated IP frame (row) and
the TRILL extended Header ECN field (column) in Table 3 below or
drop the frame in the case where the TRILL header indicates
congestion experienced but the encapsulated native IP frame
indicates a not ECN-capable transport. (Such frame dropping is
necessary because IP transport that is not ECN-capable requires
dropped frames to sense congestion.)
o When egressing a non-IP protocol frame with a means of indicating
ECN that is understood by the RBridge, it MAY set the ECN
information in the egressed native frame by combining that
information in the TRILL extended header and the encapsulated non-
IP native frame as specified in Table 3.
The following table is modified from [RFC3168] and shows the meaning
of bit values in TRILL Header extended flags 6 and 7, bits 6 and 7 in
the IPv4 TOS Byte, and bits 6 and 7 in the IPv6 Traffic Class Octet:
Binary Meaning
------ -------
00 Not-ECT (Not ECN-Capable Transport)
01 ECT(1) (ECN-Capable Transport(1))
10 ECT(0) (ECN-Capable Transport(0))
11 CE (Congestion Experienced)
Table 2. ECN Field Bit Combinations
Table 3 below (adapted from [RFC6040]) shows how, at egress, to
combine the ECN information in the extended TRILL Header ECN field
with the ECN information in an encapsulated frame to produce the ECN
information to be carried in the resulting native frame.
+---------+-----------------------------------------------+
| Inner | Arriving TRILL Header ECN Field |
| Native +---------+------------+------------+-----------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+-----------+
| Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | <drop>(*) |
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE |
| CE | CE | CE | CE(*) | CE |
+---------+---------+------------+------------+-----------+
Table 3: Egress ECN Behavior
D. Eastlake, et al [Page 14]
INTERNET-DRAFT TRILL Header Options
An RBridge detects congestion either by monitoring its own queue
depths or from participation in a link-specific protocol. An RBridge
implementing the ECN option MAY be configured to add congestion
experienced marking using ECN to any frame with a TRILL Header that
encounters congestion even if the frame was not previously marked as
ECN-capable or did not have an options area.
D. Eastlake, et al [Page 15]
INTERNET-DRAFT TRILL Header Options
4. Specific TLV Option
The table below shows the state of TRILL Header TLV option Type
assignment. See Section 6 for IANA Considerations.
Type Purpose Section
---------------------------------------
0x00 reserved
0x00-0x7F available
0x80 Test/Pad 4.1
0x81-0xFE available
0xFF reserved
Table 4. TLV Option Types
The following subsection specifies a particular TRILL TLV option.
4.1 Test/Pad Option
This option is intended for testing and padding.
A specific meaning for this option with the critical flag set will
not be defined so, in that form, it MUST always be treated as an
unknown critical option. If the critical flag is not set, the option
does nothing. In either case, it may be any length that will fit.
Thus, for example, in the non-critical form, it can be used to cause
the encapsulated frame staring right after the options area to be
64-bit aligned or for testing purposes.
o Type is 0x80.
o Length is variable. The value is ignored.
o IE may be zero or one. This option has both hop-by-hop and
ingress-to-egress versions.
o NC is zero for the pad option and one for the test option.
+ The non-critical version of this option does nothing.
+ The critical version of this option MUST always be treated
as an unknown critical option.
o MT may be zero or one except that it must be zero if the other
flags indicate the options is a critical hop-by-hop option.
This option may be flagged as mutable or immutable.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT TRILL Header Options
5. Additions to IS-IS
RBridges use IS-IS PDUs to inform other RBridges which options they
support. The specific IS-IS PDUs, TLVs, or sub-TLVs used to encode
and advertise this information are specified in a separate document.
Support for critical options MUST be advertised. Support for non-
critical options MAY be advertised unless the specification of a
particular non-critical option imposes a requirement higher than
"MAY" for the advertising of that option by RBridges that implement
it.
D. Eastlake, et al [Page 17]
INTERNET-DRAFT TRILL Header Options
6. IANA Considerations
IANA will create two subregistries within the TRILL registry. A
"TRILL Extended Header Flags" subregistry that is initially populated
as specified in Table 1 in Section 3. And a "TRILL TLV Option Types"
subregistry that is initially populated as specified in Table 4 in
Section 4. References in both of those tables to sections of this
document are to be replaced in the IANA subregistries by references
to this document as an RFC.
New TRILL bit options and TLV option types are allocated by IETF
Review [RFC5226].
7. Security Considerations
For general TRILL protocol security considerations, see [RFCtrill].
In order to facilitate authentication, options SHOULD be specified so
they do not have alternative equivalent forms. Authentication of
anything with alternative equivalent forms almost always requires
canonicalization that an authenticating RBridge ignorant of the
option would be unable to do and that may be complex and error prone
even for an RBridge knowledgeable of the option. It is best for any
option to have a unique encoding.
8. Acknowledgements
The following are thanked for their contributions: Bob Briscoe.
D. Eastlake, et al [Page 18]
INTERNET-DRAFT TRILL Header Options
9. References
Normative and informative references for this document are given
below.
9.1 Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC6040] - Briscoe, B., "Tunneling of Explicit Congestion
Notification", RFC 6040, November 2010
[RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-16.txt, in RFC Editor's queue.
9.2 Informative References
None.
D. Eastlake, et al [Page 19]
INTERNET-DRAFT TRILL Header Options
Change History
The sections below summarize changes between successive versions of
this draft. RFC Editor: Please delete this section before
publication.
Version 00 to 02
Change the requirement for TLV option ordering to be strictly ordered
by the value of the top nine bits of their first two bytes so that
the MT bit is included.
Specify meaning of mutability bit for hop-by-hop options.
Fix length of Flow ID Value at 2.
Require that options that may significantly affect the interpretation
or format of subsequent parts of the frame be critical options.
Version 02 to 03
Move Test/Pad option into this document from the More Options draft
and move the More Flags option from this document into the More
Options draft.
Prohibit multiple occurrences of a TLV option in a frame.
Version 03 to 04
Restructure the bit encoded options area so that the initial 32 bits
include a 16 bit Flow ID, various TLV-option-present bits, and a more
extended flags bit that means another 32 bits of extended flags are
present.
Change the Length of TLV encoded options so that it is in units of 4
bytes, not 1, resulting in a bigger Type field.
Update Explicit Congestion Notification to follow RFC 6040.
Rename "bit encoded options" to be "extended header flags" or
"extended flags".
D. Eastlake, et al [Page 20]
INTERNET-DRAFT TRILL Header Options
Authors' Addresses
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757
Phone: +1-508-333-2270
email: d3e3e3@gmail.com
Anoop Ghanwani
Brocade Communications Systems
130 Holger Way
San Jose, CA 95134 USA
Phone: +1-408-333-7149
Email: anoop@brocade.com
Vishwas Manral
IP Infusion Inc.
1188 E. Arques Ave.
Sunnyvale, CA 94089 USA
Tel: +1-408-400-1900
email: vishwas@ipinfusion.com
Caitlin Bestler
Quantum
1650 Technology Drive , Suite 700
San Jose, CA 95110
Phone: +1-408-944-4000
email: cait@asomi.com
D. Eastlake, et al [Page 21]
INTERNET-DRAFT TRILL Header Options
Copyright and IPR Provisions
Copyright (c) 2011 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 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 22]
