Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support
draft-ietf-trill-rbridge-oam-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | David Mich Bond , Vishwas Manral | ||
| Last updated | 2011-10-28 (Latest revision 2011-07-03) | ||
| Replaces | draft-bond-trill-rbridge-oam | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-trill-rbridge-oam-01
TRILL Working Group D. Bond
Internet-Draft IBM
Intended status: Standards Track V. Manral
Expires: April 30, 2012 HP Networking
October 28, 2011
Routing Bridges (RBridges): Operations, Administration, and Maintenance
(OAM) Support
draft-ietf-trill-rbridge-oam-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 30, 2012.
Copyright Notice
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
Bond & Manral Expires April 30, 2012 [Page 1]
Internet-Draft RBridges: OAM Support October 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TRILL OAM Message . . . . . . . . . . . . . . . . . . . . . . 5
4. RBridge Tools . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Application RBridge Tools . . . . . . . . . . . . . . . . 9
4.1.1. RBridge Ping . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Hop Count Traceroute . . . . . . . . . . . . . . . . . 10
4.1.2.1. Multi-Destination Targets . . . . . . . . . . . . 12
4.2. Error Reporting . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Hop Count Zero Error . . . . . . . . . . . . . . . . . 13
4.2.2. MTU Error . . . . . . . . . . . . . . . . . . . . . . 13
5. RBridge Channel Message Format . . . . . . . . . . . . . . . . 14
5.1. RBridge Channel Header and Sequence Number . . . . . . . . 14
6. OAM Protocol Formats . . . . . . . . . . . . . . . . . . . . . 14
6.1. Protocol Application Codes Formats . . . . . . . . . . . . 14
6.1.1. Echo Request . . . . . . . . . . . . . . . . . . . . . 15
6.1.2. Echo Reply . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Error Notification Format . . . . . . . . . . . . . . . . 16
6.2.1. Error Specifiers . . . . . . . . . . . . . . . . . . . 17
7. Type, Length, Value (TLV) Encodings . . . . . . . . . . . . . 20
7.1. Next Hop Nickname . . . . . . . . . . . . . . . . . . . . 22
7.2. Incoming Port ID . . . . . . . . . . . . . . . . . . . . . 23
7.3. Outgoing Port ID . . . . . . . . . . . . . . . . . . . . . 23
7.4. Outgoing Port MTU . . . . . . . . . . . . . . . . . . . . 24
7.5. IS-IS System ID . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Implementation Considerations . . . . . . . . . . . . 27
A.1. Hop Count Traceroute Example . . . . . . . . . . . . . . . 27
A.2. Ping Example . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Revision History . . . . . . . . . . . . . . . . . . 30
B.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 30
Bond & Manral Expires April 30, 2012 [Page 2]
Internet-Draft RBridges: OAM Support October 2011
1. Introduction
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
[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 [IS-IS] [RFC6165] [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.
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 [RFC4443]
[RFC0792] [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. For instance, if a TRILL Inner.VLAN tag has an
illegal value there should be a way for devices to report this error.
This would assist administrators of an RBridge campus in quickly
locating a problem device in the network.
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. Section 3 of this document specifies the
general usage of a defined message format. Section 4 specifies some
additional applications of the message format. Section 5 specifies
the format of the messages on the wire.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Acronyms
o BPDU - Bridge PDU
Bond & Manral Expires April 30, 2012 [Page 3]
Internet-Draft RBridges: OAM Support October 2011
o CHbH - Critical Hop-by-Hop
o CItE - Critical Ingress-to-Egress
o DA - Destination Address
o DR - Designated Router
o DRB - Designated RBridge
o ES - End Station
o ESa - End Station A
o ESb - End Station B
o ECMP - Equal-Cost Multi-Path
o ESADI - End Station Address Distribution Instance
o FCS - Frame Check Sequence
o ID - Identification
o IEEE - Institute of Electrical and Electronics Engineers
o IETF - Internet Engineering Task Force
o IP - Internet Protocol
o IS-IS - Intermediate System to Intermediate System
o MAC - Media Access Control
o MPLS - Multiprotocol Label Switching
o MTU - Maximum Transmission Unit
o OAM - Operations, Administration, and Maintenance
o P2P - Point-to-point
o PDU - Protocol Data Unit
o RBridge - Routing Bridge
o SA - Source Address
Bond & Manral Expires April 30, 2012 [Page 4]
Internet-Draft RBridges: OAM Support October 2011
o SNMP - Simple Network Management Protocol
o TLV - Type, Length, Value
o TRILL - TRansparent Interconnection of Lots of Links
o VLAN - Virtual Local Area Network
3. TRILL OAM Message
To facilitate message passing as needed by the OAM requirements, the
TRILL RBridge Channel facility [RBridgeChannel] is utilized.
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.
The specification of rate limiting is beyond the scope of this
document.
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.
Section 5 goes into the details of these formats.
+----------------------------+
| Outer Link Header |
+----------------------------+
| TRILL Header |
+----------------------------+
| Inner Ethernet Header |
+----------------------------+
| RBridge Channel Header |
+----------------------------+
| OAM Protocol Spec. Payload |
+----------------------------+
Application Frame
Figure 1
Bond & Manral Expires April 30, 2012 [Page 5]
Internet-Draft RBridges: OAM Support October 2011
+---------------------------------------+
| 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 |
+---------------------------------------+
Error Notification Frame
Figure 2
Frames with a TRILL OAM message generated in response to another
TRILL data frame have fields set as follows unless otherwise
specified:
+-------------+----------------+------------------------------------+
| Frame Type | Field | Value |
+-------------+----------------+------------------------------------+
+-------------+----------------+------------------------------------+
| Application | Inner.MacSA | If the Inner.MacDA of the received |
| or Error | | 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. |
+-------------+----------------+------------------------------------+
| Application | Inner.MacDA | The value MUST be |
| or Error | | All-Egress-RBridges. |
+-------------+----------------+------------------------------------+
| Application | Inner.VLAN ID | If the frame is generated in |
| or Error | | 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. |
Bond & Manral Expires April 30, 2012 [Page 6]
Internet-Draft RBridges: OAM Support October 2011
| Application | Ingress | If the egress RBridge nickname of |
| or Error | RBridge | the received frame is a nickname |
| | nickname | of the RBridge generating the |
| | | frame, then the value MUST be that |
| | | nickname. Otherwise, it MUST be |
| | | one of the RBridge's nicknames. |
+-------------+----------------+------------------------------------+
| Application | Egress RBridge | The value MUST be the ingress |
| or Error | nickname | 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. |
+-------------+----------------+------------------------------------+
| Error | Offending | The value MUST be N bytes of the |
| | Encapsulated | frame that had the error where N |
| | Frame | 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. |
+-------------+----------------+------------------------------------+
| Application | M Bit | The value of this field is defined |
| | | by each specific OAM protocol. |
+-------------+----------------+------------------------------------+
| Error | M Bit | The value MUST be zero. |
+-------------+----------------+------------------------------------+
| Application | Inner.Priority | The value SHOULD be one less than |
| or Error | | 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. |
+-------------+----------------+------------------------------------+
Table 1: Response Frame Field Values
Frames with a TRILL OAM message that are self-initiated have fields
set as follows unless otherwise specified:
Bond & Manral Expires April 30, 2012 [Page 7]
Internet-Draft RBridges: OAM Support October 2011
+-------------+----------------+------------------------------------+
| Frame Type | Field | Value |
+-------------+----------------+------------------------------------+
+-------------+----------------+------------------------------------+
| Application | Inner.MacSA | This SHOULD be one of the |
| | | transmitting RBridge's MAC |
| | | addresses. The Inner.MacSA MAY be |
| | | other values as specified in |
| | | Appendix A. |
+-------------+----------------+------------------------------------+
| Application | Inner.MacDA | The value SHOULD be |
| | | All-Egress-RBridges. |
+-------------+----------------+------------------------------------+
| Application | Inner.VLAN ID | The value SHOULD be the default |
| | | VLAN ID 1. The Inner.VLAN ID MAY |
| | | be other values as specified in |
| | | Appendix A. |
+-------------+----------------+------------------------------------+
| Application | Ingress | The value SHOULD be one of the |
| | RBridge | RBridge's nicknames. The Ingress |
| | nickname | RBridge nickname MAY be other |
| | | values as specified in Appendix A. |
+-------------+----------------+------------------------------------+
| Application | Egress RBridge | The value of this field is defined |
| | nickname | by each specific OAM protocol. |
+-------------+----------------+------------------------------------+
| Application | M Bit | The value of this field is defined |
| | | by each specific OAM protocol. |
+-------------+----------------+------------------------------------+
| Application | Inner.Priority | The value of this field defaults |
| | | to zero. The Inner.Priority MAY |
| | | be other values as specified in |
| | | Appendix A. |
+-------------+----------------+------------------------------------+
Table 2: Self-Initiated Frame Field Values
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.
4. RBridge Tools
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
Section 5. An echo request is a message that says please respond.
Bond & Manral Expires April 30, 2012 [Page 8]
Internet-Draft RBridges: OAM Support October 2011
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 Section 7.
4.1. Application RBridge Tools
4.1.1. RBridge Ping
Ping is a tool for verifying RBridge connectivity. As with an
RBridge traceroute, 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 Section 6.1.1). 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.
The purpose of the ping 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 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.
The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress
Nickname SHOULD default to the values specified in Table 2.
RBridges implementing ping SHOULD issue a reply in response to this
request. See Section 10 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.
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 Table 1.
The M bit MUST be zero.
Bond & Manral Expires April 30, 2012 [Page 9]
Internet-Draft RBridges: OAM Support October 2011
The reply-originating RBridge MUST include its 16-bit port ID from
the port on which the request was received in the incoming port field
of the reply. It MUST also include its 16-bit port ID from the port
on which the frame is forwarded. A port ID of 0xFFFF indicates the
frame would not have been forwarded and that the frame was consumed
by the RBridge itself. The nickname field in the generated frame
MUST be set to all zeros on transmission and ignored on reception.
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.
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.
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.
4.1.2. Hop Count Traceroute
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 Section 3).
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
Section 6.1.1). The ingress RBridge MUST be the RBridge originating
the frame.
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
Section 4.1.2.1.
The first echo request frame transmitted MUST have a hop-count of
one. The RBridge will continue transmitting these echo requests,
incrementing the hop-count by one each time until a hop-count error
notification or echo reply is received from the destination. Each of
Bond & Manral Expires April 30, 2012 [Page 10]
Internet-Draft RBridges: OAM Support October 2011
these requests in turn will generate a hop-count error notification
until the egress RBridge is reached. If a transit RBridge decrements
the hop-count by more than one it MAY transmit multiple hop-count
error notifications.
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 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.
The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress
Nickname SHOULD default to the values specified in Table 2.
The replying RBridge MUST 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 MUST 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 0xFFFF indicates the frame would not have been forwarded
and would be consumed by the RBridge itself. Finally the reply MUST
include a 16-bit nickname of the next hop RBridge the frame would
have been sent to if there were no error in the Next Hop Nickname
TLV. This is to facilitate knowledge of a more precise path through
the campus as seen in RFC 5837 [RFC5837].
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.
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.
Bond & Manral Expires April 30, 2012 [Page 11]
Internet-Draft RBridges: OAM Support October 2011
4.1.2.1. Multi-Destination Targets
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. The ingressing
RBridge can compile all of these notifications, using the parent
pointers located in the nexthop nickname field, 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 does not stop when
an echo reply is received. It stops when the transmitted hop count
reaches the maximum, 0x3F.
In multi-destination request frames, the Nexthop Nickname TLV MUST be
set to the nickname of the RBridge the frame was received from. This
is the previous hop RBridge.
4.2. Error Reporting
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 Section 10 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
Section 6.2.1. 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.
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.
Bond & Manral Expires April 30, 2012 [Page 12]
Internet-Draft RBridges: OAM Support October 2011
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. Each RBridge SHOULD also keep a set of
counters for errors reported by other RBridges.
The two sub-codes that provide for TLVs with additional information
are described below. All other sub-codes specified in this document
do not contain TLVs.
4.2.1. Hop Count Zero Error
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 MUST be the
port ID the received frame arrived on. The Outgoing Port ID TLV MUST
be 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 MUST include a 16-bit nickname of the next hop RBridge
the frame would have been sent to in the Next Hop Nickname TLV. If
the request is a multi-destination frame, this field MUST be set to
the nickname of the RBridge the frame was received from. This is the
previous hop RBridge. If the RBridge transmitting the request is the
egress RBridge, this field MUST be set to 0x0000.
4.2.2. MTU Error
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 have
the MTU of the port the frame would have otherwise been transmitted
on. The Incoming Port ID TLV MUST be the port ID the received frame
arrived on. The Outgoing Port ID TLV MUST be 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 MUST
include a 16-bit nickname of the next hop RBridge the frame would
have been sent to in the Next Hop Nickname TLV. If the request is a
multi-destination frame, this field MUST be set to the nickname of
the RBridge the frame was received from. This is the previous hop
RBridge. If the RBridge transmitting the request is the egress
RBridge, this field MUST be set to 0x0000.
Bond & Manral Expires April 30, 2012 [Page 13]
Internet-Draft RBridges: OAM Support October 2011
5. RBridge Channel Message Format
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 [RBridgeChannel].
5.1. RBridge Channel Header and Sequence Number
The RBridge Channel Header [RBridgeChannel] fields and flags and
following sequence number are as follows:
o CHV (Channel Header Version) is zero.
o Protocol code values are:
* 0x004 (Suggested): Echo
* 0x005 (Suggested): Error Notification
o Flags: The SL and NA bits SHOULD be zero, the MH bit SHOULD be one
o ERR: The ERR field MUST be zero.
o 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.
6. OAM Protocol Formats
The formats of Echo Request, Echo Reply, and Error Notification OAM
Messages are given below.
6.1. Protocol Application Codes Formats
Bond & Manral Expires April 30, 2012 [Page 14]
Internet-Draft RBridges: OAM Support October 2011
6.1.1. Echo Request
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel |
| Header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SPID | Sequence |
| Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Echo Request
Figure 3
This message is used by ingress RBridges to request an echo reply
from the egress RBridge. Further uses are specified in Section 4.1.2
and Section 4.1.1
o SPID: The SPID MUST be zero to indicate an echo request.
o Sequence Number: An arbitrary 28-bit unsigned integer used to aid
in matching reply messages to echo requests. It MAY be zero.
6.1.2. Echo Reply
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel |
| Header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SPID | Sequence |
| Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. TLVs .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Echo Reply Format
Figure 4
This message is used by egress RBridges to reply to an echo request
Bond & Manral Expires April 30, 2012 [Page 15]
Internet-Draft RBridges: OAM Support October 2011
from the ingress RBridge. Further uses are specified in
Section 4.1.2 and Section 4.1.1.
o SPID: The SPID MUST be one to indicate an echo reply.
o 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.
o TLVs: A set of type, length, value encoded fields as specified in
Section 7. The next hop nickname, outgoing port ID, and incoming
port ID TLVs are required.
6.2. Error Notification Format
| 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 .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Error Format
Figure 5
This message is used by RBridges to signal that an error has been
detected.
o SPID: The SPID MUST be set to all zeros on transmission and is
ignored on reception. It is unused by the error notification
protocol.
o 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
Bond & Manral Expires April 30, 2012 [Page 16]
Internet-Draft RBridges: OAM Support October 2011
the echo request message (See Section 6.1.1), 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.
o 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.
o Subcode: MUST be a specifier of the error discovered in the frame.
The valid values are specified in Section 6.2.1
o TLVs: A set of type, length, value encoded fields as specified in
Section 7. For Hop Count Zero errors the next hop nickname,
outgoing port ID, and incoming port ID TLVs MUST be present. For
MTU errors the outgoing port MTU, next hop nickname, outgoing port
ID, and incoming port ID TLVs MUST be present. For all other
errors the TLVs are not used by default and the length of this
section is set to zero. An RBridge MAY include additional TLVs on
any error however.
6.2.1. Error Specifiers
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.
The error specifiers sub-code values are:
Error Sub-codes
o 0: Unknown Error: Indicates an error has occurred.
Bond & Manral Expires April 30, 2012 [Page 17]
Internet-Draft RBridges: OAM Support October 2011
o 1: Corrupt Frame: Frame received with invalid FCS or that was not
an 8-bit multiple in length. It could be impossible for a device
to signal this if the low-level port hardware hides this from the
software.
o 2: M Bit Mismatch: Indicates the MAC Address is a multicast
address and the M bit is zero, the MAC Address is not a multicast
address and the M bit is one, or the M bit is zero and the frame
carried is an ESADI frame.
o 3: Illegal Outer.VLAN: Indicates the Outer.VLAN ID is 0xFFF.
o 4: Invalid Outer.VLAN: Indicates the Outer.VLAN ID was not the
designated VLAN ID.
o 5: Unknown TRILL Version: Indicates the TRILL Header Version is
unknown.
o 6: Op-Length Exceeds Frame Length: Indicates the Op-Length says
the options field extends beyond the end of the received frame
length.
o 7: Unknown Egress RBridge: Indicates the Egress RBridge in a
received frame is unknown.
o 8: Unknown Ingress RBridge: Indicates the Ingress RBridge in a
received frame is unknown. (RBridges are not required to test for
this error.)
o 9: Unsupported Critical Hop-by-hop Option: Indicates an
unsupported critical hop-by-hop option was received.
o 10: Unsupported Critical Ingress-to-Egress Option: Indicates an
unsupported critical ingress-to-egress option was received.
o 11: Hop Count Zero: Indicates a frame hop count reached zero in
transit. (Used for pings and traceroute.)
o 12: MTU Mismatch: Indicates the MTU of two RBridges is different
on a particular port.
o 13-84: Available for allocation by IETF Review
o 85: Reserved for Private Experimentation
Warning Sub-codes
Bond & Manral Expires April 30, 2012 [Page 18]
Internet-Draft RBridges: OAM Support October 2011
o 86: Illegal Inner.VLAN: Indicates the Inner.VLAN ID is 0xFFF.
o 87: Inner/Outer VLAN Priority Mismatch: Indicates the priority
values in the inner and outer VLANs do not match.
o 88: P2P Hello on TRILL Hello Link: Indicates a P2P Hello was
received on a TRILL Hello Link.
o 89: TRILL Hello on P2P Hello Link: Indicates a TRILL Hello was
received on a P2P Hello Link.
o 90: 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.)
o 91: Encapsulated Layer 2 Control Frame: A TRILL Data Frame
containing a Layer 2 Control frame with a destination MAC in the
range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or a
01-80-C2-00-00-21 (VRP) frame was received.
o 92: Invalid Mutability Flag: Indicates the mutability flag was set
on a received CHbH Option.
o 93: Invalid TLV Option Length: Indicates the option length field
of a TLV option was between 121 and 127.
o 94: Options Ordering Error: Indicates the TLV options are ordered
incorrectly.
o 95: Configured Nickname Collision: Indicates an RBridge was
detected in the campus with the same nickname (Configured or not).
o 96: Multiple appointed forwarders detected.
o 97-169: Available for allocation by IETF Review
o 170: Reserved for Private Experimentation
Comment Sub-codes
o 171: Inner.VLAN C-Bit Set: Indicates the C-Bit in the Inner.VLAN
is set.
o 172: Unknown Inner.MacDA: Indicates the Inner.MacDA is unknown.
This may occur if devices are configured to explicitly register
end stations and an unknown Inner.MacDA occurs in a unicast TRILL
data frame. This also only applies at egress and could indicate
Bond & Manral Expires April 30, 2012 [Page 19]
Internet-Draft RBridges: OAM Support October 2011
that the Inner.MacDA was a learned address that has timed out.
o 173: Unknown Inner.MacSA: Indicates the Inner.MacSA is unknown.
This may occur if devices are configured to explicitly register
end stations and an unknown Inner.MacSA occurs in a TRILL data
frame.
o 174: Outer.VLAN C-Bit Set: Indicates the C-Bit in the Outer.VLAN
is set for an Ethernet frame.
o 175: Invalid Reserved Bits: Indicates the reserved bits are non-
zero in a received frame.
o 176: Invalid Nickname: Indicates a nickname in the reserved space
of 0xFFC1 to 0xFFFF was received that is not implemented at the
receiving RBridge.
o 177: Unsupported Non-Critical Hop-by-hop Option: Indicates an
unsupported non-critical hop-by-hop option was received. While
sending a non-critical option to an unsupported device is not an
error, this could be used to support identification of devices
needing an upgrade.
o 178: Unsupported Non-Critical Ingress-to-Egress Option: Indicates
an unsupported non-critical ingress-to-egress option was received.
While sending a non-critical option to an unsupported device is
not an error, this could be used to support identification of
devices needing an upgrade.
o 179: Performance Exceeded: Indicates a frame was discarded due to
performance problems such as a buffer overflow.
o 180-254: Available for allocation by IETF Review
o 255: Reserved for Private Experimentation
7. Type, Length, Value (TLV) Encodings
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 may be ignored and skipped over. The value
Bond & Manral Expires April 30, 2012 [Page 20]
Internet-Draft RBridges: OAM Support October 2011
field is 1 byte aligned.
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Total Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. TLV List .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
TLVs Format
Figure 6
Each TLV in the TLV List appears on the wire encoded as follows:
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. Value .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
TLV Format
Figure 7
The type values are:
o 0: Next Hop Nickname, See Section 7.1
o 1: Outgoing Port ID, See Section 7.3
o 2: Incoming Port ID, See Section 7.2
o 3: Outgoing Port MTU, See Section 7.4
o 4: IS-IS System ID, See Section 7.5
Bond & Manral Expires April 30, 2012 [Page 21]
Internet-Draft RBridges: OAM Support October 2011
o 5-253: Available for allocation by IETF Review
o 254: Reserved for Private Use
o 255: Reserved
7.1. Next Hop Nickname
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Next Hop Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Next Hop Nickname Format
Figure 8
For traceroutes targeting known unicast destinations, hop-count
errors, and MTU errors, this TLV MUST be a 16-bit nickname of the
next hop RBridge the frame is being or would have been sent to. If
the RBridge transmitting the TLV is the egress RBridge this field
MUST be set to 0x0000. For traceroutes targeting multi-destination
destinations, e.g. with the TRILL M bit high, this field contains a
nickname of the RBridge the frame being responded to is from. For
pings, this field MUST be set to all zeros on transmission and
ignored on reception. For multi-destination hop-count errors this
field contains a nickname of the RBridge the frame with the exceeded
hop-count was sent from. For multi-destination MTU error traffic,
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 Nickname TLV.
Bond & Manral Expires April 30, 2012 [Page 22]
Internet-Draft RBridges: OAM Support October 2011
7.2. Incoming Port ID
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x01 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Incoming Port ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Incoming Port ID Format
Figure 9
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 [RFC6326].
7.3. Outgoing Port ID
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Outgoing Port ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Outgoing Port ID Format
Figure 10
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) [RFC6326]. If
the request was consumed by the replying RBridge, the port ID MUST be
0xFFFF.
Bond & Manral Expires April 30, 2012 [Page 23]
Internet-Draft RBridges: OAM Support October 2011
7.4. Outgoing Port MTU
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x03 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x02 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Outgoing Port MTU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Outgoing Port MTU Format
Figure 11
This TLV MUST be the MTU of the outgoing port specified in the
outgoing port ID TLV.
7.5. IS-IS System ID
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type = 0x04 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Length = 0x06 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| IS-IS System ID |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
IS-IS System ID Format
Figure 12
This TLV MUST include the IS-IS System ID of the system generating
the message. This TLV MAY be included in all/any error messages.
8. Acknowledgments
Many people have contributed to this work, including the following,
in alphabetic order: Sam Aldrin, Dinesh Dutt, Donald E. Eastlake 3rd,
Anoop Ghanwani, Jeff Laird, Marc Sklar, and Li Yizhou.
Bond & Manral Expires April 30, 2012 [Page 24]
Internet-Draft RBridges: OAM Support October 2011
9. IANA Considerations
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 Section 6.2.1. Additional values are allocated by IETF
Review [RFC5226].
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 [RFC5226].
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 Section 5.1.
10. Security Considerations
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.
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.
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.
Another security threat is denial of service through use of OAM
messages. For this reason, RBridges MUST rate limit the generation
Bond & Manral Expires April 30, 2012 [Page 25]
Internet-Draft RBridges: OAM Support October 2011
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.
11. References
11.1. Normative References
[RBridgeChannel] Eastlake, D., Manral, V., Yizhou, L., Aldrin, S.,
and D. Ward, "RBridges: TRILL RBridge Channel
Support", draft-ietf-trill-rbridge-channel-02 (work
in progress), July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R.,
Romascanu, D., and S. Mansfield, "Guidelines for
the Use of the "OAM" Acronym in the IETF", BCP 161,
RFC 6291, June 2011.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and
A. Ghanwani, "Routing Bridges (RBridges): Base
Protocol Specification", RFC 6325, July 2011.
11.2. Informative References
[IEEE.802-1ag] Institute of Electrical and Electronics Engineers,
"IEEE Stadard for Local and metropolitian area
networks / Virtual Bridged Local Area Networks /
Connectivity Fault Management", IEEE Standard
802.1Q, December 2007.
[IS-IS] International Organization for Standardization,
"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)", ISO/IEC 10589:2002, Second
Edition, Nov 2002.
[RBridgeMIB] Rijhsinghani, A. and K. Zebrose, "Definitions of
Managed Objects for RBridges",
draft-ietf-trill-rbridge-mib-04 (work in progress),
October 2011.
[RFC0792] Postel, J., "Internet Control Message Protocol",
Bond & Manral Expires April 30, 2012 [Page 26]
Internet-Draft RBridges: OAM Support October 2011
STD 5, RFC 792, September 1981.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and
JR. Rivers, "Extending ICMP for Interface and Next-
Hop Identification", RFC 5837, April 2010.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for
Layer-2 Systems", RFC 6165, April 2011.
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R.,
and A. Ghanwani, "Transparent Interconnection of
Lots of Links (TRILL) Use of IS-IS", RFC 6326,
July 2011.
Appendix A. Implementation Considerations
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.
First, an RBridge SHOULD maintain counters for each type of error
generated. There SHOULD be a way for users to view these counters.
Some of the set of default field values for self originated frames
are presented in Table 2. RBridges SHOULD be configurable to change
these values to assign the TRILL data frame to a flow.
A.1. Hop Count Traceroute Example
Figure 13 contains a campus with three RBridges. Consider a hop-
count traceroute from RB0 to RB2.
Bond & Manral Expires April 30, 2012 [Page 27]
Internet-Draft RBridges: OAM Support October 2011
+-----+ +-------+ +-------+ +-------+ +-----+
| ESa +--+ RB0 +---+ RB1 +---+ RB2 +--+ ESb |
+-----+ |ingress| |transit| |egress | +-----+
+-------+ +-------+ +-------+
Time RB0 RB1 RB2
. (1)-------> | |
. | <------- (2) |
. (3)-------> (3) -------> |
. | <------- (4) <-------(4)
Hop Count Traceroute Example Topology
Figure 13
In this diagram RB0 transmits frame (1) destined to RB2. This frame
contains the echo request message and a hop-count of 1. 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 2. RB1 decrements this hop-count by 1 to 1 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.
Below are some select fields for the frames:
+-------+----------+----------+----------------+----------+---------+
| Frame | Ingress | Egress | TRILL OAM | Sequence | Hop |
| # | RBridge | RBridge | Protocol | Number | Count |
+-------+----------+----------+----------------+----------+---------+
+-------+----------+----------+----------------+----------+---------+
| (1) | RB0 | RB2 | Echo Request | 1 | 1 |
+-------+----------+----------+----------------+----------+---------+
| (2) | RB1 | RB0 | Hop Count Zero | 1 | Default |
| | | | error | | |
| | | | notification | | |
+-------+----------+----------+----------------+----------+---------+
| (3) @ | RB0 | RB2 | Echo Request | 2 | 2 |
| RB1 | | | | | |
+-------+----------+----------+----------------+----------+---------+
| (3) @ | RB0 | RB2 | Echo Request | 2 | 1 |
| RB2 | | | | | |
+-------+----------+----------+----------------+----------+---------+
| (4) @ | RB2 | RB0 | Hop Count Zero | 2 | Default |
| RB1 | | | error | | |
| | | | notification | | |
+-------+----------+----------+----------------+----------+---------+
Bond & Manral Expires April 30, 2012 [Page 28]
Internet-Draft RBridges: OAM Support October 2011
+-------+----------+----------+----------------+----------+---------+
| (4) @ | RB2 | RB0 | Hop Count Zero | 2 | Default |
| RB0 | | | error | | |
| | | | notification | | |
+-------+----------+----------+----------------+----------+---------+
Table 3: Hop Count Traceroute Example Frames
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:
Hop Count Tracing
RBridge Incoming Port Id Outgoing Port Id RBridge Nexthop Nickname
------- ---------------- ---------------- ------------------------
0x1111 0xFFFF 0x0001 0x2222
0x2222 0x0000 0x0001 0x3333
0x3333 0x0000 0xFFFF 0x0000
Table 4: Hop Count Traceroute Example Output
In this example, the first line of output is generated from local
information, no hop-count frames are sent to generate it.
A.2. Ping Example
Figure 14 contains a campus with three RBridges. Consider a ping
from RB0 to RB2.
+-----+ +-------+ +-------+ +-------+ +-----+
| ESa +--+ RB0 +---+ RB1 +---+ RB2 +--+ ESb |
+-----+ |ingress| |transit| |egress | +-----+
+-------+ +-------+ +-------+
Time RB0 RB1 RB2
. (1)-------> (1) -------> |
. | <------- (2) <-------(2)
Ping Example Topology
Figure 14
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
Bond & Manral Expires April 30, 2012 [Page 29]
Internet-Draft RBridges: OAM Support October 2011
echo reply frame (2) destined to RB0. RB1 receives this frame and
forwards it to RB0.
Below are some select fields for the frames:
+--------+-------------+-------------+---------------+--------------+
| Frame | Ingress | Egress | TRILL OAM | Sequence |
| # | RBridge | RBridge | Protocol | Number |
+--------+-------------+-------------+---------------+--------------+
+--------+-------------+-------------+---------------+--------------+
| (1) | RB0 | RB2 | Echo Request | 1 |
+--------+-------------+-------------+---------------+--------------+
| (2) | RB2 | RB0 | Echo Reply | 1 |
+--------+-------------+-------------+---------------+--------------+
Table 5: Ping Example Frames
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:
Pinging
--------------------------------------------
... from 0x1111 to 0x3333... 0x3333 is alive
... from 0x1111 to 0x3333... 0x3333 is alive
... from 0x1111 to 0x3333... 0x3333 is alive
Table 6: Ping Example Output
In this example, the ping was repeated three times with the sequence
number (not shown) being changed each time.
Appendix B. Revision History
RFC Editor: Please delete this appendix before publication.
B.1. Changes from -00 to -01
Broke down the table "frame field values" into two tables,
"response frame field values" and "self initiated frame field
values".
Reorganized the document to move user interface related items to
the appendix and switched the order of ping/traceroute.
Numerous minor typo corrections and wording clarifications.
Bond & Manral Expires April 30, 2012 [Page 30]
Internet-Draft RBridges: OAM Support October 2011
Authors' Addresses
David Michael Bond
International Business Machines
2051 Mission College Blvd.
Santa Clara, CA 95054
US
Phone: +1-603-339-7575
EMail: mokon@mokon.net
URI: http://mokon.net
Vishwas Manral
Hewlett-Packard Co.
19111 Pruneridge Ave.
Cupertino, CA 95014
US
Phone: +1-408-447-0000
EMail: vishwas.manral@hp.com
Bond & Manral Expires April 30, 2012 [Page 31]