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]