TRILL Working Group Donald Eastlake 3rd INTERNET-DRAFT Stellar Switches Intended status: Proposed Standard Anoop Ghanwani Brocade Caitlin Bestler Quantum Expires: January 10, 2010 July 10, 2010 RBridges: TRILL Header Options Abstract The TRILL base protocol specification [RFCtrill], specifies minimal hooks for TRILL Header options. This draft specifies the format for options and an initial set of 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 . 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, A. Ghanwani, & C. Bestler [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..................................5 2.3 Options Format.........................................6 2.3.1 Summary Bits and Bit Options.........................6 2.3.2 TLV Option Format....................................7 2.3.3 Marshalling of Options...............................8 2.4 Conflict of Options....................................9 3. Specific Bit Option....................................10 3.1 ECN Bit Option........................................10 4. Specific TLV Options...................................12 4.1 Flow ID TLV Option....................................12 4.2 Additional Flags TLV Option...........................13 5. Additions to IS-IS.....................................14 5.1 Additions to Link State...............................14 5.2 Additions to Port Capabilities........................14 6. IANA Considerations....................................15 7. Security Considerations................................15 8. References.............................................16 8.1 Normative References..................................16 8.2 Informative References................................16 Change History............................................17 Version 00 to 01..........................................17 D. Eastlake, A. Ghanwani, & C. Bestler [Page 2] INTERNET-DRAFT TRILL Header Options 1. Introduction The base TRILL protocol specification, which appears in [RFCtrill], 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. This draft specifies that format and some initial options Section 2 below describes the general principles of operation, format, and ordering of TRILL Header Options. Such options are of two kinds: bit encoded options and TLV (Type, Length, Value) encoded options. Section 3 describes a specific bit option while Section 4 describes specific TLV encoded options. 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, A. Ghanwani, & C. Bestler [Page 3] INTERNET-DRAFT TRILL Header Options 2. TRILL Header Options The TRILL Protocol includes an option feature in the TRILL Header (see [RFCtrill] Sections 3.5 and 3.8). The 5-bit 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 and each option is 32-bit aligned. As described below, provision is made for both hop-by-hop options, which might affect any RBridge that receives a TRILL frame containing such an option, 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 receiving a frame with a critical option that affects it and that it does not implement MUST discard the frame as it is unsafe to process the frame without understanding the critical option. Non-critical options can be safely ignored. Any option indicating a significant change in the way later parts of the frame are interpreted or sturctured MUST be a critical option. Options also have a "mutability" flag which has a different meaning for ingress-to-egress options and for hop-by-hop options. For an ingress-to-egress option, the mutability flag indicates whether the value associated with the option can change (mutable options) or not (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 would not normally have the keys to recompute a signature or authentication code to take a changed value into account. For a non-critial hop-by-hop option, the mutability flag indicates 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 never required to remove a hop-by-hop options that it does not implement. For critial hop-by-hop options, the mutability flag is meaningless. If the RBridge does not implement the critial hop-by-hop option, it MUST drop the frame. If it does implement the critial hop-by-hop option, it will know whether or not it may/should/must remove it. For critial hop-by-hop options, the mutability flag is set to zero 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. D. Eastlake, A. Ghanwani, & C. Bestler [Page 4] INTERNET-DRAFT TRILL Header Options Although the hard limit on options length, their 32-bit alignment, and the presence of critical option summary bits as described below, are intended to assist in the efficient processing of frames with options, nevertheless the inclusion of 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 all option handling requirements in [RFCtrill]. All Rbridges MUST be able to detect 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 the critical options present, they MUST discard the frame. Transit RBridges MUST transparently forward all immutable ingress-to- egress 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 hop-by-hop options; o MAY change the value and/or length of a mutable ingress-to-egress option as permitted by that option's specification and provided there is enough room if lengthening the option; 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 in the options; 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 that they support in their IS-IS LSP and advertise the hop-by-hop options they support in the Hellos they send. An RBridge is not required to support any options. D. Eastlake, A. Ghanwani, & C. Bestler [Page 5] INTERNET-DRAFT TRILL Header Options Unless an RBridge advertises support for a critical option, it will not normally receive frames with that option except due to errors or transient conditions. 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 to which the frame will be sent 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 with multi- destination frames where it is acceptable for those frames to be discarded by the egress 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 four octets of the options area consist of two summary bits and 30 option bits as described below. The remainder of the options area, if any, consists of TLV (Type Length Value) encoded options aligned on 32-bit boundaries. Section 2.3.2 specifies the format of an individual TLV option. Section 2.3.3 describes the marshalling of TLV options. 2.3.1 Summary Bits and Bit Options | 0 1 2 3 4 5 6 7| 8 - 15|16 - 23|24 - 31| +------+------+--+--+--+--+--+--+-------+-------+-------+ | CHbH | CItE | | | | | +------+------+--+--+--+--+--+--+-------+-------+-------+ Figure 1: Options Area Initial Four Octets The top two bits of the options area, bits 0 and 1 above, are called summary bits and summarize the presence of critical options as follows: 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 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 D. Eastlake, A. Ghanwani, & C. Bestler [Page 6] INTERNET-DRAFT TRILL Header Options 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. 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 don't 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 remaining 30 bits in the initial four octets of the options area are available for bit-encoded options. Any RBridge adding an options area to a TRILL Header must set these 30 bits to zero except when permitted to set one or more as specified an option that RBridge implements. The 30 bits are categorized as follows: 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 All bit encoded options are considered mutable except the critical hop-by-hop options. Any transit RBridge MUST transparently copy bits 16 through 31, except as permitted by an option implemented by that RBridge, but MAY either copy or clear any of the bits from 8 through 15. 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 the 2 through 7 or 16 through 31 bits 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. 2.3.2 TLV Option Format 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. D. Eastlake, A. Ghanwani, & C. Bestler [Page 7] INTERNET-DRAFT TRILL Header Options | 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. 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 next to highest order bit of the first octet (NC) is zero for critical options and one for non-critical options. The highest order bit of the second octet (MT) is zero for immutable options and one for mutablable options. The IE, NC, Type, and MT fields themselves MUST NOT be changed even for a mutable option. 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. For example, if the Type indicates a Flow ID option (see Section 4.1), then it MUST 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 critial ingress-to-egress option at an egress RBridge and any critial 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-critial 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 octets. It gives the amount of option value data, if any, beyond 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 of Length can vary from zero to 120. The meaning of "Length" values of 121 through 127 is reserved and, when such values are noticed in a frame, the frame MUST be discarded. 2.3.3 Marshalling of Options In a TRILL Header with options, those options start immediately after the Ingress RBridge Nickname and completely fill the options area. D. Eastlake, A. Ghanwani, & C. Bestler [Page 8] INTERNET-DRAFT TRILL Header Options TLV options start immediately after the initial four octets of option and summary bits and MUST appear in ascending order by the value of the two high order bits of the Type octet considered as an unsigned 2-bit integer. That is, they MUST be ordered as follows: (1) critical hop-by-hop options, (2) non-critial hop-by-hop options, (3) critical ingress-to-egress options, and (4) non-critial 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. 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 next multiple of four octets. These padding octets may be any value and MAY be changed by transit RBridges. 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 four octets of the options area. 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 procesing the frame to do conflict 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 changes in way later parts of the frame are interpreted or structured MUST be discarded. 2. Critical options always override non-critical options. 2. Withing the two categories of critical and non-critical options, the option appearing first in lexical order in the frame always overrides an optiona appearing later in the frame. Thus a conflict between a bit option and a TLV option is always resolved in favor of the bit option. Bit options with lower bit numbers are considered to have occured before bit options with higher bit numbers. D. Eastlake, A. Ghanwani, & C. Bestler [Page 9] INTERNET-DRAFT TRILL Header Options 3. Specific Bit Option The table below shows the state of TRILL Header bit option assignments. See Section 6 for IANA Considerations. Bit Purpose Section ----------------------------------- 0-1 Summary 2.3 2-7 available for critical hop-by-hop options 8-9 ECN 3.1 10-15 available for non-critical hop-by-hop options 16-23 available for critical ingress-to-egress options 24-31 available for non-critical ingress-to-egress options Table 1. Flag Options 3.1 ECN Bit 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 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 does the following when that option is enabled: o When ingressing an IP frame that is ECN enabled, it MUST add an options area to the TRILL Header and copy the two ECN bits from the IP header into option bits 8 and 9. o When ingressing a frame for a non-IP protocol with 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. 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 MUST modify 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. o When egressing a non-IP protocol frame with a means of indicating ECN that is understood by the RBridge, it MAY transfer the ECN information from the ECN bits in the options area to the egressed D. Eastlake, A. Ghanwani, & C. Bestler [Page 10] INTERNET-DRAFT TRILL Header Options native frame. 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 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 Bit Combinations 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, A. Ghanwani, & 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 Flow ID 4.1 0x02-0x2F available 0x30 Additional Flags 4.2 0x31-0x3E available 0x3F reserved Table 3. TLV Option Types The following subsections specify particular TRILL TLV options. 4.1 Flow ID TLV Option In connection with multi-pathing of frames, frames that are part of the same order dependent flow need to follow the same path for correct operation. Methods to determine flows are beyond the scope of the this document; 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 and transit RBridges may wish to 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 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 sense in different regions. The value length of this option is fixed at 2 for efficiency. In a TRILL data frame with only this option, the size of the option plus the size of the initial 4 summary and flag option octets is such as to maintain 64-bit alignment of the encpasulated frame. The option fields and flags are as follows: o Type is 0x01. o Length is 2. The data is an unsigned integer that is the flow ID. o IE MUST be zero. This is a hop-by-hop option. D. Eastlake, A. Ghanwani, & C. Bestler [Page 12] INTERNET-DRAFT TRILL Header Options o NC and MT MUST be one. This is a non-critical mutable option. 4.2 Additional Flags TLV Option This option provides a means of adding a variety of additional flags to the TRILL Header beyond the bit options available in the first four octets of the options area. The value of a 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 they would be in value octets beyond those specified by the option Length, are considered zero. This option can appear once in a frame for each possible combination of ingress-to-egress, hop-by-hop, non-critical, critical, mutable and immutable flags (all combinations except for mutable critical hop-by- hop flags which is a meaningless). 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 0x30. o Length is variable with a minimum value of 1. o IE, NC, MT can be any valid combination producing several variations of this option. D. Eastlake, A. Ghanwani, & C. Bestler [Page 13] 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 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 and the specification of a particular non-critial option may impose an implementation requirement higher than "MAY" for the advertising of that option by RBridges that implement it. 5.1 Additions to Link State Rbridges indicate in their link state which ingress-to-egress TLV and bit options they support. In addition, if they support any ingress-to-egress Additional Flags TLV options, they MUST indicate which critical ingress-to-egress Additional Flags TLV option flags they support and MAY indicate which non-critial Additional Flags they support. 5.2 Additions to Port Capabilities Rbridges indicate in their Hellos which hop-by-hop TLV and bit options they support. In addition, if they support hop-by-hop Additional Flags TLV options, they MUST indicate which critical hop-by-hop Additional Flags TLV option flags they support and MAY indicate which non-critial hop-by- hop Additional Flags TLV options they support. D. Eastlake, A. Ghanwani, & C. Bestler [Page 14] INTERNET-DRAFT TRILL Header Options 6. IANA Considerations IANA will create two subregistries within the TRILL registry. A "TRILL Header Bit Options" 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 3 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]. IANA will create a third subregistry within the TRILL registry for flags in the variations of the Additional Flags TLV option that is initially empty. Such flags are allocated by TRILL Expert Review [RFC5226]. 7. Security Considerations For general TRILL protocol security considerations, see [RFCtrill]. RBridges should not trust that the options that appear in a TRILL header reflect the intent of the previous or earlier hop RBridges, including the ingress RBridge, unless the option is appropriately secured. For example, through inclusion of a TRILL authentication option, which may be specified in another document, or authentication information internal to the option itself. 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. D. Eastlake, A. Ghanwani, & C. Bestler [Page 15] INTERNET-DRAFT TRILL Header Options 8. References Normative and informative references for this document are given below. 8.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. [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. 8.2 Informative References None. D. Eastlake, A. Ghanwani, & C. Bestler [Page 16] 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 01 Liberalize requirement for TLV options to be strictly ordered by the value of their first octet to (1) require ordering by the top two bits of the first octet and (2) require that transit RBridges not re- order ingress-to-egress options. Liberalize requirements on contents TLV option padding octets that assure 32-bit alignment. Specify meaning of mutability bit for hop-by-hop options. Fix length of Flow ID Value at 2. D. Eastlake, A. Ghanwani, & C. Bestler [Page 17] INTERNET-DRAFT TRILL Header Options Authors' Addresses Donald E. Eastlake 3rd Stellar Switches 155 Beaver Street Milford, MA 01757 Phone: +1-508-333-2270 email: d3e3e3@gmail.com Anoop Ghanwani Brocade Communications Systems 1745 Technology Drive San Jose, CA 95110 USA Phone: +1-408-333-7149 Email: anoop@brocade.com Caitlin Bestler Quantum 1650 Technology Drive , Suite 700 San Jose, CA 95110 Phone: +1-408-944-4000 email: cait@asomi.com D. Eastlake, A. Ghanwani, & C. Bestler [Page 18] INTERNET-DRAFT TRILL Header Options Copyright and IPR Provisions Copyright (c) 2010 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, A. Ghanwani, & C. Bestler [Page 19]