TRILL Working Group Donald Eastlake 3rd INTERNET-DRAFT Stellar Switches Intended status: Proposed Standard Caitlin Bestler Consultant Expires: October 20, 2009 April 21, 2009 RBridges: TRILL Header Options Status of This Document 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 . 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 Abstract The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-12.txt, specifies minimal hooks for options. This draft fully describes the format for options and specifies an initial set of options. D. Eastlake & C. Bestler [Page 1] INTERNET-DRAFT TRILL Header Options Table of Contents Status of This Document....................................1 Abstract...................................................1 1. Introduction............................................3 1.1 Conventions used in this document......................3 2. TRILL Header Options....................................4 2.1 RBridge Option Handling Requirements...................4 2.2 No Surprises...........................................5 2.3 Options Format.........................................5 2.3.1 Bit Options and Summary Bits.........................6 2.3.2 TLV Option Format....................................7 2.3.3 The Padding TLV Option...............................8 2.3.4 Marshalling of Options...............................8 3. Specific Bit Options...................................10 3.1 ECN Bit Option........................................10 4. Specific TLV Options...................................12 4.1 VLAN and DA Promotion TLV Option......................12 4.2 Additional Flags TLV Option...........................12 4.3 Flow ID TLV Option....................................13 4.4 Port ID TLV Option....................................14 4.5 Authentication TLV Option.............................15 4.5.1 Authentication Option Computations..................15 4.5.2 Authentication Option Fields and Flags..............16 5. Additions to IS-IS.....................................17 5.1 Additions to Link State...............................17 5.2 Additional to Port Capabilities.......................17 6. IANA Considerations....................................18 7. Security Considerations................................18 8. Acknowledgement........................................18 9. Normative References...................................19 10. Informative References................................19 Change History............................................20 Changes from -02 to -03...................................20 Changes from -03 to -04...................................20 Authors' Addresses........................................21 Copyright and IPR Provisions..............................22 D. Eastlake & C. Bestler [Page 2] INTERNET-DRAFT TRILL Header Options 1. Introduction The base TRILL protocol specification appears in [Protocol]. That specification provides an options feature and describes minimal hooks to safely support that feature. But it does not specify the structure of options nor the details of any particular options. Section 2 below describes the general principles of operation, format, and ordering of TRILL Header Options. Section 3 describes specific bit options while Section 4 describes specific TLV encoded options. 1.1 Conventions used in this document The terminology and acronyms for [Protocol] are used herein with the same meaning. 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 & C. Bestler [Page 3] INTERNET-DRAFT TRILL Header Options 2. TRILL Header Options The TRILL Protocol includes an option capability in the TRILL Header (see [Protocol] Section 3.5). The Op-Length header field gives the length of the options in units of 4 octets, which allows up to 124 octets of options area. If Op-Length is zero there are no options present; else, the options follow immediately after the Ingress Rbridge Nickname field in the TRILL Header. As described below, provision is made for both hop-by-hop options, which could affect any RBridge which received a TRILL frame, 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. An RBridge potentially affected by a critical option that it does not understand MUST discard the frame as it is unsafe to process the frame without understanding the option. Non-critical options can be safely ignored. Options also indicate whether the value associated with them can change (mutable options) or not (immutable options). Note: Most RBridges implementations are expected to be optimized for the simplest and most common cases of frame forwarding and processing. The inclusion of any options may and the inclusion of complex or lengthy options will likely cause frame processing using a "slow path" with markedly inferior performance to "fast path" processing. Limited slow path throughput may cause such frames to be lost. 2.1 RBridge Option Handling Requirements The requirements given in this section are in additional to all option handling requirements in [Protocol]. All Rbridge MUST be able to detect whether there are any critical options present that are applicable to their processing of the frame as detailed below. If they do not implement all critical options present, they MUST discard the frame. Transit RBridges MUST transparently forward any immutable ingress-to- egress options in frames 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. Note: Even though a transit RBridge might not examine or act on an ingress-to-egress option, the presence of that option may cause the frame to suffer from slow path processing. In addition, a transit RBridge o MAY add a hop-by-hop option to a frame, D. Eastlake & C. Bestler [Page 4] INTERNET-DRAFT TRILL Header Options o MAY add a padding option if there is room and none is present, o MAY remove an unnecessary padding option, o MAY adjust the length of an existing padding option, o MAY remove a hop-by-hop option as specified for that option, o MAY change the value and Length of a mutable option as permitted by that option's specification, but o MUST NOT add or remove an ingress-to-egress option. For any of these changes which alter the overall length of the TRILL Header options area, the transit RBridge also adjusts the Header Op- Length field. 2.2 No Surprises RBridges advertise the ingress-to-egress options that they support in the core TRILL IS-IS instance and advertise the hop-by-hop options they support in Hellos they send. An RBridge is not required to support any options; however, an RBridge which supports any other option MUST also support the padding option. No RBridge will receive a frame with a critical TRILL Header option it must apply unless it advertised support for that option, except due to errors or transient conditions. Should an RBridge receive a frame with an applicable critical option it does not implement, it MUST discard the frame. If an RBridge is about to send a TRILL frame and the next hop destination RBridge (or any of the next hop destination RBridges if the frame is multi-destination) would not understand a critical option in the frame that the next hop RBridge(s) might be required to apply, it is the responsibility of the transmitting RBridge to either (1) remove the option and make any necessary other adjustments to the frame before transmission or (2) to drop the frame. (The transmitting RBridge should understand the option or else it would not have received or generated that critical option.) TRILL options are generally inappropriate for any "extension" to TRILL that all RBridges in a campus would be required to understand or for a critical hop-by-hop option that cannot be backed out as described immediately above. The addition of such an "extension" would likely be a major change to the protocol and should be handled by a revision to the TRILL protocol version number. 2.3 Options Format If any options are present in a TRILL header, as indicated by a non- zero Op-Length field, the first four octets of the options area D. Eastlake & C. Bestler [Page 5] INTERNET-DRAFT TRILL Header Options consist of two summary bits and 30 option bits as described in Section 2.3.1. The remainder of the options area consists of TLV (Type Length Value) encoded options. Section 2.3.2 specifies the format of an individual TLV option. Further details on the padding option are specified in Section 2.3.3. Section 2.3.4 describes the marshalling of TLV options. 2.3.1 Bit Options and Summary Bits | 0 1 2 3 4 5 6 7| 8 - 15|16-23|24-31| +------+------+--+--+--+--+--+--+-------+-----+-----+ | CHbH | CItE | | | | | +------+------+--+--+--+--+--+--+-------+-----+-----+ Figure 1: Options Area Initial Bit Octets Bits 0 and 1 above, the top two bits of the options are, are called summary bits and summarize the presence of critical options. The following summary bit description text is copied from [Protocol] for convenience: If the CHbH (Critical Hop by Hop) bit is one, one or more critical hop-by-hop options are present so transit RBridges that support no 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, even if the forwarding RBridge doesn't understand any options. A transit RBridge that supports no options and forwards a frame MUST transparently forward the options area. If the CItE (Critical Ingress to Egress) bit is a one, one or more critical ingress-to-egress options are present. If it is zero, no such options are present. If either CHbH or CItE is non-zero, egress RBridges that support 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, even if it doesn't understand any options. The remaining 30 bits in the options area initial four octets are available for bit encoded options. Any RBridge adding a options area to a TRILL Header must set these 30 bits to zero except when permitted to set one or more by an option that RBridge understands. The 30 bits are categorized as follows: D. Eastlake & C. Bestler [Page 6] INTERNET-DRAFT TRILL Header Options Bits Category --------------------- 2- 7 Critical hop-by-hop 8-15 Non-critical hop-by-hop 16-23 Critical ingress-to-egress 24-31 Non-critical ingress-to-egress Any transit RBridge must transparently copy any of the bits 2-31 except as permitted by an option implemented by that RBridge or to back out an critical option because it is not implemented by a next- hop RBridge. Even if a transit RBridge removes all TLV options from a TRILL Header, it MUST NOT eliminate the options area if any of these 30 bits is non-zero. 2.3.2 TLV Option Format All TRILL Header options, other than bit options described above, are TLV encoded, with some flag bits in the Type and Length octets, in the format show in Figure 2. | 0 1 2 3 4 5 6 7| 8| 9-15 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- |IE|NC| Type |MT| Length | value... +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- Figure 2. 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 and the padding option. Hop-by-hop options are potentially applicable to every RBridge which receives the frame. Ingress-to-egress options are only added at the ingress RBridge and are potentially applicable only at egress RBridges. Ingress-to-egress options MAY also be examined and acted upon by transit RBridges. The next to highest order bit of the first octet (NC) is zero for critical options and one for non-critical options and the padding option. Non-critical options are those that can be safely ignored. Critical options are those which it is unsafe to ignore, for example options that indicate a change in the format of the remainder of the frame after the TRILL Header, such that attempts to parse this remainder could fail unless the critical option is understood. The bottom six bits of the first octet give the option Type code. The option Type may constrain the values of the IE, NC, and MT bits. The highest order bit of the second octet (MT) is zero for options with immutable values, that is where the value and Length will not D. Eastlake & C. Bestler [Page 7] INTERNET-DRAFT TRILL Header Options change. It is one for such options that have a mutable value. The IE, NC, Type, and MT fields themselves are always immutable. The Length field is the unsigned length of the option value in octets. It gives the amount of option value data, if any, beyond the initial two 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 of Length can vary from zero to 120. The meaning of "Length" values of 121 through 127 is reserved and, when such values are detected, they cause the frame to be discarded. 2.3.3 The Padding TLV Option The padding option is used for padding at the end of the options area of a TRILL Header. A padding option is required if the total length of other options falls short of the space indicated by Op-Length. The padding option is Type 0x37 and MUST have the IE, NC, and MT bits equal to one although it is not an ingress-to-egress option. An option with Type 0x37 where any of the IE, NC, and MT bits are zero is invalid and, if detected, causes the frame to be discarded. A padding option MAY be included even if the length of the other options present is an exact multiple of 4 octets. Where padding is needed, it MAY be larger than strictly necessary; for example, an ingress RBridge might choose to round Op-Length up to an even value and pad any options it includes in a TRILL Header up to an exact multiple of 8 octets to retain 64-bit alignment for the inner frame. All value octets in a padding option may be any value and need not be preserved by transit RBridges. 2.3.4 Marshalling of Options In a TRILL Header with options, those options start immediately after the Ingress RBridge Nickname and completely fill the options area whose overall length is given in the Op-Length field. TLV options start immediately after the initial four octets of option and summary bits and MUST appear in ascending order by the value of their first octet considered as an unsigned 8-bit integer. As a result, all hop-by-hop options MUST be placed before all ingress-to- egress options and, within each of those two categories, all critical options MUST appear before all non-critical options. The padding option, if present, MUST appear last. A particular option first octet value MUST NOT appear more than once in a TRILL Header. Frames D. Eastlake & C. Bestler [Page 8] INTERNET-DRAFT TRILL Header Options which violate this paragraph are erroneous, will produce unspecified results, and MAY be discarded. ("MAY" is chosen to minimize the format checking burden required of transit RBridges.) Options are 32-bit aligned. Should an option not consist of a multiple of four octets, the option is padded at the end up to the nest multiple of four octets with octets that MUST be zero. Should the total length of the options (other than the padding option) in a frame not fill the area indicated by the TRILL Header Op-Length, a padding option MUST be used to exactly fill the remaining space. If any options are present, those options, both flag and TLV, MUST be correctly summarized into the CHbH and CItE bits at the top of the initial two octets of the options area. D. Eastlake & C. Bestler [Page 9] INTERNET-DRAFT TRILL Header Options 3. Specific Bit Options The table below shows the state of TRILL Header bit option assignments. See Section 7 for IANA Considerations. Bit Purpose Section ----------------------------------- 0-1 Summary 2.3 2-7 available for hop-by-hop critical options 8-9 ECN 3.1 10-15 available for hop-by-hop non-critical options 16-23 available for ingress-to-egress critical options 24-31 available for ingress-to-egress non-critical options Table 1. Flag Options 3.1 ECN Bit Option There are two distinct aspects as to how an RBridge should deal with congestion. The first deals with congestion the RBridge detects itself, and the second deals with congestion reported to it via a link-specific protocol. 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 8 and 9 of the bit options area 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 MUST do the following when that option is enabled: o When ingressing an IP frame that is ECN enabled, it adds an options area to TRILL Header and copies the two ECN bits from the IP header into option bits 8 and 9. o When forwarding a frame encountering congestion at an RBridge, if an options area is present with option bits 8 and 9 indicate ECN- capable transport, the RBridge modifies them to the congestion experienced value. o When egressing an IP frame, if the TRILL Header has an options area with option bits 8 and 9 non-zero, it copies those bits into the ECN bits in the IP header. The following table is modified from [RFC3168] and shows the meaning of bit values in TRILL Header option bits 8 and 9, bits 6 and 7 in D. Eastlake & C. Bestler [Page 10] INTERNET-DRAFT TRILL Header Options 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) An RBridge detects congestion either by monitoring its own queue depths or from participation in a link-specific protocol. An RBridge 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. On any of its links an RBridge implementing the ECN option MAY participate in other link-specific congestion control and/or traffic shaping protocols. Specific strategies for using the ECN bits in the TRILL option header for such other protocols are to be considered experimental until described in a later RFC. RBridges that have ECN enabled and are participating in a link- specific congestion protocol on more than one link SHOULD relay congestion notifications between links unless to do so would violate the link-specific protocol rules. For example, IEEE 802.1 congestion management protocols currently under development contemplate a connected cloud of nodes within which such protocols, which make use of selected frame priority, are implemented. Implementing such protocols would require that bridges or RBridges on the edge of such a cloud not admit frames with those priorities. An RBridge SHOULD NOT circumvent such link-specific rules. When forwarding a frame from a link indicating congestion to another RBridge via a link without the same congestion control protocol, an RBridge MAY use the ECN field to signal the congestion as though the RBridge had detected the congestion itself. D. Eastlake & C. Bestler [Page 11] INTERNET-DRAFT TRILL Header Options 4. Specific TLV Options The table below shows the state of TRILL Header TLV option Type assignment. See Section 6 for IANA Considerations. Type Purpose Section ----------------------------------------- 0x00 reserved 0x01 VLAN and DA Promotion 4.1 0x02-0x04 available 0x05 Authentication 4.5 0x06-0x0F available 0x10 Additional Flags 4.2 0x11 Flow ID 4.3 0x12-0x2F available 0x30 Port ID 4.4 0x31-0x3E available 0x3F Padding 2.3.3 Table 2. TLV Option Types The following subsections specify particular TRILL TLV options. 4.1 VLAN and DA Promotion TLV Option This option moves the Inner.VLAN tag and Inner.MacDA, both of which must be examined to prune multi-destination frame distribution trees, to a logically earlier location in a frame with a TRILL header and to a fixed offset from the beginning of such a frame. It will always appear first among TLV options because, as a critical hop-by-hop option with type 1, the value of its first octet is the lowest available. In a frame with the VLAN and DA promotion option, the Inner.VLAN and Inner.MacDA are not present in the encapsulated frame. The option fields and flags are as follows: o Type is 0x01. o Length MUST be 10 and data consists of a VLAN tag followed by a MAC address. o IE, NC, and MT MUST be zero. This is a hop-by-hop, critical, immutable option. 4.2 Additional Flags TLV Option The option provides a means of adding a variety of additional flags to the TRILL Header beyond the bit options available in the first D. Eastlake & C. Bestler [Page 12] INTERNET-DRAFT TRILL Header Options four octets of the options area. The value of the flags option consists of additional flags, eight per octet, numbered from the high-order to the low-order bit. Thus flag 1 is the 0x80 bit of the first octet, flag 8 is the 0x01 bit of that octet, flag 9 is the 0x80 bit of the second octet, etc. The number of additional flags that can be defined is bounded only by the options space that can be available. All flags not present, because the would be in value octets beyond those specified by the option Length, are considered zero. This option can appear up to four times in a frame to provide independent sets of all combinations of ingress-to-egress, hop-by- hop, non-critical, and critical flags. To simplify canonicalization for security, this option MUST NOT be included if all of the flag bits would be zero and the value MUST NOT have any trailing zero octets. Thus its Length MUST be at least 1 and at least the last octet of the value present MUST be non-zero. The option fields and flags are as follows: o Type is 0x10. o Length is variable with a minimum value of 1. o IE and NC are variable producing, in effect, four versions of this option. o MT MUST be zero. This is an immutable option. 4.3 Flow ID TLV Option In connection with multi-pathing of frames, it is desirable that frames that are part of the same flow follow the same path. Methods to determine flows are beyond the scope of the TRILL standard; however, it may be useful, once the flow of a frame has been determined, to preserve and transmit that information for use by subsequent RBridges. This is a non-critical option. It is considered hop-by-hop because it can be added by a transit RBridge. It can also affect transit RBridge behavior. Because the ingress RBridge or even the originating end station (which may have some way of signaling the ingress RBridge beyond the scope of TRILL), may know the most about a frame, it is expected that this option would most commonly be added at the ingress RBridge. Once in a frame, the option SHOULD NOT be removed or changed unless, for example, a campus is divided into regions such that different flow IDs would make the most sense in different regions. The option fields and flags are as follows: D. Eastlake & C. Bestler [Page 13] INTERNET-DRAFT TRILL Header Options o Type is 0x11. o Length is variable with a minimum value of 1. The data is an unsigned integer that is the flow ID. [Should length be fixed or have only a few allowed values, such as 2 or 4?] o IE MUST be zero. This is a hop-by-hop option. o NC and MT MUST be one. This is a non-critical mutable option. 4.4 Port ID TLV Option The purpose of the Port ID option is to avoid the destination MAC address to physical port mapping lookup at the egress RBridge. This might be beneficial for extremely high-speed applications. This option provides a 2-octet logical destination port and a 2-octet logical source port that, in some ways, could be considered extensions to the 6 octet inner destination and source MAC addresses in a frame. These logical port designators are local to the destination and source RBridges and may be any values those RBridges find convenient to efficiently map to their physical ports; however, the value 0x0000 is used to indicate that a logical port designator is unknown and the value 0xFFFF is reserved and MUST NOT appear in a port ID option. RBridges that implement this option learn the Port ID for a remote MAC address from the source Port ID field in the Port ID option, if present, in frames they decapsulate in the same way they can learn the egress RBridge and VLAN. This information is timed out in the same manner as remote MAC address information. Such RBridges include their local Port ID in the source field of a Port ID option when encapsulating a frame if inclusion of this option is indicated by their local policy. For known unicast TRILL data frames, one would expect ingress RBridges implementing this option to include it if sending to egress RBridges that also implement the option. For multi-destination TRILL data frames, inclusion of a Port ID option with a source port ID may make sense but the destination port ID is meaningless and ignored by egress RBridges. The option fields and flags are as follows: o Type is 0x30. o Length MUST be 4. The data is the 2-octet destination port ID followed by the 2-octet source port IS. o IE and NC MUST be one This is an ingress-to-egress non- critical option. o MT MUST be zero. This is an immutable option. D. Eastlake & C. Bestler [Page 14] INTERNET-DRAFT TRILL Header Options 4.5 Authentication TLV Option TRILL provides a security option that builds on the IS-IS security keying [RFC5304] and can be applied to frames with a TRILL Header. The first octet of the option value is the same algorithm selection code as for IS-IS. The value length for the option is variable and depends on the algorithm in the same way as the value in the IS-IS security TLV. Algorithm zero indicates a plain text password which must be configured in code which generates and checks this TLV and is NOT RECOMMENDED. Thus far, other algorithms have indicated HMAC signing of a canonical form of the message using a shared secret which must likewise be configured. This option can appear up to twice in a frame, once for ingress-to- egress security and once for hop-by-hop security. 4.5.1 Authentication Option Computations For algorithms which depend on the value of the frame (i.e., all confidentiality algorithms and all strong authentication algorithms), the frame must be canonicalized before the authentication code is computed or verified. This is canonicalization is logically done by copying the frame starting with the TRILL Header and modifying the copy as follows: 1. Set the TRILL Header Hop Count to zero. 2. Clear the octets of the Authentication Option after the algorithm selection code. 3. For all mutable options, setting the option Length to zero and remove any value octets. 4. If an ingress-to-egress authentication code is being computed, since hop-by-hop options can be added or deleted in transit, all hop-by-hop options must be removed from the frame copy. When a critical hop-by-hop option is removed, appropriate adjustments must be made in the remainder of the frame, as if it was about to be forwarded to an RBridge which did not support that hop-by-hop critical option. 5. Eliminate the padding option if it is present. 6. Adjust the TRILL Header Op-Length downward as necessary to make it correct for the other adjustment smade in the frame copy. D. Eastlake & C. Bestler [Page 15] INTERNET-DRAFT TRILL Header Options The authentication code is then calculated using this copy and either inserted into the real frame for transmission or compared against the authentication code in the real frame for verification. 4.5.2 Authentication Option Fields and Flags The security option fields and flags are as follows: o Type is 0x04. o Length MUST be at least 1. o IE is variable. There may be an ingress-to-egress or hop-by-hop security option in a frame or both. o NC and MT MUST be zero. This is a critical, immutable option. D. Eastlake & C. Bestler [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 TLVs or sub-TLVs used to encode this information is specified in a separate document. 5.1 Additions to Link State Rbridges indicate in their link state which ingress-to-egress TLV option Types they support. In addition, if they support the ingress- to-egress Additional Flags TLV option, they indicate which critical ingress-to-egress Additional Flags TLV option flags they support. 5.2 Additional to Port Capabilities Rbridges indicate in their Hellos which hop-by-hop TLV option Types they support. In addition, if they support the Hop-by-Hop Additional Flags TLV option, they indicate which critical hop-by-hop Additional Flags TLV option flags they support. D. Eastlake & C. Bestler [Page 17] INTERNET-DRAFT TRILL Header Options 6. IANA Considerations IANA will create two subregistry within the TRILL registry. One for TRILL Header bit options that is initially populated as specified in Table 1 in Section 3. And a second for TRILL TLV Option Types which is initially populated as specified in Table 2 in Section 4. New TRILL option bits and TLV type codes are allocated by IETF Review. IANA will create a third subregistry within the TRILL registry for flags in each of the four variations of the Flags option (the four combinations of critical and non-critical, ingress-to-egress and hop- by-hop) which is initially empty. Such flags are allocated by TRILL Expert Approval. 7. Security Considerations TBD 8. Acknowledgement The Port ID option was suggested as part of the TRILL Header by Silvano Gai. D. Eastlake & C. Bestler [Page 18] INTERNET-DRAFT TRILL Header Options 9. Normative References [Protocol] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-trill- rbridge-protocol-12.txt, work in progress. [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. 10. Informative References [RFC5304] - Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008. D. Eastlake & C. Bestler [Page 19] INTERNET-DRAFT TRILL Header Options Change History RFC Editor: This section to be deleted on RFC publication. Changes from -02 to -03 1. Renamed "flag options" to "bit options", expanded description of them, and added ECN bit option text. 2. Add VLAN Promotion option. 3. Update IS-IS security RFC reference. 4. Minor editorial changes. Changes from -03 to -04 1. Change options to be 32-bit aligned instead of 16-bit aligned. 2. Change bit options from all hop-by-hop non-critical so that some are ingress-to-egress and some are critical. 3. Re-name the Security option to be the Authentication option and improve its specification. 4. Change "VLAN Promotion" option to "VLAN and DA Promotion" option. 5. Minor editorial changes. D. Eastlake & C. Bestler [Page 20] INTERNET-DRAFT TRILL Header Options Authors' Addresses Donald E. Eastlake 3rd Stellar Switches, Inc. 155 Beaver Street Milford, MA 01757 tel: +1-508-634-2066 email: d3e3e3@gmail.com Caitlin Bestler Consultant 555 E. El Camino Real #104 Sunnyvale, CA 94087 tel: +1-949-528-3085 email: cait@asomi.com D. Eastlake & C. Bestler [Page 21] INTERNET-DRAFT TRILL Header Options Copyright and IPR Provisions Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 & C. Bestler [Page 22]