One document matched: draft-ietf-trill-rbridge-oam-02.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY ECHO_VALUE "0x004 (Suggested)">
<!ENTITY ERROR_VALUE "0x005 (Suggested)">
<!ENTITY CONSUMED_PORT_ID_VALUE "0xFFFF">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="10" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc rfcedstyle="yes" ?>
<rfc category="std" docName="draft-ietf-trill-rbridge-oam-02" ipr="trust200902">
<front>
<title abbrev="RBridges: OAM Support">
Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support
</title>
<author fullname="David Michael Bond" initials="D.M.B." surname="Bond">
<organization abbrev="IBM">International Business Machines</organization>
<address>
<postal>
<street>2051 Mission College Blvd.</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>
<phone>+1-603-339-7575</phone>
<email>mokon@mokon.net</email>
<uri>http://mokon.net</uri>
</address>
</author>
<author fullname="Vishwas Manral" initials="V.M." surname="Manral">
<organization abbrev="HP Networking">Hewlett-Packard Co.</organization>
<address>
<postal>
<street>19111 Pruneridge Ave.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<phone>+1-408-447-0000</phone>
<email>vishwas.manral@hp.com</email>
</address>
</author>
<date year="2012"/>
<area>Internet</area>
<workgroup>TRILL Working Group</workgroup>
<keyword>TRILL</keyword>
<keyword>RBridges</keyword>
<keyword>OAM</keyword>
<keyword>Traceroute</keyword>
<keyword>Ping</keyword>
<keyword>Bridging</keyword>
<keyword>Routing</keyword>
<keyword>Operations</keyword>
<keyword>Administration</keyword>
<keyword>Maintenance</keyword>
<abstract>
<t>Routing Bridges (RBridges) implement the TRansparent Interconnection of Lots of Links (TRILL) protocol which provide a transparent least-cost frame routing in multi-hop networks with arbitrary topologies, while also inherently providing loop mitigation. As RBridges are deployed in real-world situations, operators will need tools for debugging problems that arise. This document specifies a set of RBridge features for operations, administration, and maintenance (OAM) purposes in RBridge campuses. The features specified in this document include tools for traceroute, ping, and error reporting.
</t>
</abstract>
</front>
<middle>
<!-- ################################################################### -->
<section title="Introduction">
<t>
The IETF has standardized RBridges, devices that implement the TRILL protocol, a solution for transparent least-cost frame routing in multi-hop networks with arbitrary topologies, using a link-state routing protocol technology and encapsulation with a hop-count <xref target="RFC6325"/>. As RBridges are deployed, operators will require tools for troubleshooting of operations issues in the network. TRILL uses IS-IS for the control plane <xref target="IS-IS"/> <xref target="RFC6165"/> <xref target="RFC6326"/>. IS-IS has a link-state database which contains the information of all links in the TRILL domain and IS-IS has a routing table. This information can be used for trouble shooting purposes.
</t>
<t>
There are a number of mechanisms to verify the control plane/data plane information, however correctness of the control plane information does not guarantee the data plane is working correctly. This motivates the need for OAM tools that allow an operator to test the data plane. Protocols such as IP, MPLS, and IEEE 802.1 have features enabling an operator to exercise the data plane <xref target="RFC4443"/> <xref target="RFC0792"/> <xref target="IEEE.802-1ag"/>. There is a need for a similar set of tools in TRILL. Likewise, there is a need for error reporting capabilities inside an RBridge campus.</t>
<t>
Sometimes there may be a need for faster convergence than is provided by the TRILL hello protocol. Such fault notification functionality is not specified in this document. <xref target="BFD"/> provides this functionality using BFD.
</t>
<t>
This document specifies a set of RBridge features for operations, administration, and maintenance purposes in RBridge campuses along with the procedures and frame formats for these features. The features specified in this document include tools for traceroute, ping, and error reporting. <xref target="trill_oam_message"/> of this document specifies the general usage of a defined message format. <xref target="tools"/> specifies some additional applications of the message format. <xref target="rbridge_channel_message_format"/> specifies the format and value of the messages on the wire.
</t>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<!-- ################################################################### -->
<section anchor="acronyms" title="Acronyms">
<t>
<list style="symbols">
<t>BPDU - Bridge PDU</t>
<t>CHbH - Critical Hop-by-Hop</t>
<t>CItE - Critical Ingress-to-Egress</t>
<t>DA - Destination Address</t>
<t>DR - Designated Router</t>
<t>DRB - Designated RBridge</t>
<t>ES - End Station</t>
<t>ESa - End Station A</t>
<t>ESb - End Station B</t>
<t>ECMP - Equal-Cost Multi-Path</t>
<t>ESADI - End Station Address Distribution Instance</t>
<t>FCS - Frame Check Sequence</t>
<t>ID - Identification</t>
<t>IEEE - Institute of Electrical and Electronics Engineers</t>
<t>IETF - Internet Engineering Task Force</t>
<t>IP - Internet Protocol</t>
<t>IS-IS - Intermediate System to Intermediate System</t>
<t>MAC - Media Access Control</t>
<t>MPLS - Multiprotocol Label Switching</t>
<t>MTU - Maximum Transmission Unit</t>
<t>OAM - Operations, Administration, and Maintenance</t>
<t>P2P - Point-to-point</t>
<t>PDU - Protocol Data Unit</t>
<t>RBridge - Routing Bridge</t>
<t>SA - Source Address</t>
<t>SNMP - Simple Network Management Protocol</t>
<t>TCP - Transmission Control Protocol</t>
<t>TLV - Type, Length, Value</t>
<t>TRILL - TRansparent Interconnection of Lots of Links</t>
<t>UDP - User Datagram Protocol</t>
<t>VLAN - Virtual Local Area Network</t>
</list>
</t>
</section>
<!-- ################################################################### -->
<section anchor="trill_oam_message" title="TRILL OAM Message">
<t>
To facilitate message passing as needed by the OAM requirements, the TRILL RBridge Channel facility <xref target="RBridgeChannel"/> is utilized.
</t>
<t>
There are two types of TRILL OAM messages defined in this document carried within an RBridge Channel: application and error notification. Frames with an error notification MUST NOT be generated in response to frames that are an error notification. Implementations SHOULD rate limit the origination of error notifications. Whereas unknown unicast frames are sent as multi-destination messages, sending unknown unicast frames with an error can lead to an amplification attack. As such special care and rate limiting are necessary for error notifications.
</t>
<t>
Error notification messages contain the error-causing frame or the initial part thereof after its OAM message. The following are two figures showing application and error notification message structure. <xref target="rbridge_channel_message_format"/> goes into the details of these formats.
</t>
<figure align="center" anchor="application_frame">
<artwork align="center">
<![CDATA[
+----------------------------+
| Outer Link Header |
+----------------------------+
| TRILL Header |
+----------------------------+
| Inner Ethernet Header |
+----------------------------+
| RBridge Channel Header |
+----------------------------+
| OAM Protocol Spec. Payload |
+----------------------------+
]]>
</artwork>
<postamble>
Application Frame
</postamble>
</figure>
<figure align="center" anchor="errror_frame">
<artwork align="center">
<![CDATA[
+---------------------------------------+
| Outer Link Header |
+---------------------------------------+
| TRILL Header |
+---------------------------------------+
| Inner Ethernet Header |
+---------------------------------------+
| RBridge Channel Header |
+---------------------------------------+
| OAM Protocol Specific Payload |
+---------------------------------------+
| Offending Frame TRILL Header |
+---------------------------------------+
| Offending Frame Inner Link Header |
+---------------------------------------+
| Truncated Offending Frame Payload |
+---------------------------------------+
]]>
</artwork>
<postamble>
Error Notification Frame
</postamble>
</figure>
<t>
RBridge campuses do not, in general, guarantee lossless transport of frames so a frame containing a TRILL OAM Message, possibly generated in response to some other frame, might be lost.
</t>
</section>
<!-- ################################################################### -->
<section anchor="tools" title="RBridge Tools">
<t>
This section specifies a number of RBridge OAM tools. For classification purposes they are divided into two sections, applications and error tools. Both of these tools use messages called echo requests and echo replies. The format is described in <xref target="rbridge_channel_message_format"/>. An echo request is a message that says please respond. The echo reply is that response. The exact usage is further defined in this section. These messages also contain TLV fields which carry additional information in regards to the message. The formats of these TLVs are described in <xref target="tlvs"/>.
</t>
<section anchor="app" title="Application RBridge Tools">
<!-- ================================================================= -->
<section anchor="ping" title="RBridge Ping">
<t>
Ping is a tool for verifying RBridge connectivity. The ping-originating RBridge transmits one or more TRILL data frames with a TRILL OAM message. This message contains the code of an echo request (See <xref target="echo_request"/>). The ingress RBridge MUST be the frame-originating RBridge. The egress RBridge is the destination RBridge to which connectivity will be checked. The M bit MUST be zero.
</t>
<t>
The purpose of the ping is to confirm connectivity of the data plane, and options defined in future drafts MAY be included. The purpose of allowing the addition of options is so that the frame mimics a data frame that follows the same path through the data plane that a 'real' data frame would. An RBridge Ping, however, uses the OAM Channel and so depending on the ECMP hashing used by RBridges in the campus it may not in fact share the same path as 'real' data going through the network. The traceroute tool has a way to ensure the data follows the same path as the data does and if an operator wishes to test that path the data takes, the traceroute functionality ought to be used.
</t>
<t>The echo request MAY have an arbitrary 28-bit unsigned integer sequence number to assist in matching reply messages to the request. In most circumstances, a single echo request is needed to complete the ping but it might be desirable for a single RBridge to ping multiple egress RBridges, or trace differing flows simultaneously. Assigning differing sequence numbers to each frame aids in matching which trace the reply belongs to.</t>
<t>
The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the values specified in <xref target="self_frame_field_values" />.
</t>
<t>
RBridges implementing ping SHOULD issue a reply in response to this request. See <xref target="security"/> for reasons that RBridges are allowed to choose not to respond to a request. If an RBridge chooses to respond to the request, the reply MUST consist of one TRILL data frame per request with an OAM message containing the protocol code of an echo reply. The echo reply MUST have the same sequence number as the request being matched.
</t>
<t>
For the echo reply the ingress RBridge field MUST be the reply-originating RBridge's nickname. The egress RBridge MUST be the request-originating RBridge's nickname. The Inner.VLAN, Inner.MacSA, and Inner.MacDA SHOULD default to the values specified in <xref target="reponse_frame_field_values" />. The M bit MUST be zero for a known unicast ping.
</t>
<t>The reply-originating RBridge SHOULD include its 16-bit port ID from the port on which the request was received in the incoming port field of the reply. It SHOULD also include its 16-bit port ID from the port on which the frame would be forwarded. A port ID of &CONSUMED_PORT_ID_VALUE; indicates the frame would not have been forwarded and that the frame was consumed by the RBridge itself. </t>
<t>
The reply frame need not follow the same path though the campus as the request. The reply messages are not meant to test the data plane.
</t>
<t>End stations are not involved in this the ping process. RBridge pings are from RBridge to RBridge. While the frames sent may emulate data sent from ESa to ESb, the end stations are not, in fact, involved.</t>
<t>The transmitting RBridge MUST wait for a reply frame until a time-out occurs. At that time, the RBridge SHOULD assume the frame was lost, and this SHOULD be indicated to the operator. The length of this time-out is beyond the scope of this document.</t>
</section>
<!-- ================================================================= -->
<section anchor="hop_count_traceroute" title="Hop Count Traceroute">
<t>
The ability to trace the path the data takes through the network is an invaluable debugging tool. RBridge traceroute provides this functionality through use of the TRILL OAM message (See <xref target="trill_oam_message"/>). In a hop-count traceroute, the originating RBridge starts by transmitting one TRILL data frame with a TRILL OAM message. This message contains a protocol code of an echo request (See <xref target="echo_request"/>). The ingress RBridge MUST be the RBridge originating the frame.
</t>
<t>
When a traceroute is initiated, it is either targeting a known unicast target or a multi-destination target as specified by the operator. If the hop-count traceroute is for a known unicast target, the egress RBridge is the destination RBridge to which connectivity will be checked and the M bit MUST be zero. Otherwise, if the hop-count traceroute is for a multi-destination target, the egress RBridge is the distribution tree nickname for the traceroute. Multi-destination targets are handled the same as known unicast targets but require a small amount of additional logic as specified in <xref target="hop_count_traceroute_multi_dest_targets"/>.
</t>
<t>The first echo request frame transmitted MUST have a hop-count of zero. The RBridge will continue transmitting these echo requests, incrementing the hop-count by one each time until a hop-count error notification from the destination nickname as its ingress nickname is received. If a transit RBridge decrements the hop-count by more than one it MAY transmit multiple hop-count error notifications.</t>
<t>
The purpose of the traceroute is to confirm connectivity of the data plane, and therefore options defined in future drafts MAY be included. The purpose of allowing the addition of options is so that the frame mimics a data frame that follows the same path through the data plane that a 'real' data frame would. The ability to share the same path as 'real' data is further specified in <xref target="hop_count_traceroute_path_sharing"/>.
</t>
<t>
The echo request MAY have an arbitrary 28-bit unsigned integer sequence number to assist in matching reply messages to the request. This is important for the hop-count traceroute since replies may return to the ingress RBridge in a different order then their matching requests were sent.
</t>
<t>
The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress Nickname SHOULD default to the values specified in <xref target="self_frame_field_values" />.
</t>
<t>
The replying RBridge SHOULD include its 16-bit port ID from the port on which the hop-count error generating frame was received in the Incoming Port ID TLV of the reply. It SHOULD also include its 16-bit port ID from the port on which the frame would be forwarded if the frame did not have a hop-count error in the Outgoing Port ID TLV. A port ID of &CONSUMED_PORT_ID_VALUE; indicates the frame would not have been forwarded and would be consumed by the RBridge itself. Finally the reply SHOULD include a 16-bit nickname and 48-bit system id of the next hop RBridge the frame would have been sent to if there were no error in the Next Hop Nickname TLV. If this RBridge is the egress RBridge this TLV MUST NOT be included in the response. This is to facilitate knowledge of a more precise path through the campus as seen in <xref target="RFC5837">RFC 5837</xref>.
</t>
<t>
The advantage of this traceroute method is that the transit RBridges do not have to do any special processing of the frames until a hop-count error is detected, a condition they are required to detect by the TRILL base protocol. The disadvantage is the request-orginating RBridge needs to transmit as many frames as there are hops between itself and the destination RBridge.
</t>
<t>
The end stations are not involved in this process. RBridge traceroutes are from RBridge to RBridge. While the frames sent may emulate data sent from ESa to ESb, the end stations are not, in fact, involved. An Rbridge must keep the TRILL header contents the same for ever frame sent in a hop count traceroute.
</t>
<section anchor="hop_count_traceroute_path_sharing" title="Path Sharing">
<t>In certain cases it could be important to send 'real' data over a network as to test the path that 'real' data takes and to test the fate that such real data would have. Simple sending an RBridge channel message is insufficient because many RBridge implementations will use various forms of ECMP hashing based on fields such as MAC addresses, IP addresses, and/or TCP/UDP port numbers. To satisfy this need for path sharing an RBridge originating a traceroute MAY send a data packet instead of an echo request. The data packet will look entirely like an encapsulated data frame, with whatever fields the user specifies to ensure path sharing. The one exception is that the hop count will be set as described previously: incremented as the traceroute proceeds. Since these frames will not include a sequence number, these data frames must be sent in lock step: waiting for a timeout or an hop count error before sending the next incremented hop count frame. Since this data frame looks like a real frame but is in fact not real, when the egress RBridge is reached in the traceroute the originating RBridge MUST NOT send trace frames with higher hop-counts. RBridge ping does not have an equivalent path sharing mechanism since it tests end to end connectivity rather than the exact path taken.</t>
</section>
<section anchor="hop_count_traceroute_multi_dest_targets" title="Multi-Destination Targets">
<t>For multi-destination targets at each branch in the tree the tagged frame will be replicated causing each RBridge in the tree, possibly pruned by VLAN and/or IP multicast group, to send a response to the echo request. If all RBridges in the possibly pruned distribution tree support the echo request message, then the ingressing RBridge will receive an error notification from each of them. These error replies are staggered by distance from the generating RBridge. Meaning the first set of responses come from the first request send with hop count equal to zero and these repies will be from this RBridges neighbors. The second set of responses will come from RBridge two hops away and so forth.</t>
<t>The ingressing RBridge can compile all of these notifications, using the parent pointers located in the previous hop information TLV, into an output of the tree the traffic traversed. A traceroute application SHOULD report any errors received, such as an invalid distribution tree nickname, caused by the hop-count traceroute frames. RBridges receiving a multicast destination echo request MUST NOT transmit an echo reply if the multi-destination bit is set. Echo requests that are not used with the hop-count traceroute come from the ping tool, and ping messages are not valid as multi-destination traffic. In a hop count traceroute, devices will already be transmitting a hop-count error notification and so there is no reason to transmit a double set of replies. A multi-destination hop-count traceroute stops when the transmitted hop count reaches the maximum, 0x3F. One cannot use the diemater of the network to limit when this traceroute stops because some RBridges may decrement the hop count by more than one.</t>
<t>In multi-destination request frames, the Previous Information TLV MUST be set to the nickname and system id of the RBridge the frame was received from. This is the previous hop RBridge. The Next Hop Information TLV is not used in multi-destination traceroute frames.</t>
</section>
</section>
<!-- ================================================================= -->
</section>
<section anchor="error_reporting" title="Error Reporting">
<t>
Errors can occur in received TRILL data frames. For this purpose, the error notification format is specified. These are generated due to various events as specified subsequently. When a TRILL data frame is received with an error, an error notification frame SHOULD be generated. See <xref target="security"/> for reasons some RBridges are allowed to choose not to respond to a request. The generated reply MUST contain the error notification. The sub-code MUST contain a code specifying the error encountered. The valid sub-code values are specified in <xref target="error_specifiers"/>. Two of these sub-codes provide for TLVs with additional information. The error notification also contains a 3 bit error type field which describes the error.
</t>
<t>
This frame has a TRILL header and it contains, as its payload, the frame received with the error. If the size of the received frame would cause the generated frame to exceed 1470 bytes, the frame MUST be truncated to the 1470 bytes. The payload MUST include the TRILL header of the received frame and MUST NOT include the link-layer header. The generated reply MUST contain the error notification message specific to the error.
</t>
<t>When the original ingress RBridge receives the error frame, at a minimum, the RBridge SHOULD update a counter specifying the number of error frames received for the causing error. The encapsulated frame MUST NOT be egressed.</t>
<t>The two sub-codes that provide for TLVs with additional information are described below. All other sub-codes specified in this document do not normally contain TLVs.</t>
<section anchor="hop_count_zero_error_spec" title="Hop Count Zero Error">
<t>When a TRILL data frame is received with a hop-count of zero, an error notification frame SHOULD be generated unless rate limiting or some particular difficulty, as described below, stops the sending of such an error notification. The generated reply MUST contain the hop-count zero error sub-code. If the received frame has the echo request message, the hop-count zero error notification MUST have a sequence number matching the echo request. Otherwise, the sequence number MUST be set to zero. The Incoming Port ID TLV SHOULD be included with the port ID the received frame arrived on. The Outgoing Port ID TLV SHOULD be included with the port ID of the port the received frame would have been forwarded onto if the hop-count was not zero. Finally, the error notification SHOULD include a 16-bit nickname and 48-bit system id of the next hop RBridge the frame would have been sent to in the Next Hop Information TLV. If the request is a multi-destination frame, the previous hop information SHOULD be included instead with it set to the nickname and system id of the RBridge the frame was received from. This is the previous hop RBridge. If the RBridge transmitting the reply is the egress RBridge, this TLV MUST NOT be included in the frame.</t>
</section>
<section anchor="mtu_error_spec" title="MTU Error">
<t>When a TRILL data frame is received with a payload that would exceed the MTU of the port the frame would otherwise be forwarded to, an error notification frame MAY be generated. The generated reply MUST contain the MTU error sub-code. The Outgoing Port MTU TLV MUST be included with the MTU of the port the frame would have otherwise been transmitted on. The Incoming Port ID TLV SHOULD be included with the port ID the received frame arrived on. The Outgoing Port ID TLV SHOULD be included with the port ID of the port the received frame would have been forwarded onto if the frame size was not too large. Finally, the error notification message SHOULD include a 16-bit nickname and 48-bit system id of the next hop RBridge the frame would have been sent to in the Next Hop Information TLV. If the request is a multi-destination frame, the previous hop information SHOULD be included instead with it set to the nickname and system id of the RBridge the frame was received from. This is the previous hop RBridge. If the RBridge transmitting the reply is the egress RBridge, this TLV MUST NOT be included in the frame.</t>
</section>
</section>
</section>
<!-- ################################################################### -->
<section anchor="rbridge_channel_message_format" title="RBridge Channel Message Format">
<t>
This section specifies the format of the TRILL OAM payload after the RBridge Channel header and values of the fields in the RBridge Channel Header <xref target="RBridgeChannel"/>.
</t>
<section anchor="rbridge_channel_header_and_seq_number" title="RBridge Channel Header and Sequence Number">
<t>
The RBridge Channel Header <xref target="RBridgeChannel"/> fields and flags and following sequence number are as follows:
<list style="symbols">
<t>CHV (Channel Header Version) is zero.</t>
<t>
Protocol code values are:
<list style="symbols">
<t> &ECHO_VALUE;: Echo</t>
<t> &ERROR_VALUE;: Error Notification</t>
</list>
</t>
<t>Flags: The SL and NA bits SHOULD be zero, the MH bit SHOULD be one</t>
<t>ERR: The ERR field MUST be zero.</t>
<t>SPID and Sequence Number: For the Echo and Error Notification protocols, the RBridge Channel Header is always followed by a nibble sub-protocol identifier (SPID) and a 28-bit Sequence Number. This 28-bit field is used to sequence or match frames for certain uses. The SPID is used to provide additional op-code room for a protocol to further multiplex its messages. Not all TRILL OAM messages utilize the sequence number field or the SPID.</t>
</list>
</t>
</section>
</section>
<!-- ################################################################### -->
<section anchor="oam_protocol_field_values" title="OAM Protocol Field Values">
<section anchor="reponse_frame_field_values" title="Response Frame Field Values">
<t>
Frames with a TRILL OAM message generated in response to another TRILL data frame have fields set as follows unless otherwise specified:
</t>
<t>
<list style="symbols">
<t>Frames of type Application or Error
<list style="symbols">
<t>Field: Inner.MacSA</t>
<t>Value: If the Inner.MacDA of the received frame is one of the MAC addresses of the RBridge generating the frame, the value MUST be that MAC address. Otherwise, it MUST be one of the RBridge's MAC addresses.</t>
</list>
</t>
<t>Frames of type Application or Error
<list style="symbols">
<t>Field: Inner.MacDA</t>
<t>Value: The value MUST be All-Egress-RBridges.</t>
</list>
</t>
<t>Frames of type Application or Error
<list style="symbols">
<t>Field: Inner.VLAN ID</t>
<t>Value: If the frame is generated in response to another frame with a legal Inner.VLAN ID, it MUST be the Inner.VLAN ID of the received frame. In other cases, it SHOULD be the default VLAN ID 1.</t>
</list>
</t>
<t>Frames of type Application or Error
<list style="symbols">
<t>Field: Ingress RBridge nickname</t>
<t>Value: If the egress RBridge nickname of the received frame is a nickname of the RBridge generating the frame, then the value MUST be that nickname. otherwise, it MUST be one of the RBridge's nicknames.</t>
</list>
</t>
<t>Frames of type Application or Error
<list style="symbols">
<t>Field: Egress RBridge nickname</t>
<t>Value: The value MUST be the ingress RBridge nickname of the received frame. Except that, if the ingress RBridge nickname received is unknown or reserved the frame MUST be generated on the port the frame was received on with an Outer.MacDA and egress RBridge nickname of the previous-hop RBridge if this is known.</t>
</list>
</t>
<t>Frames of type Error
<list style="symbols">
<t>Field: Offending Encapsulated Frame</t>
<t>Value: The value MUST be N bytes of the frame that had the error where N is the minimum of the frame size and the number of bytes that would bring the resulting error frame up to 1470 bytes. This MUST include the TRILL header and MUST NOT include the link-layer header.</t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: M Bit</t>
<t>Value: The value of this field is defined by each specific OAM protocol.</t>
</list>
</t>
<t>Frames of type Error
<list style="symbols">
<t>Field: M Bit</t>
<t>Value: The value MUST be zero.</t>
</list>
</t>
<t>Frames of type Application or Error
<list style="symbols">
<t>Field: Inner.Priority</t>
<t>Value: The value SHOULD be one less than the priority of the received frame, but not less than the lowest priority. One less may be numerically one less in the normal case or logically one less in the case of priority mapping being present.</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="self_frame_field_values" title="Self-Initiated Frame Field Values">
<t>
Frames with a TRILL OAM message that are self-initiated have fields set as follows unless otherwise specified:
</t>
<t>
<list style="symbols">
<t>Frames of type Application
<list style="symbols">
<t>Field: Inner.MacSA</t>
<t>Value: This SHOULD be one of the transmitting RBridge's MAC addresses. The Inner.MacSA MAY be other values as specified in <xref target="implementationconsiderations"/>. </t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: Inner.MacDA</t>
<t>Value: The value SHOULD be All-Egress-RBridges.</t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: Inner.VLAN ID</t>
<t>Value: The value SHOULD be the default VLAN ID 1. The Inner.VLAN ID MAY be other values as specified in <xref target="implementationconsiderations"/>.</t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: Ingress RBridge nickname</t>
<t>Value: The value SHOULD be one of the RBridge's nicknames. The Ingress RBridge nickname MAY be other values as specified in <xref target="implementationconsiderations"/>.</t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: Egress RBridge nickname</t>
<t>Value: The value of this field is defined by each specific OAM protocol.</t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: M Bit</t>
<t>Value: The value of this field is defined by each specific OAM protocol.</t>
</list>
</t>
<t>Frames of type Application
<list style="symbols">
<t>Field: Inner.Priority</t>
<t>Value: The value of this field defaults to zero. The Inner.Priority MAY be other values as specified in <xref target="implementationconsiderations"/>.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section anchor="protocol_codes_format" title="OAM Protocol Formats">
<t>The formats of Echo Request, Echo Reply, and Error Notification OAM Messages are given below.</t>
<section anchor="application_codes" title="Protocol Application Codes Formats">
<section anchor="echo_request" title="Echo Request">
<figure align="center" anchor="echo_request_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel |
| Header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SPID | Sequence |
| Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Echo Request
</postamble>
</figure>
<t>
This message is used by ingress RBridges to request an echo reply from the egress RBridge. Further uses are specified in <xref target="hop_count_traceroute"/> and <xref target="ping"/>
<list style="symbols">
<t>SPID: The SPID MUST be zero to indicate an echo request.</t>
<t>
Sequence Number: An arbitrary 28-bit unsigned integer used to aid in matching reply messages to echo requests. It MAY be zero.
</t>
</list>
</t>
</section>
<section anchor="echo_reply" title="Echo Reply">
<figure align="center" anchor="echo_reply_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel |
| Header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SPID | Sequence |
| Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. TLVs .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Echo Reply Format
</postamble>
</figure>
<t>
This message is used by egress RBridges to reply to an echo request from the ingress RBridge. Further uses are specified in <xref target="hop_count_traceroute"/> and <xref target="ping"/>.
<list style="symbols">
<t>SPID: The SPID MUST be one to indicate an echo reply.</t>
<t>
Sequence Number: A 28-bit unsigned integer used to aid in matching reply messages to echo requests. Set to the sequence number field of the Echo Request that cause this Echo Reply.
</t>
<t>
TLVs: A set of type, length, value encoded fields as specified in <xref target="tlvs" />.
</t>
</list>
</t>
</section>
</section>
<section anchor="error_notification" title="Error Notification Format">
<figure align="center" anchor="error_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel |
| Header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SPID | Sequence |
| Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Err. T.| Subcode |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. TLVs .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Error Format
</postamble>
</figure>
<t>
This message is used by RBridges to signal that an error has been detected.
<list style="symbols">
<t>SPID: The SPID MUST be set to all zeros on transmission and is ignored on reception. It is unused by the error notification protocol.</t>
<t>
Sequence Number: For all sub-codes except for the hop count error this field is unused. It is set to zero on transmission and ignored on reception. For the hop count error this is a 28-bit unsigned integer used to aid in matching reply messages to echo requests. If the frame whose hop-count dropped to zero contains the echo request message (See <xref target="echo_request"/>), this MUST match the sequence number Echo Request found in that message. If this is not in reply to an Echo Request, then the sequence number MUST be set to zero.
</t>
<t>
Error Type: MUST be a specifier of the error type describing the error. The values are: 0 (Permanent Error), 1 (Transient Error), 2 (Warning), 3 (Comment). Values 4 through 7 are available for allocation by IETF Review.
</t>
<t>
Subcode: MUST be a specifier of the error discovered in the frame. The valid values are specified in <xref target="error_specifiers"/>
</t>
<t>
TLVs: A set of type, length, value encoded fields as specified in <xref target="tlvs" />.
</t>
</list>
</t>
<section anchor="error_specifiers" title="Error Specifiers">
<t>The sub-code values fall into three categories: errors (divided into transient and permanent errors), warnings, and comments. All sub-codes represent something out of the ordinary that has gone wrong, but certain ones are more important than others. Sub-codes that are classified as errors are the most severe with warning sub-codes being less severe. These are enabled by default. Errors can be futher divided into transient and permanent. Transient errors are errors that happen but where the error causing RBridge can try again in the future and the error may not happen again. Permanent errors are errors that will happen again in a converged network. It is up to implementations to determine if errors should be listed as permanent or transient. Sub-codes classified as comments are minor and are disabled by default. They may be useful for operators debugging a network. All error generations are optional and therefore MAY be generated or not generated depending on security and implementation constraints.</t>
<t>
The error specifiers sub-code values are:
</t>
<t>
Error Sub-codes
</t>
<t>
<list style="symbols">
<t>0: Unknown Error: Indicates an error has occurred.</t>
<t>1: Invalid Outer.VLAN: Indicates the Outer.VLAN ID was not the designated VLAN ID or was 0xFFFF.</t>
<t>2: Unknown Egress RBridge: Indicates the Egress RBridge in a received frame is unknown.</t>
<t>3: Unknown Ingress RBridge: Indicates the Ingress RBridge in a received frame is unknown. (RBridges are not required to test for this error.)</t>
<t>4: Unsupported Critical Hop-by-hop Option: Indicates an unsupported critical hop-by-hop option was received.</t>
<t>5: Unsupported Critical Ingress-to-Egress Option: Indicates an unsupported critical ingress-to-egress option was received.</t>
<t>6: Hop Count Zero: Indicates a frame hop count reached zero in transit. (Used for pings and traceroute.)</t>
<t>7: Frame too Big: Indicates a frame was too large for the path it took (exceeded the MTU).</t>
<t>8-84: Available for allocation by IETF Review</t>
<t>85: Reserved for Private Experimentation</t>
</list>
</t>
<t>Warning Sub-codes</t>
<t>
<list style="symbols">
<t>86: No Adjacency: Indicates a TRILL data frame was sent from an RBridge the receiving RBridge is not adjacent to. (RBridges MAY be configured to accept such frames in which case this is not an error.)</t>
<t>87-169: Available for allocation by IETF Review</t>
<t>170: Reserved for Private Experimentation</t>
</list>
</t>
<t>Comment Sub-codes</t>
<t>
<list style="symbols">
<t>171-254: Available for allocation by IETF Review</t>
<t>255: Reserved for Private Experimentation</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="tlvs" title="Type, Length, Value (TLV) Encodings">
<t>To facilitate future interoperable expansion of the data carried in OAM sub-messages some sub-messages use a TLV encoding. These TLV sections consist of a list of type, length, value encoded data where the type signals to the RBridge how to interpret the value, and the length tells the RBridge the length of the value in bytes. The type and length are both 16 bit fields. A length of zero indicates the value is a UTF-8 string with a NULL ('\0') terminating byte. Preceding the list of TLVs is a 16 bit total length field which specifies the total length of all the length fields in octet units. TLVs with an unknown Type MUST be ignored and skipped over. The value field is 1 byte aligned.</t>
<figure align="center" anchor="tlvs_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Total Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. TLV List .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
TLVs Format
</postamble>
</figure>
<t>Each TLV in the TLV List appears on the wire encoded as follows:</t>
<figure align="center" anchor="tlv_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. Value .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
TLV Format
</postamble>
</figure>
<t>
The type values are:
<list style="symbols">
<t>
0: Next Hop Information, See <xref target="next_hop_info"/>
</t>
<t>
1: Previous Hop Information, See <xref target="previous_hop_info"/>
</t>
<t>
2: Outgoing Port ID, See <xref target="outgoing_port_id"/>
</t>
<t>
3: Incoming Port ID, See <xref target="incoming_port_id"/>
</t>
<t>
4: Outgoing Port MTU, See <xref target="outgoing_port_mtu"/>
</t>
<t>
5: IS-IS System ID, See <xref target="isis_system_id"/>
</t>
<t>6-253: Available for allocation by IETF Review</t>
<t>254: Reserved for Private Use</t>
<t>255: Reserved</t>
</list>
</t>
<section anchor="next_hop_info" title="Next Hop Information">
<figure align="center" anchor="next_hop_information_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x08 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Next Hop Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| Next Hop System ID |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Next Hop Information Format
</postamble>
</figure>
<t>
For traceroutes targeting known unicast destinations, hop-count errors, and MTU errors, this TLV MUST be a 16-bit nickname and 48-bit system ID of the next hop RBridge the frame is being or would have been sent to. If the next hop RBridge has not reserved a nickname the nickname field must be 0x0000. If the RBridge transmitting the TLV is the egress RBridge this TLV is not included in the frame. For pings, this field MUST be set to all zeros on transmission and ignored on reception. If an RBridge has multiple nicknames it SHOULD use the numerically largest nickname in the Next Hop Information TLV.
</t>
</section>
<section anchor="previous_hop_info" title="Previous Hop Information">
<figure align="center" anchor="previous_hop_information_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x08 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Previous Hop Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| Previous Hop System ID |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Previous Information Format
</postamble>
</figure>
<t>
For traceroutes targeting known unicast destinations, hop-count errors, and MTU errors, this TLV MUST be a 16-bit nickname and 48-bit system ID of the previous hop RBridge the frame being responded to was forwarded from. If an RBridge has multiple nicknames it SHOULD use the numerically largest nickname in the Previous Hop Information TLV.
</t>
</section>
<section anchor="incoming_port_id" title="Incoming Port ID">
<figure align="center" anchor="incoming_port_id_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x01 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Incoming Port ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Incoming Port ID Format
</postamble>
</figure>
<t>
This TLV MUST be set to the Port ID found in 'The Special VLANs and Flags sub-TLV' for the port the request being replied to was received on <xref target="RFC6326"/>.
</t>
</section>
<section anchor="outgoing_port_id" title="Outgoing Port ID">
<figure align="center" anchor="outgoing_port_id_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Outgoing Port ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Outgoing Port ID Format
</postamble>
</figure>
<t>
This TLV MUST be set to the Port ID found in 'The Special VLANs and Flags sub-TLV' for the port the frame is being forwarded on to (or would have been for an echo request/hop-count error) <xref target="RFC6326"/>. If the request was consumed by the replying RBridge, the port ID MUST be &CONSUMED_PORT_ID_VALUE;.
</t>
</section>
<section anchor="outgoing_port_mtu" title="Outgoing Port MTU">
<figure align="center" anchor="outgoing_port_mtu_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x03 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Outgoing Port MTU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
Outgoing Port MTU Format
</postamble>
</figure>
<t>
This TLV MUST be the MTU of the outgoing port specified in the outgoing port ID TLV.
</t>
</section>
<section anchor="isis_system_id" title="IS-IS System ID">
<figure align="center" anchor="isis_system_id_format">
<artwork align="center">
<![CDATA[
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x04 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x06 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| IS-IS System ID |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]>
</artwork>
<postamble>
IS-IS System ID Format
</postamble>
</figure>
<t>
This TLV MUST include the IS-IS System ID of the system generating the message. This TLV MAY be included in all/any messages.
</t>
</section>
</section>
<!-- ###################################################################
<section anchor="notes" title="Notes">
<t>
NOTE: This section contains some ideas and will be removed later.
</t>
<t>It might be nice to specify a IS-IS sub-TLV for port-id to ifname string mapping. </t>
<t>Perhaps add a diagram for a multi-destination traceroute and for a error message</t>
<t>Traceroutes to specific multicast groups to test group pruning would be useful.</t>
</section>
-->
<!-- ################################################################### -->
<section anchor="acknowledgments" title="Acknowledgments">
<t>
Many people have contributed to this work, including the following, in alphabetic order: Sam Aldrin, Dinesh Dutt, Donald E. Eastlake 3rd, Anoop Ghanwani, Meenakshi Kaushik, Jeff Laird, Thomas Narten, Santosh Rajagopalan, Marc Sklar, and Li Yizhou.
</t>
</section>
<!-- ################################################################### -->
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is request to create a new subregistry within the TRILL Parameter registry for "TRILL OAM Message Error Sub-Message Error Specifiers". This subregistry that is initially populated as specified in <xref target="error_specifiers"/>. Additional values are allocated by IETF Review <xref target="RFC5226" />.
</t>
<t>
IANA is requested to create a new subregistry within the TRILL Parameter registry for "TRILL Error Reporting Protocol TLV Types" with initial values as listed in Section 5.3. Additional values are allocated by IETF Review <xref target="RFC5226" />.
</t>
<t>
This draft also requires action to reserve the TRILL RBridge Channel protocol codes. IANA is requested to allocate the TRILL RBridge Channel protocol codes for as listed in <xref target="rbridge_channel_header_and_seq_number"/>.
</t>
</section>
<!-- ################################################################### -->
<section anchor="security" title="Security Considerations">
<t>
The nature of the OAM Messages can lead to security concerns. By providing information about the topology and status of a network, attackers can gain greater knowledge of a network in order to exploit the network. Passive attacks such as reading frames with an OAM message could be used to gain such knowledge or active attacks where an attacker mimics an RBridge can be used to probe the network. Authentication, data integrity, protection against replay attacks, and confidentiality for TRILL OAM frames may be provided using a to-be-specified TRILL Security Option. Using such a security option would mitigate both the passive and active attacks.
</t>
<t>
For instance, data origin authentication could be provided in the future using a security options in the TRILL Header by verifying a hash using shared keys or a mechanism like SEND with CGA. To prevent replay attacks rate limiting, sequence numbers as well as some nonce based mechanism could be provided. Confidentiality for TRILL OAM frames could be provided based on some future security option extension which encypts TRILL frames.
</t>
<t>
In a network where one does not wish to configure a security option, the threat of attackers is still present. For this reason, generation of any TRILL OAM Message frames is optional and SHOULD be configurable by an operator on a per RBridge basis. An RBridge MAY have this configurable on a per port basis. For instance, an operator SHOULD be able to disable hop-count traceroute reply messages or error notification message generation per port.
</t>
<t>
Another security threat is denial of service through use of OAM messages. For this reason, RBridges MUST rate limit the generation of OAM message frames. For multi-destination frames, the frames MAY be discarded silently to prevent any denial of service attacks in case of an error packet such as an 'options not recognized' error notification.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6325.xml"?> <!-- TRILL BASE -->
<!-- Requirement Levels -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6291.xml"?>
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-trill-rbridge-channel-05"?>-->
<reference anchor="RBridgeChannel">
<front>
<title>RBridges: TRILL RBridge Channel Support</title>
<author initials="D" surname="Eastlake" fullname="Donald Eastlake">
<organization/>
</author>
<author initials="V" surname="Manral" fullname="Vishwas Manral">
<organization/>
</author>
<author initials="L" surname="Yizhou" fullname="Li Yizhou">
<organization/>
</author>
<author initials="S" surname="Aldrin" fullname="Sam Aldrin">
<organization/>
</author>
<author initials="D" surname="Ward" fullname="Dave Ward">
<organization/>
</author>
<date month="February" day="20" year="2012"/>
<abstract>
<t>
This document specifies a general channel mechanism for sending messages, such as OAM (Operations, Administration, and Maintenance) messages, between RBridges (Routing Bridges) and between RBridges and end stations in an RBridge campus through extensions to the TRILL (TRansparent Interconnection of Lots of Links) protocol.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-trill-rbridge-channel-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-channel-05.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="IEEE.802-1ag">
<front>
<title>IEEE Stadard for Local and metropolitian area networks / Virtual Bridged Local Area Networks / Connectivity Fault Management</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="December" day="17" year="2007" />
</front>
<seriesInfo name="IEEE" value="Standard 802.1Q" />
</reference>
<reference anchor="IS-IS">
<front>
<title>
Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)
</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date month="Nov" year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
</reference>
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-trill-rbridge-mib-04"?>-->
<reference anchor='RBridgeMIB'>
<front>
<title>Definitions of Managed Objects for RBridges</title>
<author initials='A' surname='Rijhsinghani' fullname='Anil Rijhsinghani'>
<organization />
</author>
<author initials='K' surname='Zebrose' fullname='Kate Zebrose'>
<organization />
</author>
<date month='January' day='30' year='2012' />
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing RBridges, which are devices that implement the TRILL protocol.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-trill-rbridge-mib-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-06.txt' />
</reference>
<reference anchor='BFD'>
<front>
<title>Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL</title>
<author initials='A' surname='Banerjee' fullname='Ayan Banerjee'>
<organization />
</author>
<author initials='D' surname='Ward' fullname='David Ward'>
<organization />
</author>
<author initials='D' surname='Eastlake' fullname='Donald Eastlake'>
<organization />
</author>
<author initials='V' surname='Manral' fullname='Vishwas Manral'>
<organization />
</author>
<date month='January' day='24' year='2012' />
<abstract><t>This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-trill-rbridge-bfd-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-02.txt' />
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6326.xml"?> <!-- TRILL ISIS -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml"?>
<!-- ICMPv4 -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml"?>
<!-- ICMPv6 -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
<!-- IANA Guidelines -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5837.xml"?>
<!-- Port Ided Traceroute-->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6165.xml"?>
</references>
<section anchor="implementationconsiderations" title="Implementation Considerations">
<t>This appendix contains a few considerations implementors should take note of when creating their user interface as well as some examples of what occurs when a traceroute or ping are executed. These provide a sample user interface one can use as the basis for their user interface.</t>
<t>First, an RBridge SHOULD maintain counters for each type of error generated. There SHOULD be a way for users to view these counters.</t>
<t>Some of the set of default field values for self originated frames are presented in <xref target="self_frame_field_values"/>. RBridges SHOULD be configurable to change these values to assign the TRILL data frame to a flow. <!--e.g. The Inner.MacSA might be changed to the MAC address of an end station connected to the ingress Rbridge to alter the ECMP path frames coming from that end station follow through the TRILL campus.--></t>
<section anchor="hop_count_traceroute_example" title="Hop Count Traceroute Example">
<t>
<xref target="hop_count_traceroute_example_topology"/> contains a campus with three RBridges. Consider a hop-count traceroute from RB0 to RB2.
</t>
<figure align="center" anchor="hop_count_traceroute_example_topology">
<artwork align="center">
<![CDATA[
+-----+ +-------+ +-------+ +-------+ +-----+
| ESa +--+ RB0 +---+ RB1 +---+ RB2 +--+ ESb |
+-----+ |ingress| |transit| |egress | +-----+
+-------+ +-------+ +-------+
Time RB0 RB1 RB2
. (1)-------> | |
. | <------- (2) |
. (3)-------> (3) -------> |
. | <------- (4) <-------(4)
]]>
</artwork>
<postamble>
Hop Count Traceroute Example Topology
</postamble>
</figure>
<t>
In this diagram RB0 transmits frame (1) destined to RB2. This frame contains the echo request message and a hop-count of 0. When RB1 receives this frame it drops it and transmits a hop-count-exceeded message, (2), to RB0. RB0 then transmits a frame, (3), with a hop-count of 1. RB1 decrements this hop-count by 1 to 0 and forwards it to RB2. RB2 drops frame (3) and transmits a Hop Count Zero error notification, (4), to RB0. The traceroute is now complete.
</t>
<t>
Below are some select fields for the frames:
</t>
<texttable anchor="hop_count_traceroute_example_frames" title="Hop Count Traceroute Example Frames" style="all">
<ttcol align="center">Frame #</ttcol>
<ttcol align="center">Ingress RBridge</ttcol>
<ttcol align="center">Egress RBridge</ttcol>
<ttcol align="center">TRILL OAM Protocol</ttcol>
<ttcol align="center">Sequence Number</ttcol>
<ttcol align="center">Hop Count</ttcol>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>(1) </c>
<c>RB0</c>
<c>RB2</c>
<c>Echo Request</c>
<c>1</c>
<c>0</c>
<c>(2)</c>
<c>RB1</c>
<c>RB0</c>
<c>Hop Count Zero error notification</c>
<c>1</c>
<c>Default</c>
<c>(3) @ RB1</c>
<c>RB0</c>
<c>RB2</c>
<c>Echo Request</c>
<c>2</c>
<c>1</c>
<c>(3) @ RB2</c>
<c>RB0</c>
<c>RB2</c>
<c>Echo Request</c>
<c>2</c>
<c>0</c>
<c>(4) @ RB1</c>
<c>RB2</c>
<c>RB0</c>
<c>Hop Count Zero error notification</c>
<c>2</c>
<c>Default</c>
<c>(4) @ RB0</c>
<c>RB2</c>
<c>RB0</c>
<c>Hop Count Zero error notification</c>
<c>2</c>
<c>Default</c>
</texttable>
<t>
For example, if the nicknames for RB0, RB1, and RB2 are 0x1111, 0x2222, and 0x3333 respectively, the console output from such a trace might be:
</t>
<texttable anchor="hop_count_traceroute_example_output" title="Hop Count Traceroute Example Output" style="headers" align="left">
<preamble>Hop Count Tracing</preamble>
<ttcol align="center">RBridge</ttcol>
<ttcol align="center">Incoming Port Id</ttcol>
<ttcol align="center">Outgoing Port Id</ttcol>
<ttcol align="center">RBridge Nexthop Nickname</ttcol>
<c>0x1111</c>
<c>Ingress</c>
<c>0x0001</c>
<c>0x2222</c>
<c>0x2222</c>
<c>0x0000</c>
<c>0x0001</c>
<c>0x3333</c>
<c>0x3333</c>
<c>0x0000</c>
<c>Egress</c>
<c>0x0000</c>
</texttable>
<t>In this example, the first line of output is generated from local information, no hop-count frames are sent to generate it.</t>
</section>
<section anchor="ping_example" title="Ping Example">
<t>
<xref target="ping_example_topology"/> contains a campus with three RBridges. Consider a ping from RB0 to RB2.
</t>
<figure align="center" anchor="ping_example_topology">
<artwork align="center">
<![CDATA[
+-----+ +-------+ +-------+ +-------+ +-----+
| ESa +--+ RB0 +---+ RB1 +---+ RB2 +--+ ESb |
+-----+ |ingress| |transit| |egress | +-----+
+-------+ +-------+ +-------+
Time RB0 RB1 RB2
. (1)-------> (1) -------> |
. | <------- (2) <-------(2)
]]>
</artwork>
<postamble>
Ping Example Topology
</postamble>
</figure>
<t>
In this diagram RB0 transmits frame (1) destined to RB2. This frame contains the echo request message. When RB1 receives this frame it forwards it to RB2. When RB2 receives this frame it transmits and echo reply frame (2) destined to RB0. RB1 receives this frame and forwards it to RB0.
</t>
<t>
Below are some select fields for the frames:
</t>
<texttable anchor="ping_example_frames" title="Ping Example Frames" style="all">
<ttcol align="center">Frame #</ttcol>
<ttcol align="center">Ingress RBridge</ttcol>
<ttcol align="center">Egress RBridge</ttcol>
<ttcol align="center">TRILL OAM Protocol</ttcol>
<ttcol align="center">Sequence Number</ttcol>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>(1) </c>
<c>RB0</c>
<c>RB2</c>
<c>Echo Request</c>
<c>1</c>
<c>(2) </c>
<c>RB2</c>
<c>RB0</c>
<c>Echo Reply</c>
<c>1</c>
</texttable>
<t>
For example, if the nicknames for RB0, RB1, and RB2 are 0x1111, 0x2222, and 0x3333 respectively, the console output from such a ping might be:
</t>
<texttable anchor="ping_example_output" title="Ping Example Output" style="headers" align="left">
<ttcol align="left">Pinging</ttcol>
<c>... from 0x1111 to 0x3333... 0x3333 is alive</c>
<c>... from 0x1111 to 0x3333... 0x3333 is alive</c>
<c>... from 0x1111 to 0x3333... 0x3333 is alive</c>
</texttable>
<t>In this example, the ping was repeated three times with the sequence number (not shown) being changed each time.</t>
</section>
</section>
<section anchor="revhis" title="Revision History">
<t>RFC Editor: Please delete this appendix before publication.</t>
<section anchor="revhis0102" title="Changes from -01 to -02">
<t>
<list>
<t>
Moved the values table to the message format section and converted from table to list.
</t>
<t>
Added previous hop information TLV.
</t>
<t>
Removed error codes that were not needed.
</t>
<t>
Added path sharing traceroute with 'real' data being sent.
</t>
<t>
Added mention of BFD draft.
</t>
<t>
Made most TLVs optional to allow hardware/fast path implementations where this information might not be available.
</t>
<t>
Changed Next Hop Nickname TLV into Next Hop Information TLV since next hop might not always reserve a nickname. The new TLV includes the next hop system id.
</t>
<t>
Numerous minor typo corrections and wording clarifications.
</t>
</list>
</t>
</section>
<section anchor="revhis0001" title="Changes from -00 to -01">
<t>
<list>
<t>
Broke down the table "frame field values" into two tables, "response frame field values" and "self initiated frame field values".
</t>
<t>
Reorganized the document to move user interface related items to the appendix and switched the order of ping/traceroute.
</t>
<t>
Numerous minor typo corrections and wording clarifications.
</t>
</list>
</t>
</section>
<!--
<section anchor="revhis0001" title="Changes from -00 to -01">
<t>
<list>
<t>
Reworked the document to use the OAM Channel rather than an OAM option.
</t>
<t>
Changed the frame formats to work within the OAM Channel.
</t>
<t>
Numerous minor typo corrections and wording clarifications.
</t>
<t>
Removed the route-respond traceroute.
</t>
<t>
Combined all the error notifications into one OAM Channel.
</t>
</list>
</t>
</section>
-->
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 23:26:06 |