TRILL Working Group Donald Eastlake INTERNET-DRAFT Huawei Intended status: Proposed Standard Vishwas Manral Updates: RFCtrill IP Infusion Li Yizhou Sam Aldrin Huawei Dave Ward Juniper Expires: October 19, 2011 April 20, 2011 RBridges: TRILL RBridge Channel Support Abstract This document specifies a general channel for sending OAM (Operations, Administration, and Maintenance) or other messages in an RBridge campus through extensions to the TRILL (TRansparent Interconnection of Lots of Links) protocol. 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, et al [Page 1] INTERNET-DRAFT RBridges: RBridge Channel Table of Contents 1. Introduction............................................3 1.1 RBridge Channel Requirements...........................3 1.2 Terminology............................................4 2. RBridge Channel Messages................................5 2.1 The RBridge Channel Message Inner Frame................6 2.1.1 RBridge Channel Header...............................6 2.1.2 Inner Ethernet Header................................7 2.1.3 Inner.VLAN Tag.......................................8 2.2 The TRILL Header for RBridge Channel Messages..........8 2.3 Channel Message Ethernet Link Header and Trailer.......9 2.4 Special Transmission and Rate Considerations..........10 3. Processing RBridge Channel Messages....................11 3.1 Processing the RBridge Channel Header.................11 3.2 RBridge Channel Errors................................12 4. Native RBridge Channel Frames..........................14 5. Allocation Considerations..............................15 5.1 IANA Considerations...................................15 5.1.1 TRILL GENAPP ID and APPsub-TLVs.....................15 5.1.2 Other IANA Considerations...........................16 5.2 IEEE Registration Authority Considerations............18 6. Security Considerations................................19 7. References.............................................20 7.1 Normative References..................................20 7.2 Informative References................................20 D. Eastlake, et al [Page 2] INTERNET-DRAFT RBridges: RBridge Channel 1. Introduction RBridge campuses support transparent forwarding using the TRILL protocol that builds on IS-IS routing [IS-IS] [RFC1195]. However, the TRILL base protocol standard [RFCtrill] provides only for TRILL Data messages to handle end station data and TRILL IS-IS messages. This document specifies a general channel mechanism for the transmission of other messages within an RBridge campus, such as OAM (Operations, Administration, and Maintenance) messages, between RBridges or between end stations and RBridges. This mechanism supports a requirement to be able to operate with no or minimal configuration. Familiarity with [RFCtrill] and [RFCadj] is assumed in this document. 1.1 RBridge Channel Requirements It is anticipated that various protocols operating at the TRILL level, such as OAM protocols, will be desired in RBridge campuses. For example, there is a need for rapid response continuity checking with a protocol such as BFD [RFC5880] [RFC5882] and for a variety of optional reporting, in the spirit of some ICMP [RFC792] messages, such as reporting Hop Count exhaustion, unknown egress nickname in the TRILL header, and the like, including ping and trace route functions. To avoid having to design and specify a way to carry each new OAM or similar protocol between RBridges, this document specifies a general channel for sending messages between RBridges in a campus at the TRILL level by extending the TRILL protocol. To accommodate a wide variety of protocols, this RBridge Channel facility accommodates all the regular modes of TRILL Data transmission including single and multiple hop unicast as well as VLAN scoped multi-destination distribution. To minimize unnecessary burden on transit RBridges and to provide a more realistic test of network continuity and the like, RBridge Channel messages are designed to look like TRILL Data frames and, in the case of multi-hop messages, can normally be handled by transit RBridges as if they were TRILL Data frames; however, to enable processing at transit RBridges when required by particular messages, an optional Alert TRILL extended header flag is specified. The Alert bit causes a transit RBridge to examine a frame with that flag set, usually by sending it to the slow path. This document also provides a format for sending RBridge Channel messages between end stations and RBridges, in either direction, when D. Eastlake, et al [Page 3] INTERNET-DRAFT RBridges: RBridge Channel appropriate for the protocol involved. Each particular protocol using the RBridge Channel will likely use only a subset of the facilities specified herein. The RBridge Channel is similar to the MPLS Generic Channel specified in [RFC5586]. Instead of using a special MPLS label to indicate a special channel message, an RBridge Channel message is indicated by a special multicast Inner.MacDA. 1.2 Terminology 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]. The terminology and acronyms of [RFCtrill] are used in this document with the additions listed below. BFD - Bidirectional Forwarding Detection CHV - Channel Header Version ICMP - Internet Control Message Protocol MH - Multi-Hop OAM - Operations, Administration, and Maintenance SL - Silent D. Eastlake, et al [Page 4] INTERNET-DRAFT RBridges: RBridge Channel 2. RBridge Channel Messages RBridge Channel messages are transmitted as TRILL Data frames. They are identified as RBridge Channel messages by their Inner.MacDA together with their Ethertype, which are the Egress-RBridges multicast address and the RBridge-Channel Ethertype. This Ethertype is part of an RBridge Channel Header. The payload of the encapsulated frame starts with an RBridge Channel Header that indicates the protocol being sent through the RBridge Channel. The diagram below shows the overall structure of a RBridge Channel Message frame on a link between two RBridges: Frame Structure Section of This Document ------------------------ +--------------------------------+ | Link Header | Section 2.3 if Ethernet Link +--------------------------------+ | TRILL Header | Section 2.2 +--------------------------------+ | Inner Ethernet Header | Section 2.1.2 +--------------------------------+ | RBridge Channel Header | Section 2.1.1 +--------------------------------+ | Protocol Specific Payload | See specific channel protocol +--------------------------------+ | Link Trailer (FCS if Ethernet) | +--------------------------------+ Some channel messages may require examination of the frame by transit RBridges that support the RBridge Channel feature, to determine if they need to take any action. To indicate this, a non-critical hop- by-hop extended TRILL header flag is allocated as the Alert bit [RFCext], as further described in Section 3 below. The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL Header for frames sent in the RBridge Channel. As always, the Outer link header is whatever is needed to get a TRILL Data frame to the next hop RBridge, depends on the technology used by the link, and can change with each hop for multi-hop messages. Section 2.3 describes the Outer link header for Ethernet. And Section 2.4 discusses some special considerations for the first hop transmission of RBridge Channel messages. Section 3 describes some details of RBridge Channel message processing. And Section 4 provides further specifications for optional native RBridge Channel frames between RBridges and end stations. D. Eastlake, et al [Page 5] INTERNET-DRAFT RBridges: RBridge Channel 2.1 The RBridge Channel Message Inner Frame The encapsulated inner frame within an RBridge Channel message frame is as shown below. Inner Ethernet Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Inner.MacDA = Egress-RBridges | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Inner.MacDA cont. | Inner.MacSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner.MacSA cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag Ethertype | Priority, VLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RBridge Channel Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBridge-Channel Ethertype | CHV | Channel Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | ERR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RBridge Channel Protocol Specific Information: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Channel Protocol Specific Data | ... The channel protocol specific data contains the information related to the specific protocol type used in the channel message. Details of that data are outside the scope of this document, except in the case of the RBridge Channel Error protocol specified below. 2.1.1 RBridge Channel Header As shown in the diagram above, the RBridge Channel header starts with the RBridge-Channel Ethertype (see Section 5.2). Following that is a four-byte quantity with four sub-fields as follows: CHV: Gives the RBridge Channel Header Version and MUST be zero. Channel Protocol: A 12-bit field that specifies the particular RBridge Channel protocol to which the message applies. Flags: Provides 12 bits of flags described below. ERR: A four-bit field used in connection with error reporting at the RBridge Channel level as described in Section 3. D. Eastlake, et al [Page 6] INTERNET-DRAFT RBridges: RBridge Channel The flag bits are numbered from 0 to 11 as shown below. 0 1 2 3 4 5 6 7 8 9 10 11 +--+--+--+--+--+--+--+--+--+--+--+--+ |SL|MH|NA| Available Flags | +--+--+--+--+--+--+--+--+--+--+--+--+ Bit 0, which is the high order bit in network order, is defined as the SL or Silent bit. If it is a one, it suppresses RBridge Channel Error messages (see Section 3). Bit 1 is the MH or Multi-Hop bit. It is used to inform the destination RBridge protocol that the message was intended to be multi-hop (MH=1) or one-hop (MH=0). Bit 2 is the NA or Native bit. It is used as described in Section 4 below. The RBridge Channel Protocol field specifies the protocol that the channel message relates to. The initial defined value is listed below. See Section 5 for IANA Considerations. Protocol Name - Section of this Document -------- ------------------------------- 0x001 RBridge Channel Error - Section 3 2.1.2 Inner Ethernet Header The special Inner.MacDA is the Egress-RBridges multicast MAC address to signal that the frame is intended for the egress RBridge itself (or the egress RBridges themselves if the frame is multi-destination) (see Section 5). That the frame is an RBridge Channel message is indicated by the RBridge-Channel Ethertype. In the future there may be other Ethertypes that make use of the Egress-RBridges Inner.MacDA. The RBridge originating the channel message selects the Inner.MacSA. The Inner.MacSA MUST be set by the originating RBridge to a MAC address unique within the campus. This MAC address can be considered, in effect, the MAC address of a virtual internal end station that handles the RBridge Channel frames originated by or destined for that RBridge. D. Eastlake, et al [Page 7] INTERNET-DRAFT RBridges: RBridge Channel 2.1.3 Inner.VLAN Tag As with all TRILL encapsulated frames, a VLAN tag MUST be present. Use of a VLAN tag Ethertype other than 0x8100 or stacked VLAN tags is beyond the scope of this document. Multi-destination RBridge Channel messages are, like all multi- destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID MUST be set to the VLAN of interest. To the extent that distribution tree pruning is in effect in the campus, such channel messages may only reach RBridges advertising that they have appointed forwarder connectivity to that VLAN. For channel messages sent as known unicast TRILL Data frames, if the message is one-hop it is RECOMMENDED that the Inner.VLAN ID be the Designated VLAN on that hop. For multi-hop unicast OAM messages, it is RECOMMENDED that the Inner.VLAN ID be the default VLAN 1. The Inner.VLAN will also specify a three-bit frame priority for which the following recommendations apply: 1. For one-hop channel messages critical to network connectivity, such as one-hop BFD for rapid link failure detection in support of TRILL IS-IS, the RECOMMENDED priority is 7. 2. For single and multi-hop known unicast channel messages important to network operation but not critical for connectivity, the RECOMMENDED priority is 6. 3. For other known unicast channel messages and all multi-destination channel messages, it is RECOMMENDED that the default priority zero be used. In any case, priorities higher than 5 SHOULD NOT be used for such frames. There is one additional bit in a VLAN tag value beyond the 12 bit VLAN ID and 3-bit priority. In some applications, this bit is called the Drop Eligibility Indicator (DEI). It is RECOMMENDED that this bit be zero for the first two categories of channel messages listed immediately above. The setting of this bit for channel messages in the third category may be dependent on the channel protocol and no general recommendation is made for that case. 2.2 The TRILL Header for RBridge Channel Messages After the outer Link Header (which, for Ethernet, ends with the TRILL Ethertype) and before the encapsulated frame, the channel message's TRILL Header initially appears as follows: D. Eastlake, et al [Page 8] INTERNET-DRAFT RBridges: RBridge Channel +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0| R |M| Ext-Len | Hops=0x3F | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Nickname | Ingress Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TRILL Header version V MUST be zero, the R bit are reserved, the M bit is set appropriately as the channel message is to be forwarded as known unicast (M=0) or multi-destination (M=1) regardless of the fact that the Inner.MacDA is always the Egress-RBridges multicast address, and Ext-Len is set appropriately for the length of the TRILL Header extensions area, if any, all as specified in [RFCtrill] (where it is referred to as the options area). When an RBridge Channel message is originated, the hop count field MUST be set to the maximum value, 0x3F. For messages sent a known number of hops, particularly one-hop messages or two-hop neighbor echo messages, checking the Hops (Hop Count) field provides an additional validity check as discussed in [RFC5082]. The RBridge originating a channel message places a nickname that it holds into the ingress nickname field. There are several cases for the egress nickname field. If the channel message is multi-destination, then the egress nickname designates the distribution tree to use. If the channel message is a multi-hop unicast message, then the egress nickname is a nickname of the target RBridge; this includes the special case of an "echo" OAM message where the originator places one of its own nicknames in both the ingress and egress nickname fields. If the channel message is a one- hop unicast message, there are two possibilities for the egress nickname. o The egress nickname can bet set to a nickname of the target neighbor RBridge. o The special nickname Any-RBridge may be used. RBridges supporting the RBridge Channel facility MUST recognize the Any-RBridge special nickname and accept TRILL Data frames having that value in the egress nickname field as being sent to them as the egress. Thus, for such RBridges, using this egress nickname guarantees processing by an immediate neighbor regardless of the state of nicknames. 2.3 Channel Message Ethernet Link Header and Trailer An RBridge Channel frame has the usual link header and trailer depending on the type of link on which it is sent. D. Eastlake, et al [Page 9] INTERNET-DRAFT RBridges: RBridge Channel For an Ethernet link [RFCtrill] the Outer.MacSA is the MAC address of the port from which the frame is sent. The Outer.MacDA is the MAC address of the next-hop RBridge port for unicast RBridge Channel messages or the All-RBridges multicast address for multi-destination RBridge Channel messages. The Outer.VLAN tag specifies the Designated VLAN for that hop and the priority should be the same as in the Inner.VLAN tag; however, the output port may have been configured to strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. And the link trailer is the Ethernet FCS. 2.4 Special Transmission and Rate Considerations If a multi-hop RBridge Channel message is received by an RBridge, the criteria and method of forwarding it are the same as for any TRILL Data frame. If it is so forwarded, it will be on a link that was included in the routing topology because it was in Report state as specified in [RFCadj]. However, special considerations apply to the first hop because, for some RBridge Channel protocols, it may be desirable to sent RBridge Channel messages on links that are not yet fully up. In particular, it is permissible, if specified by the particular channel protocol, for the source RBridge that has created an RBridge Channel message to transmit it to a next hop RBridge when the link is in the Detect or Two-Way states, as specified in [RFCadj], as well as when it is in the Report state. RBridge Channel messages represent a burden on the RBridges and links in a campus and should be rate limited, especially if they are sent as high priority, multi-destination, or multi-hop frames or have the Alert extended flag set. D. Eastlake, et al [Page 10] INTERNET-DRAFT RBridges: RBridge Channel 3. Processing RBridge Channel Messages RBridge Channel messages are designed to look like and, to the extent practical, be forwarded as regular TRILL Data frames. On receiving a channel message, the initial tests on the Outer.MacDA, Outer Ethertype, TRILL Header V and Hop Count fields and the Reverse Path Forwarding Check if the frame is multi-destination, are all performed as usual. The forwarding and/or decapsulation decisions are the same as for a regular TRILL Data frame with following exceptions for RBridges implementing the RBridge Channel facility: 1. An RBridge implementing the RBridge Channel MUST recognize the Any-RBridge egress nickname in TRILL Data frames, decapsulating such frames if they meet other checks and not forwarding them in encapsulated form unless they are an appropriate multi- destination frame. 2. If the Alert extended flag is set, then the RBridge MUST process the RBridge Channel message as described below even if it is not egressing the frame. If it is egressing the frame, then no additional processing beyond egress processing is needed even if the Alert flag is set. 3. On decapsulation, the special Inner.MacDA value of Egress- RBridges MUST be recognized to trigger checking the Inner.Ethertype and processing as an RBridge Channel message if that Ethertype is RBridge-Channel. RBridge Channel messages SHOULD only be sent to RBridges that advertise support for that facility as specified in Section 5. If an RBridge that does not recognize the Egress-RBridges Inner.MacDA multicast address received an RBridge Channel message, it might decapsulate the inner frame and sent it out all ports for which that RBridge is an appointed forwarder for the Inner.VLAN. All RBridges that recognize the Egress-RBridges multicast address MUST recognize the RBridge-Channel Ethertype. If the future, there may be other Inner.Ethertypes defined that use the Egress-RBridges Inner.MacDA. If the Ethertype is not recognized, this error condition is handled as described below. 3.1 Processing the RBridge Channel Header Knowing that it has an RBridge Channel message, the egress RBridge, and any transit RBridge if the Alert bit is set in the TRILL Header, looks at the CHV (RBridge Channel Header Version) and Channel Protocol fields. D. Eastlake, et al [Page 11] INTERNET-DRAFT RBridges: RBridge Channel If any of the following conditions occur at an egress RBridge, the frame is not processed and an error may be generated as specified in Section 3.2; however, if these conditions are detected at a transit RBridge examining the message because the Alert flag is set, no error is generated and the frame is still forwarded normally. 1. The Ethertype is not RBridge-Channel or not any other (future) Ethertype known to the RBridge as usable with the Egress- RBridges Inner.MacDA, or the frame is so short that the Ethertype is truncated. 2. The CHV field is non-zero or the frame is so short that the version zero Channel Header is truncated. 3. The Channel Protocol field is a reserved value or a value unknown to the processing RBridge. 4. The ERR field is non-zero and Channel Protocol is a value other than 0x001. 5. The RBridge Channel Header NA flag is set to one indicating that the frame should have been received as a native frame rather than an encapsulated frame. If the CHV field and NA flag are zero and the processing RBridge recognizes the Channel Protocol value, it processes the message in accordance with that channel protocol. The processing model is as if the received frame starting with and including the TRILL Header is delivered to the Channel protocol along with a flag indicating whether this is (a) transit RBridge processing due to the Alert flag being set or (b) egress processing. Errors within a recognized Channel Protocol are handled by that channel protocol itself and do not produce OAM Message Channel Error frames. 3.2 RBridge Channel Errors A variety of problems at the RBridge Channel level cause the return of an RBridge Channel Error frame unless (a) the "SL" (Silent) flag is a one in the channel message for which the problem was detected, (b) the processing is due to the Alert bit being set, (c) the frame in error appears, itself, to be an RBridge Channel error frame (has a non-zero ERR field or an Channel Protocol of 0x001), or (d) the error is suppressed due to rate limiting. An RBridge Channel Error frame is a multi-hop unicast RBridge Channel message with the ingress nickname set to the nickname of the RBridge D. Eastlake, et al [Page 12] INTERNET-DRAFT RBridges: RBridge Channel detecting the error, and the egress nickname set to the value of the ingress nickname in the channel message for which the error was detected. The SL and MH flags SHOULD be set to one, the NA flag to zero, and the ERR field MUST be non-zero as described below. For the protocol specific data area, an RBridge Channel Message Error frame has at least the first 256 bytes (or less if less are available) of the erroneous decapsulated channel message starting with the TRILL Header. (Note: The TRILL Header does not include the TRILL Ethertype which is part of the Link Header on Ethernet Links and may be absent for other link technologies.) The following values for ERR are specified: ERR Meaning --- ------- 0 - Not an RBridge Channel error frame. 1 Frame too short (truncated Ethertype or RBridge Channel Header) 2 Unrecognized Ethertype 3 Unimplemented value of CHV 4 Wrong value of NA flag 5 Channel Protocol is reserved or unimplemented 6-14 - Available for allocation, see Section 5. 15 Reserved All RBridges implementing the RBridge Channel feature MUST recognize the RBridge Channel Error protocol value (0x001). They MUST NOT generate an RBridge Channel Error message in response to a RBridge Channel Error message, that is, a channel message with a protocol value of 0x001 or with a non-zero ERR field. D. Eastlake, et al [Page 13] INTERNET-DRAFT RBridges: RBridge Channel 4. Native RBridge Channel Frames If provided for by the channel protocol involved, native RBridge channel messages may be sent between end-stations and RBridges in either direction. Such native frames have the RBridge-Channel Ethertype and are like the encapsulated frame inside an RBridge Channel message with the following exceptions: 1. TRILL does not require the presence of VLAN tagging on such native RBridge channel frames. However, port configuration, link characteristics, or the channel protocol involved may require such tagging. 2. If the frame is unicast, the destination MAC address is the unicast MAC address of the RBridge or end-station port that is its intended destination. If the frame is multicast to all the RBridges on a link that support an RBridge Channel protocol that uses this transport, the destination MAC address is the Egress-RBridges multicast address. If the frame is multicast to all the devices that TRILL considers to be end stations on a link that support an RBridge Channel protocol that uses this transport, the destination MAC address is the TRILL-End- Stations multicast address (see Section 5). The RBridge-Channel Ethertype must be present. In the future there may be other protocols using the Egress-RBridges and/or TRILL-End-Stations multicast addresses distinguished by a different Ethertype. 3. The NA bit in the RBridge Channel Header flags must be a one. 4. As with any native frame, the source MAC address is that of the port sending the frame. A native frame with the RBridge-Channel Ethertype must meet the usual VLAN and destination MAC address restrictions to be accepted by an RBridge. If provided for by the channel protocol involved, the receipt of such a native frame MAY lead to the generation and transmission of one or more native or TRILL encapsulated RBridge Channel frames. The decapsulation and processing of an encapsulated RBridge Channel frame MAY, if provided for by the channel protocol involved, result in the sending of one or more native RBridge channel frames to one or more end stations. D. Eastlake, et al [Page 14] INTERNET-DRAFT RBridges: RBridge Channel 5. Allocation Considerations The following subsections give IANA and IEEE allocation considerations. In this document, the allocation procedures "Standards Action", "IETF Review", "RFC Publication", and "Private Use" are as specified in [RFC5226]. 5.1 IANA Considerations The following subsections give IANA allocation considerations. 5.1.1 TRILL GENAPP ID and APPsub-TLVs IANA is requested to allocate an IS-IS Application Identifier under the Generic Information TLV (#251) for TRILL [RFCgenapp] and to create a subregistry in the TRILL Parameters Registry for "TRILL APPsub-TLVs under IS-IS TLV #251 Application Identifier #TBD". The initial contents of this subregistry are as follows: Type Name MI0? Reference ------ -------- ------ ----------- 0 Reserved - 1 Data Capabilities Y 2-254 Available - 255 Reserved - The V, I, D, and S flags in the initial flags byte of a TRILL Generic Information TLV [RFCgenapp] are not used as TRILL operates as a Level 1 IS-IS area and no meaning is hereby assigned to the inclusion of an IPv4 and/or IPv6 address via the I and V flags. Thus these flags will be zero; however, use of multi-level IS-IS is an obvious extension of TRILL and a future IETF Standards Action may update this specification to provide for the use of any or all of these flags. TRILL APPsub-TLVs MUST NOT alter basic IS-IS protocol operation including the establishment of adjacencies, the update process, and the decision process [IS-IS] [RFC1195]. TRILL APPsub-TLV Types 2 through 254 are available for allocation by Standard Action as modified by [RFC4020]. The standards track RFC making such allocation shall specify whether a TRILL Generic Information TLV containing an instance of that TRILL APPsub-TLV is permitted to occur in instance zero LSPs and a column in the TRILL APPsub-TLV registry will indicate this. The RFC will also include a discussion of security issues and of the rate of change of the information being advertised. D. Eastlake, et al [Page 15] INTERNET-DRAFT RBridges: RBridge Channel The Data Capabilities TRILL APPsub-TLV has as its value a bit vector where a one bit indicates support of a particular TRILL Data frame format, encapsulation, or sub-type. The bits in the value of this APPsub-TLV are numbered in network order, the high order bit of the first byte being 0, the low order bit of that byte being 7, the high order bit of the second byte being 8, etc. The maximum value length permitted is 64 so the highest available bit is number 511. A longer value is processed but bytes beyond the 64th are ignored. By implication, the value of all bits higher numbered than those present is zero. The absence of this APPsub-TLV implies that all bits are zero and the relevant RBridge supports no TRILL data capabilities other than those in the TRILL base protocol standard [RFCtrill]. To avoid wasted space, a Data Capabilities TRILL APPsub-TLV SHOULD have the smallest length that will accommodate all the one bits in its value. This Data Capabilities information is expected to be very compact and slow changing. It would typically change only on manual re- configuration, software/firmware update, or the like. The Data Capabilities TRILL APPsub-TLV may occur in instance zero LSPs. The security implications of each defined bit in the value of a Data Capabilities TRILL APPsub-TLV will be discussed in the RFC specifying that bit. IANA is requested to create a "Data Capabilities APPsub-TLV Bits" subregistry in the TRILL Parameters Registry. The initial table of bits is as follows: Bit Name Reference ----- ------ ----------- 0 RBridge Channel 1-511 Available Bits will be allocated in ascending numeric order without gaps based on IETF Review for single bits and Standards Action as modified by [RFC4020] for more than one bit. 5.1.2 Other IANA Considerations IANA is requested to allocate a previously unassigned TRILL Nickname as follows: Any-RBridge TBD (0xFFCO suggested) IANA is requested to allocate two previously unassigned TRILL Multicast address as follows: Egress-RBridges TBD (01-80-C2-00-00-43 suggested) D. Eastlake, et al [Page 16] INTERNET-DRAFT RBridges: RBridge Channel TRILL-End-Stations TBD (01-80-C2-00-00-44 suggested) IANA is request to allocate a previously unassigned TRILL non- critical hop-by-hop extended flag bit [RFCext] as follows: TBD Alert IANA is requested to create an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Protocols, with initial contents as follows: Protocol Use -------- --- 0x000 Reserved 0x001 RBridge Channel Error 0x002-0x0FF Available for allocation (1) 0x100-0xFF7 Available for allocation (2) 0xFF8-0xFFE Private Use 0xFFF Reserved (1) RBridge Channel protocol code points from 0x002 to 0x0FF require a Standards Action as modified by [RFC4020] for allocation. (2) RBridge Channel protocol code points from 0x100 to 0xFF7 require RFC Publication to allocate a single value or IETF Review to allocate multiple values. IANA is requested to create an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Header Flags with initial contents as follows: Flag Bit Mnemonic Allocation -------- -------- ---------- 0 SL Silent 1 MH Multi-hop 2 NA Native 3-11 - Available for allocation Allocation of an RBridge Channel Header Flag is based on Standards Action as modified by [RFC4020]. IANA is requested to create an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Error codes with initial contents as listed in Section 4.2 above and with available values allocated by Standards Action as modified by [RFC4020]. D. Eastlake, et al [Page 17] INTERNET-DRAFT RBridges: RBridge Channel 5.2 IEEE Registration Authority Considerations The IEEE Registration Authority has been assigned the Ethertype TBD for RBridge-Channel. D. Eastlake, et al [Page 18] INTERNET-DRAFT RBridges: RBridge Channel 6. Security Considerations See [RFCtrill] for general RBridge Security Considerations. No general integrity, authentication, or encryption mechanisms are provided herein for RBridge Channel messages. If these services are required for a particular RBridge Channel protocol, they must be supplied by that channel protocol. (See, for example, the BFD Authentication mechanism [RFC5880].) An incorrect value of the RBridge Channel bit in the TRILL APPsub-TLV can have the following effects: (1) If improperly set to zero, it could deny RBridge Channel services, for example OAM services, for the RBridge in question. (2) If improperly set to one, it could encourage RBridge Channel messages to be sent to an RBridge that does not support this feature. The inner frame of such messages would be decapsulated and that inner frame would likely be sent out all ports that are appointed forwarders for the frame's Inner.VLAN. However, this is unlikely to cause harm. There are two possibilities: (2a) If the end stations does not recognize the RBridge-Channel Ethertype of that inner frame it will drop the frame. (2b) If the end station does recognize the RBridge-Channel Ethertype, it should refuse to process the frame due to an incorrect value of the RBridge Channel Header NA flag. D. Eastlake, et al [Page 19] INTERNET-DRAFT RBridges: RBridge Channel 7. References The following sections list normative and informative references for this document. 7.1 Normative References [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002. [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFCtrill] - R. Perlman, 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. [RFCgenapp] - L. Ginsberg, S. Previdi, M. Shand, "Advertising Generic Information in IS-IS", draft-ietf-isis-genapp-04.txt, in RFC Editor's queue. [RFCadj] - D. Eastlake, R. Perlman, A. Ghanwani, D. Dutt, V. Manral, "RBridges: Adjacency", draft-ietf-trill-adj, work in progress. [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, C. Bestler, "RBridges: TRILL Header Extensions", draft-ietf-trill-rbridge- options, work in progress. 7.2 Informative References [RFC792] - Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. D. Eastlake, et al [Page 20] INTERNET-DRAFT RBridges: RBridge Channel [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007 [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection (BFD)", June 2010. [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", June 2010. D. Eastlake, et al [Page 21] INTERNET-DRAFT RBridges: RBridge Channel Authors' Addresses Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Tel: +1-508-333-2270 EMail: d3e3e3@gmail.com Vishwas Manral IP Infusion 1188 E. Arques Ave. Sunnyvale, CA 94089 USA Tel: +1-408-400-1900 EMail: vishwas@ipinfusion.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012, China Phone: +86-25-56622310 Email: liyizhou@huawei.com Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-5000 Email: sam.aldrin@huawei.com Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA Phone: +1-408-745-2000 EMail: dward@juniper.net D. Eastlake, et al [Page 22] INTERNET-DRAFT RBridges: RBridge Channel Copyright, Disclaimer, and Additional 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 Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake, et al [Page 23]