TRILL Fault Management
draft-tissa-trill-oam-fm-00
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 "Replaced".
|
|
|---|---|---|---|
| Authors | Tissa Senevirathne , Samer Salam , Deepak Kumar , Donald E. Eastlake 3rd , Sam Aldrin | ||
| Last updated | 2012-09-07 | ||
| Replaced by | draft-ietf-trill-oam-fm, RFC 7455 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tissa-trill-oam-fm-00
TRILL Working Group Tissa Senevirathne
Internet Draft Samer Salam
Intended status: Standard Track Deepak Kumar
CISCO
Donald Eastlake
Sam Aldrin
YiZhou Li
Huawei
September 7, 2012
Expires: March 2013
TRILL Fault Management
draft-tissa-trill-oam-fm-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 7, 2009.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Senevirathne Expires March 7, 2013 [Page 1]
Internet-Draft TRILL Fault Management September 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
In this document we present definitions of TRILL OAM messages.
Messages defined in this document follow a similar structure to IEEE
802.1ag messages.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. General Format of TRILL OAM frames.............................4
3.1. Identification of TRILL OAM frames........................6
3.2. Use of TRILL OAM Flag.....................................6
3.2.1. Handling of TRILL frames with F flag.................7
3.3. Backwards Compatibility Method............................8
3.4. OAM Capability Announcement...............................8
4. TRILL OAM Message Channel......................................9
4.1. TRILL OAM Message header..................................9
4.2. TRILL OAM Opcodes........................................10
4.3. Format of TRILL OAM TLV..................................11
4.4. TRILL OAM TLVs...........................................12
4.4.1. Common TLVs between 802.1ag and TRILL...............12
4.4.2. TRILL OAM Specific TLVs.............................12
4.4.2.1. TRILL OAM Application Identifier TLV...........12
4.4.3. Out Of Band IP Address TLV..........................14
4.4.3.1. Diagnostics VLAN TLV...........................14
4.4.3.2. Original Data Payload TLV......................15
4.4.3.3. RBridge scope TLV..............................15
4.4.3.4. Upstream RBridge nickname TLV..................16
4.4.3.5. Next Hop RBridge List TLV......................17
4.4.3.6. Multicast Receiver Availability TLV............17
5. Loopback Message..............................................18
5.1.1. Loopback OAM Message format.........................18
5.1.2. Theory of Operation.................................19
5.1.2.1. Originator RBridge.............................19
5.1.2.2. Intermediate RBridge...........................19
5.1.2.3. Destination RBridge............................19
6. Path Trace Message............................................20
Senevirathne Expires March 7, 2013 [Page 2]
Internet-Draft TRILL Fault Management September 2012
6.1.1. Theory of Operation.................................21
6.1.1.1. Originator RBridge.............................21
6.1.1.2. Intermediate RBridge...........................21
6.1.1.3. Destination RBridge............................22
7. Multicast Tree Verification (MTV) Message.....................22
7.1. Multicast Tree Verification (MTV) OAM Message Format.....23
7.2. Theory of Operation......................................23
7.2.1. Originator RBridge..................................23
7.2.2. Receiving RBridge...................................24
7.2.3. In scope RBridges...................................25
8. Notification Messages.........................................25
9. Return Codes..................................................26
9.1. Return Codes.............................................26
9.2. Return sub-codes.........................................26
10. Security Considerations......................................27
11. Allocation Considerations....................................27
12. References...................................................27
12.1. Normative References....................................27
12.2. Informative References..................................27
13. Acknowledgments..............................................28
1. Introduction
The general structure of TRILL OAM messages is presented in
[TRLOAMFRM]. According to [TRLOAMFRM], TRILL OAM messages consist of
four main parts: link header, TRILL header, flow entropy, and OAM
message channel.
The OAM message channel allows defining various control information
and carrying OAM related data between TRILL switches, also known as
RBridges or Routing Bridges.
The OAM message channel, if defined properly, can be shared between
different technologies. A common OAM channel allows a uniform user
experience for the customers, savings on operator training, re-use
of software code base, and faster time to market.
This document uses the message format defined in IEEE 802.1ag
Connectivity Fault Management (CFM) [802.1ag] [802.1Q] as the basis
for the TRILL OAM channel message.
The ITU-T Y.1731 standard utilizes the same messaging format as
[802.1ag]. However, IEEE defines a separate op-code space for the
messages specific to Y.1731. This document specifies asimilar
approach for TRILL and request a separate code space to be assigned
for TRILL OAM messages.
Senevirathne Expires March 7, 2013 [Page 3]
Internet-Draft TRILL Fault Management September 2012
2. Conventions used in this document
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].
Acronyms used in the document include the following:
MP - Maintenance Point [TRLOAMFRM]
OAM - Operations, Administration, and Maintenance [RFC6291]
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
3. General Format of TRILL OAM frames
The TRILL forwarding paradigm allows an implementation to select a
path from a set of equal cost paths to forward a packet. Selection
of the path of choice is implementation dependent. However, it is a
common practice to utilize Layer 2 through Layer 4 information in
the frame payload for path selection.
For accurate monitoring and/or diagnostics, OAM Messages are
required to follow the exact path as the data packets. [TRILLOAMFM]
proposes a high-level format of the OAM messages. The details of the
TRILL OAM frame format are defined in this document.
Senevirathne Expires March 7, 2013 [Page 4]
Internet-Draft TRILL Fault Management September 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . (variable)
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 8 bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . 128 bytes
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Ether Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Frame format of OAM Messages
Link Header: Media dependent header. For Ethernet this included
Destination MAC, Source MAC, VLAN (optional) and EtherType fields.
TRILL Header: Minimum of 8 bytes when the Extended Header is not
included [RFC6325]
Flow Entropy: This is a 128-byte Fixed size opaque field. The least
significant bits of the field MUST be padded with zeros up to 128
bytes, when the flow entropy is less than 128 bytes. Flow entropy
enables emulation of the forwarding behavior of the desired data
packets.
OAM Ether Type: OAM Ether Type is 16-bit EtherType that identifies
the OAM Message channel that follows. This document specifies to use
EtherType allocated for 802.1ag for the purpose. Identifying the OAM
Message Channel with a dedicated EtherType allows the easy
identification of the beginning of the OAM message channel across
multiple Ethernet standards.
Senevirathne Expires March 7, 2013 [Page 5]
Internet-Draft TRILL Fault Management September 2012
OAM Message Channel: This is a variable size section that carries
OAM related information. Reusing existing OAM message definitions
such as [RFC4379] and [8021ag] will be explored.
3.1. Identification of TRILL OAM frames
TRILL, as defined in [RFC6325], does not have a specific flag or a
method to identify OAM related frames. This document specifies to
update RFC6325 to include specific methods to identify TRILL OAM
frames. Section 3.2. 3.2. below explains the details of the method.
However, it is important, for backwards compatibility reasons, to
define methods to identify TRILL OAM frames without using the
extensions. Section 3.3. presents a set of possible methods for
identifying OAM frames without using the proposed extensions in
section 3.2. Methods defined in section 3.3. impose limitations on
the construction of the flow entropy of the OAM frames and MUST be
used for backwards compatibility scenarios only.
3.2. Use of TRILL OAM Flag
The TRILL Header, as defined in [RFC6325], has two reserved bits
that are currently unused. RBridges are currently required to ignore
these fields. This document specifies to use the reserved bit next
to Version field in the TRILL header as the OAM flag. OAM flag will
be denoted by 'F'.
Implementations that follow the extension of using the F flag to
identify TRILL OAM frames MUST exclusively use that flag as the
means of identifying OAM frames, as specified in section 3.2.1. The
F flag MUST NOT be utilized for other forwarding decisions such as
selection of ECMP paths etc.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |F|R|M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2 TRILL Header
F (1 bit) - Indicates this is an OAM frame and is subject to
specific handling as specified in this document.
Senevirathne Expires March 7, 2013 [Page 6]
Internet-Draft TRILL Fault Management September 2012
All other fields carry the same meaning as defined in RFC6325.
3.2.1. Handling of TRILL frames with F flag
When a unicast TRILL encapsulated frame is received with the F flag
set, the following processing occurs:
If the egress RBridge nickname is local, the frame MUST be forwarded
to the CPU for further processing and MUST NOT be forwarded out of
the RBridge.
If the egress RBridge nickname is not local, the frame MUST be
forwarded as specified in [RFC6325].
When a multicast TRILL encapsulated frame is received with the F
flag set, the following processing occurs:
A copy of the frame MUST be sent to the CPU for further processing.
Additionally, the frame MUST also be forwarded as specified in
[RFC6325].
A TRILL encapsulated frame with the F flag set MUST NOT be de-
capsulated and forwarded as a native frame.
Receiver Processing:
If (M==1 && F==1) then
Copy to CPU and Forward normally as defined in RFC 6325
Else if (M==0 && F==1 && egress nickname is the processing RBridge)
then
Forward to CPU BUT DO NOT forward along the data plane
Else
Forward as defined in RFC 6325
End;
Transmit Processing:
If (F==1) then
Forward as defined in RFC6325 BUT Do not de-capsulate and forward
as a native frame
Else
Forward as defined in RFC 6325
Figure 3 Pseudo code for F flag processing
Senevirathne Expires March 7, 2013 [Page 7]
Internet-Draft TRILL Fault Management September 2012
3.3. Backwards Compatibility Method
For unicast frames, TRILL MP is addressed by its TRILL egress
nickname and either OAM Inner.MacSA or OAM Ethtype .
For unicast frames, a TRILL MP (Maintenance Point) is addressed by
combination of TRILL nickname of the target TRILL RBridge (where the
MP resides as the egress nickname of the TRILL Header in the TRILL
OAM frame) and either the OAM Inner.MacSA or the OAM Ethertype
For multicast frames, TRILL MP is addressed by either Reserved
EtherType or Reserved source MAC .
The following table summarizes the identification of different OAM
frames from data frames.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Entropy |Inner |OAM Eth |Egress |
| |MacSA |Type |nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|unicast L2 | N/A |Match |Match |
| | | | |
|Multicast L2 | N/A |Match |N/A |
| | | | |
|Unicast IP | Match |N/A |Match |
| | | | |
|Multicast IP | Match |N/A |N/A |
| | | | |
|Notification | N/A |Match |Match |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Identification of TRILL OAM Frames
3.4. OAM Capability Announcement
Any given TRILL RBridge can be one of: OAM incapable OR OAM capable
with new extensions OR OAM capable with backwards compatible method.
The OAM request originator, prior to origination of the request is
required to identify the OAM capability of the target and generate
the appropriate OAM message.
We propose to utilize capability flags defined in TRILL version sub-
TLV (TRILL-VER) [rfc6326bis]. The following Flags are defined:
O - OAM Capable
Senevirathne Expires March 7, 2013 [Page 8]
Internet-Draft TRILL Fault Management September 2012
B - Backwards Compatible.
A capability announcement, with O Flag set to 1 and B flag set to 1,
indicates that the implementation is OAM capable but utilize
backwards compatible method defined in section Error! Reference
source not found.Error! Reference source not found.
A capability announcement, with O Flag set to 1 and B flag set to 0,
indicates that the implementation is OAM capable and utilizes the
method specified in section 3.2.
When O Flag is set to 0, the announcing implementation is considered
not capable of OAM and B flag is ignored.
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
|A|O|B|Other Capabilities and Header Flags| (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
Figure 5 TRILL-VER sub-TLV [rfc6326bis] with O and B flags
4. TRILL OAM Message Channel
The TRILL OAM Message Channel can be divided in to two parts: TRILL
OAM Message header and TRILL OAM Message TLVs. Every OAM Message
MUST contain a single TRILL OAM message header and a set of one or
more specified OAM Message TLVs.
4.1. TRILL OAM Message header
As discussed earlier, we propose to use the Message format defined
in IEEE 802.1ag. We believe a common messaging framework between
[802.1ag], TRILL and other similar standards such as Y.1731 can be
accomplished by re-using the OAM message header defined in [802.1ag]
and [802.1Q].
Senevirathne Expires March 7, 2013 [Page 9]
Internet-Draft TRILL Fault Management September 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Opcode Specific Information .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 OAM Message Format
o MD-L: Maintenance Domain Level (3 bits). Identifies the
maintenance domain level. For TRILL this MAY be always set to
zero. However, in multilevel TRILL [TRILLML], backbone MAY be
of a different MD-LEVEL. (Please refer to [802.1ag] for the
definition of MD-Level)
o Version: Indicates the version (5 bits). [802.1ag] sets the
version to zero.
o Flags: Include operational flags (1 byte). The definition of
flags is Opcode specific and is covered in the applicable
sections.
o FirstTLVOffset: Defines the location of the first TLV, in
bytes, starting from the end of the FirstTLVOffset field (1
byte). (Refer to [802.1ag] for the definition of the
FirstTLVOffset.)
MD-L, Version, Opcode, Flags, FirstTLVOffset, fields collectively
are referred to as the OAM Message Header.
The Opcode specific information section of the OAM Message may
contain Session Identification number, time-stamp, etc. Details
about the Opcode specific information section and the associated
TLVs will be presented later in this document.
4.2. TRILL OAM Opcodes
Following Opcodes are defined for TRILL. Each of the opcodes defines
a separate TRILL OAM message. Details of the messages are presented
in the related sections.
Senevirathne Expires March 7, 2013 [Page 10]
Internet-Draft TRILL Fault Management September 2012
TRILL OAM Message Opcodes:
64 : Loopback Message Reply
65 : Loopback Message
66 : Path Trace Reply
67 : Path Trace Message
68 : Notification Message
69 : Multicast Tree Verification Reply
70 : Multicast Tree Verification Message
71 : Performance Measurement one-way Reply
72 : Performance Measurement one-way Message
73 : Performance Measurement two-way Reply
74 : Performance Measurement two-way Message
75 - 95 : Reserved
4.3. Format of TRILL OAM TLV
We propose to use the same format as defined in section 21.5.1 of
[802.1ag]. The following figure depicts the general format of TRILL
OAM TLV:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value(variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 TRILL OAM TLV
Type (1 octet) : Specifies the Type of the TLV (see sections 4.4.
4.4.1. 4.4.2. for TLV types).
Length (2 octets) : Specifies the length of the values field in
octets. Length of the value field can be either zero or more octets.
Value (variable): Length and the content of the value field depend
on the type of the TLV. Please refer to applicable TLV definitions
for the details.
Semantics and usage of Type values allocated for the TRILL OAM
purpose are defined by this document and other future related
documents.
Senevirathne Expires March 7, 2013 [Page 11]
Internet-Draft TRILL Fault Management September 2012
4.4. TRILL OAM TLVs
In this section we define TRILL related TLVs. We propose to re-use
[802.1ag] defined TLVs where applicable. Types 32-63 are reserved
for ITU-T Y.1731. We propose to reserve Types 64-95 for the purpose
of TRILL OAM TLVs.
4.4.1. Common TLVs between 802.1ag and TRILL
Following TLVs are defined in [802.1ag], we propose to re-use them
where applicable. Format and semantics of the TLVs are as defined in
[802.1g]. NOTE: Presented within brackets is the corresponding Type.
1. End TLV (0)
2. Sender ID TLV (1)
3. Port Status TLV (2)
4. Data TLV (3)
5. Interface Status TLV (4)
6. Reply Ingress TLV (5)
7. Reply Egress TLV (6)
8. LTM Egress Identifier TLV (7)
9. LTR Egress Identifier TLV (8)
10. Reserved (9-30)
11. Organization specific TLV (31)
4.4.2. TRILL OAM Specific TLVs
As indicated above, Types 64-95 will be requested to be reserved for
TRILL OAM purposes. Listed below, a summary of TRILL OAM TLV and the
corresponding codes. Format and semantics of TRILL OAM TLVs are
defined in subsequent sections.
1. TRILL OAM Application Identifier (64)
2. Out of Band IP Address (65)
3. Diagnostic VLAN (66)
4. RBridge scope (67)
5. Original Payload (68)
6. Upstream RBridge nickname(69)
7. TRILL Next Hop RBridge List (ECMP) (70)
8. Multicast Receiver Availability (71)
9. Reserved (71-95)
4.4.2.1. TRILL OAM Application Identifier TLV
TRILL OAM Application Identifier TLV carries TRILL OAM application
specific information. The TRILL OAM Application Identifier TLV MUST
always be present and MUST be the first TLV in TRILL OAM messages.
Messages that do not include the TRILL OAM Application Identifier
TLV as the first TLV MUST be discarded.
Senevirathne Expires March 7, 2013 [Page 12]
Internet-Draft TRILL Fault Management September 2012
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |Return sub-code| Reserved |F|C|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 TRILL OAM Message TLV
Type (1 octet) = 64 indicate that this is the TRILL OAM Version
Length (2 octets) = 6
Version (1 Octet), currently set to zero. Indicates the TRILL OAM
version. TRILL OAM version can be different than the [802.1ag]
version.
Return Code (1 Octet): Set to zero on requests. Set to an
appropriate value in response or notification messages. Please see
section x below for definition of return codes.
Return sub-code (1 Octet): Return sub-code is set to zero on
transmission of request message. Return sub-code identifies
categories within a specific Return code. Return sub-code MUST be
interpreted within a Return code and specified in section x below.
Reserved: set to zero on transmission and ignored on reception.
F (1 bit) : Final flag, when set, indicates this is the last
response.
C (1 bit ): Cross connect error (VLAN mapping error), if set
indicates VLAN cross connect error detected. This field is ignored
in request messages and MUST only be interpreted in response
messages.
O (1 bit) : If set, indicates, OAM out-of-band response requested.
I (1 bit) : If set, indicates, OAM in-band response requested.
NOTE: When both O and I bits are set to zero, indicates that no
response is required (silent mode). User MAY specify both O and I or
one of them or none.
Senevirathne Expires March 7, 2013 [Page 13]
Internet-Draft TRILL Fault Management September 2012
4.4.3. Out Of Band IP Address TLV
Out of Band IP Address TLV specifies the IP address to which an out
of band OAM reply message MUST be sent. When O bit in the Version
TLV is not set, Out of Band IP Address TLV is ignored. Length of the
TLV implies the IP Address version.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IP Address .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Out of Band IP Address TLV
Type (1 octet) = 64 indicate that this is the TRILL OAM Version
Length (2 octets) = 5 or 17. Length Value 5 indicates it is IPv4
address and Length value of 17 indicates that it is IPv6 address.
IP Address (4 or 16 octets), valid IP address.
4.4.3.1. Diagnostics VLAN TLV
Diagnostic VLAN specifies the VLAN in which the OAM messages are
generated. Receiving RBridge MUST compare the inner.VLAN of the Flow
entropy to the VLAN specified in the Diagnostic VLAN TLV. Cross
connect Flag in the response MUST be set when the two VLANs do not
match.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | L-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label(VLAN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 Diagnostic VLAN TLV
Senevirathne Expires March 7, 2013 [Page 14]
Internet-Draft TRILL Fault Management September 2012
Type (1 octet) = 65 indicates that this is the TRILL Diagnostic
VLAN TLV
Length (2 octets) = 5
L-Type (Label type, 1 octet)
0- indicate 802.1Q 12 bit VLAN.
1 - indicate TRILL 24 bit fine grain label
Label (24 bits): Either 12 bit VLAN or 24 bit fine grain label.
NOTE: TRILL Operate above the MAC Layer of IEEE 802.1 architecture.
Hence it is safe to assume there is no VLAN translation
functionality on the inner payload by intermediate RBridges.
4.4.3.2. Original Data Payload TLV
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Original Payload .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 Out of Band IP Address TLV
Length (2 octets) = variable
4.4.3.3. RBridge scope TLV
RBridge scope TLV identifies nicknames of RBridges from which a
response is required. RBridge scope TLV only applicable to Multicast
Tree Verification messages. This TLV SHOULD NOT be included in other
messages. Receiving RBridges MUST ignore this TLV on messages other
than Multicast Verification Message.
Each TLV can contain up to 255 nicknames of in scope RBridges. A
Multicast Verification Message may contain multiples of "RBridge
scope TLVs", in the event more than 255 in scope RBridges needed to
be specified.
Absence of the "RBridge scope TLV" indicates, response is needed
from all the RBridges. Please see section 7. for details.
Senevirathne Expires March 7, 2013 [Page 15]
Internet-Draft TRILL Fault Management September 2012
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nickname-1 | nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 RBridge Scope TLV
Type (1 octet) = 67 indicates that this is the "RBridge scope TLV"
Length (2 octets) = variable. Minimum value is 2.
Nickname (2 octets) = 16 bit RBridge nickname.
4.4.3.4. Upstream RBridge nickname TLV
"Upstream RBridge nickname TLV" identifies nickname or nicknames of
the upstream RBridge. [RFC6325] allow a given RBridge to announce
multiple nicknames.
"Upstream RBridge nickname TLV" is an optional TLV. Multiple of this
TLV MAY be included when an upstream RBridge is represeneted by more
than 255 nicknames.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nickname-1 | nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 Upstream RBridge nickname TLV
Type (1 octet) = 69 indicates that this is the "Upstream RBridge
nickname"
Length (2 octets) = variable. Minimum value is 2.
Senevirathne Expires March 7, 2013 [Page 16]
Internet-Draft TRILL Fault Management September 2012
Nickname (2 octets) = 16 bit RBridge nickname.
4.4.3.5. Next Hop RBridge List TLV
"Next Hop RBridge List TLV" identifies nickname or nicknames of the
downstream next hop RBridges. [RFC6325] allows a given RBridge to
have mulriple Equal Cost Multi paths to a specified destination.
"Next Hop RBridge List TLV" is an optional TLV. Multiple of this TLV
MAY be included when there are more than 255 Equal Cost Paths to the
destination.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nickname-1 | nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 Next Hop RBridge List TLV
Type (1 octet) = 69 indicates that this is the "Next nickname"
Length (2 octets) = variable. Minimum value is 2.
Nickname (2 octets) = 16 bit RBridge nickname.
4.4.3.6. Multicast Receiver Availability TLV
"Multicast Receiver Availability TLV" identifies the number of
available multicast receivers available on the responding RBridge on
the VLAN specified by the Diagnostic VLAN TLV.
Multicast Receiver Availability is an Optional TLV.
Senevirathne Expires March 7, 2013 [Page 17]
Internet-Draft TRILL Fault Management September 2012
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of Receivers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 Multicast Receiver Availability TLV
Type (1 octet) = 71 indicates that this is the "Multicast
Availability TLV"
Length (2 octets) = 5.
Number if Receivers (4 octets) = Indicates number of Multicast
receivers available on the responding RBridge on the VLAN specified
by the diagnostic VLAN.
5. Loopback Message
Loopback message is utilized for fault verification. It verifies
connectivity between two RBridges, for a specified flow.
Additionally, Loopback Message may be utilized for connectivity
monitoring and proactive fault detection.
5.1.1. Loopback OAM Message format
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identification Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 Loopback OAM Message Format
The above figure depicts the format of the Loopback Request and
response messages. Opcode for Loopback Message is set to 65 and
Opcode of Reply Message is set to 64. Session Identification Number
is a 32 bit integer that allows the requesting RBridge to uniquely
Senevirathne Expires March 7, 2013 [Page 18]
Internet-Draft TRILL Fault Management September 2012
identify the corresponding session. Responding RBridges, MUST echo
the received "Session Identification" number without modification.
5.1.2. Theory of Operation
5.1.2.1. Originator RBridge
Originator RBridge Identifies the destination RBridge nickname based
on user specification or based on location of the specified
destination inner MAC address.
Construct the flow entropy based on user specified parameters or
implementation specific default parameters.
Construct the TRILL OAM header: Set the opcode to Loopback message
type (65). Assign applicable Session Identification number for the
request.
TRILL OAM Version TLV MUST be included and set the flags to
applicable values.
Include following OAM TLVs, where applicable
o Out-of-band IP address TLV
o Diagnostic VLAN TLV
o Sender ID TLV
Specify the Hop count of the TRILL data frame per user specification
or utilize an applicable Hop count value.
Dispatch the OAM frame to the TRILL data plane for transmission.
RBridge may continue to retransmit the request at periodic
intervals, until a response is received or the re-transmission count
expires. At each transmission Session Identification number MUST be
incremented.
5.1.2.2. Intermediate RBridge
Intermediate RBridges forward the frame as a normal data frame and
no special handling is required.
5.1.2.3. Destination RBridge
If the Loopback message is addressed to the local RBridge and
satisfies OAM identification methods specified in sections Error!
Senevirathne Expires March 7, 2013 [Page 19]
Internet-Draft TRILL Fault Management September 2012
Reference source not found.or 3.2. then the RBridge data plane
forwards the message to the CPU for further processing.
TRILL OAM application layer further validates the received OAM frame
by examining the presence of OAM-Ethertype at the end of the flow
entropy. Frames that do not contain OAM-Ethertype at the end of the
flow entropy MUST be discarded.
Construction of the TRILL OAM response:
TRILL OAM application encodes the received TRILL header and flow
entropy in the Original payload TLV and includes it in the OAM
message.
Set the Return Code and Return sub code to applicable values. Update
the TRILL OAM opcode to 64 (Loopback Message Reply)
If the VLAN identifier value of the flow entropy differs from the
value specified in the diagnostic VLAN, set the Cross connect Flag
on TRILL OAM Application Identifier TLV.
Include the sender ID TLV (1)
If in-band response was requested, dispatch the frame to the TRILL
data plane with request-originator RBRidge nickname as the egress
RBridge nickname.
If out-of-band response was requested, dispatch the frame to the
standard IP forwarding process.
6. Path Trace Message
The Path Trace Message has the same format as Loopback Message.
Opcode for Path Trace Reply Message is 66 and Request 67.
Primary use of Path Trace Message is fault isolation. It may also be
used for plotting path taken from a given RBridge to another
RBridge. Operation of Path Trace message is identical to Loopback
message except, that it is first transmitted with a TRILL Hop count
field value of 1. Sending RBridge expects a Time Expiry Return-Code
from the next hop or a successful response. If a Time Expiry Return-
code is received as the response, the originator RBridge records the
information received from intermediate node that generated the Time
Expiry message and resends the message by incrementing the previous
Hop count value by 1. This process is continued until, a response is
received from the destination RBridge or Path Trace process timeout
occur or Hop count reaches a configured maximum value.
Senevirathne Expires March 7, 2013 [Page 20]
Internet-Draft TRILL Fault Management September 2012
6.1.1. Theory of Operation
6.1.1.1. Originator RBridge
Identify the destination RBridge based on user specification or
based on location of the specified MAC address.
Construct the flow entropy based on user specified parameters or
implementation specific default parameters.
Construct the TRILL OAM header: Set the opcode to Path Trace Request
message type (67). Assign applicable Session Identification number
for the request. Return-code and sub-code MUST be set to zero.
TRILL OAM Application Identifier TLV MUST be included and set the
flags to applicable values.
Include following OAM TLVs, where applicable
o Out-of-band IP address TLV
o Diagnostic VLAN TLV
o Include the Sender ID TLV
Specify the Hop count of the TRILL data frame as 1 for the first
request.
Dispatch the OAM frame to the TRILL data plane for transmission.
RBridge may continue to retransmit the request at periodic interval,
until a response received or re-transmission count expires. At each
new re-transmission Session Identification number MUST be
incremented. Additionally for responses received from intermediate
RBridges, RBridge nickname and interface information may be
recorded.
6.1.1.2. Intermediate RBridge
Intermediate RBridge receive the Path Trace Messages as Hop count
expired frame.
TRILL OAM application layer further validates the received OAM frame
by examining the presence of OAM-Ethertype at the end of the flow
entropy. Frames that do not contain OAM-Ethertype at the end of the
flow entropy MUST be discarded.
Senevirathne Expires March 7, 2013 [Page 21]
Internet-Draft TRILL Fault Management September 2012
Construction of the TRILL OAM response:
TRILL OAM application encodes the received TRILL header and flow
entropy in the Original payload TLV and include in the OAM message.
Set the Return Code to (2) "Time Expired" and Return sub code to
zero (0). Update the TRILL OAM opcode to 66 (Path Trace Message
Reply).
If the VLAN identifier value of the flow entropy differs from the
value specified in the diagnostic VLAN, set the Cross connect Flag
on TRILL OAM Application Identifier TLV.
Include following TLVs
Upstream RBridge nickname TLV (69)
Reply Ingress TLV (5)
Interface Status TLV (4)
TRILL Next Hop RBridge (Repeat for each ECMP) (70)
Sender ID TLV (1)
If VLAN cross connect error detected, set C flag (Cross connect
error detected) in the version.
If in-band response was requested, dispatch the frame to the TRILL
data plane with request-originator RBRidge nickname as the egress
RBridge nickname.
If out-of-band response was requested, dispatch the frame to the
standard IP forwarding process.
6.1.1.3. Destination RBridge
Processing is identical to section 5.1.2.3. With the exception that
TRILL OAM Opcode is set to Path Trace Reply (66).
7. Multicast Tree Verification (MTV) Message
Multicast Tree Verification messages allow verifying multicast tree
integrity and Multicast address pruning. IGMP snooping is widely
deployed in Layer 2 networks for restricting the forwarding of
multicast traffic to unwanted destinations. This is accomplished by
pruning the multicast tree such that for specified (S,G,VLAN) or
(*,G,VLAN), only required destinations are included in the outgoing
interface list. It is possible due to timing or implementation
Senevirathne Expires March 7, 2013 [Page 22]
Internet-Draft TRILL Fault Management September 2012
defects, inaccurate pruning of multicast tree, may occur. Such
events lead to incorrect multicast connectivity. Multicast tree
verification and Multicast group verification messages are design to
detect such multicast connectivity defects. Additionally, these
tools can be used for plotting a given multicast tree within the
TRILL campus.
Multicast tree verification OAM frames are copied to the CPU of
every intermediate RBridge that are part of the Multicast tree being
verified. Originator of the Multicast Tree verification message,
specify the scope of RBridges that a response is required. Only, the
RBridges listed in the scope field respond to the request. Other
RBridges silently discard the request. Definition of scope parameter
is required to prevent receiving large number of responses. Typical
scenario of multicast tree verification or group verification
involves verifying multicast connectivity to selected set of end-
nodes as opposed to the entire network. Availability of the scope,
facilitate narrowing down the focus only to the interested RBridges.
Implementations MAY choose to rate limit CPU bound multicast
traffic. As result of rate limiting or due to other congestion
conditions, MTV messages may be discarded from time to time by the
intermediate RBRidges and requester may be required to retransmit
the request. Implementations SHOULD narrow the embedded scope of
retransmission request only to RBRidges that has failed to respond.
7.1. Multicast Tree Verification (MTV) OAM Message Format
Format of MTV OAM Message format is identical to that of Loopback
Message format defined in section 5.1.1.
7.2. Theory of Operation
7.2.1. Originator RBridge
User is required at minimum to specify either the multicast trees
that needed to be verified or Multicast MAC address and VLAN or VLAN
and Multicast destination IP address. Alternatively, for more
specific multicast flow verification, user MAY specify more
information e.g. source MAC address, VLAN, Destination and Source IP
addresses. Implementation, at minimum, must allow user to specify,
choice of multicast trees, Destination Multicast MAC address and
VLAN that needed to be verified. Although, it is not mandatory, it
is highly desired to provide option to specify the scope. It should
be noted source MAC address and some other parameters may not be
specified if the Backwards Compatibility Method of section 3.2 is
used to identify the OAM frames.
Senevirathne Expires March 7, 2013 [Page 23]
Internet-Draft TRILL Fault Management September 2012
Default parameters MUST be used for unspecified parameters. Flow
entropy is constructed based on user specified parameters and/or
default parameters.
Based on user specified parameters, originating RBridge identify the
nickname that represent the multicast tree.
Obtain the applicable Hop count value for the selected multicast
tree.
Construct TRILL OAM message header and include Session
Identification number. Session Identification number facilitate the
originator to map the response to the correct request.
TRILL OAM Application Identifier TLV MUST be included.
Op-Code MUST be specified as Multicast Tree Verification Message
(70)
Include RBridge scope TLV (67)
Optionally, include following TLV, where applicable
o Out-of-band IP address
o Diagnostic VLAN
o Sender ID TLV (1)
Specify the Hop count of the TRILL data frame per user
specification. Or utilize the applicable Hop count value, if TRILL
Hop count is not being specified by the user.
Dispatch the OAM frame to the TRILL data plane for transmission.
RBridge may continue to retransmit, the request at a periodic
interval, until a response received or re-transmission count
expires. At each new re-transmission Session Identification number
MUS be incremented. At each re-transmission, RBridge may further
reduce the scope to the RBridges it has not received a response.
7.2.2. Receiving RBridge
Receiving RBridges identify multicast verification frames per the
procedure explained in either section Error! Reference source not
found.or section 3.2.
CPU of the RBridge validates the frame and analyzes the scope
RBridge list. If the RBrdige scope TLV is present and the local
Senevirathne Expires March 7, 2013 [Page 24]
Internet-Draft TRILL Fault Management September 2012
RBridge nickname is not specified in the scope list, it will
silently discard the frame. If the local RBridge is specified in the
scope list OR RBridge scope TLV is absent the receiving RBridge
proceed for further processing as defined in section 7.2.3.
7.2.3. In scope RBridges
Construction of the TRILL OAM response:
TRILL OAM application encodes the received TRILL header and flow
entropy in the Original payload TLV and include in the OAM message.
Set the Return Code to (0) and Return sub code to zero (0). Update
the TRILL OAM opcode to 69 (Multicast Tree Verification Reply).
Include following TLVs
Upstream RBridge nickname TLV (69)
Reply Ingress TLV (5)
Interface Status TLV (4)
TRILL Next Hop RBridge (Repeat for each downstream RBridge) (70)
Sender ID TLV (1)
Multicast Receiver Availability TLV (71)
If VLAN cross connect error detected, set C flag (Cross connect
error detected) in the version.
If in-band response was requested, dispatch the frame to the TRILL
data plane with request-originator RBRidge nickname as the egress
RBridge nickname.
If out-of-band response was requested, dispatch the frame to the
standard IP forwarding process.
8. Notification Messages
TRILL OAM Notification message format is depicted in following
figure.
Senevirathne Expires March 7, 2013 [Page 25]
Internet-Draft TRILL Fault Management September 2012
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 Notification OAM Message Format
The opcode of the Notification message is 68. Notification messages
may be generated for variety of errors, warning and informational
purposes. Notification messages are almost always asynchronous.
Hence there is no Session Identification.
TRILL OAM Application Identifier TLV, which is mandatory, MUST be
the first TLV. Return Code and Return sub-code in TRILL OAM version
TLV MSUT be set to appropriate value.
9. Return Codes
9.1. Return Codes
Following Return codes are currently defined. These return codes are
the initial content of registry setup by IANA. Future allocations
are administered by IANA.
0: Success
1: Egress RBridge Nickname unknown
2: Time Expired
3: VLAN Unknown
4: Parameter Problem
5-255: Reserved
9.2. Return sub-codes
For all of the above Return codes, sub-code zero (0) indicates no
Return-sub code included.
Currently all other values are reserved and MUST NOT be included
unless otherwise specified by IETF publication and registered in
IANA.
Senevirathne Expires March 7, 2013 [Page 26]
Internet-Draft TRILL Fault Management September 2012
10. Security Considerations
For general TRILL related security considerations, please refer to
[RFC6325]. Specific security considerations related methods
presented in this document are currently under investigation.
11. Allocation Considerations
10.1 IEEE Allocation Considerations
The IEEE 802.1 Working Group is requested to allocate a separate
opcode and TLV space within 802.1g CFM messages for TRILL purpose.
10.2 IANA Considerations
- Set up sub-registry within the TRILL Parameters registry for block
of TRILL OAM OpCodes -
- Set up sub-registry within the TRILL Parameters registry for TRILL
OAM TLV Types -
- Set up sub-registry within the TRILL Parameters registry for TRILL
OAM return code and return sub codes -
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5:
Connectivity Fault Management", 802.1ag, 2007.
[8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q-2011, August st 31 , 2011.
[TRILLOAMFM] Salam, S., et.al., "TRILL OAM Framework", draft-salam-
trill-oam-framework-02, Work in Progress, September, 2012.
12.2. Informative References
[RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base
Protocol Specification", RFC 6325, July 2011.
Senevirathne Expires March 7, 2013 [Page 27]
Internet-Draft TRILL Fault Management September 2012
[TRILLML] Senevirathne, T., et.al., "Default Nickname Based Approach
for Multi-level TRILL", draft-tissa-trill-multilevel-00,
Work in Progress, February 2012.
[RFC6291] Andersson, L., et.al., "Guidelines for the use of the
"OAM" Acronym in the IETF" RFC 6291, June 2011.
13. Acknowledgments
Work in this document was largely inspired by the directions
provided by Stewart Bryant in finding common OAM solution between
SDO.
This document was prepared using 2-Word-v2.0.template.dot.
Senevirathne Expires March 7, 2013 [Page 28]
Internet-Draft TRILL Fault Management September 2012
Authors' Addresses
Tissa Senevirathne
CISCO Systems
375 East Tasman Drive.
San Jose, CA 95134
USA.
Phone: +1 408-853-2291
Email: tsenevir@cisco.com
Samer Salam
CISCO Systems
595 Burrard St. Suite 2123
Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com
Deepak Kumar
CISCO Systems
510 McCarthy Blvd,
Milpitas, CA 95035, USA
Phone : +1 408-853-9760
Email: dekumar@cisco.com
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Senevirathne Expires March 7, 2013 [Page 29]
Internet-Draft TRILL Fault Management September 2012
Sam Aldrin
Huawei Technologies
2330 Central Express Way
Santa Clara, CA 95951
USA
Email: aldrin.ietf@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Senevirathne Expires March 7, 2013 [Page 30]